|
Description de la tâche
Bonjour,
J’ai repéré un comportement très étrange sur le bridge réalisé par Freebox entre un client wifi et une cible filaire.
(donc sur un traffic uniquement à l’intérieur du LAN de la Freebox)
Voici la situation simple pour reproduire:
1) Un client qqconque en wifi connecté sur la Freebox Pop (F-GW08D)
2) Une machine “serveur” qqconque branchée en ethernet (directement sur la freebox)
Il suffit de ping le “serveur” depuis le client wifi.
Alors, les requêtes ARP arrivent bien sur le serveur, mais avec une longueur anormalement grande, cf:
clientwifi$ ping 192.168.8.14
PING 192.168.8.14 (192.168.8.14): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
Request timeout for icmp_seq 0
serveur# tcpdump -i igb0 -nn -vvve arp
21:01:59.377399 14:10:zz:zz:zz:cb > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 64: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.8.14 tell 192.168.8.227, length 50
⇒ 64 bytes ici (vs 60 bytes normalement)
Une analyse avec wireshark (toujours du coté du serveur) montre un FCS ou un padding (suivant l’heuristique d’analyse choisi) anormal de 4 bytes: 0×00000000 qui semble ajouté sur la couche ethernet de toutes les requêtes ARP qui sont passés par la Freebox en wifi.
Ma conclusion:
⇒ le bridge de la freebox “modifie” (+4 bytes) les trames ARP lorsqu’elles transitent depuis le coté wifi vers les ports ethernet, ce qui les rends non standard
⇒ bug de la freebox ?
Important: le mot “bridge” que j’utilise ici n’a rien à voir avec le fameux “mode bridge”, car je parle du “switch” (layer 2) fait par la freebox entre les différentes partie du LAN (wifi & ports ether).
NB: ma Freebox est en mode “routeur” comme par défaut, et il n’y aucun routeur ou autre équipement “avancé” supplémentaire.
Merci d’avance
|
