3. Questions et réponses

Contenu de cette section

3.1 Qu'est-ce que PPP ?

PPP, ou "Point-to-Point Protocol", est un protocole internet "officiel". Il est destiné à l'échange de paquets IP (ou autre type de réseau) sur une liaison série. Sa description se trouve dans le RFC 1661.

Contrairement à ce que beaucoup de personnes pensent, PPP ne signifie pas du tout "Peer to Peer Processing", bien qu'il soit possible d'effectuer des communications "peer-peer" en utilisant TCP/IP sur une liaison PPP.

3.2 Mon entreprise (université) ne supporte pas PPP. Puis-je l'utiliser ?

En général, non. Une implémentation "classique" de PPP nécessite des modifications aux routages et interfaces réseau du système d'exploitation. Cela peut nécessiter la recompilation du noyau du système distant.

Ce n'est pas une tâche de simple utilisateur. Si vous arrivez à convaincre vos administrateurs système que PPP est une "bonne chose", alors vous aurez une chance de voir ce protocole installé. Si ils sont réfractaires à cette idée, vous ne pourrez probablement pas utiliser PPP.

Malgré tout, si vous utilisez un système qui est supporté par les gens qui vendent "TIA" (The Internet Adapter) il y a un petit espoir. Nous n'avons pas beaucoup d'informations sur ce paquetage, mais nous avons entendu dire qu'ils comptent supporter PPP dans les prochaines versions. (Ces informations sont sans doute très anciennes, contactez-les directement. Vous trouverez des renseignements sur TIA sur ftp.marketplace.com dans le répertoire /pub/tia).

Si votre système n'est pas supporté par TIA et que vous ne pouvez convaincre vos administrateurs de l'utilité de PPP, essayez d'utiliser le paquetage "term". Malgré tout, beaucoup refuseront pour des "raisons de sécurité".

Il existe une version de TIA pour Linux.

3.3 Où et sous quelle forme se trouve PPP ?

Il se décompose en deux parties, dont la première est dans le noyau, incluse depuis Linux 1.1.13.

NE REMPLACEZ PAS LE PILOTE FOURNI AVEC LE NOYAU PAR UNE VERSION TROUVEE DANS LE PAQUETAGE PPPD !!!

La seconde partie est le "démon pppd". Ce programme est INDISPENSABLE, ses sources se trouvent dans le fichier ppp-2.1.2c.tar.gz sur les sites diffusant Linux.

Pour les noyaux de version inférieure à 1.1.13, le pilote nécessaire est inclus dans un sous-répertoire de cette archive. C'est le seul cas où vous deviez utiliser ces fichiers système, mais il est préférable de mettre à jour votre noyau.

3.4 Je viens de récupérer PPP. Quelle est la suite des opérations ?

Lisez la documentation fournie. Elle a été écrite pour vous !

Commencez par lire les fichiers README et README.linux. Diverses autres sources de documentation sont indiquées ci-après.

3.5 Quelles autres documentations sur PPP sont disponibles ?

(Où est la doc ? Où est la FAQ ? etc.)

Il existe plusieurs sources d'information concernant le protocole PPP tel qu'il est implémenté sous Linux.

Le fichier HOWTO peut se télécharger sur les sites habituels diffusant Linux, par exemple sur ftp.ibp.fr dans le répertoire /pub/linux/docs/HOWTO.

Le Network Administration Guide fait partie du projet de documentation Linux, vous trouverez ce livre sous forme électronique au même endroit. Il a été publié par O'Reilly et est disponible en version française, sous le titre "Administration réseau sous Linux". Si vous désirez un document de présentation professionnelle, vous pourrez alors acheter cet ouvrage plutôt que de le télécharger et l'imprimer vous-même.

Les pages de manuel sont fournies avec les sources. Il vous faudra les placer dans les répertoires standard, /usr/man/man8 pour que la commande man puisse les traiter. Vous pouvez bien entendu les examiner directement à l'aide de groff.

La FAQ de PPP décrit le protocole en lui-même et ses diverses implémentations sur différents systèmes. Vous trouverez ce document dans le forum Usenet comp.protocols.ppp, ou encore dans news.answers et il est bien entendu archivé sur rtfm.mit.edu dans le répertoire /usenet. Il est à l'heure actuelle composé de huit parties.

3.6 Où dois-je poser des questions relatives à PPP ?

Il est préférable de les poser dans le groupe comp.protocols.ppp. Il est fait pour cela. Hélas, beaucoup d'utilisateurs ont tendance à exposer d'abord leur problème dans les groupes comp.os.linux.*, dans lesquels ils reçoivent des réponses bien que ce ne soit pas l'endroit idéal.

Très peu de questions sur PPP sont directement liées à son implémentation sous Linux. La plupart des problèmes posés sont d'ordre général, concernent l'utilisation du paquetage PPP et les réponses sont applicables à n'importe quel autre système d'exploitation.

Aussi, pour réduire le trafic dans les groupes Linux, et pour toucher les vrais spécialistes de PPP, si vous devez utiliser Usenet à ce sujet, utilisez absolument le groupe comp.protocols.ppp.

3.7 PPP ne marche pas, pppd se termine après l'appel. SOS !!!

C'est l'une des questions les plus irritantes. Nous nous rendons bien compte que c'est un appel à l'aide, mais il est inutile de poster un tel message SANS AUCUNE AUTRE INFORMATION. La plupart des gens susceptibles de pouvoir vous aider l'ignoreront, purement et simplement.

Il vous faut fournir les traces système (syslog) produites lorsque vous lancez le programme pppd avec l'option debug. De plus, si vous utilisez chat pour l'appel du service, utilisez son option -v pour obtenir un enregistrement du dialogue.

Fournissez également la trace (log) de démarrage de votre noyau Linux. elle informe des différentes configurations propres à votre système, comme la version de PPP, le type de port série, etc.

Enfin, rajoutez toute information que vous pensez relative à votre problème. Bien entendu, votre machine, disques durs, boutons de souris, terminaux, n'ont aucun intérêt... Ce qui compte est surtout le système que vous tentez de contacter, la version de PPP ou de serveur de terminaux qu'il utilise, les types et vitesses des modems de part et d'autre, etc.

Faites attention, éditez soigneusement ces informations, en supprimant éventuellement tout numéro de téléphone, login et mot de passe susceptibles d'apparaître. Ils n'ont aucune utilité pour le déboguage, et les diffuser sur Usenet ne serait pas très malin. Supprimez aussi les lignes qui ne viennent pas du noyeau ou de pppd.

Ne postez jamais intégralement la trace du programme pppd lancé avec l'option kdebug 7 !

Si le problème demande une analyse du flux de données, vous serez contacté par courrier électronique et l'on vous demandera la trace par ce biais. Usenet coûte déjà bien trop cher pour beaucoup de gens.

L'information est écrite sous plusieurs niveaux. Les messages de déboguage sont au niveau debug. Ceux d'information le sont au niveau info, les erreurs au niveau error. Incluez tous les niveaux par le groupe local2, issu du processus pppd.

Enfin, ne supprimez surtout pas les informations horaires, elles sont très importantes.

3.8 Comment utiliser PPP avec un serveur assignant des adresses dynamiques ?

Le serveur m'attribue une adresse IP différente à chaque appel.

L'assignation de l'adresse IP locale dépend à la fois des options passées à pppd et du protocole IPCP. Vous devez utiliser l'adresse magique 0.0.0.0 s'il vous faut vraiment spécifier une adresse IP locale. La plupart des gens préfèrent ne pas préciser du tout d'adresse locale dans la liste des options.

Une autre option est intimement liée à cette adresse locale, il s'agit de "noipdefault". Celle-ci indique à pppd de ne pas tenter de deviner l'adresse IP locale à partir du nom de votre machine et des adresses déclarées dans le fichier /etc/hosts. La plupart des utilisateurs emploient cette option lors d'un adressage dynamique. Toutefois, elle ne signifie pas "utiliser des adresses dynamiques" ; cet usage est automatique dès lors que l'adresse IP locale n'est pas précisée.

3.9 Comment savoir quelle adresse locale m'a été attribuée dynamiquement ?

Utilisez par exemple le script /etc/ppp/ip-up. L'adresse IP locale est le quatrième argument qui lui est passé ; ce script est automatiquement exécuté s'il existe dès que pppd connaît l'adresse IP du système local. Le cinquième paramètre contient l'adresse IP du système distant, au cas où vous auriez aussi besoin de connaître cette valeur.

3.10 Puis-je utiliser la même adresse IP locale pour toutes les lignes de mon serveur PPP ?

Oui.

L'adresse locale n'est pas significative pour le système local. Vous devez avoir une adresse IP distante unique. Le routage est fait en fonction de l'adresse distante, et non locale.

3.11 Je cherche une implémentation de PPP ailleurs que sous Linux.

Existe-t-il des versions pour HP-UX, AIX, ou... bien d'autres systèmes ?

Lisez les documentations mentionnées plus haut.

AIX sera supporté dans la version 2.2 du paquetage pppd. HP-UX n'est à notre connaissance supporté que par la version commerciale MorningStar.

Si vous ne trouvez vraiment aucun renseignement, demandez dans comp.protocols.ppp, mais surtout pas dans un groupe Linux, qui n'est en aucun cas concerné.

3.12 Saviez vous qu'il existe une autre implémentation nommée "dp" ?

Oui, nous sommes au courant. Le paquetage "dp" fut envisagé au tout début de l'implémentation de PPP sous Linux. Il est très bien, il supporte l'appel à la demande. Il ne peut fonctionner que sur un système supportant les streams, c'est à dire principalement le nouveau SunOS (Solaris).

Linux, pour l'instant, ne supporte pas les streams.

Il existe d'autres ensembles PPP disponibles par l'Internet. Le paquetage Portable ppp ressemble beaucoup au code TIA ; une autre implémentation se nomme tout simplement ppp, et on trouve du code pour PPP dans l'excellent paquetage KA9Q.

De toutes ces versions, pppd était le plus proche de ce que Linux nécessitait pour assurer un portage correct.

(Si vous désirez plus d'informations sur ces autres implémentations, demandez dans comp.protocols.ppp).

3.13 Quels RFC décrivent le protocole PPP tel qu'implémenté sous Linux ?

L'implémentation courante de PPP est un mélange de plusieurs. La plus grande partie du code de PPP est réalisée selon les RFC 1331 et 1332. Ces documents sont maintenant obsolètes ; le 1331 fut remplacé par le 1548 qui, à son tour, fut remplacé par le 1661 six mois plus tard. Vous trouverez une liste complète dans la FAQ PPP.

La plupart des implémentations de PPP converseront sans problème avec celle de Linux.

Extrait de la FAQ PPP :

Tous les RFC 1134, 1171, et 1172 (et, de ce fait, 1055) sont maintenant obsolètes. Ils ne sont intéressants que si vous comptez déboguer une connection avec une ancienne implémentation de PPP, et si vous vous demandez pourquoi, par exemple, elle vous a demandé l'option IPCP 2 avec une longueur de 4 seulement, et un type de compression 0x0037.

(Il en circule encore de nombreuses versions, faites attention).

Le PPP de Linux ne supportera pas ces vieilleries.

3.14 PPP peut il converser avec SLIP ?

Non. SLIP fonctionne avec SLIP, PPP fonctionne avec PPP.

Quelques distributeurs peuvent offrir des produits fonctionnant à la fois en SLIP et PPP. Toutefois, ils doivent être configurés dans l'un de ces deux modes. Il n'existe actuellement aucune méthode permettant de déterminer à la connexion quel type de protocoles SLIP, ou PPP, est attendu.

3.15 Quel est le meilleur ? PPP ou SLIP ?

CELA DEPEND DE NOMBREUX FACTEURS !

Les gens qui posent ce genre de question n'ont en général pas lu le moindre document sur ces protocoles, à commencer par le Net-2-HOWTO.

Un articles très intéressant sur ce sujet est disponible sur le serveur Web de Morning Star, www.morningstar.com.

3.16 Quel est le mieux ? L'authentification CHAP ou PAP ?

Si vous avez le choix, prenez CHAP. Sinon, PAP sera mieux que rien.

3.17 Que doit contenir le fichier /etc/ppp/pap-secrets ?

Le protocole pap est le plus souvent implémenté sous la forme de votre nom d'utilisateur associé à un mot de passe. Vous devez mettre le nom du système distant, votre nom d'utilisateur, et le mot de passe.

Prenons un exemple : L'utilisateur abbot veut appeler costello. L'entrée sera la suivante :

        #remote    account    password     IP address list
        *          abbot      firstbase

3.18 Que doit contenir le fichier /etc/ppp/chap-secrets ?

Le problème le plus courant est la non-reconnaissance de cette négociation CHAP par un couple de secrets. Chacun des deux ordinateurs devant se relier doit connaître les deux secrets pour que la communication aboutisse.

Par exemple, si abbot veut communiquer avec costello, le fichier sur abbot contiendra :

            #local      distant         secret        liste d'adresses IP
            abbot       costello       firstbase
            costello    abbot          who

Et celui de costello sera :

            #local      distant         secret        liste d'adresses IP
            abbot       costello       firstbase
            costello    abbot          who

3.19 J'ai des erreurs lors de la compilation...

J'ai des erreurs lors de la compilation du noyau quand j'inclus le pilote ppp.c. Ce noyau est en version 1.1.8. Que faire ?

Ne tentez pas de faire fonctionner PPP avec un noyau aussi ancien, mettez votre système à jour ! Les versions 1.0 de Linux demandaient une modification des sources, les versions 1.1 supportaient déjà PPP mais nécessitaient beaucoup d'ajustements.

A partir de la version 1.2 du noyau, le pilote PPP est fourni en standard et est prévu pour fonctionner le plus simplement du monde.

3.20 Pourquoi ne puis-je lancer pppd si je ne suis pas root ?

Le processus pppd a besoin de modifier le paramétrage du réseau, et ceci n'est autorisé qu'au super-utilisateur. Si vous désirez pouvoir lancer pppd sous un autre nom d'utilisateur, le programme doit alors être "suid root" :

        chown root pppd
        chmod 4755 pppd

Si vous voulez n'autoriser pppd qu'à un petit groupe de personnes, attribuez-le à ce groupe et interdisez son exécution à tous les autres.

3.21 Bon sang ! J'ai récupéré ppp-2.1.2c et il dit qu'il a besoin des versions 4.6 des bibliothèques partagées ! Alors ???

Désolé, on s'est trompé, nous travaillons avec vos programmes du futur, que voulez-vous. Un jour où l'autre, vous disposerez également de ces bibliothèques.

En attendant,il va vous falloir recompiler le code vous-même, avec les bibliothèques dont vous disposez. C'est très facile :

Allez dans le répertoire pppd, effacez le mauvais binaire, et tapez la commande "make". Faites de même dans le répertoire chat si vous comptez utiliser ce programme.

Une autre solution est de vous procurer une version de ces bibliothèques et de jouer les alpha-testeurs :-) Quoi qu'il en soit, depuis le 21 mai 1995 Linux utilise le format binaire ELF par défaut, et ce paragraphe est obsolète. Assurez-vous avant toute compilation de l'ensemble de prendre l'archive la plus récente.

3.22 Que signifie le message : unable to create pid file ?

Vous devez créer le répertoire /var/run. Dans certaines distributions, il s'agit d'un lien symbolique vers le répertoire /etc.

Ce n'est qu'un avertissement, qui n'empêche pas PPP de fonctionner correctement. Toutefois, le script ppp-off dépend de ce fichier, il est donc préférable de régler le problème.

L'entête POSIX path.h définit l'emplacement du fichier pid sous le nom _VAR_RUN. Si vous désirez utiliser un autre répertoire pour PPP ou d'autres programmes, changez la valeur de cette définition et recompilez les programmes.

3.23 Que veut dire /etc/ppp/options: no such file or directory ?

Vous devez créer le répertoire /etc/ppp et y mettre un fichier nommé options. Il doit être lisible par le processus pppd (root).

Ce fichier peut être vide, tout simplement. Dans ce cas, utilisez la commande touch pour le créer. Lisez la page de manuel de pppd pour obtenir une description de ce fichier.

Il est possible de compiler pppd pour qu'il n'utilise pas ce fichier ; dans ce cas il faut supprimer (commenter) la ligne SECURE_FLAGS = -DREQ_SYSOPTIONS=1 dans le Makefile.

3.24 Je tente de me connecter à un Telebit Netblazer, et il termine par le message "Could not determine local IP address".

Cela se produit avec de nombreuses configurations du Telebit Netblazer. Le problème ne provient pas du serveur de terminaux, mais le site n'a pas égé configuré ce dernier avec un couple d'adresses IP.

Le Netblazer n'a pas votre adresse IP. Vous n'avez pas non plus votre adresse IP. La liaison ne s'effectuera pas tant que cette situation durera.

  1. Le Netblazer ne connaît pas votre adresse IP, et vous ne la connaissez pas non plus.
  2. Le Netblazer connaît sa propre adresse IP mais vous ne la connaissez pas.

La connexion n'aboutira pas tant que ces deux adresses ne seront pas connues.

On a dû vous donner une feuille de papier sur laquelle ces deux adresses IP sont indiquées. Vous devez signaler au Netblazer l'adresse à utiliser. Indiquez alors ces deux adresses, locale et distante, comme paramètres lors du lancement du programme pppd, selon le format suivant :

        adresse_locale:adresse_distante

N'oubliez surtout pas les deux points (:) de séparation.

3.25 Je tente de me connecter à un Telebit Netblazer, et il termine par le message "Could not determine remote IP address".

Lisez donc la réponse à la question précédente...

3.26 Je n'arrête pas de recevoir le message disant que le "magic number" est toujours refusé (NAK). Le système ne se connecte pas.

La probabilité que les deux systèmes aient choisi le même nombre magique est d'une chance sur un milliard. Si vous obtenez continuellement cette erreur, prenez un billet de loterie et/ou surveillez votre femme :-)

Les deux causes les plus courantes de ce problème sont :

  1. Le modem s'est déconnecté immédiatement après avoir réalisé la connexion et l'accès au système distant. Beaucoup de modems sont configurés pour renvoyer l'écho des données qu'on leur injecte, et vos dialoguez avec l'écho local.
  2. Les programmes réalisant PPP ne sont pas en service sur le système distant au moment où vous tentez d'établir le lien. La machine distante est-elle bien configurée pour PPP ? Les programmes s'y trouvent sont-ils bien accessibles, tant en chemin d'accès qu'en permissions ? Cela tendrait à indiquer que c'est le shell qui vous réalise un écho local des données que vous envoyez. Quoi qu'il en soit, le système Linux envoie des données que l'autre côté retourne immédiatement. Ce n'est pas une condition acceptable, vous avez ce que l'on appelle une "boucle".

3.27 J'utilise un serveur de terminaux Xyplex et pppd se plaint de se voir refuser le protocole fffb. Qu'est-ce que c'est que ça ?

La version 5.1 du logiciel des serveurs de terminaux Xyplex est connue pour avoir beaucoup de problèmes sous PPP. Il est fortement recommandé de faire une mise à jour pour passer en version 5.3 ou supérieure.

Si vous devez rester en version 5.1, utilisez alors l'option "vj-max-slots 3" pour limiter le nombre de slots à trois, au lieu des 16 par défaut, qu'est censé supporter le logiciel alors qu'il ne fonctionne pas au-delà du troisième. Il devrait retourner une trame NAK, mais ne le fait pas.

Sinon, vous pouvez désactiver la compression d'en-têtes Van Jacobson. Utilisez l'option -vj de pppd.

3.28 La connexion s'effectue mais la séquence d'initialisation semble ne jamais se terminer. Le périphérique n'est jamais "UP", et finalement le programme raccroche. Que se passe-t-il ?

Essayez avec l'option debug et examinez les traces système (vous aurez de toutes façons besoin de ces traces si vous comptez demander de l'aide). Si elles montrent que vous envoyez la séquence "LCP-request" continuellement et que la valeur de "id" ne s'incrémente pas, c'est qu'il n'y a pas de PPP à l'autre bout.

Les trois causes les plus courantes sont :

  1. PPP n'est pas lancé sur la machine distante. Vous envoyez des demandes de négociation à un programme quelconque, qui est probablement en train de vous répondre "Qu'est-ce que c'est que ce charabia ?" Assurez-vous que le protocole PPP soit bien lancé à l'autre bout avant d'entrer dans la phase de négociation du protocole. Essayez d'utiliser un programme de communications normal et simulez la session à la main. Vous devriez alors voir nettement la tentative de négociation PPP vous arriver, c'est facile à identifier : il s'agit de trains d'environ 16 caractères, contenant beaucoup d'accolades ouvrantes. Ils ne doivent pas contenir de retour-chariot et sont envoyés par saccades.
  2. La liaison n'est pas "8 bits clean". Cela signifie que pour utiliser PPP, vous devez être configuré en 8 bits de données, pas de parité et un bit de stop. PPP ne peut fonctionner qu'en 8 bits. Le programme pppd passera automatiquement la ligne sous ce format. La machine distante doit également se conformer à cette configuration sous peine de nombreuses erreurs de format et parité. PPP encode certains caractères. Il ne lui est pas possible de travailler au niveau du bit comme kermit peut le faire. PPP ne fonctionne pas sur une liaison 7 bits. Il y a une option de compilation dans le pilote ppp.c (qui fait partie du noyau) appelée CHECK_CHARACTERS, qui ajoute du code destiné à effectuer des tests supplémentaires sur les caractères reçus. Elle pourra vous indiquer si la parité était validée ou si le système distant envoyait du 7 bits.
  3. Le système distant est configuré pour demander l'authentification PAP ou CHAP. Vous n'avez pas configuré votre système local pour le faire. Par conséquent, l'autre côté refuse tous vos paquets jusqu'à en rencontrer un d'identification, que vous n'enverrez jamais. Dans ce cas, il vous fait soit configurer la machine distante pour qu'elle ne demande pas d'authentification, ou configurer le système local pour qu'il le fasse. Examinez la réception des trames LCP de configuration. Si vous y voyez le type "auth", c'est que le système distant est configuré pour demander l'authentification.

3.29 J'essaie d'utiliser le réseau merit, et je me fais jeter.

Des utilisateurs de ce réseau ont signalé qu'il nécessite PAP. Avez-vous essayé l'authentification PAP ?

3.30 Le programme "dip" référence PPP...

Lorsque je tente d'utiliser mode ppp depuis dip j'obtiens une erreur disant que le mode PPP n'est pas supporté. Est-il prévu d'utiliser dip avec PPP ?

Le programme dip contrôle l'établissement d'une liaison SLIP. Puisque le processus pppd doit faire plusieurs choses à des moments différents que dans un lien SLIP, il y a fort peu de chances pour que dip et pppd puissent s'entendre un jour.

La commande dip peut néanmoins être utilisée pour l'appel téléphonique et le lancement de PPP sur le système distant. Dans ce cas il est préférable de le lancer en tant qu'argument connect de pppd.

La version en cours de dip-uri supporte PPP en ce sens qu'elle exécute le programme pppd sur l'instruction "mode ppp". Toutefois, elle ne passe aucun des nombreux arguments nécessaires au fonctionnement correct de pppd, aussi est-il indispensable de mettre ces options dans le fichier /etc/ppp/options.

La manière dont est exécuté pppd importe peu pour la liaison PPP. Mais ce programme doit absolument être lancé, car il est indispensable au protocole PPP.

3.31 Comment arrêter PPP ? Existe-t-il un "dip -k" pour PPP ?

Non, il n'y en a pas.

Dans le répertoire chat, vous trouverez un script appelé ppp-off. Il arrêtera la liaison PPP de la même façon que votre dip -k.

Le voici ci-dessous. Copiez-le dans un fichier que vous rendrez exécutable par la commande chmod +x et le tour sera joué.


#!/bin/sh
DEVICE=ppp0
#
# Si le fichier pid de ppp0 est present, alors c'est que le programme
# tourne. Arretons-le.
if [ -r /var/run/$DEVICE.pid ]; then
        kill -INT `cat /var/run/$DEVICE.pid`
#
# Si ca n'a pas marche, c'est qu'il n'y a plus de processus actifs
# correspondant a ce pid. Cela peut aussi signifier que le fichier
# de verrouillage a ete laisse en place. Il faut supprimer ce verrou.
        if [! "$?" = "0" ]; then
                rm -f /var/run/$DEVICE.pid
                echo 'ERROR: Removed stale pid file'
                exit 1
        fi
#
# Succes. Laissons pppd faire son propre menage.
        echo 'PPP link to $DEVICE terminated.'
        exit 0
fi
#
# Le processus pppd n'est pas actif sur ppp0
echo 'ERROR: PPP link is not active on $DEVICE'
exit 1

3.32 Le processus pppd ne se termine pas lorsque le modem se déconnecte. Je dois l'arrêter manuellement pour que getty reprenne la main.

Ce problème peut avoir plusieurs causes.

Le script doit avoir un format du type suivant :


 
     #!/bin/sh
     exec pppd -detach modem ...           

3.33 Les transferts FTP échouent quand je fais un "put" mais se passent bien lorsque je fais un "get".

Le contrôle de flux est-t-il bien en service ? Il se valide par l'option crtscts de pppd, pour ce qui est du contrôle de flux matériel RTS/CTS, et par l'option xonxoff pour XON/XOFF. Sans contrôle de flux, vous perdrez des caractères et le résultat sera désastreux pour la compression vj, entre autres.

3.34 Comment utiliser le contrôle de flux XON/XOFF ?

Le mieux est de ne pas l'utiliser, et de choisir RTS/CTS. Toutefois, si vous ne pouvez faire autrement, vous devez opérer selon les trois points suivants :

3.35 Le modem ne semble jamais se connecter aux vitesses rapides.

Mettez la vitesse désirée dans la commande de pppd. Si vous ne l'indiquez pas, ce sera celle qui est initialisée au moment ou vous lancez le programme qui sera utilisée, et elle peut être quelconque : tous les programmes ne remettent pas correctement les paramètres du port série qu'ils ont trouvé en arrivant. Certains peuvent même laisser des valeurs étranges amenant un fonctionnement curieux (une vitesse de 0, par exemple !).

3.36 Les transferts FTP semblent très lents sur les "get", alors que les"put" sont corrects.

Avez-vous bien indiqué l'option :

asyncmap 0

lors du lancement de pppd ? Si vous l'avez oubliée, l'autre côté doit encoder (doubler) tous les caractères de contrôle entre les valeurs hexadécimales 00 et 1F. Cette opération résulte en une perte de vitesse moyenne de 12,5 % pour tout ce que vous recevez.

Le système distant est-il bien configuré ? Si oui, le contrôle de flux est-il bien en service ?

3.37 J'essaie d'utiliser proxyarp. La fonction proxyarp n'arrive pas à trouver l'adresse MAC avec Linux 1.0.

Utilisez l'archive ppp-2.1.2d.tar.gz. Le programme pppd était compilé par erreur sous Linux 1.1.8 et utilisait les définitions Net-3 plutôt que celles de l'ancien Net-2.

Vous pouvez également consulter le document "mini-HOWTO" proxy-ARP pour obtenir plus de détails sur le sujet.

3.38 Ma route vers le site distant disparaît toute seule au bout de troisminutes !

Cela n'a rien à voir avec PPP.

Bon, allez, on vous le dit : n'utilisez JAMAIS routed !

3.39 Je peux atteindre la machine distante, mais aucune autre.

N'auriez-vous pas oublié le paramètre defaultroute ? Il ajoute une route par défaut dans vos tables de routage, afin que les paquets vers toutes les autres adresses IP soient envoyés par l'interface PPP.

Le programme ne remplacera pas une route par défaut déjà existante. Cela est volontaire, pour éviter de détruire la route par défaut vers d'éventuels routeurs Ethernet par accident. Dans ce cas, un message d'avertissement est envoyé au système de trace de la machine, via syslog, et ce sera à vous d'effectuer les opérations que vous jugerez nécessaires.

3.40 J'ai une route par défaut mais je ne peux toujours pas me connecter ailleurs !

Cela ne provient pas de votre système Linux local, mais probablement d'un problème de routage sur la machine distante.

Le système distant n'est pas configuré pour supporter l'IP forwarding. Les RFC stipulent que cette option ne soit PAS validée par défaut, pour des raisons de sécurité. Vous devez mettre cette option en service ; sous Linux il vous faut alors reconstruire le noyau en indiquant que vous désirez supporter "IP forwarding/gatewaying".

Le système distant a besoin d'une route vers vous, tout comme vous en avez une vers lui. Cela peut être réalisé de quatre façons différentes. Chaque méthode a ses avantages et inconvénients ; vous devez en choisir une, et une seule.

  1. Utiliser une route de type "host". Sur chaque machine du site distant, ajouter une route vers votre adresse IP Linux, avec comme passerelle le serveur de terminaux que vous utilisez pour votre accès local. Cette méthode fonctionnera si vous avez un nombre limité de machines et un réseau très simple.
  2. Utiliser une route de type "network". Subdivisez les adresses IP distantes de manière que l'adresse IP locale à votre machine Linux, celle de votre serveur distant, et celle de l'interface Ethernet de ce dernier soient dans le même domaine IP. Cette méthode fonctionnera si vous possédez des adresses à distribuer. Elle sera parfaite si vous possédez un réseau de classe B et pouvez assigner toutes les adresses distantes dans le même domaine IP. Ajoutez alors une route réseau sur chacune des passerelles et routeurs de façon que toute adresse du réseau distant soit accédée par le serveur de terminaux. Beaucoup de configurations possèdent beaucoup de machines mais très peu de routeurs (à sii.com, nous avons plus de 300 systèmes actifs et seulement 3 routeurs).
  3. Utilisez le programme gated sur toutes les passerelles et sur le serveur de terminaux. Cela fera diffuser par le serveur de terminaux des informations vers les passerelles, indiquant qu'il peut accepter des paquets pour votre adresse IP. Puisque les machines auront une route par défaut vers l'une de ces passerelles, ces dernières génèreront les requêtes ICMP de redirection et le routage s'établira automatiquement.
  4. Utilisez "proxy ARP" sur le serveur de terminaux. Cette méthode ne fonctionnera que si votre adresse IP locale correspond à l'un des domaines IP des cartes réseau.

En résumé, il n'y a pas de solution miracle, simple et unique. Vous devez faire votre choix parmi l'une de ces quatre-là.

Si votre routeur nécessite des trames RIP afin de mettre à jour la route vers votre système, vous devrez utiliser le programme "bcastd" disponible sur sunsite.unc.edu. Il générera les paquets RIP nécessaires sans avoir besoin de déranger gated.

3.41 Je ne peux pas "pinguer" mon adresse IP locale.

Vous ne pouvez pas parce que vous n'avez pas de route vers cette adresse. C'est le fonctionnement normal. N'essayez pas.

Si vous voulez faire un ping sur votre propre système, utilisez l'adresse loopback : 127.0.0.1.

Vous devriez pouvoir "pinguer" l'adresse distante. Toutefois, certains serveurs interdisent cette opération.

En règle générale, n'essayez pas ping sur l'une ou l'autre de ces adresse. Choisissez-en une troisième, que vous savez accessible sur le réseau distant.

Bien que PPP ne s'occupe pas de cette tâche, vous pouvez ajouter manuellement une route vous-même une fois que la liaison est établie. La syntaxe est la suivante :

        route add -host 192.187.163.32 lo 
où l'adresse IP locale est ici représentée par 192.187.163.32. Tous les paquets destinés à votre adresse IP locale seront alors dirigés vers votre interface loopback.

Vous ne devrez pas oublier de supprimer manuellement cette route lorsque la liaison ne sera plus établie, bien entendu.

3.42 J'utilise Trumpet (pour MS-DOS) et la connexion n'aboutit pas. Pourquoi ?

Trumpet n'aime pas du tout la compression d'en-têtes Van Jacobson. Utilisez l'option -vj pour la mettre hors service.

3.43 J'utilise dp-3.1.2 (sous SunOS) et rien ne marche sauf ping et nslookup.

Il y a un bogue dans la version 3.1.2 de dp. Procurez-vous la version 3.1.2a ou plus récente sur le site de référence harbor.ecn.purdue.ecu. Tant que vous n'avez pas pu effectuer cette mise à jour, supprimez la compression vj.

3.44 Je ne peux pas connecter de/vers mon code Windows NT (Daytona) avec le PPP Microsoft. Pourquoi diable ?

Microsoft a choisi d'utiliser un protocole d'authentification non standard dans Windows NT. C'est leur droit le plus strict, à condition qu'ils aient enregistré leur numéro de protocole auprès de l'IANA. (C'est le cas). Si l'option "accept only Microsoft encrypted authentication" de la boite check de l'agenda téléphonique est positionnée, la connexion n'aboutira jamais : celle-ci demande que le système Windows NT n'échange d'authentification PPP qu'avec une autre implémentation PPP de Microsoft.

Linux ne supporte pas ce protocole d'authentification.

Si vous avez la possibilité de changer le paramétrage du système Windows NT, allez dans la configuration de l'agenda téléphonique, et assurez-vous que "Accept any authentication including clear text" est validée et que "accept only Microsoft encrypted authentication" ne le soit pas. Les autres options sont fonction de ce que vous désirez.

Puis, utilisez PAP du côté Linux. Mettez votre compte (nom et mot de passe) Windows NT dans le fichier /etc/ppp/pap-secrets.

La séquence d'authentification Microsoft est de style PAP, avec leur propre algorithme de chiffrement DES pour ce qui concerne les mots de passe. La séquence normale envoie le mot de passe sous forme ASCII pure ; ce qui dans leur cas violerait la sécurité C2.

Les versions de PPP antérieures à 2.1.2c sous Linux ont un problème avec le décodage de la requête d'authentification. Elles ne fonctionneront pas avec un système Windows NT car elles ne négocient pas la méthode correcte. Utilisez la version 2.1.2c ou ultérieure si vous voulez vous connecter sur un bidule machin Windows NT. La version en cours, 2.1.2d est préférable.

Scott Hutton <shutton@habanero.ucs.indiana.edu> nous a indiqué ceci :

NT RAS (Remote Access Services) coupe la connexion dès lors que quelque chose de critique est REJeté (par exemple, le protocole d'authentification). Par conséquent, l'astuce consiste à créer un fichier chap-secrets bidon. Le mien contient :

* "" ""
Il a pour conséquence de faire envoyer un NAK par pppd, plutôt qu'un REJ. La clé d'enregistrement SPAP supprimée, le protocole suivant essayé est PAP (c'est celui que j'utilise).

Il faut également s'assurer que seuls les services TCP/IP sont validés dans RAS (et pas NetBEUI ni IPX). Il a aussi fallu prendre en considération deux autres clés pour éliminer les time-out (qui ne posent des problèmes qu'avec TCP/IP) :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters
    Autodisconnect: REG_DWORD: 0
Et pour obtenir un routage fonctionnel :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasArp\Parameters
    DisableOtherSrcPackets: REG_DWORD: 0
Enfin, la clé pour éliminer complètement SPAP :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\SPAP

3.45 Le trace contient souvent Alarm. Est-ce grave ?

Non.

Cela signifie simplement qu'une mesure de temps s'est écoulée, c'est une partie nécessaire de la phase d'établissement du protocole.

3.46 La trace indique SIGHUP.

Le processus pppd a reçu un signal HUP. Celui-ci est généré par le pilote de périphérique lorsque le système distant s'est déconnecté de votre modem. Il signifie que le modem a raccroché la ligne, tout simplement ; la communication est coupée.

On peut également utiliser la commande kill pour envoyer ce signal au programme pppd.

Sur réception de ce SIGHUP, le programme pppd se termine proprement.

3.47 La trace indique SIGINT.

Le processus pppd a reçu un signal INT. Celui-ci est généré par le pilote de la console lorsque vous pressez la combinaison de touche CTRL-C et que pppd est en avant-plan.

On peut également utiliser la commande kill pour envoyer ce signal au programme pppd. En fait, c'est la méthode recommandée pour arrêter le programme et terminer la liaison. Consultez la question concernant "dip -k", vous y trouverez un script effectuant cette opération.

Sur réception de ce SIGHUP, le programme pppd se termine proprement.

3.48 La trace indique protocol reject for protocol c025. Qu'est-ce que c'est que cette histoire ?

Le site distant voudrait mettre en service le protocole d'analyse de qualité de liaison sur la machine Linux. (LQR, "Link Quality Reporting"). Ce protocole n'est pas encore supporté, ce n'est pas une erreur. Linux signale en substance : "L'autre m'a demandé ça, je lui ai dit que je ne sais pas le faire pour l'instant et qu'il ne m'embête pas avec".

L'implémentation MorningStar tentera toujours LQR. C'est normal.

3.49 La connexion échoue sur une erreur ioctl(TIOCSCTTY).

Utilisez l'archive ppp-2.1.2d.tar.gz. Il s'agit d'un bogue qui n'était pas géré avant la diffusion de ppp-2.1.2a.

3.50 La connexion échoue, avec des erreurs du genre ioctl(TIOCGETD): I/O error ou bien encore ioctl(PPPIOCSINPSIG): I/O error. Allô ! Docteur ?

Regardez les messages du noyau lors de l'amorçage de votre système Linux. Si il affiche PPP version 0.1.2, vous avez une version beaucoup trop ancienne du pilote ppp.c.

Si vous voyez PPP version 0.2.7, vous disposez de la version à jour, mais qui cependant n'a pas été compilée avec les mêmes définitions pour les valeurs d'ioctl().

Vérifiez que vous disposez bien d'un fichier, ppp.h, qui doit se trouver dans le répertoire include/linux des sources du noyau. Dans ce cas, recompilez le noyau, puis le programme pppd.

3.51 Quelquefois, j'obtiens les messages "ioctl(PPPIOCGDEBUG): I/O error", "ioctl(TIOCSETD): I/O error" et "ioctl(TIOCNXCL): I/O error". Pourquoi donc ?

Parce que le système distant a raccroché le téléphone. Les pilotes tty rétablissent alors la discipline de ligne correcte sur le port série, et ces erreurs sont le résultat du processus pppd, tentant de faire la même chose.

Tout cela est parfaitement normal, il n'y a pas d'inquiétudes à avoir.

3.52 Mon ifconfig affiche autre chose que ce qui suit. Il indique l'interface ppp comme "unknown" et une adresse MAC bizarroïde.

   ppp0      Link encap Point-to-Point Protocol
             inet addr 192.76.32.2  P-t-P 129.67.1.165  Mask 255.255.255.0
Ce n'est pas grave. Cet affichage n'est là que pour information. Si vous utilisez un noyau 1.1. récent, mettez à jour vos programmes réseau.

3.53 Je viens de regarder /proc/net/dev comme indiqué dans la documentation et c'est vide... Pourquoi ?

Avez-vous juste tapé la commande "ls -l /proc/net" en vous étonnant de trouver une taille de zéro octet ? Si c'est le cas, c'est normal. Vous devez faire :

                cat /proc/net/dev

Vous devriez alors voir le contenu de ce fichier, qui ne doit pas être vide. Sa taille est toujours indiquée comme étant nulle, c'est le système de fichiers "proc" qui veut ça. Ce ne sont pas de vrais fichiers, ils sont simulés par le noyau. Ne tenez pas compte de la taille, tapez la commande indiquée.

Les programmes more, less ou most ne peuvent pas être directement utilisés sur ce fichier. Si vous voulez malgré tout les employer, faites-le comme ceci :

                cat /proc/net/dev | less

3.54 Mon système ne marche pas. J'utilise slattach, ifconfig et route et ça ne marche toujours pas ! J'ai lu ça dans le Net-2-HOWTO ; où est l'erreur ?

N'utilisez jamais slattach et ifconfig avec PPP. Ces programmes ne sont utiles que pour SLIP. Le processus pppd s'occupe de ces fonctions tout seul au moment opportun, c'est à dire après l'échange des protocoles LCP et IPCP.

Vous ne pouvez pas remplacer pppd par slattach et ifconfig. La plus grande partie du protocole PPP se trouve dans pppd. Le noyau ne connaît que IP (et IPX dans l'avenir).

La route vers le site distant sera automatiquement ajoutée par pppd. Il n'y a pas d'option pour supprimer cette opération. Le programme se terminera si la route ne peut pas être ajoutée a la table de routage.

La route par défaut peut être automatiquement ajoutée, ou non. Cela est controlé par l'option defaultroute. Si vous avez déjà une route par défaut, elle ne sera pas modifiée.

Si vous devez router un réseau entier, mettez la commande dans le script /etc/ppp/ip-up. Les paramètres passés à ce script sont :

3.55 D'accord, j'ai les paramètres. Mais je veux la route vers le réseau et non pas la route vers le host. Comment faire ?

Sur sunsite.unc.edu se trouve un paquetage du nom de devinfo.tar.gz. Il contient quelques petits utilitaires pratiques qui extraient les données concernant un périphérique et font différentes opérations sur les notations d'adresses IP.

La documentation est fournie sous forme de pages de manuel.

Par exemple, si vous voulez router le domaine IP entier vers le site distant, vous pouvez mettre les choses suivantes dans le script /etc/ppp/ip-up.

Bien entendu, si les valeurs ne sont pas variables, il vous suffit d'utiliser les entrées appropriées avec la commande route.


# Obtention du masque reseau pour l'interface ppp0 (ou autres)
NETMASK = `devinfo -d $1 -t mask`

# Obtention du domaine IP (sans l'adresse host en supprimant les bits ad hoc)
DOMAIN = `netmath -a $5 $NETMASK`

# Ajout de la route vers le reseau que nous connaissons maintenant
route -net add $DOMAIN gw $5

3.56 Quand Linux supportera-t-il la numérotation sur demande ? J'en ai absolument besoin !

Utilisez diald. Il est disponible sur tous les sites diffusant Linux et fonctionne très bien avec PPP.

3.57 Quid du filtrage ? Quand allez-vous implémenter ça ?

Rien n'est prévu à ce sujet dans le code de PPP. Utilisez le code ipfirewall, c'est disponible sur sunsite.unc.edu. Aidez l'auteur à déboguer la chose, et ça fera ce que vous désirez que ça fasse.

Les dernières versions de développement du noyau comprennent en standard les modifications ad hoc (vous aurez toujours besoin du code ipfirewall). Là encore, le filtrage est relatif au réseau en général et n'est pas spécifique au protocole PPP.

3.58 Quid de IPX ?

L'addition du support pour IPX se fait tranquillement. J'ai (Al Longyear) commencé à y travailler pour quelqu'un me l'ayant demandé sur l'IRC (Internet Relay Chat). Je dois d'abord approfondir les manuels Novell pour comprendre quelles sont les valeurs correctes pour les fonctions de routage nécessaires pour IPXCP (IPXCP est le protocole de contrôle d'IPX).

3.59 Quid de NETBIOS ?

Il existe un protocole PPP Netbios. Toutefois, la meilleure solution serait que vous utilisiez TCP/IP et le code "samba".

Microsoft et quelques autres ont utilisé le protocole PPP Netbios.

Le protocole nbfcp fait l'objet d'un document public, disponible auprès de plusieurs sources d'information. Le protocole Netbios n'est pas une famille valide sous Linux, pour l'instant. Tant que Linux ne supportera pas le protocole, il n'y a aucun intérêt à supporter Netbios sur PPP.

3.60 J'ai besoin d'un support ISDN (NUMERIS). Ca existe ?

Pour cela, il faut un pilote ad hoc. La conception actuelle du pilote PPP n'est pas très adaptée, mais cela va changer. Un pilote pour l'interface Sonix est en cours de développement.

3.61 Comment faire du PPP synchrone, "tout bêtement" ?

Supporter une interface synchrone demande quelques modifications. La réécriture du pilote PPP aidera beaucoup. Kate Marika Alhola a l'intention de réaliser ce type de pilote pour le matériel dont elle dispose. Vous pouvez la contacter à l'adresse kate@digiw.fi pour plus d'information.

3.62 Avez-vous un lecteur de courrier compatible PPP ? et pour les News ?

Heu... ?

Vous vous trompez de groupe si vous cherchez des bricoles MS-DOS. PPP n'a rien à voir du tout avec l'agent de transport de courrier ! Ils sont tous "compatibles" avec PPP :-)


Chapitre suivant, Chapitre Précédent

Table des matières de ce chapitre, Table des matières générale

Début du document, Début de ce chapitre