10.9. Pourquoi ppp tente de se connecter sans raison em mode -auto ?

10.9.1. Que veulent dire ces erreurs CCP ?

Je n'arrête pas de voir les erreurs suivantes dans mon fichier log :

CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)
       

Ceci est obtenu parce que ppp est en train de négocier la compression Predictor1 et que l'autre parti ne veut pas du tout négocier de compression. Ces messages sont sans conséquences aucune, mais si vous voulez les enleverm vous pouvez désactiver la compression Predictor1 aussi en local.

disable pred1
       

10.9.2. Ppp se bloque durant les transferts de fichiers avec une erreur IO.

Sous FreeBSD 2.2.2 et avant, il y avait un bug dans le driver tun qui stoppait tous les paquets entrants d'une taille plus grande que la taille MTU de l'interace tun. La réception de paquets plus grands que la taille du MTU résultait en une erreur IO qui était alors tracé avec syslogd,

Les spécifications ppp disent qu'un MTU de 1500 devrait toujours être accepté comme un minimum, ceci quelque soit la négociation LCP. Il est toutefois possible que vous diminuez le MTU à moins de 1500, votre ISP vous transmettra des paquets de 1500 sans s'en préoccuper, et cela vous bloquera, gelant ainsi la ligne.

Ce problème peut être contourné en ne réglant jamais un MTU en dessous de 1500 sous FreeBSD 2.2.2 et avant.

10.9.3. Pourquoi ppp ne trace-t-il pas ma vitesse de connexion ?

La façon de tracer toutes les lignes de la ``conversation'' de votre modem est d'activer :

set log +connect
       

Cela permettra à ppp de tout tracer jusqu'à la dernière chaîne de requête d'"attente"

Si vous voulez voir votre vitesse de connexion et que vous utilisez PAP ou CHAP (et donc ne rien avoir avec "chat" après le CONNECT dans le script dial - pas de script "set login"), vous devez vous assurer que vous prévenez ppp de s'attendre tout la ligne CONNECT, quelque chose comme :

set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"
       

Ici, nous avons notre CONNECT, ne rien envoyer, et puis attendre un saut de ligne, forçant ppp à lire toute la réponse CONNECT.

10.9.4. Ppp ignore le caractère `\' dans mon script chat

Ppp parse chacune des lignes de votre fichier de configuration, de telle sorte qu'il puisse interprêter des chaines comme set phone "123 456 789" correctement (et réaliser qu'il n'y a que un seul argument. Pour pouvoir spécifier un caractère ``"'', vous devez l'échapper avec un backslash (``\'').

Quand l'interprêteur chat parse chaque argument, il re-interprête l'argument de telle sorte à trouver des séquences de caractères d'échappement comme ``\P'' ou ``\T'' (voir les pages de manuel). En conséquence de ce double-parsing, vous devez vous souvenir d'utiliser le nombre correct d'échappement.

Si vous voulez envoyer un caractère ``\'' à votre modem, vous aurez besoin de faire quelque chose comme :

set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"
       

qui se résultera en la séquence suivante :

ATZ
OK
AT\X
OK
       

ou encore

set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"
       

résultera en la séquence suivante :

ATZ
OK
ATDT1234567
       

10.9.5. Ppp reçoit une erreur de segmentation, mais je ne trouve pas de fichier ppp.core

Ppp (ou n'importe quel programme dans le même cas) ne devrait jamais faire de coredump. Parce que ppp tourne avec une identité d'utilisateur effectif de 0, le système d'exploitation n'écrira pas d'image du core sur le disque avant de l'avoir terminé. Si, malgrè tout, ppp se termine actuellement à cause d'une violation de segmentation, ou n'importe quel autre signal qui cause normalement un core dump, et que vous êtes sûr que vous utilisez la dernière version (voir le début de cette section), alors vous devriez faire la chose suivante :

$ tar xfz ppp-*.src.tar.gz
$ cd ppp*/ppp
$ echo STRIP= >>Makefile
$ echo CFLAGS+=-g >>Makefile
$ make clean all
$ su
make install
chmod 555 /usr/sbin/ppp
       

Vous aurez alors une version déboguable de ppp installé. Vous aurez à être root pour lancer ppp puisque tous ses privilèges auront été révoqués. Quand vous démarrez ppp, retenez soigneusement le répertoire courant dans lequel vous étiez.

A présent, si et quand ppp recevra une violation de segmentation, cela crééra un fichier core nommé ppp.core. Vous aurez alors à faire la chose suivante :

$ su
gdb /usr/sbin/ppp ppp.core
(gdb) bt
.....
(gdb) f 0
.....
(gdb) i args
.....
(gdb) l
.....
       

Toutes ces informations devront être données suivant votre question, rendant ainsi possible le diagnostique de votre problème.

Si vous êtes familier avec gdb, vous pouvez vouloir trouver d'autres techniques pour trouver ce qui a causé le dump, et les adresses et valeurs des variables concernées.

10.9.6. Le processus qui force un appel en mode auto ne se connecte jamais.

Cela est un problème connu quand ppp est réglé de telle sorte à négocier une adresse IP dynamique avec son homologue. Quand ce programme initial appelle connect(2) , l'adresse IP de l'interface tun est assignée à l'extrêmité de la socket. Le noyau crée le premier paquet sortant et l'écrit sur le périphérique tun. Ppp lit alors le paquet et établit alors la connexion. Si, comme résultat de l'assignation dynamique de ppp, l'adresse de l'interface est changée, l'extrêmité originale de la socket sera invalide. Tout paquet envoyé à l'autre parti sera alors en principe perdu. Et même s'il ne l'était pas, toute réponse ne pourrait pas être renvoyée à la machine originelle puisque l'adresse IP ne serait plus possèdée par cette machine.

Théoriquement, il y a plusieurs manières d'aborder ce problème. Le mieux serait que l'homologue re-assigne la même adresse IP si possible :-)

La meilleure méthode de notre côté, serait de ne jamais changer l'adresse IP de l'interface tun, mais à la place, changer tous les paquets sortant de telle sorte que les adresses IP de la source soient changées de l'interface Ip à l'IP négocié au vol. C'est essentiellement ce que libalias(3) (et l'option -alias de ppp) font actuellement.

Une autre alternative (et probablement la plus sûre); est d'implémenter un appel système qui change tous les sockets reliées depuis une adresse IP à une autre. Ppp utiliserait cet appel pour modifier la socket de tous les programmes existant lorsqu'une nouvelle adresse IP est négociée.

Une troisième possibilité est d'autoriser à une interface de s'activer sans adresse IP. Les paquets sortant auront une adresse IP de 255.255.255.255 jusqu'à ce que le premier SIOCAIFADDR ioctl soit fait. Cela reviendrait à lier entièrement la socket, et ça serait à ppp de changer l'adresse IP source, mais seulement si il est à 255.255.255.255, et seulement si le numéro IP et le checksum IP doivent être changés. Quoiqu'il en soit, c'est de la bidouille puisque le noyau enverra des paquets invalides à une interface mal configurée, en supposant que d'autres mécanismes seront capables de réparer les choses retrospectivement.

Aucune de ces solutions n'a (encore) été implémentée.

10.9.7. Pourquoi la plupart des jeux ne marchent pas avec l'option -alias ?

La raison pour laquelle les jeux et assimilés ne marchent pas avec libalias est que la machine extérieure essaye d'ouvrir une connexion ou envoyer des paquets UDP (non sollicités) à la machine interne. Le logiciel packet alias ne sait alors pas qu'il faut envoyer ces paquets à une machine interne.

Pour que ça marche, assurez vous que la seule chose qui tourne est le logiciel avec lequel vous avez des problèmes, puis alors, soit vous lancez tcpdump sur votre interface tun de votre routeur, soit vous activez le login ppp tcp/ip (``set log +tcp/ip'') sur votre routeur.

Quand vous démarrez le logiciel incriminé, vous devriez voir les paquets passer à travers la machine routeur. Quand quelque chose revient depuis l'extérieur, il sera retiré (c'est ça le problème). Noter le numéro de port de ces paquets, puis arrêtez le logiciel incriminé. Faite ceci quelques fois pour voir si les numéro de ports sont consistants. Si ils le sont, alors la ligne suivante dans la section appropriée de /etc/ppp/ppp.conf rendra le logiciel fonctionnel.

alias port proto internalmachine:port port
       

où ``proto'' est soit ``tcp'' ou ``udp'', ``internalmachine'' est la machine à laquelle vous voulez que les paquets soient envoyés et ``port'' le numéro de port de destination des paquets.

Vous ne pourrez pas utiliser le logiciel sur d'autres machines sans changer la commande du dessus, et lancer le logiciel sur 2 machines internes en même temps est hors de question - après tout, le monde extérieur voit tout votre réseau entier comme une seule machine.

Si les numéros de ports ne sont pas consistants, il y a 3 autres options :

1) Soumettre le support dans libalias. Des exemples de ``cas spéciaux'' peuvent être trouvés dans /usr/src/lib/libalias/alias_*.c (alias_ftp.c iest un bon prototype). Cela implique habituellement la lecture de certains paquets sortant reconnus, identification des instructions qui dit à la machine extérieure d'initialiser la connexion en retour vers machine interne sur un port (aléatoire) spécifique, et mettre en place une ``route'' dans la table d'alias de telle sorte que les paquets concernés sachent où aller.

C'est la solution la plus difficile, mais c'est la meilleure et permettra au logiciel de marcher sur plusieurs machines

2) Utiliser un proxy. L'application peut pouvoir supporter socks5 par exemple, ou (comme dans le cas de ``cvsup'') peut avoir une option ``passive'' qui évite d'avoir à toujours demander que l'autre parti ouvre une connexion en retour sur la machine locale.

3) Tout rediriger vers une machine interne utilisant ``alias addr''. C'est l'approche "bourrin".

10.9.8. Rien de cela ne marche - je suis désespéré !

Si tout le reste échoue, envoyer autant d'informations que vous pouvez, y compris vos fichiers de configuration, comment vous avez démarré ppp, les parties pertinentes de votre fichier log, et la sortie de la commande netstat -rn (avant et après connexion) à la liste de diffusion freebsd-questions@FreeBSD.org ou au newsgroup comp.unix.bsd.freebsd.misc, et quelqu'un devrait vous orienter dans la bonne direction.