LCP terminated by peer

[Greywolf]

Bonsoir all,

 

j'aimerai avoir votre avis sur ce problème de connexion ADSL

contexte: Debian sarge, modem ECI USB, driver eci.usermode 0.7. => marchait sans souci depuis le mois de Janvier sauf depuis environ 2 semaines (j'ai modifié un peu iptables mais uniquement côté lan et a priori c'est un problème au niveau de la couche 2 OSI).

J'ai des déconnexions sauvages qui, me semble-t-il sont initiés par le serveur distant. J'aimerai savoir si vous confirmez mon analyse des logs:

 

Je n'ai pas de problème de connexion initiale, lancée au boot, mais de déconnexion sauvage => la nuit dernière par exemple

connexion relancée ce matin par #pppd call adsl

May  7 06:58:08 Gandalf pppd[21112]: pppd 2.4.1 started by root, uid 0

May  7 06:58:08 Gandalf pppd[21112]: using channel 72

May  7 06:58:08 Gandalf pppd[21112]: Using interface ppp0

May  7 06:58:08 Gandalf pppd[21112]: Connect: ppp0 <--> /dev/pts/2

May  7 06:58:09 Gandalf pppd[21112]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xacb34bb7>]

May  7 06:58:09 Gandalf pppd[21112]: rcvd [LCP ConfReq id=0x48 <mru 9178> <auth chap MD5> <magic 0x2e69772a>]

May  7 06:58:09 Gandalf pppd[21112]: sent [LCP ConfAck id=0x48 <mru 9178> <auth chap MD5> <magic 0x2e69772a>]

May  7 06:58:12 Gandalf pppd[21112]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xacb34bb7>]

May  7 06:58:12 Gandalf pppd[21112]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xacb34bb7>]

May  7 06:58:12 Gandalf pppd[21112]: rcvd [CHAP Challenge id=0xa0 <6ee4800bb0ad5f2d82a845094409aa9d>, name = "BSROU106"]

May  7 06:58:12 Gandalf pppd[21112]: sent [CHAP Response id=0xa0 <10e7b8494069af05bf7ed8f717bfa9a3>, name = "xxxxxxxxxxxx@freeadsl"]

May  7 06:58:12 Gandalf pppd[21112]: rcvd [CHAP Success id=0xa0 ""]

May  7 06:58:12 Gandalf pppd[21112]: sent [iPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]

May  7 06:58:12 Gandalf pppd[21112]: rcvd [iPCP ConfReq id=0x3e <addr 192.168.254.254>]

May  7 06:58:12 Gandalf pppd[21112]: sent [iPCP ConfAck id=0x3e <addr 192.168.254.254>]

May  7 06:58:14 Gandalf pppd[21112]: rcvd [iPCP ConfReq id=0x3f <addr 192.168.254.254>]

May  7 06:58:14 Gandalf pppd[21112]: sent [iPCP ConfAck id=0x3f <addr 192.168.254.254>]

May  7 06:58:15 Gandalf pppd[21112]: sent [iPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]

May  7 06:58:15 Gandalf pppd[21112]: rcvd [iPCP ConfNak id=0x1 <addr xx.xx.xx.xx> <ms-dns1 212.27.32.176> <ms-dns3 212.27.32.177>]

May  7 06:58:15 Gandalf pppd[21112]: sent [iPCP ConfReq id=0x2 <addr xx.xx.xx.xx> <ms-dns1 212.27.32.176> <ms-dns3 212.27.32.177>]

May  7 06:58:15 Gandalf pppd[21112]: rcvd [iPCP ConfAck id=0x2 <addr xx.xx.xx.xx> <ms-dns1 212.27.32.176> <ms-dns3 212.27.32.177>]

May  7 06:58:16 Gandalf pppd[21112]: local  IP address xx.xx.xx.xx

May  7 06:58:16 Gandalf pppd[21112]: remote IP address 192.168.254.254

May  7 06:58:16 Gandalf pppd[21112]: primary   DNS address 212.27.32.176

May  7 06:58:16 Gandalf pppd[21112]: secondary DNS address 212.27.32.177

May  7 06:58:16 Gandalf pppd[21112]: Script /etc/ppp/ip-up started (pid 21122)

May  7 06:58:16 Gandalf pppd[21112]: Script /etc/ppp/ip-up finished (pid 21122), status = 0x1

 

le protocole LCP s'occupe de mon authentification auprès du RADIUS de Free par CHAP

IPCP négocie les adresses IP assignées de part et d'autre (mon IP, la passerelle et les DNS)

jusque là tout est normal

 

May  7 07:24:50 Gandalf pppd[21112]: rcvd [LCP EchoReq id=0x2 magic=0x2e69772a d4 1b 20 b0]

May  7 07:24:50 Gandalf pppd[21112]: sent [LCP EchoRep id=0x2 magic=0xacb34bb7 d4 1b 20 b0]

May  7 07:26:53 Gandalf pppd[21112]: rcvd [LCP EchoReq id=0x3 magic=0x2e69772a d4 1b 20 b0]

May  7 07:26:53 Gandalf pppd[21112]: sent [LCP EchoRep id=0x3 magic=0xacb34bb7 d4 1b 20 b0]

May  7 07:28:56 Gandalf pppd[21112]: rcvd [LCP EchoReq id=0x4 magic=0x2e69772a d4 1b 20 b0]

May  7 07:28:56 Gandalf pppd[21112]: sent [LCP EchoRep id=0x4 magic=0xacb34bb7 d4 1b 20 b0]

 

je reçois régulièrement des LCP echo request auquel mon système répond, pareil normal (enfin il me semble)

 

May  7 11:13:58 Gandalf pppd[21112]: rcvd [LCP TermReq id=0x49]

May  7 11:13:58 Gandalf pppd[21112]: LCP terminated by peer

May  7 11:13:58 Gandalf pppd[21112]: Script /etc/ppp/ip-down started (pid 21454)

May  7 11:13:58 Gandalf pppd[21112]: sent [LCP TermAck id=0x49]

May  7 11:13:58 Gandalf pppd[21112]: Script /etc/ppp/ip-down finished (pid 21454), status = 0x0

May  7 11:14:01 Gandalf pppd[21112]: Connection terminated.

May  7 11:14:01 Gandalf pppd[21112]: Connect time 255.9 minutes.

May  7 11:14:01 Gandalf pppd[21112]: Sent 19853123 bytes, received 1668825 bytes.

 

et là, je reçois un LCP termination request qui coule ma connexion. Le temps total de connexion peut varier de entre 2 et 13h (le max que j'ai atteint dernièrement. Tout ceci ne serait pas trop grave grâce à l'option persist du script pppd sauf que

 

May  7 11:14:01 Gandalf pppd[21112]: using channel 73

May  7 11:14:01 Gandalf pppd[21112]: Using interface ppp0

May  7 11:14:01 Gandalf pppd[21112]: Connect: ppp0 <--> /dev/pts/0

May  7 11:14:01 Gandalf kernel: usbdevfs: usb_submit_urb returned -12

May  7 11:14:01 Gandalf pppd[21112]: Script /usr/bin/pppoeci -vpi 8 -vci 35 -vendor 0x0915 -product 0x8000 -mode VCM_RFC2364 finished (pid 21113), status = 0x0

May  7 11:14:01 Gandalf pppd[21112]: Script /usr/bin/pppoeci -vpi 8 -vci 35 -vendor 0x0915 -product 0x8000 -mode VCM_RFC2364 finished (pid 21461), status = 0xf4

May  7 11:14:01 Gandalf pppd[21112]: Modem hangup

May  7 11:14:01 Gandalf pppd[21112]: Connection terminated.

May  7 11:14:01 Gandalf pppd[21112]: using channel 74

May  7 11:14:01 Gandalf pppd[21112]: Using interface ppp0

May  7 11:14:01 Gandalf pppd[21112]: Connect: ppp0 <--> /dev/pts/0

May  7 11:14:02 Gandalf pppd[21112]: sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0xf8a07ac0>]

May  7 11:14:02 Gandalf pppd[21112]: rcvd [LCP ConfReq id=0xe <mru 9178> <auth chap MD5> <magic 0x15126396>]

May  7 11:14:02 Gandalf pppd[21112]: sent [LCP ConfAck id=0xe <mru 9178> <auth chap MD5> <magic 0x15126396>]

May  7 11:14:05 Gandalf pppd[21112]: sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0xf8a07ac0>]

May  7 11:14:05 Gandalf pppd[21112]: rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> <magic 0xf8a07ac0>]

May  7 11:14:05 Gandalf pppd[21112]: rcvd [CHAP Challenge id=0xb2 <2342eaad95b56600a9b3907ea0990034>, name = "BSROU106"]

May  7 11:14:05 Gandalf pppd[21112]: sent [CHAP Response id=0xb2 <16e9e7b5f8acbc151e7ed60291d57623>, name = "xxxxxxxx@freeadsl"]

May  7 11:14:14 Gandalf last message repeated 3 times

May  7 11:14:16 Gandalf pppd[21112]: rcvd [CHAP Failure id=0xb2 "Tunnel startup failure"]

May  7 11:14:16 Gandalf pppd[21112]: Remote message: Tunnel startup failure

May  7 11:14:16 Gandalf pppd[21112]: CHAP authentication failed

May  7 11:14:16 Gandalf pppd[21112]: sent [LCP TermReq id=0x3 "Failed to authenticate ourselves to peer"]

May  7 11:14:16 Gandalf pppd[21112]: rcvd [LCP TermReq id=0xf]

May  7 11:14:16 Gandalf pppd[21112]: sent [LCP TermAck id=0xf]

May  7 11:14:16 Gandalf pppd[21112]: rcvd [LCP TermAck id=0x3]

May  7 11:14:16 Gandalf pppd[21112]: Connection terminated.

May  7 11:14:16 Gandalf pppd[21112]: using channel 75

May  7 11:14:16 Gandalf kernel: usbdevfs: usb_submit_urb returned -12

May  7 11:14:16 Gandalf pppd[21112]: ioctl(PPPIOCGFLAGS): Inappropriate ioctl for device

May  7 11:14:16 Gandalf pppd[21112]: Exit.

 

le modem hangup, c'est le mien qui raccroche?

le script change de channel, tente une authentification CHAP mais non reconnu par le RADIUS => tunnel startup failure (c'est le radius qui arrive pas à faire le lien?)

la reconnexion automatique plante et je ne peux la relancer manuellement qu'au bout d'un certain temps (variable) par un pppd call adsl.

 

(NB: je n'ai fait tourner aujourd'hui aucun programme pouvant surcharger la connexion, le système, le DD)

 

questions:

Si je modifie des paramètres LCP, ça peut influencer quelquechose ou manifestement ça vient du serveur distant?

Les abonnés freeadsl ont-ils des problèmes de déco/reco (j'ai pas remis win depuis longtemps mais il va falloir que j'essaye)

Si j'appelle la hotline, ai-je une chance de tomber sur quelqu'un pouvant comprendre mon problème?

 

Merci de vos avis éclairés, commentaires, etc....

[PaTaToR]

'soir

 

Wouah alors là, ça va pas t'avancer beaucoup, mais je dois dire que ce dont tu parle, ça me troue le cul (pour reprendre les bonnes expressions made in South park ) J'ai beau relire le tout, je crois que je manque sacrément de vocabulaire pour comprendre ton problème....

Il me semble que tu m'avais dit que tu n'avais pas suivi de cours et que tu avais appris tout ça tout seul. Non ? J'aimerais bien comprendre un peu de quoi tu parle, ne serait-ce que pour ma culture informatique. Aurais tu un bon bouquin à me conseiller qui me permettrais d'obtenir au moins des bases dans ce domaine que tu semble (trés) bien maîtriser ?

Sinon, bopnne chance pour ton problème.

A+

 

Florent

[Greywolf]

ça vient de recommencer

May  7 22:13:44 Gandalf pppd[21624]: rcvd [LCP TermReq id=0xaa]

May  7 22:13:44 Gandalf pppd[21624]: LCP terminated by peer

May  7 22:13:44 Gandalf pppd[21624]: Script /etc/ppp/ip-down started (pid 22197)

May  7 22:13:44 Gandalf pppd[21624]: sent [LCP TermAck id=0xaa]

May  7 22:13:44 Gandalf pppd[21624]: Script /etc/ppp/ip-down finished (pid 22197), status = 0x0

May  7 22:13:47 Gandalf pppd[21624]: Connection terminated.

May  7 22:13:47 Gandalf pppd[21624]: Connect time 152.4 minutes.

May  7 22:13:47 Gandalf pppd[21624]: Sent 1935535 bytes, received 7290593 bytes.

 

et la reco automatique marche pas...

 

>Florent , si je maîtrisais aussi bien je demanderai pas un coup de pouce

 

Le problème semble se situer au niveau du protocole PPP qui s'occupe d'établir la connexion ADSL. c'est un protocole de niveau 2 de la classification OSI (juste en dessous de IP, niveau 3)

 

Description de PPP: HDLC, LCP, IPCP, CCP

A la base du protocole, il y a HDLC, High-Level Data Link Protocol (un standard ISO, utilisé dans X25) qui décrit un format de paquet avec un checksum.

     * PPP peut non seulement véhiculer dans HDLC des paquets IP mais aussi IPX ou AppleTalk.

     * LCP, Link Control Protocol, négocie des options comme MRU (Maximum Receive Unit), taille maximum du datagram que l'on peut recevoir et s'occupe s'il y a lieu de l'authentification du client, du serveur ou des deux par PAP ou CHAP.

     * Un Network Control Protocol (NCP) négocie les particularités d'un protocole. Pour IP, IPCP (RFC1332) négocie les adresses IP assignées de part et d'autre.

     * IPCP peut faire de la compression par le Compression Control Protocol (CCP)

     * CCP comporte:

     * le Van Jacobson header compression (VJ compression) des headers des paquets TCP (module slhc.o)

             * la compression des paquets par la méthode BSD qui utilise l'algorithme LZW (licence Unisys comme gif) identique à la commande compress de Unix (module bsd_comp.o )

             * la compression des paquets par la méthode Deflate: c'est la même méthode que celle de gzip. Elle est recommandée.

             * La compression consomme de la mémoire. Le serveur peut ne pas la prévoir, auquel cas la demande de compression du client sera non satisfaite. Les deux parties doivent utiliser le même algorithme.

       

       La compression dans PPP est plus performante si elle est bien paramétrée que la compression faite dans le modem (V.42).

       

       Le logiciel pppd a un fonctionnement symétrique, il joue le rôle de serveur comme de client. Les fichiers de configuration servent à la fois comme serveur et comme client. Il n'y a pas en principe de différence entre le client et le serveur. Une machine Linux peut être client, serveur ou les deux à la fois. Pour la clarté, la distinction est préférable. Dans les documents le terme "peer" désigne l'autre partenaire.

 

Sur Linux, ppp est en deux parties, l'une dans le noyau (traitement de HDLC) et l'autre sous forme du daemon pppd

http://www-phase.c-strasbourg.fr/inform/li...x-reseau-6.html

 

je lis beaucoup de liens comme celui-ci, j'arrive à en comprendre le principe mais pour l'instant ça ne m'aide pas trop

 

//vais essayer de retourner sous windows pour voir si j'ai le même problème. J'ai aucune idée si des modifs techniques sont nécessaires sur le RADIUS pour le dégroupage de FreeTél qui peuvent entraîner ce genre de souci avec un driver linux....j'appréhende de les appeler de peur de ne pas pouvoir me faire comprendre.

Modifié le 7 mai 2003 par Greywolf

[patzepat]

Contacte les pour savoir si ils n'ont pas des problèmes sur leurs serveurs d'authentification ou s'ils n'ont pas fait des modifs sur ces serveurs. N'importe quel interlocuteur de la hot-line devrait avoir l'info dans un journal d'alertes ou d'incidents.

[yul]

Pour ton probléme, honnétement gen sait rien. La j'apprend le japonais, quand jle parlerais courament, je comprendrais peut étre sque tu veut dire

 

Sinon pour la hotline, oublie. Les mecs on déja du mal avec windows sur des questions tout con comme c'est quoi le smtp de wanadoo? Alors tu pense bien que sur une debian...

A la limite fait comme dit Pat, cad contacte les pour connaitre l'état de leur serveur, mais pas plus.

Modifié le 7 mai 2003 par yul

[Greywolf]

Contacte les pour savoir si ils n'ont pas des problèmes sur leurs serveurs d'authentification ou s'ils n'ont pas fait des modifs sur ces serveurs. N'importe quel interlocuteur de la hot-line devrait avoir l'info dans un journal d'alertes ou d'incidents.

Je tenterai demain (ou plutôt après demain si les hotlines ne font pas le pont arf).

 

Mais serai-je le seul dans cette situation? j'ai parcouru les divers forums adsl et linux et à part des problèmes de DNS chez Free, ou des authentifications ratées dès le départ de la connexion nada...

 

 

//je suis repassé sous windows et il y a un truc qui me chiffonne:

sous linux, le point distant d'accès c'est 192.168.254.254 (= la passerelle internet) et mon IP locale c'est xx.xx.xx.xx

sous windows, un ipconfig /all me donne une adresse IP de passerelle par défaut identique à celle de mon IP locale(qui est fixe, d'ailleurs je sais pas si ça a un quelconque intérêt) mais par contre j'accède à internet toujours via 192.168.254.254 (traceroute) euh

 

je verrais combien de temps tient la connexion.

Modifié le 7 mai 2003 par Greywolf

[KewlCat]

(...) identique à celle de mon IP locale(qui est fixe, d'ailleurs je sais pas si ça a un quelconque intérêt)

Ah bin si, ça a un interêt de le savoir... apparemment les gens qui sont en IP fixe chez Free ont les pires problèmes de connexion, fais un tour sur le forum Free de DSLValley.com, tu verras que tu n'es pas seul !

[Greywolf]

merci de l'info Kewlcat j'avais fais des recherches sur LCP terminated by peer et pas simplement déconnexions , il semble que pour les déconnexions observées en IP fixe, les gens subissent plus qu'ils ne peuvent faire quelquechose.

 

sous windows, j'ai bien eu une déco mais ADSL autoconnect arrive à faire son taf

Info            07/05/03 22:48:01 Connexion ouverte : xx.xx.xx.xx

Erreur 08/05/03 06:28:46 Impossible de joindre l'hote : 192.168.254.254

Erreur 08/05/03 06:28:57 WinSock Error : IP_DEST_HOST_UNREACHABLE (11003).

Erreur 08/05/03 06:28:57 WinSock Error : IP_DEST_HOST_UNREACHABLE (11003).

Erreur 08/05/03 06:28:57 Impossible de joindre l'hote : 192.168.254.254

Info    08/05/03 06:29:00 Connexion refermée par ADSL Autoconnect

Info    08/05/03 06:30:47 Connexion ouverte : xx.xx.xx.xx

 

le problème c'est que le script IP-up n'arrive pas à rétablir la connexion dans les secondes qui suivent et s'arrête après x échecs, je pense qu'il y a moyen d'imposer un délai entre chaque tentative de connexion ou d'augmenter le nombre de tentatives le temps pour la passerelle de se remettre d'aplomb. Mais où??

 

les paramètres LCP-echo-interval et LCP-echo-failure du script de connexion? un truc à rajouter après l'option persist? une modif au sein même d'ip-up? (vous allez me dire man pppd, je le fais dès que je suis de retour sous linux )

[nick667]

ça me fait pareil chez moi, la connection tombe et le routeur met des fois 20 min à me reconnecter, je suis aussi en IP fixe chez Free.....

--- Log Begin ---

ADT sent

PADI sent

PADI sent

PADI sent

DOD:TCP trigger from 192.168.0.176:2274 to 81.248.133.216:4662

PPPoE start to dial-up

PADI sent

PADO recv 0016 BSPLB111

PADR sent

PADS recv 0002 D00C

CHAP3: Tunnel startup failure

LCP3: terminate request

PPP3: closed

DOD:UDP trigger from 192.168.0.176:3746 to 217.235.203.64:3337

PPPoE start to dial-up

PADT sent

PADI sent

PADO recv 0016 BSPLB111

PADR sent

PADS recv 0002 D80C

LCP3: terminate request

PPP3: closed

DOD:UDP trigger from 192.168.0.176:3746 to 217.228.226.68:4666

PPPoE start to dial-up

PADT sent

PADI sent

PADO recv 0016 BSPLB111

PADR sent

PADS recv 0002 E10C

LCP3: terminate request

PPP3: closed

DOD:TCP trigger from 192.168.0.176:3165 to 81.49.90.205:4662

PPPoE start to dial-up

PADT sent

PADI sent

PADO recv 0016 BSPLB111

PADR sent

PADS recv 0002 EA0C

LCP3: terminate request

PPP3: closed

DOD:TCP trigger from 192.168.0.176:2257 to 80.15.118.21:4662

PPPoE start to dial-up

PADT sent

PADI sent

PADO recv 0016 BSPLB111

PADR sent

PADS recv 0002 FB0C

LCP3: terminate request

PPP3: closed

DOD:TCP trigger from 192.168.0.176:3533 to 193.251.35.219:4662

PPPoE start to dial-up

PADT sent

PADI sent

PADO recv 0016 BSPLB111

PADR sent

PADS recv 0002 0C0D

PAP3: OK

IPCP3: IP is xxx.xxx.xxx.xxx

Le problème, c'est que pour moi c'est encore du chinois tout ça, je l'ai as vu en cours

[Greywolf]

PADI, PADO et PADR sont des paquets de PPPoE de "découverte d'hôte distant"

PADI : PPPoE Active Discovery Initiation => pour regarder si il y a quelqu'un au bout du fil

PADO: PPPoE Active Discovery Offer => la réponse du serveur disatnt à PADI avec une offre de session

PADR: PPPoE Active Discovery Request => la réponse du client à PADO (pour dire oui oui je veux établir une connexion)

PADS: PPPoE Active Discovery Session-Confirmation => le serveur qui re-confirme

 

=> ça ressemble comme 2 gouttes d'eau à l'initialisation d'une connexion TCP (Syn/syn-ack/ack)

 

ensuite vient la session PPP (on passe à la couche 2) avec l'envoi de paquets LCP et l'identification par CHAP (challenge envoyé par le serveur, le client l'encrypte avec comme clés son login et pass, renvoie le résultat au serveur, qui le compare au résultat qu'il obtient lui)

 

PADT: PPPoE Active Discovery Terminate => notification de fin de session

 

des réf ici : http://www.faqs.org/rfcs/rfc2516.html

 

tu reçois comme moi des LCP terminate request au moment de l'initialisation de la connexion et ce qui est bizarre c'est que tu arrives à te reconnecter non plus avec une authentification CHAP mais PAP à la fin.

 

De mon côté, j'ai modifié le paramètre maxfail de pppd de 10 à 50 pour laisser le temps au serveur distant de se remettre à l'écoute d'une nouvelle tentative de connexion avant que pppd ne laisse tomber. C'est un peu bourrin mais ça a l'air de marcher.