Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

Bonjour

Etrange, car j’ai une time capsule en mode bridge derrière une freebox v6 et ça fonctionne sans problème. La time capsule n’a pas d’ip paramétrée, elle la reçoit via dhcp de la freebox (avec un bail statique cependant)

Pourquoi ce fonctionnement? vmware ne permet pas de faire un pont entre tes machines?

J’ai un WN2000RPT configuré en Client (et non en Répéteur) pour pouvoir y connecter plusieurs PC en Ethernet et accéder ainsi à mon réseau WiFi.
Le WN2000RPT reçoit bien une adresse IP dynamique de la part de la FB Server.
Ce sont les PC connectés derrière le WN2000RPT qui ne reçoivent jamais d’adresse IP dynamique de la part de la FB Server.
Solutions de contournement :
- affecter des adresses IP fixes aux PC
- utiliser le serveur DHCP (caché) intégré au WN2000RPT (en jouant sur des plages d’adresses différentes du serveur DHCP de la FB Server)

Probleme deja rapporté ici ⇒ http://bugs.freeplayer.org/task/5181

J’ai un WN2000RPT configuré en Client (et non en Répéteur)

C’est à dire?

@corrector :

C’est à dire que le WN2000RPT ne fait “qu’écouter” sans ré-émettre : j’ai décoché la fonction “Activer le point d’accès sans fil”. J’utilise le WN2000RPT comme un “switch WiFi” pour connecter plusieurs PC en Ethernet et accéder au Wifi de la FB.

Aide en ligne du WN2000RPT : Le point d’accès sans fil de ce périphérique peut être activé ou désactivé pour permettre un accès sans fil. Lorsque cette fonction est activée, les stations sans fil pourront accéder à votre réseau existant via ce périphérique. Lorsque cette fonction est désactivée, les stations sans fil ne pourront pas accéder à votre réseau existant via ce périphérique.

Cordialement,

DFAL

Et tu peux faire une capture réseau du coté de la Freebox, branché en filaire sur la Freebox?

Il s’agit de capter les paquets DHCP qui sont en diffusion limité IP, donc en diffusion Ethernet.

@corrector

Ceci dépasse mon niveau de compétence... où alors il faut m’expliquer comment faire.

Ceci dit dans le suivi  FS#3856 , Maxime Bizon (excusez du peu), indique qu’il s’agit d’un bug du WN2000RPT et indique :

“En fait il y a un problème en mode de cryptage WPA TKIP + AES quand le 802.11n est activé (mode 20Mhz et 40Mhz). Le bug est coté répeteur, et une mise à jour du firmware sur celui ci n’y change rien.

Pour résoudre le problème:
- désactivez le mode 802.11n
- passez en WPA2”
Donc...

Maintenant si le problème affecte plusieurs équipements, ce n’est peut être pas aussi évident. Ils ne peuvent pas tous être bogués.

Cordialement,

DFAL

Des tutos sur la capture de paquets se trouvent sur lafibre.info, dont celui-ci :

http://lafibre.info/tutoriels/realiser-une-capture-wireshark-pas-a-pas/msg28957 /#msg28957

En fait il y a un problème en mode de cryptage WPA TKIP + AES quand le 802.11n est activé

C’est pour voir s’il y a un problème spécifique au DHCP en plus de ça.

@corrector

Ok, je vais essayer (pas aujourd’hui, probablement ce week-end).

Sachant qu’aujourd’hui ma config réseau est : PC ←Ethernet→ WN2000RPT ←Wifi→ FB Server V6

Quel(s) branchement(s) dois-je faire et que dois-je capturer ? (J’ai d’autres PC avec Ethernet et Wifi que je peux utiliser).

Cordialement,

DFAL

Il faut :
- un PC branché en filaire pour écouter (WireShark : le requin du câble)
- un PC pour qu’il y ait quelque chose à écouter

PC (WireShark) ←—→ Freebox <. . . .> WN2000RPT ←—→ PC (DHCP)

Il faut que l’écoute commence avant que les données arrivent, donc avant que le DHCP démarre.

Tu peux installer WireShark sur les deux PC pour avoir un point de comparaison entre ce qui est émis d’un coté et ce qui est reçu de l’autre.

Avec WireShark tu as tout le trafic réseau par défaut. Quand on maitrise bien, on définit le filtre qui convient pour ne voir que ce qu’on cherche mais en général les débutants ferment toutes les applications réseau non nécessaires pour éviter toute distraction dans la capture.

À noter : Firefox et Thunderbird disposent chacun d’un mode déconnecté dans lequel ils cessent tout échange réseau.

Pour n’afficher que les paquets DHCP, tu peux utiliser “bootp” comme expression de filtrage dans WireShark.

Tu peux sauvegarder toute la capture ou seulement les paquets sélectionnés.

La question que me pose : est-ce que les paquets DHCP sont bien transmis à travers le lien Wifi? WireShark permettrait d’y répondre.

Bonjour,

J’ai effectué les captures demandées et je les ai mises à disposition sur le site “dl.free.fr” :

http://dl.free.fr/c7sTBF0oR

Mot de passe :  FS#7207 

Cordialement,

DFAL

PS :

Je ne suis pas expert, mais je trouve dans la capture du PC de surveillance :
- 49 : DHCP REQUEST de la part de mon PC connecté derrière le WN2000RPT
- 50 : DHCP NAK de la part du Freebox Server

On retrouve les mêmes messages en 128/129, 230/231, 264/265, 268/269, 273/274, 316/317, 323/324, 333/334, 355/356, 367/368, 373/374, 384/385, 396/397, 728/729, 731/732, 737/738, 744/745, 757/758, 767/768, 775/776, 786/787, 1012/1013, 1016/1017, 1021/1022, 1028/1029, 1040/1041, 1048/1049, 1058/1059, 1069/1070.

Donc le Freebox Server reçoit bien la demande DHCP, mais il la refuse...

Cordialement,

DFAL

Bravo pour la présentation, c’est “carré”!

Tu fais quoi dans la vie? des rapports d’expertise?

Bon, pour revenir au sujet, est-ce que tu peux configurer le WN2000RPT pour qu’il créé un *pont* Ethernet (Ethernet bridge).

Je pense que le problème viens de là : il n’est pas un pont Ethernet.

Sinon, il faut demander à Free de gérer ce cas là, ce qui n’est pas bien dur.

- utiliser le serveur DHCP (caché) intégré au WN2000RPT (en jouant sur des plages d’adresses différentes du serveur DHCP de la FB Server)

Quand tu fais ça, tu as accès au net?

@ corrector

Réponse au message de 18h48:

A priori, je n’ai tellement de possibilité de configuration sur le WN2000RPT...
La documentation est disponible ici : http://support.netgear.com/app/products/model/a_id/13017 Mais apparemment tout ne figure pas dans cette documentation puisqu’on y trouve pas la fonction DHCP intégrée à l’appareil.

Réponse au message de 19h29 :

C’est ce que j’ai fait en attendant mieux.
Lorsque j’active le serveur DHCP intégré au WN2000RPT, je peux connecter mon PC et j’ai alors accès au réseau local et à Internet, mais c’est le WN2000RPT qui fournit l’adresse IP, pas le FB Server. En plus il doit y avoir un “petit bug” dans le serveur DHCP du WN2000RPT car il donne une adresse IP différente à chaque demande (+1 par rapport à la dernière utilisée).

Cordialement,

DFAL

Je me suis plongé dans la documentation du protocole DHCP et j’ai analysé la capture par le PC Client.

Je remarque que le PC Client commence directement par un DHCP REQUEST sans avoir fait de DHCP DISCOVER avant et en fournissant son ancienne adresse IP. Je pense que cela correspond au renouvellement du bail.

Il ne reçoit pas les DHCP NACK du Freebox Server (filtrés par le WN2000RPT ?).

Cette demande DHCP REQUEST est effectuée 6 fois (1, 76, 152, 179, 181, 184). Elle semble correspondre à une demande de renouvellement de bail.

Puis ce sont des demandes DHCP DISCOVER qui sont effectuées 24 fois (233, 245, 262, 289, 312, 319, 326, 335, 684, 686, 692, 706, 724, 733, 738, 755, 1019, 1022, 1027, 1035, 1058, 1064, 1075, 1089), mais qui ne reçoivent pas non plus de réponse.

Les DHCP DISCOVER sont bien reçu par le Freebox Server (je me suis trompé dans mon message de 17h50 où je les ai considérés comme des DHCP REQUEST).
On les retrouve sur les références 316/317 à 1069/1070 dans la capture du PC de surveillance avec des réponses DHCP OFFER.
Mais ces DHCP OFFER ne reviennent pas vers le PC Client, ils sont probablement supprimés par le WN2000RPT...

Je me suis alors livré à l’expérience suivante :
- j’ai configuré le serveur DHCP du WN2000RPT avec la même plage d’adresses que le Freebox Server, pour le forcer à attribuer une adresse IP dans la même plage que le serveur DHCP du Freebox Server, (l’ancienne plage était disjointe de la plage du Freebox Server); ceci a déconnecté mon PC client,
- mon PC client a demandé le renouvellement de son bail avec son ancienne adresse qui n’était plus valable et a obtenu une nouvelle adresse IP qui s’est trouvée dans la même plage que le serveur DHCP du Freebox Server,
- puis j’ai désactivé le serveur DHCP interne du WN2000RPT; ceci a déconnecté mon PC client,
- mon PC client a de nouveau demandé le renouvellement de son bail qui cette fois a été dirigé vers le Freebox Server et a été accepté puisque dans la plage du serveur DHCP du Freebox Server !

Note : je n’ai pas fait de capture pour m’assurer que c’était bien comme cela que les choses s’étaient réellement passées, mais au final ça a fonctionné.

J’ai fait le test du redémarrage du WN2000RPT : ça tient !

Jusqu’au prochain besoin de changement d’adresse IP de mon PC client DHCP car je retomberai alors dans le même problème.

Il semblerait donc bien que ce soit le répéteur Netgear WN2000RPT (firmware mis à jour en V1.0.1.20) qui soit bogué :
- il filtre les réponses DHCP NACK
- il filtre les réponses DHCP OFFER

Je pense que ce qui a déclenché le problème est qu’avant l’installation de la Freebox V6, (j’avais une Freebox V4 et un routeur Wifi externe) et mon PC en DHCP dynamique avait l’adresse IP 192.168.0.1, (avec un leasetime infini sur le routeur Wifi externe. J’utilisais déjà le répéteur WN2000RPT, mais après que le PC client ait obtenu pour la première fois son adresse IP 192.168.0.1. J’avais fait un pont WDS avec deux routeurs mais ce n’était pas très stable et surtout limité au 802.11g).
Or il semblerait que cette adresse x.x.x.1 soit réservée au Freebox Player, donc dès la première tentative de connexion, le renouvellement du bail de l’adresse 192.168.0.1 a été refusé par un DHCP NACK, qui a été éliminé par le WN2000RPT, et comme les DHCP OFFER semblent aussi être éliminés, impossible au PC client d’obtenir une autre adresse IP tant qu’il était connecté au travers du WN2000RPT.

Cordialement,

DFAL

Mauvaise nouvelle...

La solution décrite ci-dessus n’a pas résisté à un redémarrage complet (power off) du PC client DHCP !

Au redémarrage, celui-ci a directement débuté la négociation DHCP avec un DHCP DISCOVER et une adresse IP courante à 0.0.0.0, et comme le WN2000RPT ne laisse pas passer les DHCP OFFER qui reviennent du Freebox Server, le PC client n’a jamais pu obtenir une adresse IP de la part du Freebox Server.

Donc retour à la case départ : activation du serveur DHCP intégré au WN2000RPT avec une plage d’adresses IP en dehors de la plage d’adresses IP du serveur DHCP du Freebox Server.

Au moins, j’aurai appris comment fonctionne le protocole DHCP

Cordialement,

DFAL

Bonjour,

Pour info, j’ai testé la connexion au Freebox Server avec un Netgear WGPS606 et un cryptage WPA/TKIP (ce client Wifi est trop ancien et ne supporte par le WPA2 et il n’existe malheureusement pas de mise à jour).

Même résultat : le WGPS606 se connecte bien au réseau Wifi, mais refuse de transmettre les réponses DHCP vers les clients qui lui sont connectés en filaires.

Pourtant j’ai utilisé de WGPS606 par le passé sans problème, mais avec un routeur Micradigital (Belkin) F5D7230.

Je doute donc que les matériels Netgear soient les seuls en causes sur ces problèmes...

Je vais me plonger dans l’analyse détaillée des messages DHCP renvoyés par le Freebox Server.

Cordialement,

DFAL

Bonjour,

En analysant finement les frames capturées par WireShark, j’ai peut être mis le doigt sur le problème au niveau de la gestion des entêtes Ethernet (noter le conditionnel).

Analyse d’une requête DHCP DISCOVER.

1) Le client DHCP envoie sa requête DHCP DISCOVER avec en source son adresse MAC et en destination l’adresse MAC broadcast (ff:ff:ff:ff:ff:ff).

2) Le répéteur Netgear WN2000RPT retransmet la requête DHCP DISCOVER en remplacant l’adresse source avec sa propre adresse MAC et en laissant en destination l’adresse MAC broadcast (ff:ff:ff:ff:ff:ff). Les données du messages ne sont pas modifiées, entre autre l’adresse MAC du client DHCP est conservée.

3) Le Freebox Server reçoit la requête DHCP DISCOVER et répond par un DHCP OFFER avec en en source son adresse MAC et en destinsation l’adresse MAC du client DHCP et non pas l’adresse MAC du répéteur WN2000RPT. Il n’a donc pas repris au niveau de l’adressage Ethernet l’adresse MAC qu’il a reçu comme source du message, mais reprend l’adresse MAC qui était dans les données du message (Bootstrap Protocol).

Du coup, je suppose que le répéteur WN2000RPT considère que la frame Ethernet contenant le message DHCP OFFER ne lui est pas destiné et l’ignore purement et simplement, ne propageant donc pas la réponse vers le client DHCP.

J’ai constaté la même chose avec le message DHCP REQUEST émis pour renouveller le bail :

1) Le client DHCP envoie sa requête DHCP REQUEST avec en source son adresse MAC et en destination l’adresse MAC broadcast (ff:ff:ff:ff:ff:ff).

2) Le répéteur Netgear WN2000RPT retransmet la requête DHCP REQUEST en remplacant l’adresse source avec sa propre adresse MAC et en laissant en destination l’adresse MAC broadcast (ff:ff:ff:ff:ff:ff). Les données du messages ne sont pas modifiées, entre autre l’adresse MAC du client DHCP est conservée.

3) Le Freebox Server reçoit la requête DHCP REQUEST et répond par un DHCP NACK avec en en source son adresse MAC et en destinsation l’adresse MAC du client DHCP et non pas l’adresse MAC du répéteur WN2000RPT. Il n’a donc pas repris au niveau de l’adressage Ethernet l’adresse MAC qu’il a reçu comme source du message, mais reprend l’adresse MAC qui était dans les données du message (Bootstrap Protocol).

Ceci pourrait expliquer le comportement observé : la non prise en compte et la non réémission des réponses DHCP du Freebox Server par le répéteur WN2000RPT.

Cordialement,

DFAL