10.8. Ma connexion se termine au bout de 3 minutes

set timeout NNN
       

10.8.1. Ma connexion se termine lors de gros chargements.

Si vous avez activé le report de la qualité de connexion (Link Quality Reporting (LQR)), il est possible ce soit parce que que trop de paquets LQR sont perdus entre la machine et son interlocuteur. PPP en déduit que la ligne doit être trop mauvaise, et se déconnecte. Avant la version 2.2.5 de FreeBSD, LQR était activé par défaut. Il est maintenant désactivé par défaut. LQR peut-être désactivé avec la ligne suivante :

disable lqr
       

10.8.2. Ma connexion se termine après un certain temps aléatoire.

Parfois, sur une ligne de téléphone avec des parasites, ou même sur une ligne avec des attentes d'appels activées, le modem peut se suspendre parce qu'il pense (de manière erronée) qu'il y a une perte du support de connexion (lost carrier)

Il y a un réglage sur la plupart des modems qui déterminent le degré de tolérance sur la perte temporaire de la ligne porteuse. Sur un USR Sportster par exemple, cela est mesuré par le registre S10 en dixième de secondes. Pour rendre votre modem plus tolérant, vous pouvez ajouter la séquence envoi-attente suivante à votre chaîne de connexion :

set dial "...... ATS10=10 OK ......"
       

Se référer au manuel de votre modem pour plus de détails.

10.8.3. Rien ne se passe après le message Login Ok!

Avant la version 2.2.5 de FreeBSD, une fois la ligne établie, ppp devait attendre que ce soit l'autre parti (peer) qui initialise le protocole de contrôle de ligne (Line Control Protocol (LCP). Or, plusieurs ISPs ne débuteront pas la négociation et attendront du client qu'il le fasse. Pour forcer ppp à initialiser le LCP, utiliser la ligne suivante :

set openmode active
       

Note: Cela ne fait pas de dégats si chacun des deux parties initialisent tous les deux la connexion, c'est pourquoi openmode est à présent activé par défaut. Quoiqu'il en soit, la prochaine section expliquera quand est-ce ce que cela peut gêner.

10.8.4. Je n'arrête pas de voir des erreurs à propos de magic being the same

De temps en temps, juste après la connexion, vous pouvez voir des messages dans le log qui dit "magic is the same". Parfois ces messages sont sans conséquences, et parfois l'un ou l'autre des partis quitte. La plupart des implémentations ppp ne peuvent survivre à ce problème, et même si la ligne semble venir, vous verrez régulièrement des demandes de configuration et des accusés de réception de configuration dans le fichier log à moins que ppp abandonne et ne ferme la connexion.

Cela apparaît normallement sur les machines serveurs avec des disques lents qui diffusent un getty sur le port, et qui exécute ppp depuis un script ou programme de login après le login. J'ai aussi eu vent de cela arrivant lorsqu'on utilise slirp. La raison est qu'entre le temps où getty quitte et que ppp commence, le ppp côté-client commence par envoyer des paquets Line Control Protocol (LCP). Parce que l'ECHO est toujours actif sur les ports du côté serveur, le client ppp verra ces paquets qui lui seront "reflèté".

Une partie de la négociation LCP est d'établir un nombre magique (magic number) de chaque côté de la ligne, ceci afin que les "réflexions" soient détectées. Le protocole dit que lorsque l'autre parti essaye de négocier le même nombre magique, un NAK devrait être envoyé et un nouveau nombre magique choisi. Durand la période où le serveur où le port serveur a l'ECHO activé, le client ppp envoie des paquets LCP, voit le même nombre magique dans les paquets reflètés et il le "NAK". Il voit aussi les reflexions de NAK (qui veut aussi dire que ppp devrait changer son nombre magique). Cela produit potentiellement un énorme nombre de nombre magiques à changer, chacun d'entre eux tous s'empilant joyeusement dans le buffer stty du serveur. Aussitôt que ppp démarre sur le serveur, il est innondé par des changement de nombre magique et souvent décide qu'il a assez essayé de négociation LCP et abandonne. Pendant ce temps, le client qui ne voit alors plus de réflexions, se réjouit juste le temps de voir que le serveur l'a déconnecté.

Cela peut-être évité en autorisant l'autre parti à démarrer la négociation avec la ligne suivante dans le fichier ppp.conf

set openmode passive
       

Cela dit à ppp d'attendre que le serveur débute la négociation LCP. Certains serveurs toutefois peuvent ne jamais initier la négociation. Si cela est le cas, vous pouvez faire quelque chose du genre :

set openmode active 3
       

Cela dit à ppp de rester passif pendant 3 secondes, et puis commencer à envoyer les requêtes LCP/ Si l'autre parti commence à envoyer des requêtes durant cette période, ppp répondra immédiatement plutôt qu'en attendant que la période des 3 secondes se termine.

10.8.5. Les négociations LCP continuent jusqu'à ce que la connexion soit fermée.

Cela est pour l'instant un défaut d'implémentation dans ppp où il n'associe pas les réponses LCP, CCP & IPCP avec leur requête originale. Comme conséquence, si l'une des implémentations ppp est 6 secondes plus lente que l'autre côté, l'autre côté enverra 2 requêtes de configuration LCP supplémentaire. Cela est fatal. Soient 2 implémentations, A et B. A commence à envoyer des requêtes LCP immédiatement après s'être connecté et B met 7 secondes à démarer. Quand B démarre, A a envoyé 3 requêtes LCP. Nous supposons que la ligne a désactivée l'ECHO, car dans le cas contraire nous verrions des problèmes de nombres magiques comme décrit dans la section précédente. B envoi un REQ, puis un ACK au premier REQ de A. Le résultat est que A entre dans l'état OPENED et envoie un ACK (le premier) en retour à B. Pendant ce temps, B renvoi 2 ACK de plus en réponse au 2 REQ supplémentaires envoyés par A avant B que B n'ait commencé. B reçoit alors le premier ACK de A et entre dans l'état OPENED. A reçoit le deuxième ACK de B et revient à l'état REQ-SENT, et envoie un autre (quatrième) REQ comme décrit dans la RFC. Il envoie alors un troisième ACK et entre dans l'état OPENED. Durant ce moment, B reçoit le quatrième REQ de A, par conséquent, revient dans l'état ACK-SENT et envoie un autre (second) REQ et (quatrième) ACK as per the RFC. A reçoit le REQ, va dans l'état REQ-SENT et envoie un autre REQ. Il reçoit alors immédiatement le ACK suivant et entre dans l'état OPENED.

Cela continue tant qu'un des partis ne s'aperçoive qu'ils n'iront nulle part comme cela et abandonne.

La meilleure façon d'éviter cela est de configurer un côté comme étant passif - cela fait, faire de telle sorte qu'un des côtés attende que l'autre commence la négociation. Cela peut-être fait par la commande :

set openmode passive
       

Faire attention avec cette option, vous devriez aussi utiliser la commande

set stopped N
       

afin de limiter la durée avant que ppp attende de l'autre parti de commencer la négociation. D'une autre façon, la commande

set openmode active N
       

(où N est le nombre de secondes qu'il faut attendre avant que le démarrage de la négociation ne soit faite). Regardez les pages de manuels pour plus de détails.

10.8.6. Ppp se verrouille peu après la connexion.

Avant la version 2.2.5 de FreeBSD, il était possible que votre ligne soit désactivée peu après la connexion, dûe à une mauvaise négociation de compression Predictor1 de ppp Cela ne devrait arriver que si deux côtés essayent de négocier des protocoles de contrôle de compression ( Compression Control Protocols (CCP) différents. Ce problème est à présent résolu, mais si vous utilisez toujours une vieille version de ppp, le problème peut-être sauté avec la ligne

disable pred1
       

10.8.7. Ppp se verrouille quand je "shell" pour le tester.

Quand vous exécutez le shell ou la commande !, ppp exécute un shell (ou si vous avez passé des arguments, ppp exécutera ces arguments). Ppp attendra que la commande se termine avant de continuer. Si vous avez l'intention d'utiliser la connexion ppp pendant que vous lancez la commande, la connexion apparaîtra alors comme ayant été gelée. Cela parce que ppp attend que la commande se termine.

Si vous voulez exécuter des commandes comme cela, utilisez plutôt la commande !bg. Cela exécutera la commande en arrière plan, et ppp pourra continuer de servir la connexion.

10.8.8. Ppp sur un null-modem ne quitte jamais.

Il n'y a aucune manière pour que ppp détermine automatiquement qu'une connexion directe s'est achevée. Cela est dû aux lignes utilisées dans un câble série null-modem. Quand on utilise cette sorte de connexion, LQR devrait être toujours activé avec la ligne :

enable lqr
       

LQR est accepté pas défaut si négocié par l'autre parti.