[technique] Bug firmware Modem Routeur ADSL TP-Link TL-8816 quand le LAN multicast est disabled

Laurent GUERBY laurent at guerby.net
Dim 29 Jan 20:29:24 CET 2012


Bonsoir,

Un petit bug du firmware TP-Link TL-8816 ADSL2/2+ Ethernet Modem Router
hardware v6 Firmware Version 6.0.0 Build 100906 Rel.43560
ADSL Firmware Version : FwVer:3.11.2.175_TC3086 HwVer:T14.F7_6.0
le processus de decouverte et solution trouvée.

Ca se mérite l'ADSL ...

Sincèrement,

Laurent

On Sun, 2012-01-29 at 20:22 +0100, Laurent GUERBY wrote:
> Le TP-Link est en 10.0.0.250 et il reponds
> gaillardement au multicast maintenant :
> 
> 20:18:23.689126 f4:ec:38:9b:be:bb > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 46: 10.0.0.250 > 224.0.0.1: igmp query v2
> 20:18:23.689739 f4:ec:38:9b:be:bb > 01:00:5e:00:00:0c, ethertype IPv4 (0x0800), length 46: 10.0.0.250 > 224.0.0.12: igmp v2 report 224.0.0.12
> 
> J'attends que Benjamin ait fini de manger
> et on teste la bascule sur IP tetaneutral.net.
> 
> Bonne soirée,
> 
> Laurent
> 
> On Sun, 2012-01-29 at 20:06 +0100, Laurent GUERBY wrote:
> > Bon j'ai essayé un truc et ça a marché, le ping
> > a l'air stable maintenant. Dans interface setup, LAN, mettre
> > Multicast a IGMPv2 au lieu de Disabled.
> > 
> > Je vais maintenant remettre le modem TP-Link sur 10.0.0.250/24.
> > Je te laisse repasser la nanostation loco2 aussi sur le reseau et au
> > moment ou tu le fais surveille et laisse tourner un ping vers le modem.
> > 
> > Je continue avec FDN :)
> > 
> > Laurent
> > 
> > <guerby> a un moment sur le LAN ya le PC linux qui envoie un multicast 19:31:00.072175 00:16:3e:21:cf:2c > 01:00:5e:59:bc:01, ethertype IPv4 (0x0800), length 46: 10.0.3.20.33589 > 233.89.188.1.10001: UDP, length 4
> > <guerby> benoar, et pouf le modem ADSL se mets a plus repondre au ping, il est plus ou moins planté par ce paquet visiblement
> > <guerby> peut etre il comprends pas et il mets mal a jour sa table MAC
> > <fab> guerby: t'as un truc qui fait de l'uPnP sur le LAN je pense
> > <fab> et qui mets le modem en rade (ou le configure « pas propre »)
> > <guerby> fab, je connais pas bien l'upnp, j'ai pas avahi sur le PC en question
> > <fab> guerby: oh, ça peut être n'importe quoi...un client torrent, un mediaplayer, ...
> > <guerby> fab, la c'est l'ip/mac source du PC sur lequel je joue
> > <benoar> guerby: ip link set eth0 multicast off
> > <benoar> et basta
> > <guerby> benoar, j'ai activé igmpv2 sur le modem et il survit maintenant
> > <guerby> 19:58:00.074707 00:16:3e:21:cf:2c > 01:00:5e:59:bc:01, ethertype IPv4 (0x0800), length 46: (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 32)
> > <guerby>     10.0.3.20.33589 > 233.89.188.1.10001: [bad udp cksum 93ef!] UDP, length 4
> > <guerby> marrant tcpdump dit que le checksum est pas bon sur ce packet of death
> > <gradator> normal
> > <gradator> c'est ta carte réseau qui le fait
> > <gradator> c'est de l'offloading udp checksum
> > <gradator> si tu désactives l'offloading sur ta carte réseau c'est le kernel qui va calculer le checksum (en soft), et tcpdump verra un bon checksum
> > <guerby> gradator, ah ok, en mode offload le kernel mets des zero ou un truc du genre et c'est le matos qui corrige on the fly
> > <guerby> j'ai bon ?
> > <gradator> il met ce qu'il y a en mémoire je pense
> > <gradator> mettre des 0 ça a un coût
> > <guerby> gradator, :)
> > <gradator> et un 0 n'a pas plus de signification que n'importe quelle autre valeur
> > 
> > On Sun, 2012-01-29 at 19:31 +0100, Laurent GUERBY wrote:
> > > Le ping s'arrete de nouveau suite a trois paquets multicast,
> > >  c'est  une piste
> > > 19:30:57.616513 f4:ec:38:9b:be:bb > 00:16:3e:21:cf:2c, ethertype IPv4 (0x0800), length 98: 10.0.3.15 > 10.0.3.20: ICMP echo reply, id 27116, seq 270, length 64
> > > 19:30:58.616904 00:16:3e:21:cf:2c > f4:ec:38:9b:be:bb, ethertype IPv4 (0x0800), length 98: 10.0.3.20 > 10.0.3.15: ICMP echo request, id 27116, seq 271, length 64
> > > 19:30:58.617533 f4:ec:38:9b:be:bb > 00:16:3e:21:cf:2c, ethertype IPv4 (0x0800), length 98: 10.0.3.15 > 10.0.3.20: ICMP echo reply, id 27116, seq 271, length 64
> > > 19:30:59.618560 00:16:3e:21:cf:2c > f4:ec:38:9b:be:bb, ethertype IPv4 (0x0800), length 98: 10.0.3.20 > 10.0.3.15: ICMP echo request, id 27116, seq 272, length 64
> > > 19:30:59.619267 f4:ec:38:9b:be:bb > 00:16:3e:21:cf:2c, ethertype IPv4 (0x0800), length 98: 10.0.3.15 > 10.0.3.20: ICMP echo reply, id 27116, seq 272, length 64
> > > 19:31:00.072175 00:16:3e:21:cf:2c > 01:00:5e:59:bc:01, ethertype IPv4 (0x0800), length 46: 10.0.3.20.33589 > 233.89.188.1.10001: UDP, length 4
> > > 19:31:00.073853 00:16:3e:21:cf:2c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 46: 10.0.3.20.33589 > 255.255.255.255.10001: UDP, length 4
> > > 19:31:00.077031 00:0d:b9:21:e6:6c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 46: 10.0.3.20.33589 > 255.255.255.255.10001: UDP, length 4
> > > 19:31:00.623676 00:16:3e:21:cf:2c > f4:ec:38:9b:be:bb, ethertype IPv4 (0x0800), length 98: 10.0.3.20 > 10.0.3.15: ICMP echo request, id 27116, seq 273, length 64
> > > 19:31:01.622638 00:16:3e:21:cf:2c > f4:ec:38:9b:be:bb, ethertype IPv4 (0x0800), length 98: 10.0.3.20 > 10.0.3.15: ICMP echo request, id 27116, seq 274, length 64
> > > 19:31:02.625892 00:16:3e:21:cf:2c > f4:ec:38:9b:be:bb, ethertype IPv4 (0x0800), length 98: 10.0.3.20 > 10.0.3.15: ICMP echo request, id 27116, seq 275, length 64
> > > 19:31:03.625025 00:16:3e:21:cf:2c > f4:ec:38:9b:be:bb, ethertype IPv4 (0x0800), length 98: 10.0.3.20 > 10.0.3.15: ICMP echo request, id 27116, seq 276, length 64
> > > 19:31:04.625098 00:16:3e:21:cf:2c > f4:ec:38:9b:be:bb, ethertype IPv4 (0x0800), length 98: 10.0.3.20 > 10.0.3.15: ICMP echo request, id 27116, seq 277, length 64
> > > 
> > > 
> > > On Sun, 2012-01-29 at 19:09 +0100, Laurent GUERBY wrote:
> > > > Salut,
> > > > 
> > > > J'ai cherché longtemps pourquoi je ne pouvais pas acceder
> > > > a l'interface du modem ADSL TP-Link sur la ligne FDN
> > > > et la solution :
> > > > 
> > > > 18:01:26.167746 00:16:3e:21:cf:2c > f4:ec:38:9b:be:bb, ethertype IPv4 (0x0800), length 98: 10.0.0.221 > 10.0.0.252: ICMP echo request, id 25889, seq 3, length 64
> > > > 18:01:26.169069 00:15:6d:19:41:84 > 00:16:3e:21:cf:2c, ethertype IPv4 (0x0800), length 98: 10.0.0.252 > 10.0.0.221: ICMP echo reply, id 25889, seq 3, length 64
> > > > 
> > > > 00:16:3e:21:cf:2c => la VM
> > > > f4:ec:38:9b:be:bb => tplink
> > > > 00:15:6d:19:41:84 => ubiquity "KABANON" ??? pourquoi il repond
> > > > 
> > > > J'ai fini par changer les IP de subnet pour avoir la paix :
> > > > 
> > > > KABANON => 10.0.2.251 (hors LAN)
> > > > 10.0.1.15 => TPLINK
> > > > 10.0.1.20 => VM (alias)
> > > > 
> > > > Avec ça je peux acceder tranquillement au web du modem sur le LAN et le
> > > > WAN.
> > > > 
> > > > Laurent
> > > > 




Plus d'informations sur la liste de diffusion technique