Modem mode bridge, pppoe et pas de résolution de nom

Support Debian
#1

Bonjour,
ma connexion avec mon FAI a tendance à “tomber” de temps en temps et mon modem
n’a pas de fonction pour la rétablir automatiquement donc je souhaite le passer en mode bridge et établir la connection depuis un PC.

D’après les logs, la connexion s’établit.
Je peux pinguer la “passerelle” de mon FAI mais rien d’autre
La résolution de nom ne fonctionne pas.
N’ayant jamais utilisé ppp auparavant, je loupe probablement une évidence …

Le fichier de conf de ppp et quelques logs :

default: set log Phase Chat LCP IPCP CCP tun command pppoe: set device "!/usr/sbin/pppoe -i msk0" set mtu max 1492 set mru max 1492 set speed sync disable acfcomp protocomp deny acfcomp set authname "numero@FAI" set authkey "secret" enable dns # avec ou sans ça ne change pas mon problème

tun0 est une interface virtuelle, msk0 une interface ethernet.

Phase: Using interface: tun0 Phase: deflink: Created in closed state tun0: Command: pppoe: set device !/usr/sbin/pppoe -i msk0 tun0: Command: pppoe: set mtu max 1492 tun0: Command: pppoe: set mru max 1492 tun0: Command: pppoe: set speed sync tun0: Command: pppoe: disable acfcomp protocomp tun0: Command: pppoe: deny acfcomp tun0: Command: pppoe: set authname numero@FAI tun0: Command: pppoe: set authkey ******** tun0: Phase: PPP Started (ddial mode). tun0: Phase: bundle: Establish tun0: Phase: deflink: closed -> opening tun0: Phase: deflink: Connected! tun0: Phase: deflink: opening -> dial tun0: Phase: deflink: dial -> carrier tun0: Phase: deflink: carrier -> login tun0: Phase: deflink: login -> lcp tun0: LCP: FSM: Using "deflink" as a transport tun0: LCP: deflink: State change Initial --> Closed tun0: LCP: deflink: State change Closed --> Stopped tun0: LCP: deflink: RecvConfigReq(0) state = Stopped tun0: LCP: MRU[4] 1492 tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) tun0: LCP: MAGICNUM[6] 0xc4c99aaf tun0: Warning: deflink: Reducing configured MRU from 1500 to 1492 tun0: LCP: deflink: SendConfigReq(1) state = Stopped tun0: LCP: MRU[4] 1492 tun0: LCP: MAGICNUM[6] 0x29d34d12 tun0: LCP: deflink: SendConfigAck(0) state = Stopped tun0: LCP: MRU[4] 1492 tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) tun0: LCP: MAGICNUM[6] 0xc4c99aaf tun0: LCP: deflink: LayerStart tun0: LCP: deflink: State change Stopped --> Ack-Sent tun0: LCP: deflink: RecvConfigAck(1) state = Ack-Sent tun0: LCP: MRU[4] 1492 tun0: LCP: MAGICNUM[6] 0x29d34d12 tun0: LCP: deflink: State change Ack-Sent --> Opened tun0: LCP: deflink: LayerUp tun0: Phase: bundle: Authenticate tun0: Phase: deflink: his = CHAP 0x05, mine = none tun0: Phase: Chap Input: CHALLENGE (16 bytes) tun0: Phase: Chap Output: RESPONSE (numero@FAI) tun0: LCP: deflink: RecvConfigReq(171) state = Opened tun0: LCP: deflink: LayerDown tun0: LCP: MRU[4] 1492 tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) tun0: LCP: MAGICNUM[6] 0xc4c99aaf tun0: Warning: deflink: Reducing configured MRU from 1500 to 1492 tun0: LCP: deflink: SendConfigReq(2) state = Opened tun0: LCP: MRU[4] 1492 tun0: LCP: MAGICNUM[6] 0x2bae9e81 tun0: LCP: deflink: SendConfigAck(171) state = Opened tun0: LCP: MRU[4] 1492 tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) tun0: LCP: MAGICNUM[6] 0xc4c99aaf tun0: LCP: deflink: State change Opened --> Ack-Sent tun0: LCP: deflink: RecvConfigAck(2) state = Ack-Sent tun0: LCP: MRU[4] 1492 tun0: LCP: MAGICNUM[6] 0x2bae9e81 tun0: LCP: deflink: State change Ack-Sent --> Opened tun0: LCP: deflink: LayerUp tun0: Phase: deflink: his = CHAP 0x05, mine = none tun0: Phase: Chap Input: CHALLENGE (16 bytes from SE800-MIT-2) tun0: Phase: Chap Output: RESPONSE (numero@FAI) tun0: Phase: Chap Input: SUCCESS tun0: CCP: FSM: Using "deflink" as a transport tun0: CCP: deflink: State change Initial --> Closed tun0: CCP: deflink: LayerStart. tun0: CCP: MPPE: Not usable without CHAP81 tun0: CCP: deflink: SendConfigReq(1) state = Closed tun0: CCP: DEFLATE[4] win 15 tun0: CCP: PRED1[2] tun0: CCP: deflink: State change Closed --> Req-Sent tun0: Phase: deflink: lcp -> open tun0: Phase: bundle: Network tun0: IPCP: FSM: Using "deflink" as a transport tun0: IPCP: deflink: State change Initial --> Closed tun0: IPCP: deflink: LayerStart. tun0: IPCP: deflink: SendConfigReq(1) state = Closed tun0: IPCP: IPADDR[6] 127.0.0.1 tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression tun0: IPCP: deflink: State change Closed --> Req-Sent tun0: IPCP: deflink: RecvConfigReq(1) state = Req-Sent tun0: IPCP: IPADDR[6] 178.32.37.13 tun0: IPCP: deflink: SendConfigAck(1) state = Req-Sent tun0: IPCP: IPADDR[6] 178.32.37.13 tun0: IPCP: deflink: State change Req-Sent --> Ack-Sent tun0: LCP: deflink: RecvProtocolRej(1) state = Opened tun0: LCP: deflink: -- Protocol 0x80fd (Compression Control Protocol) was rejected! tun0: CCP: deflink: State change Req-Sent --> Stopped tun0: IPCP: deflink: RecvConfigRej(1) state = Ack-Sent tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression tun0: IPCP: deflink: SendConfigReq(2) state = Ack-Sent tun0: IPCP: IPADDR[6] 127.0.0.1 tun0: IPCP: deflink: RecvConfigNak(2) state = Ack-Sent tun0: IPCP: IPADDR[6] XX.XX.XX.XX tun0: IPCP: IPADDR[6] changing address: 127.0.0.1 --> X.X.X.X tun0: IPCP: deflink: SendConfigReq(3) state = Ack-Sent tun0: IPCP: IPADDR[6] X.X.X.X tun0: IPCP: deflink: RecvConfigAck(3) state = Ack-Sent tun0: IPCP: IPADDR[6] X.X.X.X tun0: IPCP: deflink: State change Ack-Sent --> Opened tun0: IPCP: deflink: LayerUp. tun0: IPCP: myaddr X.X.X.X hisaddr = 178.32.37.13 tun0: LCP: deflink: RecvEchoRequest(1) state = Opened tun0: LCP: deflink: SendEchoReply(1) state = Opened
puis les deux dernières lignes se répètent plein de fois …

Des idées de commandes pour faire un bon diagnostic ?

Je precise que sur la machine depuis laquelle j’essaie la connexion ppp se trouve un serveur de nom fonctionnel en temps normal ( quand mon modem s’occupe lui-même de la liaison ppp )

#2

Que contient la table de routage (route -n ou ip route) quand la connexion est établie ?

Que contient /etc/resolv.conf quand la connexion est établie ?

Ça ne ressemble pas à un fichier de configuration ni des logs de pppd. Avec quel programme la connexion est-elle établie ?

#3

[code]Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
127/8 127.0.0.1 UGRS 0 0 33200 8 lo0
127.0.0.1 127.0.0.1 UH 2 23277 33200 4 lo0
178.32.37.13 mon_ip UH 0 13 - 4 tun0
192.168.1/24 link#1 UC 1 0 - 4 msk0
192.168.1.10 00:13:77:f2:cb:e9 UHLc 5 2063 - 4 msk0
192.168.1.11 127.0.0.1 UGHS 0 1436 33200 8 lo0
224/4 127.0.0.1 URS 0 0 33200 8 lo0 [/code]
Je n’ai pas ajouté la partie ipv6

Le lien vers 178.32.37.13 ( qui est la “passerelle” de mon FAI ) l’est par l’interface virtuelle tun0.
C’est la première chose que je dois modifier, non ?

[quote=“PascalHambourg”]Que contient /etc/resolv.conf quand la connexion est établie ?[/quote]search blah lookup file bind nameserver 91.121.161.184 nameserver 188.165.197.144
Les dns du FAI.
Pour être sur j’ai essayé avec et sans mon serveur de nom d’activé.

J’ai passé les logs à travers cut, histoire d’alleger en supprimant
date heure machine démon etc … en début de ligne.
le programme utilisé est pppd et c’est bien son fichier de conf que j’ai posté.

Je pensais que mon problème est agnostique du point de vue du système d’exploitation,
que mon erreur vient d’une méconnaissance de l’administration réseau
alors j’ai aussi posté ici car il y a bien plus de passage que sur le forum dédié
et je pourrais aussi récolter de précieuses infos.

Allez, un petit traceroute pour la route :$ traceroute 178.32.37.13 traceroute to 178.32.37.13 (178.32.37.13), 64 hops max, 40 byte packets 1 178.32.37.13 (178.32.37.13) 35.712 ms * 34.914 ms
Mais bon, je pense que tu l’avais déjà déduit du résultat de route -n …

#4

Bon, c’est résolu, enfin presque.
Ça fonctionne en mode interactif depuis la ligne de commande,
reste plus qu’à finaliser le fichier de conf pour automatiser le tout.

Pour la petite histoire, bien que les logs m’indiquait une connexion réussie vers le FAI, il fallait que j’ajoute manuellement la route vers le FAI dans le prompt de ppp, mais ça doit pouvoir se faire depuis le fichier de conf …

Merci Pascal, tu m’as quand même mis sur le chemin avec tes questions sur les routes.

Donc en résumé, aucun problème avec le dns, désolé d’avoir chosi un mauvais titre.

#5

J’ai beaucoup utilisé pppd et ses fichiers de conf sur GNU/Linux, et ça ne ressemble à rien de ce que je connais.
La table de routage ne ressemble pas non plus à celle d’un système Linux. Notamment l’interface de loopback de Linux est lo et non lo0, et le nom de l’interface créée par pppd est de la forme ppp*, pas tun*. Ce ne serait pas un système *BSD ?

En tout cas la table de routage montrait qu’il manquait la route par défaut sur tun0. Il y a peut-être une option de type ‘defaultroute’ à ajouter au fichier de configuration.

#6

Saluts,

Pourrais tu m’en dire plus sur cette application s’il te plaît …

[quote]J’ai passé les logs à travers cut, histoire d’alleger en supprimant
date heure machine démon etc … en début de ligne.[/quote]
aptitude search reste vague pour moi sur ce coup là, où alors … quelle est donc ce doux paquet … :083

#7

cut est une commande UNIX/POSIX

#8

Salut,

Merci M3t4linux,

n’as tu pas un lien pour son utilisation, parce que là, brut … :033

#9

http://www.funix.org/fr/unix/filtres.htm

#10

je viens de lancé :~$ cut --help et man cut, c’est chaud …

Merci pour le lien l’ami, super cool ça Les filtres UNIX :023

-edit-

Je vais trouver un grand intérêt à ce lien funix.org/fr/unix/ … merci M3t4linux :wink:

#11

J’ai beaucoup utilisé pppd et ses fichiers de conf sur GNU/Linux, et ça ne ressemble à rien de ce que je connais.
La table de routage ne ressemble pas non plus à celle d’un système Linux. Notamment l’interface de loopback de Linux est lo et non lo0, et le nom de l’interface créée par pppd est de la forme ppp*, pas tun*. Ce ne serait pas un système *BSD ?[/quote]
Tu as raison, pppd est ce qui apparaît dans les logs mais la commande était ppp,
oui le système est un *BSD, comme dit plus haut, j’ai aussi posté ici car je pensais que mes erreurs était liées à mon ignorance des bases du réseau,
( l’apprentissage avance lentement mais sûrement, en tout cas je l’espère )
connaisances que j’estimais pouvoir être apportées indépendamment du système utilisé et aussi parce que la fréquentation est bien plus élévé ici que là-bas.

Sinon, j’ai aussi essayé depuis la Debian, mais j’ai un peu triché …
pppoeconf a tout fait tout seul.

[quote=“PascalHambourg”]En tout cas la table de routage montrait qu’il manquait la route par défaut sur tun0. Il y a peut-être une option de type ‘defaultroute’ à ajouter au fichier de configuration.[/quote]Oui, j’en étais arrivé aux mêmes conclusions suite à ton poste précédent.

#12

Seulement à première vue, tu verras à l’usage c’est tout simple.

[quote=“loreleil.747”]Merci pour le lien l’ami, super cool ça Les filtres UNIX :023

-edit-

Je vais trouver un grand intérêt à ce lien funix.org/fr/unix/ … merci M3t4linux :wink:[/quote]

Content que ce fil vous ait servi aussi à d’autres.

#13

C’est un système Debian/kFreeBSD ou un “pur” BSD ? (Je connais aussi peu l’un que l’autre, c’est juste par curiosité.)

#14

[quote=“PascalHambourg”]C’est un système Debian/kFreeBSD ou un “pur” BSD ?[/quote] OpenBSD

Depuis j’ai lu qu’il existe une autre façon d’y “gérer” ppp
directement depuis le noyau qui est présenté comme plus efficace, faut juste que je familiarise avec.[quote=“PascalHambourg”](Je connais aussi peu l’un que l’autre, c’est juste par curiosité.)[/quote]Vraiment ?
Depuis que je fréquente ce forum je tombe régulièrement sur tes interventions et je me dis que quelqu’un avec tes connaissances pourrait “s’éclater” avec OpenBSD.

Sans tomber dans le prosélytisme primaire avoir un système sur lequel le serveur mail
( OpenSMTPD qui n’est pas encore celui par défaut parce que trop neuf mais déjà parfaitement utilisable )
se configure en moins de 10 lignes ( et encore dans les cas complexes, chez moi, c’est 5 lignes ) est AMHA un bon aperçu de la simplicité du système.

Je ne vais pas m’étendre sur le sujet, mais je pense que ce c’est un système qui pourrait rapidement gagner tes faveurs si tu te penches dessus.