Page suivantePage précédenteTable des matières

18. Résoudre les problèmes

Il y a de nombreuses raisons pour que votre liaison ne fonctionne pas - chat n'a pas réussi à aller jusqu'au bout, vous avez une mauvaise ligne, etc. Regardez votre syslog pour avoir des indications.

18.1 J'ai compilé le support PPP dans le noyau, mais...

Un problème relativement courant est que les gens compilent le support PPP dans leur noyau et après, lorsqu'ils essayent de lancer pppd, le noyau répond qu'il ne supporte pas ppp ! Un grand nombre de raisons peuvent en être la cause.

Bootez-vous avec le bon noyau ?

Même si vous avez recomplié votre support de ppp dans le noyau, vous ne bootez pas sur le nouveau noyau. Cela peut arriver si vous n'avez pas mis à jour /etc/lilo.conf et relancé lilo.

Une bonne façon de vérifier le noyau est d'envoyer la commande uname -a, qui affiche la ligne ressemblant à


Linux archenland 2.0.28 #2 Thu Feb 13 12:31:37 EST 1997 i586

Cela donne la version du noyau et la date à laquelle il a été compilé - ce qui vous donnera une bonne idée de ce qui se passe.

Avez-vous compilé le support noyau de ppp comme un module ?

Si vous avez compilé le support de ppp comme un module, mais n'avez pas fait d'installation des modules, alors vous pouvez avoir cette erreur. Relisez le kernel-HOWTO et le fichier README de /usr/src/linux !

Une autre possibilité concernant les modules est que vous supposez que les modules sont chargés automatiquement, alors que le daemon kerneld n'est pas lancé (il charge et décharge les modules au vol). Vérifiez le mini-HOWTO kerneld pour des informations sur la configuration de kerneld.

Utilisez-vous une bonne version de PPP pour votre noyau ?

Vous devez utiliser ppp-2.2 avec les versions 2.0.x du noyau. Vous pouvez utiliser ppp-2.2 avec les versions 1.2.x du noyau (si vous le patchez) sinon vous devez utiliser ppp-2.1.2.

Lancez vous pppd en étant root ?

Si vous ne lancez pas pppd en étant l'utilisateur root (et que pppd n'est pas suid vers root), vous pourrez recevoir ce message.

18.2 Mon modem se connecte mais PPP ne démarre jamais

Il y a d'innombrables possibilités avec ça (regardez dans comp.os.linux....).

Une erreur EXTREMEMENT fréquente est que vous avez mal tapé quelque chose dans vos scripts. La seule chose à faire est de vérifier que vous avez la conversation entre votre PC Linux et le serveur rapporté dans le syslog /var/log/message) allez ensuite dans celui-ci ligne par ligne. Vous aurez peut-être besoin d'appeler votre serveur ppp à la main pour revérifier tout ça.

Vous devez vérifier les messages de logs réels très attentivement - et ayez à l'esprit que les hommes on tendance à lire ce qu'ils PENSENT avoir tapé - et non ce qu'ils ont sous leurs yeux !

18.3 Le syslog contient "serial line is not 8 bit clean..."

Il y a plusieurs possibilités à cela - comme des retours sur la ligne etc., qui peuvent être la conséquence d'une (ou plusieurs) choses.

Pour comprendre ce qui se passe, il est nécessaire de chercher se qui se passe en coulisses dans pppd lui-même.

Lorsque pppd démarre, il envoie des paquets LCP (Link Control Protocol) à la machine distante. Si il reçoit une réponse valide il passe ensuite à l'étape suivante (avec IPCP - les paquets de contrôle IP) et c'est seulement une fois que cette négociation est terminée que les trames IP réelles commencent et que vous pouvez utiliser la liaison PPP.

Si il n'y a pas de serveur ppp fonctionnel à l'autre bout quand votre PC envoie les paquets LCP, ceux-ci sont renvoyés par le processus de login final. Comme ces paquets utilisent 8 bits, et sont réfléchis avec le 8ème bit (souvenez vous qu'ASCII est un code 7 bits). PPP s'en aperçoit et s'en plaint.

Il y a plusieurs possibilité pour qu'un réflexion arrive.

Vous n'êtes pas correctement connecté sur le serveur

Lorsque le script chat se termine, pppd démarre sur votre PC. Cependant, si vous n'avez pas terminé le processus de connexion au serveur (comme envoyer une commande nécessaire à lancer PPP sur le serveur), PPP ne se lancera pas.

Ainsi, le paquet LCP sera réfléchi et vous aurez une erreur.

Vous devez vérifier et corriger (si nécessaire) attentivement votre script chat (voir plus haut).

Vous n'avez pas lancé PPP sur le serveur

Certains serveurs PPP nécessitent que vous entriez une commande et/ou un retour chariot après avoir terminé le processus de connexion et avant que ppp soit lancé à l'autre bout.

Vérifiez votre script chat (voir plus haut).

Si vous vous connectez à la main et que vous vous rendez compte que vous devez envoyer sur ENTREE après avoir lancé PPP, ajouter simplement une paire attente/envoi vide à la fin de votre script chat (un chaîne vide envoie en fait ENTREE).

18.4 Le processus PPP distant est long à démarrer

Là c'est un peu délicat !

Par défaut, votre pppd Linux est compilé pour envoyer un maximum de 10 requêtes LCP de configuration. Si le serveur est un peu lent à démarrer, la totalité des 10 requêtes auront été envoyées avant que le serveur PPP distant n'ait eu le temps de les recevoir.

Sur votre machine, pppd voit la réflexion des 10 requêtes (avec le 8éme bit inversé) et s'arrête.

Il y a deux façon de résoudre cela :

Ajouter lcp-max-configure 30 comme option de ppp. Cela augmentera le nombre de packets de configuration LCP que pppd enverra avant d'abandonner. Pour les serveurs vraiment lents, vous devez même mettre plus que ça.

Sinon, vous pouvez être un peu malin de votre côté. Vous avez peut-être remarqué que lorsque vous vous connectez à la main au serveur PPP et que vous démarrez alors PPP, le premier caractère que ppp envoie et qui apparaît est toujours le caractère tilda (~).

En savant cela, vous pouvez ajouter une nouvelle paire attente/envoi à la fin de votre script chat qui attendra un tilda et n'enverra rien. Cela ressemblera alors à :


\~      ''

Remarque : comme le caractère tilda a une signification particulière pour le shell, il doit être échappé (en fait précédé par un backslash).

18.5 La route par défaut n'est pas configurée

Si pppd refuse de configurer la route par défaut, c'est parce que (assez justement) il refuse de remplacer/supprimer une route par défaut existante.

La raison habituelle lorsque cette erreur apparaît est que certaines distributions configurent une route par défaut pour votre carte Ethernet au lieu de la configurer comme une route réseau spécifique.

Voir le Linux NAG et le HOWTO Net2/3 pour des informations sur la façon de configurer correctement votre carte Ethernet et les routes associées.

Une alternative à cela est que votre réseau local utilise déjà un gateway/routeur et que votre table de routage est déjà configurée pour envoyer la route par défaut à cet endroit.

Résoudre cette situation peut nécessiter quelques connaissances de réseau IP qui sort du domaine de ce HOWTO. Il est suggéré d'obtenir l'avis d'un expert (par les groupes de news ou quelqu'un que vous pouvez interroger près de vous).

18.6 Autres problèmes

Il y a des tas de raisons autres que celles-ci pour que ppp ne parvienne pas à se connecter et/ou fonctionner correctement.

Lisez la FAQ PPP(qui est une série de questions-réponses). C'est un document très didactique et les réponses y SONT ! De ma propre (et triste) expérience, si la réponse à votre problème n'est pas dedans, votre problème N'est PAS de la faute de ppp ! Pour ma part, j'utilisais un noyau ELF alors que je n'avais pas mis à jour les modules du noyau. J'ai juste perdu 2 jours (et presque une nuit) à chercher comment doit être un serveur PPP parfait avant de faire lumière !


Page suivantePage précédenteTable des matières