Problème de configuration PPPoE avec modem Ethernet Omniacom

Support Debian
#28

Pourquoi ifup eth0 ? C’est la connexion PPP qui nous intéresse, pas l’interface ethernet.
Accessoirement je n’avais pas fait attention mais il n’y a aucune raison qu’eth0 soit configurée en DHCP dans /etc/network/interfaces. D’ailleurs visiblement il n’y a pas de serveur DHCP. Elle n’a pas besoin d’être configurée, juste activée puisqu’elle ne sert que pour faire passer la connexion PPPoE. Donc si pppd/pppoe ne le fait pas automatiquement, l’option “pre-up /sbin/ifconfig eth0 up” dans le paragraphe de définition de la connexion PPP suffit.

Le log de pppoe indique que le serveur PPPoE termine la session (PADT) après quelques seconde sans qu’il se soit apparemment rien passé. Comme je l’évoquais plus haut, il se peut que le nom de service soit requis pour établir la connexion (tu peux le vérifier sous Windows en l’enlevant). Dans ce cas il faudrait essayer d’ajouter l’option “-S <service_name>” au contenu de l’option pty. Si j’ai bien compris la procédure du FAI c’est le numéro de téléphone qui tient lieu de nom de service (étape 8 ).

#29

Effectivement, le nom de service représente le numéro de téléphone.
j’ai ajouté l’option “-S 123456” comme tu l’as suggéré, ça ne marche toujours pas. Et j’ai remarqué dans les logs que j’ai souvent ppp1,ppp2, ppp3, … qui est essaient de se connecter à /dev/pts/4 , /dev/pts/5 , …
Que représente /dev/pts/4 ?
Pourquoi ppp ne pointe pas toujours sur eth0?

voici le contenu de tail -f /var/log/syslog.

Nov 26 01:09:43 debian pppd[4429]: Serial connection established.
Nov 26 01:09:43 debian pppd[4429]: Using interface ppp2
Nov 26 01:09:43 debian pppd[4429]: Connect: ppp2 <–> /dev/pts/4
Nov 26 01:09:46 debian pppd[4580]: Timeout waiting for PADO packets
Nov 26 01:09:46 debian pppd[4580]: Unable to complete PPPoE Discovery
Nov 26 01:09:46 debian pppd[4641]: Serial connection established.
Nov 26 01:09:46 debian pppd[4641]: Using interface ppp3
Nov 26 01:09:46 debian pppd[4641]: Connect: ppp3 <–> /dev/pts/6
Nov 26 01:09:56 debian pppd[4711]: No response to PAP authenticate-requests
Nov 26 01:10:02 debian pppd[4711]: Connection terminated.
Nov 26 01:10:02 debian pppd[4711]: Modem hangup
Nov 26 01:10:02 debian pppoe[5084]: read (asyncReadFromPPP): Session 2: Input/output error
Nov 26 01:10:02 debian pppoe[5084]: Sent PADT
Nov 26 01:10:14 debian pppd[4429]: LCP: timeout sending Config-Requests
Nov 26 01:10:14 debian pppd[4429]: Connection terminated.
Nov 26 01:10:14 debian pppd[4429]: Modem hangup
Nov 26 01:10:17 debian pppd[4641]: LCP: timeout sending Config-Requests
Nov 26 01:10:17 debian pppd[4641]: Connection terminated.
Nov 26 01:10:17 debian pppd[4641]: Modem hangup
Nov 26 01:10:18 debian pppoe[5147]: Timeout waiting for PADO packets
Nov 26 01:10:22 debian pppd[4580]: PPP session is 2
Nov 26 01:10:22 debian pppd[4580]: Using interface ppp1
Nov 26 01:10:22 debian pppd[4580]: Connect: ppp1 <–> eth0
Nov 26 01:10:32 debian pppd[4711]: Serial connection established.
Nov 26 01:10:32 debian pppd[4711]: Using interface ppp2
Nov 26 01:10:32 debian pppd[4711]: Connect: ppp2 <–> /dev/pts/4
Nov 26 01:10:38 debian pppoe[5156]: PADS: Service-Name: '123456’
Nov 26 01:10:38 debian pppoe[5156]: PPP session is 2 (0x2)
Nov 26 01:10:38 debian pppoe[5214]: PADS: Service-Name: '123456’
Nov 26 01:10:38 debian pppoe[5214]: PPP session is 2 (0x2)
Nov 26 01:10:38 debian pppoe[5156]: read (asyncReadFromPPP): Session 2: Input/output error
Nov 26 01:10:38 debian pppoe[5156]: Sent PADT
Nov 26 01:10:44 debian pppd[4429]: Serial connection established.
Nov 26 01:10:44 debian pppd[4429]: Using interface ppp3
Nov 26 01:10:44 debian pppd[4429]: Connect: ppp3 <–> /dev/pts/5
Nov 26 01:10:47 debian pppd[4641]: Serial connection established.
Nov 26 01:10:47 debian pppd[4641]: Using interface ppp4
Nov 26 01:10:47 debian pppd[4641]: Connect: ppp4 <–> /dev/pts/6
Nov 26 01:10:50 debian pppoe[5226]: PADS: Service-Name: '123456’
Nov 26 01:10:50 debian pppoe[5226]: PPP session is 2 (0x2)
Nov 26 01:10:50 debian pppoe[5232]: PADS: Service-Name: '123456’
Nov 26 01:10:50 debian pppoe[5232]: PPP session is 2 (0x2)
Nov 26 01:10:52 debian pppd[4580]: LCP: timeout sending Config-Requests
Nov 26 01:10:52 debian pppd[4580]: Connection terminated.
Nov 26 01:10:52 debian pppd[4580]: Modem hangup
Nov 26 01:11:03 debian pppd[4711]: LCP: timeout sending Config-Requests
Nov 26 01:11:03 debian pppd[4711]: Connection terminated.
Nov 26 01:11:03 debian pppd[4711]: Modem hangup
Nov 26 01:11:03 debian pppoe[5214]: read (asyncReadFromPPP): Session 2: Input/output error
Nov 26 01:11:03 debian pppoe[5214]: Sent PADT

#30

Il y a plusieurs interfaces ppp1, ppp2… parce qu’elles correspondent chacune à une connexion en cours. Tu as dû lancer plusieurs fois la connexion avec pon sans l’arrêter auparavant avec poff. En effet avec l’option “persist” la connexion se relance automatiquement en cas d’échec ou de coupure. Tu peux commenter cette option le temps de la mise au point. Tu peux aussi ajouter l’option “debug” pour avoir plus d’information dans les logs. /dev/pts/N représente un pseudo-terminal (l’équivalent d’un port série) par lequel chaque instance de pppd communique avec l’instance de pppoe qui a été lancée par l’option “pty”. Lorsque pppd communique directement avec eth0, c’est via le plugin rp-pppoe.so et non via l’option pty.

En résumé :

  • commenter l’option persist
  • ajouter l’option debug
  • arrêter toutes les connexions PPP en cours (à grands coups de poff, kill ou autre)
  • lancer une seule connexion à la fois (une configurée avec pty et pas plugin) et regarder les logs détaillés
#31

En analysant le contenu du /var/log/syslog que j’ai précédemment posté, pourquoi je n’arrive toujours pas à me connecter à internet?

#32

Difficile à dire. On voit différents time-outs par absence de réponse du FAI, mais comme il y a plusieurs tentatives de connexion concurrentes, pas étonnant que certaines n’aboutissent pas. Apparemment depuis que le nom de session a été spécifié il n’y a plus la réception du PADT, donc c’est un progrès. J’observe aussi qu’on ne voit pas ppp0 dans cet extrait de log, ce qui signifie qu’elle est déjà occupée ; se pourrait-il que la connexion soit établie avec celle-ci ? Avec les logs d’une seule connexion en mode debug, on devrait y voir plus clair.

#33

Apparemment, j’ai un problème d’authentification.
voici le tail -f /var/log/syslog

Nov 26 19:21:44 debian pppd[5571]: Using interface ppp0
Nov 26 19:21:44 debian pppd[5571]: Connect: ppp0 <–> /dev/pts/4
Nov 26 19:21:45 debian pppd[5571]: sent [LCP ConfReq id=0x1 <magic 0xe22d9dca> ]
Nov 26 19:21:48 debian pppoe[5572]: PADS: Service-Name: '110002’
Nov 26 19:21:48 debian pppoe[5572]: PPP session is 2 (0x2)
Nov 26 19:21:48 debian pppd[5571]: sent [LCP ConfReq id=0x1 <magic 0xe22d9dca> ]
Nov 26 19:21:48 debian pppd[5571]: rcvd [LCP ConfReq id=0x53 <mru 1492> <asyncmap 0x9e> ]
Nov 26 19:21:48 debian pppd[5571]: sent [LCP ConfRej id=0x53 <asyncmap 0x9e>]
Nov 26 19:21:48 debian pppd[5571]: rcvd [LCP ConfRej id=0x1 <magic 0xe22d9dca> ]
Nov 26 19:21:48 debian pppd[5571]: sent [LCP ConfReq id=0x2]
Nov 26 19:21:48 debian pppd[5571]: rcvd [LCP ConfRej id=0x1 <magic 0xe22d9dca> ]
Nov 26 19:21:48 debian pppd[5571]: rcvd [LCP ConfReq id=0x54 <mru 1492> ]
Nov 26 19:21:48 debian pppd[5571]: sent [LCP ConfAck id=0x54 <mru 1492> ]
Nov 26 19:21:48 debian pppd[5571]: rcvd [LCP ConfNak id=0x2 <mru 1492>]
Nov 26 19:21:48 debian pppd[5571]: sent [LCP ConfReq id=0x3 <mru 1492>]
Nov 26 19:21:48 debian pppd[5571]: rcvd [LCP ConfAck id=0x3 <mru 1492>]
Nov 26 19:21:48 debian pppd[5571]: sent [LCP EchoReq id=0x0 magic=0x0]
Nov 26 19:21:48 debian pppd[5571]: sent [PAP AuthReq id=0x1 user=“mon_login” password=]
Nov 26 19:21:48 debian pppd[5571]: rcvd [LCP EchoRep id=0x0 magic=0x0]
Nov 26 19:21:51 debian pppd[5571]: sent [PAP AuthReq id=0x2 user=“mon_login” password=]
Nov 26 19:21:54 debian pppd[5571]: sent [PAP AuthReq id=0x3 user=“mon_login” password=]
Nov 26 19:21:57 debian pppd[5571]: sent [PAP AuthReq id=0x4 user=“mon_login” password=]
Nov 26 19:22:00 debian pppd[5571]: sent [PAP AuthReq id=0x5 user=“mon_login” password=]
Nov 26 19:22:03 debian pppd[5571]: sent [PAP AuthReq id=0x6 user=“mon_login” password=]
Nov 26 19:22:06 debian pppd[5571]: sent [PAP AuthReq id=0x7 user=“mon_login” password=]
Nov 26 19:22:08 debian pppd[5571]: sent [LCP EchoReq id=0x1 magic=0x0]
Nov 26 19:22:08 debian pppd[5571]: rcvd [LCP EchoRep id=0x1 magic=0x0]
Nov 26 19:22:09 debian pppd[5571]: sent [PAP AuthReq id=0x8 user=“mon_login” password=]
Nov 26 19:22:12 debian pppd[5571]: sent [PAP AuthReq id=0x9 user=“mon_login” password=]
Nov 26 19:22:15 debian pppd[5571]: sent [PAP AuthReq id=0xa user=“mon_login” password=]
Nov 26 19:22:18 debian pppd[5571]: No response to PAP authenticate-requests
Nov 26 19:22:18 debian pppd[5571]: sent [LCP TermReq id=0x4 “Failed to authenticate ourselves to peer”]
Nov 26 19:22:21 debian pppd[5571]: sent [LCP TermReq id=0x5 “Failed to authenticate ourselves to peer”]
Nov 26 19:22:24 debian pppd[5571]: Connection terminated.

Avez-vous une idée?

#34

Effectivement. Le FAI demande une authentification PAP, pppd l’envoie mais le FAI n’y répond pas et pppd finit par perdre patience. Tu as bien vérifié les identifiants dans /etc/ppp/pap-secrets et chap-secrets ? Ceci dit en cas de mauvais login ou mot de passe le FAI devrait rejeter l’authentification, au lieu de faire la sourde oreille.

Au cas où il y aurait un problème avec l’authentification PAP tu peux essayer de refuser PAP et forcer CHAP soit en commentant la ligne dans pap-secrets soit en ajoutant l’option “refuse-pap” au fichier d’options dans /etc/ppp/peers/.

#35

je ne crois pas que le probleme vienne de /etc/ppp/pap…
Il n’y a qu’une seule ligne qui contient le login et le password.
Pour le chap, je ne peut pas forcer car le serveur du FAI est configure pour une authentification pap.
En analisant le log, j’ai l’impression que la requete s’authentification n’arrive pas chez le FAi. Sinon, on aurait un message de rejet ou autre.
A mon avis, le probleme est local, au niveau de ma machine.

#36

Je ne vois pas pourquoi, car il y a bien un dialogue LCP, donc ça cause dans les deux sens.

EDIT : tu pourrais “écouter” le trafic PPPoE sur eth0 avec tcpdump, wireshark… pour voir ce qui passe.

#37

Pas de trafic au niveau eth0.
Je crois que le log nous montre bien le problème. La requête d’authentification n’aboutit pas. Il y a forcément un problème au niveau du fichier /etc/ppp/peers/dsl-provider.
Je vais passer un moment à travailler dessus et j’espère trouver une solution. Le “debug” nous a permis d’avoir de plus amples informations.

#38

Pas possible qu’il n’y ait pas de trafic. Il y a de la communication PPPoE et LCP dans les deux sens, donc ça passe forcément sur eth0.

#39

Bonjour,
Finalement, je me suis rendu compte que c’est le paramètre “default-asyncmap” qui empechait la requête d’authentification PAP d’aboutir.
Je l’ai commenté et ça y est; la requête a abouti et la liaison s’est établie sans problème.
A présent la connexion internet marche très bien!
Merci à Pascalhambourg et tous les autres membres pour votre assistance.

#40

Merci pour le retour.
Je n’ai jamais fait particulièrement attention à cette option. J’observe qu’elle figure aussi dans mon fichier dsl-provider (que je n’ai jamais utilisé) mais dans aucun de mes propres fichiers de configuration de pppd, que ce soit avec PPPoE, PPTP, PPPoA ou modem classique.

#41

Bonjour à tous,

Je viens creer une interface sur une passerelle de mon reseau qui est connecté en RJ45 à un modem en PPOE. Etant donné que cette passerelle a déja sa route vers internet de configuré j’ai commenté l’option default route du fichier de conf:

[code]klnet01:/etc/ppp/peers# cat dsl-provider | grep default
#noipdefault

Use this connection as the default route.

Comment out if you already have the correct default route installed.

#defaultroute
[/code]

Pourtant lorsque je lance la connexion et que mon interface ppp0 se monte, mon serveur n’accède plus à Internet:

klnet01:/etc/ppp/peers# ping google.fr PING google.fr (209.85.148.147) 56(84) bytes of data. 64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_seq=1 ttl=57 time=23.6 ms 64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_seq=2 ttl=57 time=27.9 ms

klnet01:/etc/ppp/peers# route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 212.11.48.80 0.0.0.0 255.255.255.248 U 0 0 0 eth1 192.168.7.0 192.168.1.1 255.255.255.0 UG 0 0 0 eth0 192.168.6.0 192.168.1.1 255.255.255.0 UG 0 0 0 eth0 172.19.251.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 192.168.4.0 192.168.1.1 255.255.255.0 UG 0 0 0 eth0 192.168.3.0 192.168.1.1 255.255.255.0 UG 0 0 0 eth0 192.168.50.0 192.168.1.1 255.255.255.0 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.0.0.0 192.168.1.1 255.0.0.0 UG 0 0 0 eth0 0.0.0.0 212.11.48.81 0.0.0.0 UG 0 0 0 eth1

klnet01:/etc/ppp/peers# pon dsl-provider Plugin rp-pppoe.so loaded.

klnet01:/etc/ppp/peers# ping google.fr

klnet01:/etc/ppp/peers# route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 178.32.37.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 212.11.48.80 0.0.0.0 255.255.255.248 U 0 0 0 eth1 192.168.7.0 192.168.1.1 255.255.255.0 UG 0 0 0 eth0 192.168.6.0 192.168.1.1 255.255.255.0 UG 0 0 0 eth0 172.19.251.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 192.168.4.0 192.168.1.1 255.255.255.0 UG 0 0 0 eth0 192.168.3.0 192.168.1.1 255.255.255.0 UG 0 0 0 eth0 192.168.50.0 192.168.1.1 255.255.255.0 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.0.0.0 192.168.1.1 255.0.0.0 UG 0 0 0 eth0 0.0.0.0 212.11.48.81 0.0.0.0 UG 0 0 0 eth1

J’ai loupé quelque chose?

Merci d’avance

#42

Petite correction ce n’ets pas la connexion qui ne fonctionne plus, en fait il n’y a plus de resolution DNS. J’imagine qu’il me reste à bien configurer pour que ca fonctionne.

Bonne après midi à vous

[EDIT] il fallait commenter l’option suivante:

[code]klnet01:/etc/ppp/peers# cat dsl-provider | grep -C 1 usepeerdns

Try to get the name server addresses from the ISP.

#usepeerdns

Use this connection as the default route.[/code]

#43

Bonjour à tous,

Me revoilà avec un pti souci.

Mon interface ppp0 ne “tient pas” dans le temps, elle se démonte régulièrement mais le système n’essaie pas automatiquement de la remonter je suis obligé d’executer la commande “pon dsl-provider”

voici la config:

[code]klnet01:/etc/ppp/ip-up.d# cat /etc/network/interfaces | grep -A 9 “# Config necessaire pour l’interface ppp0”

Config necessaire pour l’interface ppp0

auto dsl-provider
iface dsl-provider inet ppp
pre-up /sbin/ifconfig eth2 up # line maintained by pppoeconf
provider dsl-provider

(remplacé par deux scripts dans /etc/ppp.ifup.d et ifdown.d) Ajout de la route vers l’ip de KLnet04 en passant par l’ADSL OVH (passerelle de l’interface ppp0)

#up route add 87.98.155.142 gw 178.32.37.1[/code]

Merci d’avance

#44

Il faut ajouter l’option persist dans le fichier d’options de pppd (dsl-provider) pour qu’il y ait reconnexion automatique.

#45

Elle y est déja.

[code]klnet01:/home/jrivoire# cat /etc/ppp/peers/dsl-provider | grep -B 5 persist
lcp-echo-interval 20
lcp-echo-failure 3

Override any connect script that may have been set in /etc/ppp/options.

connect /bin/true
noauth
persist
[/code]

Entre temps j’ai trouvé cette doc: help.ubuntu.com/community/ADSLPPPoE et j’ai ajouté ceci au fichier /etc/rc.local. mais j’avoue ne pas savoir à quel moment intervient ce fichier /etc/rc.local…

ip link set dev eth0 up pon dsl-provider

#46

Dans ce cas je ne vois pas. Il faudrait activer l’option debug et analyser les logs de pppd dans /var/log/syslog pour voir pourquoi ça ne reconnecte pas.

C’est inutile et redondant avec la définition dans /etc/network/interfaces.
De mémoire, rc.local est exécuté à la fin du démarrage du système (après les scripts d’init).

#47

Entendu j’active le debug de ce pas et je surveillerai

Merci à toi!