RED en dhcp, problème à la déco/reconnexion (IP dynamique)

par **lurey** » 17 Juin 2005 11:56

Voilà mon nouveau problème…
Modem Bewan ST / firmware A988 fonctionnant en PPPoE, IPCop 1.4.6 > RED en dhcp…
Au moment du changement d'adresse IP par mon FAI, IPCop reste fixé sur l'ancienne adresse … J'ai essayé déconnexion/reconnexion par l'interface, pareil. Solution pour l'instant: reboot !
J'ai reprovoqué le pb. en débranchant puis rebranchant mon modem, voici les logs de RED (mode debug):

--- Pour l'instant, ça marche, xxx.old.ip.xxx m'est attribuée par le FAI ---
10:36:38 dhcpcd[579] dhcpIPaddrLeaseTime=240 in DHCP server response.
10:36:38 dhcpcd[579] DHCP_ACK received from (192.168.0.253)
10:37:23 dhcpcd[579] sending DHCP_REQUEST for xxx.old.ip.xxx to 192.168.0.253
10:37:23 dhcpcd[579] dhcpIPaddrLeaseTime=240 in DHCP server response.
10:37:23 dhcpcd[579] DHCP_ACK received from (192.168.0.253)
10:38:08 dhcpcd[579] sending DHCP_REQUEST for xxx.old.ip.xxx to 192.168.0.253
--- Modem débranché, puis rebranché > changement d'adresse IP par le FAI ---
10:38:37 dhcpcd[579] dhcpIPaddrLeaseTime=240 in DHCP server response.
10:38:37 dhcpcd[579] dhcpT1value is missing in DHCP server response. Assuming 120 sec
10:38:37 dhcpcd[579] dhcpT2value is missing in DHCP server response. Assuming 210 sec
10:38:37 dhcpcd[579] DHCP_NAK server response received
10:38:37 dhcpcd[579] broadcasting DHCP_REQUEST for xxx.old.ip.xxx
10:38:37 dhcpcd[579] dhcpIPaddrLeaseTime=240 in DHCP server response.
10:38:37 dhcpcd[579] DHCP_ACK received from (192.168.0.253)
10:39:22 dhcpcd[579] sending DHCP_REQUEST for xxx.old.ip.xxx to 192.168.0.253
10:39:22 dhcpcd[579] dhcpIPaddrLeaseTime=240 in DHCP server response.
10:39:22 dhcpcd[579] DHCP_ACK received from (192.168.0.253)
10:40:07 dhcpcd[579] sending DHCP_REQUEST for xxx.old.ip.xxx to 192.168.0.253
10:40:07 dhcpcd[579] dhcpIPaddrLeaseTime=240 in DHCP server response.
10:40:07 dhcpcd[579] dhcpT1value is missing in DHCP server response. Assuming 120 sec
10:40:07 dhcpcd[579] dhcpT2value is missing in DHCP server response. Assuming 210 sec
10:40:07 dhcpcd[579] DHCP_NAK server response received
10:40:07 dhcpcd[579] broadcasting DHCP_REQUEST for xxx.old.ip.xxx
10:40:07 dhcpcd[579] dhcpIPaddrLeaseTime=240 in DHCP server response.
10:40:07 dhcpcd[579] DHCP_ACK received from (192.168.0.253)
10:40:52 dhcpcd[579] sending DHCP_REQUEST for xxx.old.ip.xxx to 192.168.0.253
10:40:52 dhcpcd[579] dhcpIPaddrLeaseTime=240 in DHCP server response.
10:40:52 dhcpcd[579] DHCP_ACK received from (192.168.0.253)
10:41:37 dhcpcd[579] sending DHCP_REQUEST for xxx.old.ip.xxx to 192.168.0.253
10:41:37 dhcpcd[579] dhcpIPaddrLeaseTime=240 in DHCP server response.
10:41:37 dhcpcd[579] DHCP_ACK received from (192.168.0.253)
(et ainsi de suite, ces3 lignes se répètent, pas de connexion de Green > Web !)
--- Déconnexion – reconnexion par interface IPCop ---
10:47:26 dhcpcd[579] terminating on signal 15
10:48:16 kernel: eth1: Setting 3c5x9/3c5x9B half-duplex mode if_port: 0, sw_info 9321
10:48:16 kernel: eth1 Setting Rx mode to 0 addresses.
10:48:16 kernel: eth1 Setting Rx mode to 1 addresses.
10:48:16 dhcpcd[21345] broadcasting DHCP_REQUEST for xxx.old.ip.xxx
10:48:20 dhcpcd[21345] broadcastAddr option is missing in DHCP server response. Assuming xxx.NEW.IP.xxx
10:48:20 dhcpcd[21345] dhcpIPaddrLeaseTime=240 in DHCP server response.
10:48:20 dhcpcd[21345] DHCP_ACK received from (192.168.0.253)
10:49:05 dhcpcd[21347] sending DHCP_REQUEST for xxx.old.ip.xxx to 192.168.0.253
10:49:05 dhcpcd[21347] dhcpIPaddrLeaseTime=240 in DHCP server response.
10:49:05 dhcpcd[21347] DHCP_ACK received from (192.168.0.253)
10:49:50 dhcpcd[21347] sending DHCP_REQUEST for xxx.old.ip.xxx to 192.168.0.253
10:49:50 dhcpcd[21347] dhcpIPaddrLeaseTime=240 in DHCP server response.
10:49:50 dhcpcd[21347] DHCP_ACK received from (192.168.0.253)
10:50:35 dhcpcd[21347] sending DHCP_REQUEST for xxx.old.ip.xxx to 192.168.0.253
10:50:35 dhcpcd[21347] dhcpIPaddrLeaseTime=240 in DHCP server response.
10:50:35 dhcpcd[21347] DHCP_ACK received from (192.168.0.253)
--- Reboot de l'IPCop ---
10:50:50 dhcpcd[21347] terminating on signal 15
10:52:09 kernel: eth1 3c5x9 at 0x300, 10baseT port, address 00 20 af be 33 ea, IRQ 9.
10:52:09 kernel: eth2 NE2000 found at 0x240, using IRQ 10.
10:52:16 kernel: eth1: Setting 3c5x9/3c5x9B half-duplex mode if_port: 0, sw_info 9321
10:52:16 dhcpcd[245] broadcasting DHCP_DISCOVER
10:52:20 dhcpcd[245] dns option is missing in DHCP server response. Assuming 192.168.0.253
10:52:20 dhcpcd[245] broadcastAddr option is missing in DHCP server response. Assuming xxx.NEW.IP.xxx
10:52:20 dhcpcd[245] dhcpIPaddrLeaseTime=240 in DHCP server response.
10:52:20 dhcpcd[245] DHCP_OFFER received from (192.168.0.253)
10:52:20 dhcpcd[245] broadcasting DHCP_REQUEST for xxx.NEW.IP.xxx
10:52:20 dhcpcd[245] dhcpIPaddrLeaseTime=240 in DHCP server response.
10:52:20 dhcpcd[245] DHCP_ACK received from (192.168.0.253)
10:52:20 kernel: eth1 Setting Rx mode to 1 addresses.
10:53:05 dhcpcd[247] sending DHCP_REQUEST for xxx.NEW.IP.xxx to 192.168.0.253
10:53:05 dhcpcd[247] dhcpIPaddrLeaseTime=240 in DHCP server response.
10:53:05 dhcpcd[247] DHCP_ACK received from (192.168.0.253)
(ça marche…)

j'imagine que pour que ça fonctionne, il faudrait que la réponse du serveur-modem "DHCP_NAK" entraîne une nouvelle "DHCP_DISCOVER" du client-Ipcop ? mais ceci dépasse ce que je sais comprendre… que se passe-t-il ? Une idée pour contourner ce nouvel écueil ?
(nota: 192.168.0.253 est l'adresse du modem)

par **lurey** » 20 Juin 2005 13:07

... je vous ai déjà trop saoulé avec mon bewan...?

par **Gesp** » 20 Juin 2005 13:42

Cela fonctionnait pour moi avec la freebox ou un Eicon DIVA avant que je sois dégroupé Free.

Tu débranches le modem ou la ligne téléphonique?

Dégroupé ou non dégroupé?

Dans le premier cas, je n'ai pas d'expérience de savoir comment ton FAI gère cela.
Dans le second cas, cela entraine un changement de serveur DHCP à chaque connexion, ce qui est un peu plus long mais qui fonctionnait chez moi. A ce que je me rappelle, il n'y a pas de problème pour avoir un DHCP_DISCOVER.

Je pense que tu as un lease-time trop long (240 soit 6 mn) pour avoir la patience d'attendre que la reconnexion se fasse. La reconnexion ne se fait que quand le bail a expiré.

Donc essaye d'attendre plus de 6 mn ou met un bail plus court (il est de 1 mn sur le DIVA, je ne sais plus sur la Freebox).

par **lurey** » 20 Juin 2005 23:15

bonsoir,
Merci Gesp, de t'intéreser encore à mes malheurs !

Dégroupé ou non dégroupé?

Dégroupé, chez télé2

Je pense que tu as un lease-time trop long (240 soit 6 mn) pour avoir la patience d'attendre que la reconnexion se fasse. La reconnexion ne se fait que quand le bail a expiré.

la première fois que ça me l'a fait, c'était dans la nuit, et c'est donc resté plusieurs heures à rien faire de mieux :oops:

La seule chose, c'est que j'avais à ce moment enlevé les "logs débug" pour ne pas remplir mon disque des lignes du dhcp interrogé toutes les 45"... je les ai remis pour faire mes essais de compréhension....
Je vais refaire des essais "patients", pour être sûr...
Quant au lease-time, si je comprends bien, il dépend de mon modem ? auquel cas... je ne vois aucun accès à ça a travers la seule communication que j'aie trouvé, à savoir l'interface de paramétrage sous windows fournie par bewan avec ce @:evil:#! de firmware. (rien sous telnet, par exemple)

Tu débranches le modem ou la ligne téléphonique?

j'ai fait l'un ou l'autre; juste la ligne téléphonique, il est arrivé que le modem récupère la même adresse IP, (je n'avais pas beaucoup attendu) et donc ça ne reproduisait pas le pb dans ce cas. en débranchant l'alim du modem, ça reprend à chaque coup une adresse différente (le temps aussi de retrouver la synchro).

par **lurey** » 25 Juin 2005 09:35

bonjour,
nouvelle perte de liaison à l'occasion d'un changement d'adresse (heureusement, mon FAI ne renouvelle pas l'adresse chaque jour !)
> nouvelle expérience.
comme dernièrement, RED garde pour adresse l'ancienne, pendant des heures...
09:04:08 dhcpcd[1216] sending DHCP_REQUEST for xxx.OLD.IP.xxx to 192.168.0.253
07:04:08 dhcpcd[1216] dhcpIPaddrLeaseTime=240 in DHCP server response.
07:04:08 dhcpcd[1216] DHCP_ACK received from (192.168.0.253)
07:04:53 dhcpcd[1216] sending DHCP_REQUEST for xxx.OLD.IP.xxx to 192.168.0.253
07:04:53 dhcpcd[1216] dhcpIPaddrLeaseTime=240 in DHCP server response.
07:04:53 dhcpcd[1216] DHCP_ACK received from (192.168.0.253)
Cette fois, j'ai seulement déconnecté le cable entre la carte RED et le modem, voila les logs:
09:07:08 dhcpcd[1216] sending DHCP_REQUEST for xxx.OLD.IP.xxx to 192.168.0.253
09:07:53 dhcpcd[1216] broadcasting DHCP_REQUEST for xxx.OLD.IP.xxx
09:10:23 kernel: eth1: Setting 3c5x9/3c5x9B half-duplex mode if_port: 0, sw_info 9321
09:10:23 kernel: eth1 Setting Rx mode to 0 addresses.
09:10:23 kernel: eth1 Setting Rx mode to 1 addresses.
09:10:23 dhcpcd[1216] broadcasting DHCP_DISCOVER
09:12:20 dhcpcd[1216] dns option is missing in DHCP server response. Assuming 192.168.0.253
09:12:20 dhcpcd[1216] broadcastAddr option is missing in DHCP server response. Assuming xxx.NEW.IP.xxx
09:12:20 dhcpcd[1216] dhcpIPaddrLeaseTime=240 in DHCP server response.
09:12:20 dhcpcd[1216] DHCP_OFFER received from (192.168.0.253)
09:12:20 dhcpcd[1216] broadcasting DHCP_REQUEST for xxx.NEW.IP.xxx
09:12:20 dhcpcd[1216] dhcpIPaddrLeaseTime=240 in DHCP server response.
09:12:20 dhcpcd[1216] DHCP_ACK received from (192.168.0.253)
... et c'est reparti !
Il semblerait (?) que mon modem-serveur dhcp entretienne l'accord pour une adresse , pour peu que la carte RED en aie déjà une, même si elle est différente de celle donnée par le FAI, tant que la liaison n'est pas interrompue... #-o

par **jdh** » 25 Juin 2005 10:27

Je prends ce fil en cours ...

Ta config : Modem Bewan ST / firmware A988 fonctionnant en PPPoE, IPCop 1.4.6 > RED en dhcp

Je ne comprends pas bien.

Si tu as un modem qui gère la communication avec ton FAI (PPPOE), quel besoin as tu de mettre ton IPCOP en dhcp ? Moi je le mettrais en statique et j'éviterais ainsi tous les pbs.

Un modem ne peut fonctionner qu'en 2 modes :

- mode "bridge" : il n'est qu'un convertisseur d'interface ADSL/ethernet (ou USB), c'est le PC relié en direct qui gère rééllement la connexion (au choix PPPOE ou DHCP)

- mode "routeur" : c'est le modem qui gère la connexion = on règle les parametres dans une interface web en général, le côté ethernet utilise un adressage privé (192.168.x en général), le routeur intègre en général un relais dns et un mini serveur dhcp.

Le mode "routeur" est celui qui tend à se généraliser. Les modems dédiés fournis par les FAI standards fonctionne ainsi : par exemple LiveBox, Triway, NeufBox (depuis v3), FreeBox (mode routeur possible). Pour un quidam moyen, cela me parait le mieux car au moins un NAT est réalisé et cela permet de mettre 2 (ou +) PC derrière le modem(-routeur).

Il est assez clair que si un modem fonctionne en routeur, il vaut mieux mettre son IPCOP (ou autre firewall) en adressage statique. Et bien sur, il faudrait paramétrer le modem pour les renvois de ports nécessaire sur l'adresse statique du firewall.

Ta question semble donc plutôt : est-ce qu'IPCOP gère correctement le dhcp ? Normalement cela devrait être le cas.

A noter qu'un parametre du serveur DHCP (= le modem) ne semble pas terrible : il ne se fournit pas lui-même comme serveur DNS, ce qui devrait être le cas. Je suis surpris aussi que dans le premier message il y a à la fois des adresses publiques que tu caches (xxx.OLD.IP.xxx) et des adresses privées (192.168.0.253). C'est vraisemblablement la raison de tes pbs.

Je suis désolé pour cette réponse qui ne devrait pas forcément te convenir.

par **lurey** » 25 Juin 2005 23:08

surtout ne sois ps désolé...
Les idées tous azimut finiront par me faire progresser !
> un préalable: le fonctionnement de mon modem en "routeur" n'est pas clair, il n'est pas expliqué par Bewan (qui m'a pourtant fourni le firmware qui l'a ainsi modifié, par raport à une version précédente qui ne faisait que modem, mais était buggé, c'est une longue histoire).
- donc je peux le paramétrer pour fonctionner en PPPoE, mais par exemple il n'y a rien qui permette de

jdh a écrit:bien sur, il faudrait paramétrer le modem pour les renvois de ports nécessaire sur l'adresse statique du firewall.

Pour compléter, il est prévu aussi de pouvoir utiliser le modem en mode bridge, mais là je n'y suis jamais parvenu, d'où mon utilisation en PPPoE. Enfin, pour mettre en confiance, ce firmware était promis à la publication sur le site Bewan en Avril, et... ils ne l'ont toujours pas officiellement sorti !

Actuellement tel que mon système est paramétré, pour que "ça marche" (accès au web depuis mes réseaux green et orange), il faut que ma carte RED prenne pour adresse IP l'adresse publique attribuée par le FAI. Au premier coup, c'est cette adresse qui est attribuée à RED par le serveur DHCP du modem, et ça coince, donc, quand le FAI me change d'adresse, car la carte RED continue d'être adressée à l'ancienne IP.

Si je suis ta piste: je peux mettre à ma carte RED une adresse dans le réseau de la connexion ethernet du modem (lui, c'est 192.168.0.253 on peut dire RED= 192.168.0.1) Mais je n'ai alors pas de connexion internet...
Peut-être parce que je ne sais pas y faire dans cette configuration, que faut-il indiquer comme "passerelle" aux postes du réseau (actuellement, c'est l'adresse d'IPCop pour chaque patte) , ou encore comme passerelle pour IPCop... ?

par **lurey** » 25 Juin 2005 23:52

Je viens de refaire un essai, que j'avais je crois déjà fait avant réinstall:
RED ip fixe 192.168.0.1
et (pour red ipcop)
passerelle = 192.168.0.253 (ip modem)
dns1 = idem
dns2 = dns proposé par mon fai

de green, je pingue jusqu'à l'adresse du modem, mais pas au-delà (même pas ma propre adresse publique, qui n'a pas bougé tant que le modem reste connecté au web) donc c'est pas un pb de dns seulement, mais bien d'accès...

a propos du Bewan,et des changements apportés par ce firmware, j'ai déjà alimenté un très long post à propos de mon incapacité à l'utiliser en simple bridge comme avant...

par **micjack** » 26 Juin 2005 00:14

Salut,

Ton probleme reste franchement à creuser (comme tu l'as remarqué, j'ai supprimé mon message precedent qui dit la meme chose, etant pas sûr de moi )

Si tu as une connexion établie dés le depart, je ne vois pas la raison du non renouvellement IP (donc, pas de rapport avec un protocole ou ppp machin) ..

Il n'est pas normal, que ton modem ne reprene pas une IP lors d'un changement d'activité (debranchement de la prise tel, coupure sur le réseau..etc )

Connaissant les modem BW ST, ton brobleme reste à creuser pour moi.. ( Donc ? le probleme ne viendrait peut etre pas du modem, mais d'une conf... )

As tu reinstallé ton IPCop au propre pour etre sûr du meme probleme ?

par **lurey** » 26 Juin 2005 00:31

ah, j'avais pas la berlue ! je me demandais où j'avais vu ton post...!
Oui, donc, mon IPCop a été refait de neuf après mes essais en tous genres suite au flashage du firmware.
Ce firmware change le comportement du Bewan ST ethernet ...

jdh a écrit:A noter qu'un parametre du serveur DHCP (= le modem) ne semble pas terrible : il ne se fournit pas lui-même comme serveur DNS, ce qui devrait être le cas

C'est vrai que à ce qu'en disent les logs,
dns option is missing in DHCP server response. Assuming 192.168.0.253
il semble ne s'en remettre que par défaut à 192.168.0.253 (qui est l'adresse du modem côté ethernet), et
broadcastAddr option is missing in DHCP server response. Assuming xxx.NEW.IP.xxx
semble aussi ne s'en remettre que par défaut à l'adresse publique, donnée par le FAI au modem et (?ré-)attribuée à la carte RED de l'IPCop
Ce serait ce " broadcastAddr option is missing" qui ferait qu'après, si RED a une adresse (la précédente), il la lui laisse (DHCP_ACK) alors que l'adresse publique a changé ...?

par **micjack** » 26 Juin 2005 00:41

Pourquoi ne revient tu pas sur un flashage enterieur ? (Si cela fonctonnait bien)
Les derniers flashages sont là pour resoudre certains problemes, mais pas pour forcement ameliorer les choses :wink:

par **lurey** » 26 Juin 2005 01:07

...parceque... Bewan dit que c'est infaisable ! le Firmware est totalement différent (noyau linux au lieu de nucléus) . J'avais fabriqué un système qui contournait efficacement le pb récurent de blocage que beaucoup connaissaient avec ce modem et les firmwares précédents... ajourd'hui, que ne donnerais-je pour avoir encore l'ancien firmware et m'en remettre à mon "bidule" pour retrouver la connexion lorsque le modem bloquait ! :cry:

Je leur ai encore envoyé un mail demandant si une mise au point est en cours, ou s'il y a moyen de revenir à l'ancien...

par **micjack** » 26 Juin 2005 01:39

Bon, vu tout les probleme que tu rencontre depuis ton flashage (qui visiblement n'est plus remediable)
autant changer de modem compatible à 100 % qui simplifiera surrement ta vie (vu le prix des modem ADSL de nos jours , y'a pas à s'en priver)

par **lurey** » 26 Juin 2005 21:07

J'ai très envie de crier victoire, mais les épisodes précédents m'ont appris à être prudent...
Cependant...
J'ai refait mon IPCop, en modifiant l'attribution des cartes réseau. De ce fait, RED est sur la carte intégrée à ma carte mère (Compaq Netelligent), et GREEN est sur la 3Com EtherlinkIII (ISA) qui était avant l'interface RED.
J'ai reparamétré mon modem en passerelle ethernet (bridge) j'ai branché les bons fils dans les bons trous... et je me suis connecté du premier coup !!!
J'en déduis un pb d'incompatibilité, apparu avec le nouveau firmware, car j'avais toujours utilisé ces cartes, et avant flashage ça fonctionnait (à part les blocages du modem)
Je vais faire un essai en intervertissant les cartes à nouveau...

[edit 3/4 d'heure après]
JE CONFIRME ! $\:D/$ Même materiel, même config. sauf les cartes interverties... ça marche pas !
Reste, pour les puristes, à comprendre pourquoi... d'autant qu'avec le firmware précédent, le modem marchait sur la 3Com !
La carte 3Com est en ISA, l'autre en PCI, toutes deux en 10 (et pas 100)
Je ne sais plus la commande pour voir si elles sont en "half/full duplex" et autres paramétrages... qui auraient peut-être une incidence ?

Pour Micjack : je pensais à changer de modem, et d'ailleurs, je vais d'ici peu essayer avec une carte interne Olitec... pas dit que je poste pas à ce sujet, vu mes tâtonnements !

par **micjack** » 26 Juin 2005 23:14

Salut,

Pour verifier tes cartes et en forcer le debit...
http://forums.fr.ixus.net/viewtopic.php ... a27#186072

RED en dhcp, problème à la déco/reconnexion (IP dynamique)

RED en dhcp, problème à la déco/reconnexion (IP dynamique)

Qui est en ligne ?