J'ai un problème assez curieux avec ma passerelle internet sous
NetBSD3 : en gros, quand la ligne ADSL est déconnectée et reconnectée,
le PPP ne redétecte pas convenablement l'endpoint du tunnel : un
ifconfig pppoe0 montre par exemple :
Les routes sont du même goût, et, du coup, ça marche très mal. Comme
c'est un site distant (pas loin, mais quand-même) et que le VPN passe
par internet, c'est un poil agaçant.
Il me semble avoir scrupuleusement suivi les instructions du manuel, et,
d'ailleurs, si je relance à la mano la connexion (reboot du PC ou du
modem), ça marche tout seul sans mon intervention.
Pour le moment, j'ai rajouté un script ALC qui greppe 0.0.0.1 dans
ifconfig pppoe0, mais bon...
Quelqu'un aurait une idée du coupable :
- mon provider (les déconnexions sont voulues, pour forcer les
changements d'IP)?
- mon fidèle mais néanmoins vieillissant modem ADSL speedtouch ?
- moi ?
Fred
--
Au bout De la course Remonte jusqu'a A la source One trip One noise
Circuit Nuit bleue Spécialiste De l'enjeu One trip One noise
Longue attente avant de s'elancer One trip (Noir Désir,
Longue vie et tout a recracher One noise One Trip / One Noise)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Manuel Bouyer
F. Senault wrote:
Oy.
J'ai un problème assez curieux avec ma passerelle internet sous NetBSD3 : en gros, quand la ligne ADSL est déconnectée et reconnectée, le PPP ne redétecte pas convenablement l'endpoint du tunnel : un ifconfig pppoe0 montre par exemple :
Les routes sont du même goût, et, du coup, ça marche très mal. Comme c'est un site distant (pas loin, mais quand-même) et que le VPN passe par internet, c'est un poil agaçant.
Il me semble avoir scrupuleusement suivi les instructions du manuel, et, d'ailleurs, si je relance à la mano la connexion (reboot du PC ou du modem), ça marche tout seul sans mon intervention.
Pour le moment, j'ai rajouté un script ALC qui greppe 0.0.0.1 dans ifconfig pppoe0, mais bon...
Quelqu'un aurait une idée du coupable : - mon provider (les déconnexions sont voulues, pour forcer les changements d'IP)?
Peut-etre. Il faudrait faire tourner tcpdump -s 1500 sur l'interface ethernet (eventuellement avec les bonne options ou un grep pour par que le fichier de sortie soit trop gros) pour voir ce que le materiel en face renvoie quand la connection tombe puis remonte (tcpdump decode tres bien le protocole pppoe).
- mon fidèle mais néanmoins vieillissant modem ADSL speedtouch ?
Je ne pense pas. J'ai aussi un speedtouch+pppoe (mais sous NetBSD-2 pour l'instant).
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
F. Senault <fred@lacave.net> wrote:
Oy.
J'ai un problème assez curieux avec ma passerelle internet sous
NetBSD3 : en gros, quand la ligne ADSL est déconnectée et reconnectée,
le PPP ne redétecte pas convenablement l'endpoint du tunnel : un
ifconfig pppoe0 montre par exemple :
Les routes sont du même goût, et, du coup, ça marche très mal. Comme
c'est un site distant (pas loin, mais quand-même) et que le VPN passe
par internet, c'est un poil agaçant.
Il me semble avoir scrupuleusement suivi les instructions du manuel, et,
d'ailleurs, si je relance à la mano la connexion (reboot du PC ou du
modem), ça marche tout seul sans mon intervention.
Pour le moment, j'ai rajouté un script ALC qui greppe 0.0.0.1 dans
ifconfig pppoe0, mais bon...
Quelqu'un aurait une idée du coupable :
- mon provider (les déconnexions sont voulues, pour forcer les
changements d'IP)?
Peut-etre. Il faudrait faire tourner tcpdump -s 1500 sur l'interface
ethernet (eventuellement avec les bonne options ou un grep pour par que
le fichier de sortie soit trop gros) pour voir ce que le materiel en
face renvoie quand la connection tombe puis remonte (tcpdump decode tres
bien le protocole pppoe).
- mon fidèle mais néanmoins vieillissant modem ADSL speedtouch ?
Je ne pense pas. J'ai aussi un speedtouch+pppoe (mais sous NetBSD-2 pour
l'instant).
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
J'ai un problème assez curieux avec ma passerelle internet sous NetBSD3 : en gros, quand la ligne ADSL est déconnectée et reconnectée, le PPP ne redétecte pas convenablement l'endpoint du tunnel : un ifconfig pppoe0 montre par exemple :
Les routes sont du même goût, et, du coup, ça marche très mal. Comme c'est un site distant (pas loin, mais quand-même) et que le VPN passe par internet, c'est un poil agaçant.
Il me semble avoir scrupuleusement suivi les instructions du manuel, et, d'ailleurs, si je relance à la mano la connexion (reboot du PC ou du modem), ça marche tout seul sans mon intervention.
Pour le moment, j'ai rajouté un script ALC qui greppe 0.0.0.1 dans ifconfig pppoe0, mais bon...
Quelqu'un aurait une idée du coupable : - mon provider (les déconnexions sont voulues, pour forcer les changements d'IP)?
Peut-etre. Il faudrait faire tourner tcpdump -s 1500 sur l'interface ethernet (eventuellement avec les bonne options ou un grep pour par que le fichier de sortie soit trop gros) pour voir ce que le materiel en face renvoie quand la connection tombe puis remonte (tcpdump decode tres bien le protocole pppoe).
- mon fidèle mais néanmoins vieillissant modem ADSL speedtouch ?
Je ne pense pas. J'ai aussi un speedtouch+pppoe (mais sous NetBSD-2 pour l'instant).
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
F. Senault
F. Senault wrote:
Oy.
Quelqu'un aurait une idée du coupable : - mon provider (les déconnexions sont voulues, pour forcer les changements d'IP)?
Peut-etre. Il faudrait faire tourner tcpdump -s 1500 sur l'interface ethernet (eventuellement avec les bonne options ou un grep pour par que le fichier de sortie soit trop gros) pour voir ce que le materiel en face renvoie quand la connection tombe puis remonte (tcpdump decode tres bien le protocole pppoe).
Hélas, c'est une passerelle internet - le dump atteindrait rapidement des tailles impossibles à gérer, et, la dernière fois, le tout a tenu environ une semaine avant de tomber.
Mh. Lancer le dump depuis le script ip-down d'ifwatchd, ça semble réalisable ?
- mon fidèle mais néanmoins vieillissant modem ADSL speedtouch ?
Je ne pense pas. J'ai aussi un speedtouch+pppoe (mais sous NetBSD-2 pour l'instant).
Quand je dis vieillissant, en fait, c'est carrément obsolète, sans oublier qu'il a été "bricolé" (mis à jour pour en faire un routeur, puis re-downgradé ; il perd ses paramètres de temps en temps si le courant se coupe, ce genre de choses).
Mais bon, je doute aussi très fort de cette éventualité, vu que ça ne se reproduit que lors d'une reconnexion...
Il y a des références simples sur le fonctionnement global de pppoe/oa dans le contexte d'une connexion ADSL (comment le protocole attribue l'IP, gère l'authentification, ce genre de choses) ?
Fred -- Petite soeur de mes nuits Ca m'a manqué tout ça Quand tu sauvais la face A bien d'autres que moi Sache que je n'oublie rien mais qu'on efface A ton étoile (Noir Désir, A ton étoile)
F. Senault <fred@lacave.net> wrote:
Oy.
Quelqu'un aurait une idée du coupable :
- mon provider (les déconnexions sont voulues, pour forcer les
changements d'IP)?
Peut-etre. Il faudrait faire tourner tcpdump -s 1500 sur l'interface
ethernet (eventuellement avec les bonne options ou un grep pour par que
le fichier de sortie soit trop gros) pour voir ce que le materiel en
face renvoie quand la connection tombe puis remonte (tcpdump decode tres
bien le protocole pppoe).
Hélas, c'est une passerelle internet - le dump atteindrait rapidement
des tailles impossibles à gérer, et, la dernière fois, le tout a tenu
environ une semaine avant de tomber.
Mh. Lancer le dump depuis le script ip-down d'ifwatchd, ça semble
réalisable ?
- mon fidèle mais néanmoins vieillissant modem ADSL speedtouch ?
Je ne pense pas. J'ai aussi un speedtouch+pppoe (mais sous NetBSD-2 pour
l'instant).
Quand je dis vieillissant, en fait, c'est carrément obsolète, sans
oublier qu'il a été "bricolé" (mis à jour pour en faire un routeur, puis
re-downgradé ; il perd ses paramètres de temps en temps si le courant se
coupe, ce genre de choses).
Mais bon, je doute aussi très fort de cette éventualité, vu que ça ne se
reproduit que lors d'une reconnexion...
Il y a des références simples sur le fonctionnement global de pppoe/oa
dans le contexte d'une connexion ADSL (comment le protocole attribue
l'IP, gère l'authentification, ce genre de choses) ?
Fred
--
Petite soeur de mes nuits Ca m'a manqué tout ça
Quand tu sauvais la face A bien d'autres que moi
Sache que je n'oublie rien mais qu'on efface
A ton étoile (Noir Désir, A ton étoile)
Quelqu'un aurait une idée du coupable : - mon provider (les déconnexions sont voulues, pour forcer les changements d'IP)?
Peut-etre. Il faudrait faire tourner tcpdump -s 1500 sur l'interface ethernet (eventuellement avec les bonne options ou un grep pour par que le fichier de sortie soit trop gros) pour voir ce que le materiel en face renvoie quand la connection tombe puis remonte (tcpdump decode tres bien le protocole pppoe).
Hélas, c'est une passerelle internet - le dump atteindrait rapidement des tailles impossibles à gérer, et, la dernière fois, le tout a tenu environ une semaine avant de tomber.
Mh. Lancer le dump depuis le script ip-down d'ifwatchd, ça semble réalisable ?
- mon fidèle mais néanmoins vieillissant modem ADSL speedtouch ?
Je ne pense pas. J'ai aussi un speedtouch+pppoe (mais sous NetBSD-2 pour l'instant).
Quand je dis vieillissant, en fait, c'est carrément obsolète, sans oublier qu'il a été "bricolé" (mis à jour pour en faire un routeur, puis re-downgradé ; il perd ses paramètres de temps en temps si le courant se coupe, ce genre de choses).
Mais bon, je doute aussi très fort de cette éventualité, vu que ça ne se reproduit que lors d'une reconnexion...
Il y a des références simples sur le fonctionnement global de pppoe/oa dans le contexte d'une connexion ADSL (comment le protocole attribue l'IP, gère l'authentification, ce genre de choses) ?
Fred -- Petite soeur de mes nuits Ca m'a manqué tout ça Quand tu sauvais la face A bien d'autres que moi Sache que je n'oublie rien mais qu'on efface A ton étoile (Noir Désir, A ton étoile)
F. Senault
F. Senault écrivait :
Mh. Lancer le dump depuis le script ip-down d'ifwatchd, ça semble réalisable ?
Oui c'est un script tu mets ce que tu veux dedans.
Oui, ça, je sais. Mais est-ce que c'est une bonne idée, c'est surtout la question.
Fred -- De la gelée encore Du givre au bord des lèvres Ah mais où sont les mots secrets ? C'est des bornes d'hôpital C'est des couloirs en vrac Du néon malicieux Et de la douche en laque Hosanna, Hosanna Et en route pour la joie (Noir Désir, En route pour la joie)
F. Senault écrivait :
Mh. Lancer le dump depuis le script ip-down d'ifwatchd, ça semble
réalisable ?
Oui c'est un script tu mets ce que tu veux dedans.
Oui, ça, je sais. Mais est-ce que c'est une bonne idée, c'est surtout
la question.
Fred
--
De la gelée encore Du givre au bord des lèvres Ah mais où sont les
mots secrets ? C'est des bornes d'hôpital C'est des couloirs en vrac
Du néon malicieux Et de la douche en laque Hosanna, Hosanna Et en
route pour la joie (Noir Désir, En route pour la joie)
Mh. Lancer le dump depuis le script ip-down d'ifwatchd, ça semble réalisable ?
Oui c'est un script tu mets ce que tu veux dedans.
Oui, ça, je sais. Mais est-ce que c'est une bonne idée, c'est surtout la question.
Fred -- De la gelée encore Du givre au bord des lèvres Ah mais où sont les mots secrets ? C'est des bornes d'hôpital C'est des couloirs en vrac Du néon malicieux Et de la douche en laque Hosanna, Hosanna Et en route pour la joie (Noir Désir, En route pour la joie)
F. Senault
F. Senault écrivait :
J'ai un problème assez curieux avec ma passerelle internet sous NetBSD3 : en gros, quand la ligne ADSL est déconnectée et reconnectée, le PPP ne redétecte pas convenablement l'endpoint du tunnel : un ifconfig pppoe0 montre par exemple :
Quel est l'état de la session pppoe ? "pppoectl -d pppoe0"
A priori, elle était tout à fait normale. Au début, j'ai essayé de relancer la connexion depuis un script qui cherchait si elle n'était pas "dead", mais ça n'a pas marché.
Il me semble avoir scrupuleusement suivi les instructions du manuel, et, d'ailleurs, si je relance à la mano la connexion (reboot du PC ou du modem), ça marche tout seul sans mon intervention.
Un "ifconfig pppoe0 down" puis "up" ne suffit pas ?
Pour le moment mon script se retrouve à faire ça :
ifconfig pppoe0 down sleep 5 ifconfig pppoe0 0.0.0.0 0.0.0.1 netmask 0xff000000 up
Là où je voulais en venir, c'est qu'on dirait que c'est la reconnexion qui foire par opposition à une connexion initiale.
Fred -- Once you will know my dear You don't have to fear A new beginning always starts at the end Once you will know my dear You don't have to fear Until the end of time She goes her way (Within Temptation, Mother Earth)
F. Senault écrivait :
J'ai un problème assez curieux avec ma passerelle internet sous
NetBSD3 : en gros, quand la ligne ADSL est déconnectée et reconnectée,
le PPP ne redétecte pas convenablement l'endpoint du tunnel : un
ifconfig pppoe0 montre par exemple :
Quel est l'état de la session pppoe ? "pppoectl -d pppoe0"
A priori, elle était tout à fait normale. Au début, j'ai essayé de
relancer la connexion depuis un script qui cherchait si elle n'était pas
"dead", mais ça n'a pas marché.
Il me semble avoir scrupuleusement suivi les instructions du manuel,
et, d'ailleurs, si je relance à la mano la connexion (reboot du PC ou
du modem), ça marche tout seul sans mon intervention.
Un "ifconfig pppoe0 down" puis "up" ne suffit pas ?
Pour le moment mon script se retrouve à faire ça :
ifconfig pppoe0 down
sleep 5
ifconfig pppoe0 0.0.0.0 0.0.0.1 netmask 0xff000000 up
Là où je voulais en venir, c'est qu'on dirait que c'est la reconnexion
qui foire par opposition à une connexion initiale.
Fred
--
Once you will know my dear You don't have to fear A new beginning
always starts at the end Once you will know my dear You don't have
to fear Until the end of time She goes her way
(Within Temptation, Mother Earth)
J'ai un problème assez curieux avec ma passerelle internet sous NetBSD3 : en gros, quand la ligne ADSL est déconnectée et reconnectée, le PPP ne redétecte pas convenablement l'endpoint du tunnel : un ifconfig pppoe0 montre par exemple :
Quel est l'état de la session pppoe ? "pppoectl -d pppoe0"
A priori, elle était tout à fait normale. Au début, j'ai essayé de relancer la connexion depuis un script qui cherchait si elle n'était pas "dead", mais ça n'a pas marché.
Il me semble avoir scrupuleusement suivi les instructions du manuel, et, d'ailleurs, si je relance à la mano la connexion (reboot du PC ou du modem), ça marche tout seul sans mon intervention.
Un "ifconfig pppoe0 down" puis "up" ne suffit pas ?
Pour le moment mon script se retrouve à faire ça :
ifconfig pppoe0 down sleep 5 ifconfig pppoe0 0.0.0.0 0.0.0.1 netmask 0xff000000 up
Là où je voulais en venir, c'est qu'on dirait que c'est la reconnexion qui foire par opposition à une connexion initiale.
Fred -- Once you will know my dear You don't have to fear A new beginning always starts at the end Once you will know my dear You don't have to fear Until the end of time She goes her way (Within Temptation, Mother Earth)
F. Senault
F. Senault écrivait :
Là où je voulais en venir, c'est qu'on dirait que c'est la reconnexion qui foire par opposition à une connexion initiale.
En résumé : - tu rebootes ou tu éteins le modem ça se connecte bien. - un ifconfig pppoe0 down puis up ne relance pas la connexion ? Enfin si mais avec le problème de route ?
D'endpoint du tunnel, et donc de route.
À priori le seul changement que je vois avec le reboot c'est que la carte ethernet reste active, as tu essayé de faire un aussi un ifconfig down de l'interface ethernet juste pour voir ? Pas d'autres idées ...
Ehm... Et là, dans le script ip-down (donc de pppoe), faire un down / up de l'interface "porteuse", ça présente un risque ?
Fred -- So deep, so wide, will you take me on your back for a ride If I should fall, would you swallow me deep inside River, show me how to float, I feel like I'm sinking down Thought that I could get along (Peter Gabriel, Washing Of The Water)
F. Senault écrivait :
Là où je voulais en venir, c'est qu'on dirait que c'est la reconnexion
qui foire par opposition à une connexion initiale.
En résumé :
- tu rebootes ou tu éteins le modem ça se connecte bien.
- un ifconfig pppoe0 down puis up ne relance pas la connexion ? Enfin si
mais avec le problème de route ?
D'endpoint du tunnel, et donc de route.
À priori le seul changement que je vois avec le reboot c'est que la
carte ethernet reste active, as tu essayé de faire un aussi un ifconfig
down de l'interface ethernet juste pour voir ? Pas d'autres idées ...
Ehm... Et là, dans le script ip-down (donc de pppoe), faire un down /
up de l'interface "porteuse", ça présente un risque ?
Fred
--
So deep, so wide, will you take me on your back for a ride
If I should fall, would you swallow me deep inside
River, show me how to float, I feel like I'm sinking down
Thought that I could get along (Peter Gabriel, Washing Of The Water)
Là où je voulais en venir, c'est qu'on dirait que c'est la reconnexion qui foire par opposition à une connexion initiale.
En résumé : - tu rebootes ou tu éteins le modem ça se connecte bien. - un ifconfig pppoe0 down puis up ne relance pas la connexion ? Enfin si mais avec le problème de route ?
D'endpoint du tunnel, et donc de route.
À priori le seul changement que je vois avec le reboot c'est que la carte ethernet reste active, as tu essayé de faire un aussi un ifconfig down de l'interface ethernet juste pour voir ? Pas d'autres idées ...
Ehm... Et là, dans le script ip-down (donc de pppoe), faire un down / up de l'interface "porteuse", ça présente un risque ?
Fred -- So deep, so wide, will you take me on your back for a ride If I should fall, would you swallow me deep inside River, show me how to float, I feel like I'm sinking down Thought that I could get along (Peter Gabriel, Washing Of The Water)
F. Senault
Ca vient de se reproduire, mais la configuration fonctionne un peu par miracle. Alors :
Internet: Destination Gateway Flags Refs Use Mtu Interface default 0.0.0.1 UGS 5 368 - pppoe0 0.0.0.1 213.193.172.39 UH 1 0 - pppoe0 127/8 127.0.0.1 UGRS 0 0 33192 lo0 127.0.0.1 127.0.0.1 UH 18 1739161 33192 lo0 192.168/16 192.168.3.1 UGS 27375 1665035 - rtk0 192.168.3/24 link#1 UC 7 0 - rtk0 192.168.3.1 00:11:2f:94:95:ed UHLc 3 50313 - lo0 [+ des routes dynamiques] 16:02 armagnac:~# pppoectl -d pppoe0 pppoe0: state = session Session ID: 0xcf4d PADI retries: 3 PADR retries: 0 16:04 armagnac:~# grep ppp /var/log/alllog Oct 24 15:40:42 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-down pppoe0 /dev/null 9600 213.193.172.45 213.193.172.1 Oct 24 15:40:47 armagnac /netbsd: pppoe0: ipcp illegal up in state ack-sent Oct 24 15:40:48 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-up pppoe0 /dev/null 9600 213.193.172.39 0.0.0.1 Oct 24 15:55:05 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-down pppoe0 /dev/null 9600 0.0.0.0 0.0.0.1 Oct 24 15:55:08 armagnac /netbsd: pppoe0: ipcp illegal up in state ack-sent Oct 24 15:55:09 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-up pppoe0 /dev/null 9600 213.193.172.39 0.0.0.1 Oct 24 15:57:18 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-down pppoe0 /dev/null 9600 0.0.0.0 0.0.0.1 Oct 24 15:57:23 armagnac /netbsd: pppoe0: ipcp illegal up in state ack-sent Oct 24 15:57:23 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-up pppoe0 /dev/null 9600 213.193.172.39 0.0.0.1
Je vais essayer de le relancer en shuntant aussi l'interface porteuse, et on verra bien.
Fred Qui va se faire haïr par les gens qui utilisent le réseau à ce bout la du VPN... -- The Admins are the priesthood of an irrational, anarchistic, random, pseudo-religious hardware platform, trying to impose their will on people who would rather be using us to avoid real work. (Joe Moore in the SDM)
Ca vient de se reproduire, mais la configuration fonctionne un peu par
miracle. Alors :
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 0.0.0.1 UGS 5 368 - pppoe0
0.0.0.1 213.193.172.39 UH 1 0 - pppoe0
127/8 127.0.0.1 UGRS 0 0 33192 lo0
127.0.0.1 127.0.0.1 UH 18 1739161 33192 lo0
192.168/16 192.168.3.1 UGS 27375 1665035 - rtk0
192.168.3/24 link#1 UC 7 0 - rtk0
192.168.3.1 00:11:2f:94:95:ed UHLc 3 50313 - lo0
[+ des routes dynamiques]
16:02 armagnac:~# pppoectl -d pppoe0
pppoe0: state = session
Session ID: 0xcf4d
PADI retries: 3
PADR retries: 0
16:04 armagnac:~# grep ppp /var/log/alllog
Oct 24 15:40:42 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-down pppoe0 /dev/null 9600 213.193.172.45 213.193.172.1
Oct 24 15:40:47 armagnac /netbsd: pppoe0: ipcp illegal up in state ack-sent
Oct 24 15:40:48 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-up pppoe0 /dev/null 9600 213.193.172.39 0.0.0.1
Oct 24 15:55:05 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-down pppoe0 /dev/null 9600 0.0.0.0 0.0.0.1
Oct 24 15:55:08 armagnac /netbsd: pppoe0: ipcp illegal up in state ack-sent
Oct 24 15:55:09 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-up pppoe0 /dev/null 9600 213.193.172.39 0.0.0.1
Oct 24 15:57:18 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-down pppoe0 /dev/null 9600 0.0.0.0 0.0.0.1
Oct 24 15:57:23 armagnac /netbsd: pppoe0: ipcp illegal up in state ack-sent
Oct 24 15:57:23 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-up pppoe0 /dev/null 9600 213.193.172.39 0.0.0.1
Je vais essayer de le relancer en shuntant aussi l'interface porteuse,
et on verra bien.
Fred
Qui va se faire haïr par les gens qui utilisent le réseau à ce bout la
du VPN...
--
The Admins are the priesthood of an irrational, anarchistic, random,
pseudo-religious hardware platform, trying to impose their will on
people who would rather be using us to avoid real work.
(Joe Moore in the SDM)
Internet: Destination Gateway Flags Refs Use Mtu Interface default 0.0.0.1 UGS 5 368 - pppoe0 0.0.0.1 213.193.172.39 UH 1 0 - pppoe0 127/8 127.0.0.1 UGRS 0 0 33192 lo0 127.0.0.1 127.0.0.1 UH 18 1739161 33192 lo0 192.168/16 192.168.3.1 UGS 27375 1665035 - rtk0 192.168.3/24 link#1 UC 7 0 - rtk0 192.168.3.1 00:11:2f:94:95:ed UHLc 3 50313 - lo0 [+ des routes dynamiques] 16:02 armagnac:~# pppoectl -d pppoe0 pppoe0: state = session Session ID: 0xcf4d PADI retries: 3 PADR retries: 0 16:04 armagnac:~# grep ppp /var/log/alllog Oct 24 15:40:42 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-down pppoe0 /dev/null 9600 213.193.172.45 213.193.172.1 Oct 24 15:40:47 armagnac /netbsd: pppoe0: ipcp illegal up in state ack-sent Oct 24 15:40:48 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-up pppoe0 /dev/null 9600 213.193.172.39 0.0.0.1 Oct 24 15:55:05 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-down pppoe0 /dev/null 9600 0.0.0.0 0.0.0.1 Oct 24 15:55:08 armagnac /netbsd: pppoe0: ipcp illegal up in state ack-sent Oct 24 15:55:09 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-up pppoe0 /dev/null 9600 213.193.172.39 0.0.0.1 Oct 24 15:57:18 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-down pppoe0 /dev/null 9600 0.0.0.0 0.0.0.1 Oct 24 15:57:23 armagnac /netbsd: pppoe0: ipcp illegal up in state ack-sent Oct 24 15:57:23 armagnac /usr/sbin/ifwatchd[312]: calling: /etc/ppp/ip-up pppoe0 /dev/null 9600 213.193.172.39 0.0.0.1
Je vais essayer de le relancer en shuntant aussi l'interface porteuse, et on verra bien.
Fred Qui va se faire haïr par les gens qui utilisent le réseau à ce bout la du VPN... -- The Admins are the priesthood of an irrational, anarchistic, random, pseudo-religious hardware platform, trying to impose their will on people who would rather be using us to avoid real work. (Joe Moore in the SDM)
F. Senault
Je vais essayer de le relancer en shuntant aussi l'interface porteuse, et on verra bien.
Marche pas plus. Amusante petite chose, j'ai lancé un tcpdump juste avant, et j'ai droit à un gentil "Segmentation fault (core dumped)" quand j'essaie de lire le fichier dump. Joie, bonheur, tout ça.
Ethereal en veut bien, par contre, et je vois passer un message avec l'IP du serveur :
PPP-over-Ethernet Session Version: 1 Type: 1 Code: Session Data Session ID: 12c7 Payload Length: 12 Point-to-Point Protocol Protocol: IP Control Protocol (0x8021) PPP IP Control Protocol Code: Configuration Request (0x01) Identifier: 0x31 Length: 10 Options: (6 bytes) IP address: 213.193.172.1
(Qui est bien l'adresse du BAS à l'autre bout du fil.)
Fred La bonne nouvelle, c'est que ça marche encore - le téléphone n'a pas fondu. -- Don't open your eyes you won't like what you see The devils of truth steal the souls of the free Don't open your eyes take it from me I have found You can find Happiness is slavery (Nine inch Nails, Happiness in Slavery)
Je vais essayer de le relancer en shuntant aussi l'interface porteuse,
et on verra bien.
Marche pas plus. Amusante petite chose, j'ai lancé un tcpdump juste
avant, et j'ai droit à un gentil "Segmentation fault (core dumped)"
quand j'essaie de lire le fichier dump. Joie, bonheur, tout ça.
Ethereal en veut bien, par contre, et je vois passer un message avec
l'IP du serveur :
PPP-over-Ethernet Session
Version: 1
Type: 1
Code: Session Data
Session ID: 12c7
Payload Length: 12
Point-to-Point Protocol
Protocol: IP Control Protocol (0x8021)
PPP IP Control Protocol
Code: Configuration Request (0x01)
Identifier: 0x31
Length: 10
Options: (6 bytes)
IP address: 213.193.172.1
(Qui est bien l'adresse du BAS à l'autre bout du fil.)
Fred
La bonne nouvelle, c'est que ça marche encore - le téléphone n'a pas
fondu.
--
Don't open your eyes you won't like what you see The devils of truth
steal the souls of the free Don't open your eyes take it from me
I have found You can find Happiness is slavery
(Nine inch Nails, Happiness in Slavery)
Je vais essayer de le relancer en shuntant aussi l'interface porteuse, et on verra bien.
Marche pas plus. Amusante petite chose, j'ai lancé un tcpdump juste avant, et j'ai droit à un gentil "Segmentation fault (core dumped)" quand j'essaie de lire le fichier dump. Joie, bonheur, tout ça.
Ethereal en veut bien, par contre, et je vois passer un message avec l'IP du serveur :
PPP-over-Ethernet Session Version: 1 Type: 1 Code: Session Data Session ID: 12c7 Payload Length: 12 Point-to-Point Protocol Protocol: IP Control Protocol (0x8021) PPP IP Control Protocol Code: Configuration Request (0x01) Identifier: 0x31 Length: 10 Options: (6 bytes) IP address: 213.193.172.1
(Qui est bien l'adresse du BAS à l'autre bout du fil.)
Fred La bonne nouvelle, c'est que ça marche encore - le téléphone n'a pas fondu. -- Don't open your eyes you won't like what you see The devils of truth steal the souls of the free Don't open your eyes take it from me I have found You can find Happiness is slavery (Nine inch Nails, Happiness in Slavery)
Manuel Bouyer
F. Senault wrote:
F. Senault wrote:
Oy.
Quelqu'un aurait une idée du coupable : - mon provider (les déconnexions sont voulues, pour forcer les changements d'IP)?
Peut-etre. Il faudrait faire tourner tcpdump -s 1500 sur l'interface ethernet (eventuellement avec les bonne options ou un grep pour par que le fichier de sortie soit trop gros) pour voir ce que le materiel en face renvoie quand la connection tombe puis remonte (tcpdump decode tres bien le protocole pppoe).
Hélas, c'est une passerelle internet - le dump atteindrait rapidement des tailles impossibles à gérer, et, la dernière fois, le tout a tenu environ une semaine avant de tomber.
Y'a peut-etre moyen de filtrer avec les filtres bpf, ou un grep -v ?
Mh. Lancer le dump depuis le script ip-down d'ifwatchd, ça semble réalisable ?
Aussi, mais je ne sais pas si ca pourra capturer tout ce qui est interessant pour analyser le probleme. C'est a essayer.
Je ne pense pas. J'ai aussi un speedtouch+pppoe (mais sous NetBSD-2 pour l'instant).
Quand je dis vieillissant, en fait, c'est carrément obsolète, sans
Le miens aussi (99 ou 2000, je ne sais plus)
oublier qu'il a été "bricolé" (mis à jour pour en faire un routeur, puis re-downgradé ; il perd ses paramètres de temps en temps si le courant se coupe, ce genre de choses).
Pas de problemes chez moi, mais je n'ai jamais essaye de changer son firmware
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
F. Senault <fred@lacave.net> wrote:
F. Senault <fred@lacave.net> wrote:
Oy.
Quelqu'un aurait une idée du coupable :
- mon provider (les déconnexions sont voulues, pour forcer les
changements d'IP)?
Peut-etre. Il faudrait faire tourner tcpdump -s 1500 sur l'interface
ethernet (eventuellement avec les bonne options ou un grep pour par que
le fichier de sortie soit trop gros) pour voir ce que le materiel en
face renvoie quand la connection tombe puis remonte (tcpdump decode tres
bien le protocole pppoe).
Hélas, c'est une passerelle internet - le dump atteindrait rapidement
des tailles impossibles à gérer, et, la dernière fois, le tout a tenu
environ une semaine avant de tomber.
Y'a peut-etre moyen de filtrer avec les filtres bpf, ou un grep -v ?
Mh. Lancer le dump depuis le script ip-down d'ifwatchd, ça semble
réalisable ?
Aussi, mais je ne sais pas si ca pourra capturer tout ce qui est
interessant pour analyser le probleme. C'est a essayer.
Je ne pense pas. J'ai aussi un speedtouch+pppoe (mais sous NetBSD-2 pour
l'instant).
Quand je dis vieillissant, en fait, c'est carrément obsolète, sans
Le miens aussi (99 ou 2000, je ne sais plus)
oublier qu'il a été "bricolé" (mis à jour pour en faire un routeur, puis
re-downgradé ; il perd ses paramètres de temps en temps si le courant se
coupe, ce genre de choses).
Pas de problemes chez moi, mais je n'ai jamais essaye de changer son
firmware
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
Quelqu'un aurait une idée du coupable : - mon provider (les déconnexions sont voulues, pour forcer les changements d'IP)?
Peut-etre. Il faudrait faire tourner tcpdump -s 1500 sur l'interface ethernet (eventuellement avec les bonne options ou un grep pour par que le fichier de sortie soit trop gros) pour voir ce que le materiel en face renvoie quand la connection tombe puis remonte (tcpdump decode tres bien le protocole pppoe).
Hélas, c'est une passerelle internet - le dump atteindrait rapidement des tailles impossibles à gérer, et, la dernière fois, le tout a tenu environ une semaine avant de tomber.
Y'a peut-etre moyen de filtrer avec les filtres bpf, ou un grep -v ?
Mh. Lancer le dump depuis le script ip-down d'ifwatchd, ça semble réalisable ?
Aussi, mais je ne sais pas si ca pourra capturer tout ce qui est interessant pour analyser le probleme. C'est a essayer.
Je ne pense pas. J'ai aussi un speedtouch+pppoe (mais sous NetBSD-2 pour l'instant).
Quand je dis vieillissant, en fait, c'est carrément obsolète, sans
Le miens aussi (99 ou 2000, je ne sais plus)
oublier qu'il a été "bricolé" (mis à jour pour en faire un routeur, puis re-downgradé ; il perd ses paramètres de temps en temps si le courant se coupe, ce genre de choses).
Pas de problemes chez moi, mais je n'ai jamais essaye de changer son firmware
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Manuel Bouyer
Patrick Lamaizière wrote:
Manuel Bouyer écrivait :
Je ne pense pas. J'ai aussi un speedtouch+pppoe (mais sous NetBSD-2 pour l'instant).
J'ai la même config et je suis chez Nerim aussi (en dégroupé), aurais-tu
nerim aussi, mais non degroupe
une idée sur ce problème : la connexion tombe -enfin ça ne marche plus- mais ce n'est pas détecté par pppoe, la machine continue à envoyer des paquets en sortie sur pppoe0 d'après netstat mais plus rien ne rentre. Un ifconfig down puis up suffit à relancer la connexion. Cela ne n'est arrivé que deux ou trois fois en un an sous NetBSD 1.6.2.
Je me demande s'il n'y a pas eu des corrections dans pppoe(4) depuis 1.6.2, pour ce genre de problemes justement. La aussi un tcpdump -s 1500 sur l'interface ethernet peut aider a voir ce qui se passe (en particulier la negotiation avec le BAS). Normalement lcp (a 1s par defaut) devrait detecter la chute de la session ppp, si ca n'est pas detecte il faudrait voir si les paquets LCP sont bien emis, et si le BAS repond.
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Patrick Lamaizière <adresse@est.invalid> wrote:
Manuel Bouyer écrivait :
Je ne pense pas. J'ai aussi un speedtouch+pppoe (mais sous NetBSD-2
pour l'instant).
J'ai la même config et je suis chez Nerim aussi (en dégroupé), aurais-tu
nerim aussi, mais non degroupe
une idée sur ce problème : la connexion tombe -enfin ça ne marche plus-
mais ce n'est pas détecté par pppoe, la machine continue à envoyer des
paquets en sortie sur pppoe0 d'après netstat mais plus rien ne rentre.
Un ifconfig down puis up suffit à relancer la connexion. Cela ne n'est
arrivé que deux ou trois fois en un an sous NetBSD 1.6.2.
Je me demande s'il n'y a pas eu des corrections dans pppoe(4) depuis
1.6.2, pour ce genre de problemes justement.
La aussi un tcpdump -s 1500 sur l'interface ethernet peut aider a voir
ce qui se passe (en particulier la negotiation avec le BAS). Normalement lcp
(a 1s par defaut) devrait detecter la chute de la session ppp, si ca n'est pas
detecte il faudrait voir si les paquets LCP sont bien emis, et si le BAS
repond.
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
Je ne pense pas. J'ai aussi un speedtouch+pppoe (mais sous NetBSD-2 pour l'instant).
J'ai la même config et je suis chez Nerim aussi (en dégroupé), aurais-tu
nerim aussi, mais non degroupe
une idée sur ce problème : la connexion tombe -enfin ça ne marche plus- mais ce n'est pas détecté par pppoe, la machine continue à envoyer des paquets en sortie sur pppoe0 d'après netstat mais plus rien ne rentre. Un ifconfig down puis up suffit à relancer la connexion. Cela ne n'est arrivé que deux ou trois fois en un an sous NetBSD 1.6.2.
Je me demande s'il n'y a pas eu des corrections dans pppoe(4) depuis 1.6.2, pour ce genre de problemes justement. La aussi un tcpdump -s 1500 sur l'interface ethernet peut aider a voir ce qui se passe (en particulier la negotiation avec le BAS). Normalement lcp (a 1s par defaut) devrait detecter la chute de la session ppp, si ca n'est pas detecte il faudrait voir si les paquets LCP sont bien emis, et si le BAS repond.
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
