- État Fermée
- Pourcentage achevé
- Type Anomalie
- Catégorie LAN → WiFi
- Assignée à Personne
- Système d'exploitation Tous
- Sévérité Basse
- Priorité Très Basse
- Basée sur la version 1.1.3
- Due pour la version Non décidée
-
Échéance
Non décidée
- Votes
- Privée
Ouverte par paillassou - 07/12/2011
FS#9138 - freebox révolution v6 incompatible avec les répéteurs WIFI
Bonjour, je ne sais pas si cela fera avancer le schmilblik,
mais, le fonctionnement du serveur DHCP de la FREEBOX REVOLUTION v6
la rend incompatible avec certains répéteurs WIFI actuels.
En effet, alors que certains répéteurs WIFI comme le WN2000RPT
était parfaitement fonctionnels avec la FREEBOX v5 HD, il ne peuvent plus l’être
la nouvelle FREEBOX REVOLUTION v6.
Dernièrement, ayant acheté un petit répéteur de la marque SAPIDO RB-1602,
je me retrouve confronté au même pb...
http://www.sapido.com.tw/EN/productrb1602o.htm
Petit, pas trop cher (25€), avec ses 3 fonctions intéressantes [ROUTEUR / AP / WIFI AP]
je comptais m’en servir pour étendre le réseau WIFI 802.11N faiblard de ma FREEBOX v6 REVOLUTION
en restant sur le même sous-reseau (répéteur wifi bridge / mode WIFI AP)
FREEBOX v6 REVOLUTION est en 192.168.0.254 avec serveur DHCP serveur actif
et broadcast DHCP actif également
bon ben, je capitule :(
[b]le RB-1602 ne fonctionne pas en mode WIFI AP MODE (wifi repeater bridge mode) pour répéter le SSID d’une FREEBOX v6 REVOLUTION
le RB-1602 fonctionne parfaitement en mode WIFI AP MODE (wifi repeater bridge mode) pour répéter le SSID d’un WRT54GS (sous DD-WRT)
EDIT 04/12/2011:
le RB-1602 fonctionne parfaitement en mode WIFI AP MODE (wifi repeater bridge mode) pour répéter le SSID d’une BBBOX (box modem adsl routeur de chez BOUYGUES TELECOM)
[/b]
il y a donc bien qqchose, dans le mode de fonctionnement de la FREEBOX v6 REVOLUTION
qui la rend incompatible avec le SAPIDO RB-1602.
le problème rencontré est un des problèmes TRES TRES connus des
” WIFI REPEATER BRIDGE " / répéteurs WIFI bridge (c.a.d sur le même sous-réseau)
à savoir le tracassant pb lié au MAT M.A.T Mac Address Translation (translation d’adresse MAC)
⇒ des tas de problèmes sont recencés sur le WEB avec d’autres répéteurs WIFI dans ce mode de fonctionnement BRIDGE
(c.a.d sur le même sous-réseau)
comme avec le netgear WN2000RPT
http://www.google.fr/#sclient=psy-ab&hl=fr&rlz=1R2GGLR_frFR440&source=hp&q=wn2000rpt+freebox&pbx=1&oq=WN2000&aq=1&aqi=g4&aql=&gs_sm=e&gs_upl=0l0l1l360l0l0l0l0l0l0l0l0ll0l0&rlz=1R2GGLR_frFR440&bav=on.2,or.r_gc.r_pw.r_cp.,cf.osb&fp=ad8277bae25f9e4&biw=1680&bih=849
en gros, le principe est le suivant:
La FREEBOX v6 REVOLUTION emet un SSID “toto” de type 802.11N canal 6 avec cryptage WPA2-PSK/AES & passphrase (key=12345678)
Le SAPIDO RB-1602, quant à lui, est configuré en mode " WIFI AP "
il est censé “s’accrocher” au SSID emis par la FREEBOX v6 REVOLUTION
et emettre, de son côté, un autre SSID étendu (extended SSID) avec le type de cryptage que l’on souhaite
[pour pas s’embêter on utilise le même type de crypage que celui de départ, à savoir:
Extended SSID “tata” de type 802.11N canal 6 avec cryptage WPA2-PSK/AES & même passphrase (key=12345678)]
Les PCs clients (en DHCP) devraient se connecter au Extended SSID (émis par le RB-1602)
et récupérer une adresse IP via le serveur DHCP de la FREEBOX v6 REVOLUTION
(du type 192.168.0.xxx / c.a.d sur le MEME SOUS-RESEAU puisqu’on est en mode WIFI REPEATER BRIDGE)
et tout devrait rouler...
et bien ⇒ NADA ! ça mouline ça mouline mais rien... aucun transfert DHCP :( et pas de NET sur les PCs clients...
Peu importe si la fonction BROADCAST DHCP soit activée ou pas sur la FREEBOX v6 REVOLUTION
ça ne fonctionne pas...
Peu importe si la fonction 802.11N soit activée ou pas sur la FREEBOX v6 REVOLUTION
ça ne fonctionne pas...
Voilà... donc si nos amis devs ont une idée...
MERCI d’avance
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
Mon ticket pourrait très bien être fusionné avec un autre ticket ouvert qui est relatif au même type de problème
http://bugs.freeplayer.org/task/9088
D’un point de vue protocolaire:
- le DHCP est fait de telle manière que l’adresse mac du client transite deux fois, une fois dans le header ethernet, et une fois dans la requête DHCP elle même,
- le 802.11 est fait de telle manière qu’un STA ne peut transmettre des paquets que si ils viennent de sa propre mac address,
Si c’est comme pour les autres répéteurs, le problème est normalement le suivant:
- un paquet DHCP arrive sur le réseau créé par le répéteur, le répéteur le MAT et le transmet,
- le paquet arrive sur la box, avec pour adresse source mac l’adresse du répéteur, et contenant toujours l’adresse mac du client dans le payload DHCP,
- la box répond, comme il se doit, à l’adresse du client,
- le client n’est pas présent sur ce réseau, il ne reçoit pas la réponse, le répéteur non plus.
La réponse en broadcast est un contournement de base, faisant que le répéteur reçoit une copie du paquet, et la transmet (normalement) à son client.
Restre à comprendre pourquoi l’activation de la réponse en broadcast systématique ne suffit pas.
Pour savoir à quel niveau il y a du trafic perdu, des traces réseau aideraient.
autre ticket qui pourrait être lié ⇒ http://bugs.freeplayer.org/task/3856
Merci Nicolas pour cette MEGA réponse TRES TRES technique ;)
oui effectivement, je me doute bien qu’il doit y avoir une explication dans la trame ethernet ;)
bon il est vrai que je ne suis pas un as de l’utilisation de WireShark...
et surtout je ne sais pas trop comment m’y prendre pour récupérer les traces de quelque chose qui fonctionne pas lol ;)
Tout ce que je peux constater, c’est que le comportement et le fonctionnement même du serveur DHCP de la FREEBOX REVOLUTION v6
est bien en cause, puisque ce répéteur SAPIDO RB-1602 fonctionne parfaitement pour répéter le WIFI d’une BBOX et/ou d’un WRT54GS.
Le fonctionnement d’un serveur DHCP ne devrait il pas être générique (specs RFC) si celui de la FREEBOX REVOLUTION v6 est le BON cela voudrait dire que celui de la BBOX et du WRT54GS eux ne se comportent pas correctement ???!!!
EDIT 20/12/2011: pour info
Le SAPIDO RB-1602 fonctionne parfaitement en mode WIFI AP MODE
(wifi repeater bridge mode) pour répéter le SSID d’une NEUF BOX
(box modem adsl routeur de chez SFR)
Bonnes Fêtes de fin d’année aux développeurs de chez FREE.
PS: j’attends toujours (avec impatience) que la fusée FREEMOBILE soit lancée
Moyen de contournement : utiliser une IP fixe sur les clients, ou activer le serveur DHCP sur le répéteur.
Sinon il suffit de définir une ip pseudo statique dans la freebox pour l’adresse mac sur répéteur, ou alors de lui définir une IP fixe en dur.