Deconnection à répétition

[shwing]

Bonjour tous le monde,

Depuis le 9 aout j'ai passé d'Adsl à Vdsl.
Depuis là la patte RED ne fais que de ce déconnecté.
Je pense que le soucis doit venir de DHCP_NAK (If the client receives a DHCPNAK message, it cannot reuse its remembered network address.)

J'ai lu ce post de 10 pages, mais sans grand résultat. http://forums.ixus.fr/viewtopic.php?t=1 ... sc&start=0
le patch de Gesp n'est plus installable, apparemment.

Je ne l'ai pas encore réinstallé, mais c'est évidemment envisageable.
La config est simple: ipcop 1.4.16, et 2 - 3 addons comme net-traffic -fail2ban ...

J'ai forcer la vitesse de eth2 en 10Full et pas en 100, pas de changement.

J'ai laissé un seul PC sur le routeur Netopia (3399, numéro à vérifier) pendant plus d'une heure, et évidemment je n'ai pas eu la moindre coupure. Dès que j'a mis le cable réseau de l'interface RED en moins de 10 sec, il y a eu une coupure, alors que IPCOP était en mode déconnecté, et ne cherchait pas à faire de connection. J'ai changer le cable réseau. Mais je n'ai pas encore essayé d'y mettre un switch en le netopia et ipcop.


Ce qui est marrant, et qu'en regardant les logs, il y a 1h30, entre chaque coupure et que cela correspont au bail dhcp.

Code: Tout sélectionner

IPCop diagnostics
Section: red
Date: Août 27, 2007

04:07:11 dhcpcd[9615] DHCP_NAK server response received
04:07:11 kernel: eth2 remaining active for wake-on-lan
04:07:11 kernel: eth2 autonegotiation did not complete in 4000 usec.
04:07:11 kernel: eth2 link up.
04:07:11 kernel: eth2 Setting full-duplex based on negotiated link capability.
05:37:21 dhcpcd[9615] DHCP_NAK server response received
05:37:21 kernel: eth2 remaining active for wake-on-lan
05:37:21 kernel: eth2 autonegotiation did not complete in 4000 usec.
05:37:21 kernel: eth2 link up.
05:37:21 kernel: eth2 Setting full-duplex based on negotiated link capability.
07:07:36 dhcpcd[9615] DHCP_NAK server response received
07:07:36 kernel: eth2 remaining active for wake-on-lan
07:07:36 kernel: eth2 autonegotiation did not complete in 4000 usec.
07:07:36 kernel: eth2 link up.
07:07:36 kernel: eth2 Setting full-duplex based on negotiated link capability.
08:37:46 dhcpcd[9615] DHCP_NAK server response received
08:37:46 kernel: eth2 remaining active for wake-on-lan
08:37:46 kernel: eth2 autonegotiation did not complete in 4000 usec.
08:37:46 kernel: eth2 link up.
08:37:46 kernel: eth2 Setting full-duplex based on negotiated link capability.

Pour l'instant c'est tout ce que je peux dire.
Merci.

[Gesp]

Si ton IP est fixe, tu pourrais noter les paramétres reçus (IP, netmask, passerelle, DNS,...) et passer en IP fixe en rentrant toi-même les paramêtres.

le patch de Gesp n'est plus installable, apparemment.

La modif a été incluse depuis mais c'est une manière pauvre de contourner.
Je pense que le coeur du pb est dans le code de dhcpcd.

Ce qui me faudrait, c'est le log complet de ce qui se passe au moment de la déconnexion.
Se connecter par ssh et extraire de /var/log/messages la partie intéressante.

[shwing]

Salut Gesp,

Pour l'IP, que ce passe t-il si je suis en IP dynamique et que je la rentre en dur ? Car ce'st bien mon FAI qui me l'attribue. Je peux tester, apparemment depuis le 9 aout j'ai la même IP.

Si ton IP est fixe, tu pourrais noter les paramétres reçus (IP, netmask, passerelle, DNS,...) et passer en IP fixe en rentrant toi-même les paramêtres.

Toutes ces infos je les connais.


logs:

Code: Tout sélectionner

Aug 27 07:05:00 embcop fcron[3120]: Job /usr/local/bin/wlanrrd.pl timer > /dev/null started for user root (pid 3121)
Aug 27 07:05:00 embcop fcron[3124]: Job [ -f "/var/ipcop/red/active" ] && /usr/local/bin/setddns.pl started for user root (pid 3126)
Aug 27 07:05:00 embcop fcron[3122]: Job /usr/local/bin/monitorTraff > /dev/null started for user root (pid 3123)
Aug 27 07:05:00 embcop fcron[3127]: Job /usr/local/bin/makegraphs >/dev/null started for user root (pid 3128)
Aug 27 07:05:00 embcop fcron[3132]: Job /usr/local/bin/timecheck > /dev/null 2>&1 started for user root (pid 3134)
Aug 27 07:05:00 embcop kernel: INPUT IN=eth2 OUT= MAC=01:00:5e:00:00:01:00:90:d0:63:ff:00:08:00 SRC=1.1.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2


Aug 27 07:05:02 embcop fcron[3132]: Job /usr/local/bin/timecheck > /dev/null 2>&1 completed
Aug 27 07:05:05 embcop kernel: INPUT IN=eth2 OUT= MAC=01:00:5e:00:00:01:00:90:d0:63:ff:00:08:00 SRC=1.1.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Aug 27 07:05:07 embcop fcron[3124]: Job [ -f "/var/ipcop/red/active" ] && /usr/local/bin/setddns.pl completed
Aug 27 07:05:10 embcop kernel: INPUT IN=eth2 OUT= MAC=01:00:5e:00:00:01:00:90:d0:63:ff:00:08:00 SRC=1.1.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Aug 27 07:05:11 embcop fcron[3122]: Job /usr/local/bin/monitorTraff > /dev/null completed
Aug 27 07:05:12 embcop fcron[3120]: Job /usr/local/bin/wlanrrd.pl timer > /dev/null completed
Aug 27 07:05:15 embcop kernel: INPUT IN=eth2 OUT= MAC=01:00:5e:00:00:01:00:90:d0:63:ff:00:08:00 SRC=1.1.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Aug 27 07:05:25 embcop last message repeated 2 times
Aug 27 07:05:30 embcop fcron[3127]: Job /usr/local/bin/makegraphs >/dev/null completed
Aug 27 07:05:30 embcop kernel: INPUT IN=eth2 OUT= MAC=01:00:5e:00:00:01:00:90:d0:63:ff:00:08:00 SRC=1.1.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Aug 27 07:06:01 embcop last message repeated 6 times
Aug 27 07:07:06 embcop last message repeated 13 times
Aug 27 07:07:36 embcop last message repeated 5 times
Aug 27 07:07:36 embcop kernel: martian source 85.5.112.1xx from 255.255.255.255, on dev eth2
Aug 27 07:07:36 embcop kernel: ll header: 00:0d:b9:01:4b:1e:00:90:d0:63:ff:04:08:00
Aug 27 07:07:36 embcop dhcpcd[9615]: DHCP_NAK server response received
Aug 27 07:07:36 embcop kernel: eth2: remaining active for wake-on-lan
Aug 27 07:07:36 embcop kernel: eth2: autonegotiation did not complete in 4000 usec.
Aug 27 07:07:36 embcop kernel: eth2: link up.
Aug 27 07:07:36 embcop kernel: eth2: Setting full-duplex based on negotiated link capability.
Aug 27 07:07:36 embcop rc.updatered: /var/ipcop/dhcpc/dhcpcd.exe locking for 3156
Aug 27 07:07:41 embcop dnsmasq[3195]: started, version 2.38 cachesize 150
Aug 27 07:07:41 embcop dnsmasq[3195]: compile time options: no-IPv6 GNU-getopt ISC-leasefile no-DBus no-I18N TFTP
Aug 27 07:07:41 embcop dnsmasq[3195]: reading /var/state/dhcp/dhcpd.leases
Aug 27 07:07:41 embcop dnsmasq[3195]: reading /var/ipcop/red/resolv.conf
Aug 27 07:07:41 embcop dnsmasq[3195]: using nameserver 195.186.4.162#53
Aug 27 07:07:41 embcop dnsmasq[3195]: using nameserver 195.186.1.162#53
Aug 27 07:07:41 embcop dnsmasq[3195]: read /etc/hosts - 3 addresses
Aug 27 07:07:41 embcop dhcpcd.exe: eth2 has been brought down
Aug 27 07:07:41 embcop kernel: INPUT IN=eth2 OUT= MAC=01:00:5e:00:00:01:00:90:d0:63:ff:00:08:00 SRC=1.1.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Aug 27 07:07:46 embcop rc.updatered: unlocking from 3156
Aug 27 07:07:46 embcop kernel: INPUT IN=eth2 OUT= MAC=01:00:5e:00:00:01:00:90:d0:63:ff:00:08:00 SRC=1.1.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Aug 27 07:07:46 embcop kernel: INPUT IN=eth2 OUT= MAC=ff:ff:ff:ff:ff:ff:00:90:d0:63:ff:04:08:00 SRC=195.186.59.185 DST=255.255.255.255 LEN=372 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=352
Aug 27 07:07:47 embcop rc.updatered: /var/ipcop/dhcpc/dhcpcd.exe locking for 3579
Aug 27 07:07:47 embcop kernel: NEW not SYN? IN=eth0 OUT=eth2 SRC=192.168.34.239 DST=81.48.14.87 LEN=1480 TOS=0x00 PREC=0x00 TTL=127 ID=34960 DF PROTO=TCP SPT=4453 DPT=7567 WINDOW=65272 RES=0x00 ACK PSH URGP=0
Aug 27 07:07:47 embcop kernel: NEW not SYN? IN=eth0 OUT=eth2 SRC=192.168.34.239 DST=82.65.161.89 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=34961 DF PROTO=TCP SPT=4760 DPT=4662 WINDOW=65287 RES=0x00 ACK FIN URGP=0
Aug 27 07:07:47 embcop kernel: NEW not SYN? IN=eth2 OUT= MAC=00:0d:b9:01:4b:1e:00:90:d0:63:ff:04:08:00 SRC=88.161.62.134 DST=85.5.112.1xx LEN=1500 TOS=0x00 PREC=0x00 TTL=111 ID=13879 DF PROTO=TCP SPT=35940 DPT=4318 WINDOW=65218 RES=0x00 ACK URGP=0
Aug 27 07:07:47 embcop kernel: NEW not SYN? IN=eth0 OUT=eth2 SRC=192.168.34.239 DST=88.161.62.134 LEN=1500 TOS=0x00 PREC=0x00 TTL=127 ID=34963 DF PROTO=TCP SPT=4318 DPT=35940 WINDOW=65535 RES=0x00 ACK PSH URGP=0
Aug 27 07:07:47 embcop kernel: NEW not SYN? IN=eth0 OUT=eth2 SRC=192.168.34.239 DST=195.132.158.189 LEN=1500 TOS=0x00 PREC=0x00 TTL=127 ID=34964 DF PROTO=TCP SPT=4375 DPT=44094 WINDOW=64999 RES=0x00 ACK PSH URGP=0
Aug 27 07:07:51 embcop dnsmasq[3618]: started, version 2.38 cachesize 150
Aug 27 07:07:51 embcop dnsmasq[3618]: compile time options: no-IPv6 GNU-getopt ISC-leasefile no-DBus no-I18N TFTP
Aug 27 07:07:51 embcop dnsmasq[3618]: reading /var/state/dhcp/dhcpd.leases
Aug 27 07:07:51 embcop dnsmasq[3618]: reading /var/ipcop/red/resolv.conf
Aug 27 07:07:51 embcop dnsmasq[3618]: using nameserver 195.186.4.162#53
Aug 27 07:07:51 embcop dnsmasq[3618]: using nameserver 195.186.1.162#53
Aug 27 07:07:51 embcop dnsmasq[3618]: read /etc/hosts - 3 addresses
Aug 27 07:07:51 embcop dhcpcd.exe: eth2 has been configured with same IP=85.5.112.1

Merci.

[Gesp]

dans le log, ce qui me parait anormal c'est

kernel: martian source 85.5.112.1xx from 255.255.255.255, on dev eth2

Après le NAK la déconnexion est faite entre
rc.updatered: /var/ipcop/dhcpc/dhcpcd.exe locking for 3156
et
rc.updatered: unlocking from 3156

Puis la reconnexion se passe entre
rc.updatered: /var/ipcop/dhcpc/dhcpcd.exe locking for 3579
et une ligne que tu n'as pas inclus.

Donc, de ce point de vue, les ordres se sont passés dans le bon sens.

Il faudrait un log plus complêt de dhcpcd obtenu comme indiqué dans le sujet que tu as cité.
Ou plus rapide pour activer debug de dhcpcd
echo 'DEBUG=on' >>/var/ipcop/ppp/settings

[shwing]

les derniers log après un reboot

Code: Tout sélectionner

16:14:18 kernel: eth2 remaining active for wake-on-lan
16:15:17 kernel: eth0 NatSemi DP8381[56] at 0xc8840000, 00:0d:b9:01:4b:xx, IRQ 10.
16:15:17 kernel: eth1 NatSemi DP8381[56] at 0xc8842000, 00:0d:b9:01:4b:xx, IRQ 9.
16:15:17 kernel: eth2 NatSemi DP8381[56] at 0xc8844000, 00:0d:b9:01:4b:xx, IRQ 11.
16:15:43 kernel: eth0 link up.
16:15:43 kernel: eth0 Setting full-duplex based on negotiated link capability.
16:15:43 kernel: eth1 link up.
16:15:43 kernel: eth1 Setting full-duplex based on negotiated link capability.
16:15:46 kernel: eth2 autonegotiation did not complete in 4000 usec.
16:15:46 kernel: eth2 link up.
16:15:46 kernel: eth2 Setting full-duplex based on negotiated link capability.
16:15:46 dhcpcd[1034] broadcasting DHCP_DISCOVER
16:15:46 dhcpcd[1034] broadcastAddr option is missing in DHCP server response. Assuming 85.5.112.255
16:15:46 dhcpcd[1034] dhcpIPaddrLeaseTime=28800 in DHCP server response.
16:15:46 dhcpcd[1034] DHCP_OFFER received from  (138.187.24.106)
16:15:46 dhcpcd[1034] broadcasting DHCP_REQUEST for 85.5.112.xx
16:15:59 dhcpcd[1034] dhcpIPaddrLeaseTime=28800 in DHCP server response.
16:15:59 dhcpcd[1034] DHCP_ACK received from  (138.187.24.106)

[Gesp]

Cela a l'air normal mais il n'y avait pas de renouvellement ici, juste l'attribution de l'adresse.
On verra au renouvellement, soit à 17h45 si j'ai bien compris.

Garder DEBUG du dhcpcd activé n'est pas un problème avec un temps de bail de 1h30.
Par contre avec un bail très court comme 1mn comme avec certain modems routeur, cela remplit pas mal le log.

[shwing]

la suite, j'ai repris des logs d'avant aussi:

Code: Tout sélectionner

17:45:59   dhcpcd[1036]   broadcasting DHCP_DISCOVER
17:46:00   dhcpcd[1036]   broadcastAddr option is missing in DHCP server response. Assuming 85.5.112.255
17:46:00   dhcpcd[1036]   dhcpIPaddrLeaseTime=28800 in DHCP server response.
17:46:00   dhcpcd[1036]   DHCP_OFFER received from (138.187.24.106)
17:46:00   dhcpcd[1036]   broadcasting DHCP_REQUEST for 85.5.112.132
17:46:09   dhcpcd[1036]   dhcpIPaddrLeaseTime=28800 in DHCP server response.
17:46:09   dhcpcd[1036]   DHCP_ACK received from (138.187.24.106)
17:46:26   dhcpcd[1036]   sending DHCP_REQUEST for 85.5.112.132 to 138.187.24.106
19:16:09   dhcpcd[1036]   broadcasting DHCP_REQUEST for 85.5.112.132
19:16:09   dhcpcd[1036]   dhcpIPaddrLeaseTime=28800 in DHCP server response.
19:16:09   dhcpcd[1036]   dhcpT1value is missing in DHCP server response. Assuming 14400 sec
19:16:09   dhcpcd[1036]   dhcpT2value is missing in DHCP server response. Assuming 25200 sec
19:16:09   dhcpcd[1036]   DHCP_NAK server response received
19:16:09   kernel   eth2: remaining active for wake-on-lan
19:16:09   kernel   eth2: autonegotiation did not complete in 4000 usec.
19:16:09   kernel   eth2: link up.
19:16:09   kernel   eth2: Setting full-duplex based on negotiated link capability.
19:16:09   dhcpcd[1036]   broadcasting DHCP_DISCOVER
19:16:10   dhcpcd[1036]   broadcastAddr option is missing in DHCP server response. Assuming 85.5.112.255
19:16:10   dhcpcd[1036]   dhcpIPaddrLeaseTime=28800 in DHCP server response.
19:16:11   dhcpcd[1036]   DHCP_OFFER received from (138.187.24.106)
19:16:11   dhcpcd[1036]   broadcasting DHCP_REQUEST for 85.5.112.132
19:16:20   dhcpcd[1036]   dhcpIPaddrLeaseTime=28800 in DHCP server response.
19:16:20   dhcpcd[1036]   DHCP_ACK received from (138.187.24.106)
19:16:37   dhcpcd[1036]   sending DHCP_REQUEST for 85.5.112.132 to 138.187.24.106

[shwing]

Je viens de lire un peu la doc sur christian.caleca.free.fr, et en regardant les logs, je comprends pas tout...

02:34:47 dhcpcd[5923] broadcasting DHCP_DISCOVER
Ici ipcop envoie une demande.

02:34:48 dhcpcd[5923] broadcastAddr option is missing in DHCP server response. Assuming 85.5.112.255
Ici on suppose que c'est la bonne IP, pourquoi pas...

02:34:48 dhcpcd[5923] dhcpIPaddrLeaseTime=28800 in DHCP server response.
Ici je comprends que le lease est de 8h (ce qui ne correspont pas avec la page netstatus.cgi d'ipcop

02:34:48 dhcpcd[5923] DHCP_OFFER received from (138.187.24.106)
Ici le DHCP de mon provider réponds à ma demande.

02:34:48 dhcpcd[5923] broadcasting DHCP_REQUEST for 85.5.112.132
Je fais la demande pour avoir cette IP

02:34:57 dhcpcd[5923] dhcpIPaddrLeaseTime=28800 in DHCP server response.
Tiens on me redis bien que c'est pour 8h.

02:34:57 dhcpcd[5923] DHCP_ACK received from (138.187.24.106)
Et ensuite le confirmation du DHCP qui confirme mon IP. Elle est mienne.

02:35:26 dhcpcd[5923] sending DHCP_REQUEST for 85.5.112.132 to 138.187.24.106
Maintenant ici, pourquoi je renvoie un demande ? après 30 sec ???
Et même à partir d'ici, je ne comprends plus grand chose sur les évenemnts qui se produisent...

04:04:57 dhcpcd[5923] broadcasting DHCP_REQUEST for 85.5.112.132
04:04:57 dhcpcd[5923] dhcpIPaddrLeaseTime=28800 in DHCP server response.
04:04:57 dhcpcd[5923] dhcpT1value is missing in DHCP server response. Assuming 14400 sec
04:04:57 dhcpcd[5923] dhcpT2value is missing in DHCP server response. Assuming 25200 sec
04:04:57 dhcpcd[5923] DHCP_NAK server response received

Bon ce que je me dis aussi est que vu le nombre de personnes utilisant le patte RED en dhcp, et que apparemment depuis la version, 1.4.x (sais plus exactement la version) tout fonctionne, une réinstalle peut s'avérer salutaire...

[Gesp]

Je ne pense pas que réinstaller change le comportement.

Le serveur qui t'a répondu a proposé une adresse.

02:35:26 dhcpcd[5923] sending DHCP_REQUEST for 85.5.112.132 to 138.187.24.106
Maintenant ici, pourquoi je renvoie un demande ? après 30 sec ???
Et même à partir d'ici, je ne comprends plus grand chose sur les évenemnts qui se produisent...

Tu informes d'autres serveurs dhcp potentiels que tu vas utiliser 85.5.112.132 fourni par 138.187.24.10

04:04:57 dhcpcd[5923] broadcasting DHCP_REQUEST for 85.5.112.132 [/quote]

Le problème commence avec

DHCP_NAK server response received

Je ne vois pas de raison pour le serveur de refuser 85.5.112.132 étant donné que c'est toujours le même serveur qui t'attribue la même adresse.
Si tu regardes l'exemple en dégroupé fournis par malicious, il y a plusieurs NAK mais la cause en est un changement à la fois d'adresse fournie et de serveur dhcp.

Est-il possible d'écouter le trafic quand le routeur Netopia remplace IPCop pour voir comment la négociation se passe?
Pour cela, tu peux éventuellement utiliser le tcpdump inclu dans IPCop. Mais il faudrait brancher IPCop en amont du routeur avec un hub pour écouter de ce coté et arrêter le client dhcpcd
tcpdump -i eth(l'interface qui est branché)

[shwing]

Merci pour ces précisions.
Je vais installé un 2 ème ipcop pour tcpdumpiser ce qui se passe.
Reviens dès que j'ai les résultats.

a+

[shwing]

Voici ce que j'ai récupéré à différents moments.

Evidemment je ne t'ai pas écouté, j'ai réinstallé. Pour rien.

Code: Tout sélectionner

###Netopia en mode 'Mode Pont/Modem:activé'#
19:06:53.405885 arp who-has 192.168.1.246 tell 192.168.1.1
19:06:53.415885 arp who-has 192.168.1.247 tell 192.168.1.1
19:06:53.425921 arp who-has 192.168.1.248 tell 192.168.1.1
19:06:53.435885 arp who-has 192.168.1.249 tell 192.168.1.1
19:06:53.445885 arp who-has 192.168.1.250 tell 192.168.1.1
19:06:53.455996 arp who-has 192.168.1.251 tell 192.168.1.1
19:06:53.465885 arp who-has 192.168.1.252 tell 192.168.1.1
19:06:53.475885 arp who-has 192.168.1.253 tell 192.168.1.1
19:06:53.485885 arp who-has 192.168.1.254 tell 192.168.1.1
19:06:59.855963 IP 192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 290
19:07:00.055876 IP 192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 269
19:07:00.195957 IP 192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 254
19:07:00.196560 IP 192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 322
19:07:00.275875 IP 192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 314
19:07:00.295873 IP 192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 320
19:07:00.355870 IP 192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 254
19:07:00.515872 IP 192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 249
19:07:00.615873 IP 192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 326
19:07:00.715875 IP 192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 318
19:07:00.765872 IP 192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 235
19:07:01.145872 IP 192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 273
19:07:01.185876 IP 192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 318
19:07:01.225994 IP 192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 283
19:07:01.245876 IP 192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 316
19:07:01.465881 IP 192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 313
19:07:20.625868 IP 192.168.1.1 > 224.0.0.1: igmp query v3 [max resp time 10s]

19:31:51.206181 arp who-has 192.168.1.254 tell 192.168.1.1
19:32:16.056114 IP 192.168.1.1.router > 255.255.255.255.router: RIPv1, Response, length: 44
19:32:48.505868 IP 192.168.1.1.router > 255.255.255.255.router: RIPv1, Response, length: 44
19:33:07.565867 IP 192.168.1.1 > 224.0.0.1: igmp query v3 [max resp time 10s]
19:33:21.575870 IP 192.168.1.1.router > 255.255.255.255.router: RIPv1, Response, length: 44
19:33:53.085867 IP 192.168.1.1.router > 255.255.255.255.router: RIPv1, Response, length: 44
19:34:24.505868 IP 192.168.1.1.router > 255.255.255.255.router: RIPv1, Response, length: 44
19:34:55.325872 IP 192.168.1.1.router > 255.255.255.255.router: RIPv1, Response, length: 44
19:35:11.316774 IP 192.168.1.1 > 224.0.0.1: igmp query v3 [max resp time 10s]

ICI j'ai relancer la connection du netopia. (sans aucun PC sur le lan)

19:56:48.936045 arp who-has 192.168.1.254 tell 192.168.1.1
19:57:13.365868 IP 192.168.1.1.router > 255.255.255.255.router: RIPv1, Response, length: 44
19:57:45.895951 IP 192.168.1.1.router > 255.255.255.255.router: RIPv1, Response, length: 44
19:57:52.625871 IP 192.168.1.1 > 224.0.0.1: igmp query v3 [max resp time 10s]
19:58:15.765871 IP 192.168.1.1.router > 255.255.255.255.router: RIPv1, Response, length: 44
19:58:47.925871 IP 192.168.1.1.router > 255.255.255.255.router: RIPv1, Response, length: 44
19:59:21.225872 IP 192.168.1.1.router > 255.255.255.255.router: RIPv1, Response, length: 44

###########Et à partir d'ici en mode ''Transpance ip'' (netopia est en mode routeur)###



22:57:28   dhcpcd[10058]   sending DHCP_REQUEST for 85.5.112.132 to 192.168.1.1
22:57:28   dhcpcd[10058]   dhcpIPaddrLeaseTime=120 in DHCP server response.
22:57:28   dhcpcd[10058]   DHCP_ACK received from (192.168.1.1)
22:58:28   dhcpcd[10058]   sending DHCP_REQUEST for 85.5.112.132 to 192.168.1.1
22:58:28   dhcpcd[10058]   dhcpIPaddrLeaseTime=120 in DHCP server response.
22:58:28   dhcpcd[10058]   DHCP_ACK received from (192.168.1.1)
22:59:28   dhcpcd[10058]   sending DHCP_REQUEST for 85.5.112.132 to 192.168.1.1
22:59:28   dhcpcd[10058]   dhcpIPaddrLeaseTime=120 in DHCP server response.
22:59:28   dhcpcd[10058]   DHCP_ACK received from (192.168.1.1)
23:00:28   dhcpcd[10058]   sending DHCP_REQUEST for 85.5.112.132 to 192.168.1.1
23:00:28   dhcpcd[10058]   dhcpIPaddrLeaseTime=120 in DHCP server response.
23:00:28   dhcpcd[10058]   DHCP_ACK received from (192.168.1.1)

[Gesp]

Je n'y vois rien d'intéressant.
Ce que j'aurais voulu voir, c'est la négociation dhcp du netopia, pour voir en quelle manière elle diffère de celle de dhcpcd.
Donc cela doit nécessiter de brancher la machine qui écoute coté amont du netopia, ce qui n'est possible simplement que si l'interface amont est ethernet.

Sinon mets toi en IP fixe et le problème sera sinon réglé, au moins contourné.

[shwing]

Effectivement, je ne peux pas me mettre en amont, car ce n'est pas du RJ45 mais du RJ11 (ligne téléphonique).
Je ne sais pas pourquoi j'ai mis ces derniers logs, un moment d'égarement probablement.

Penses-tu que le problème puisse être 'hardware' du côté du netopia ? Car je le soupçonne d'être 'instable'. Un exemple, un soir je change le mot de passe suite à un reset que je lui ai fais, le lendemain impossible de me loger dedans sans le redémarrer. Etrange non ? Mais l'autre chose étrange, est que si le netopia est seul, donc sans ipcop, je n'ai pas de coupure.

Aussi j'ai tenté de mettre en IP fixe ipcop, cela a tenu en tout cas 30 min, ensuite je suis parti pendant 7h30, et à mon retour plus de connexion au net. Il a fallu que je reswitch en DHCP pour pouvoir allé sur le net, malgré que pour ipcop la connection était établie dans la page d'accueil. Conclusion si tu es en DHCP via ton FAI et que quand même tu fais le setup en IP fixe, 'cela n'est pas une bonne idée'.

Je sais que je peux facilement changer le routeur Netopia dans le magasin de mon FAI, penses-tu que cela peut s'avérer utiles dans mon cas ?

Sinon une autre suggestion ?

[Gesp]

Conclusion si tu es en DHCP via ton FAI et que quand même tu fais le setup en IP fixe, 'cela n'est pas une bonne idée'.

Je ne vois pas de raison en IP fixe, pour que tu sois obligé d'utiliser le dhcp.
Je soupçonne que le routeur soit planté quand tu perds la connexion.

Mais l'autre chose étrange, est que si le netopia est seul, donc sans ipcop, je n'ai pas de coupure.

Quand ipcop n'est pas branché, ta connexion reste établie en continu sans aucune interruption?

[shwing]

Quand ipcop n'est pas branché, ta connexion reste établie en continu sans aucune interruption?

Exacte. aucun déconnection. Dès que j'ai planter le RJ45 d'ipcop (patte red), une déconnection quasi instantanée.

Salut gesp,
Je n'ai pas eu le temps de lire ta réponse pour le moment. Mais apparemment le problème
ne viendrait pas d'ipcop, mais du FAI.
Je ne suis pas le seul, à recevoir des reset de ligne chaque 1h30.

http://www.libellules.ch/phpBB2/siemens ... 24545.html

Bon il y a aussi de neuf. J'ai posté ceci sur le post Probleme de reconnexion avec RED en DHCP
Donc apparemment, le FAI n'est pas tout blanc.

Ceci dit cela fait 5 jours que je n'ai pas eu de coupure. Le mystère planne...