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

Jocelyn Delalande jocelyn.lists2011 at crapouillou.net
Lun 30 Jan 04:13:13 CET 2012


Salut,

J'ai des soucis également avec un modem TP-LINK (TD-8840) de Rhizome. Le 
machin est plus ou moins accessible sur son interface web selon 
l'humeur, ne répond plus quand ça lui chante. Suite à tes indications, 
j'ai surveillé un peu ce qui se passait sur le réseau qui le faisait 
foirer et effectivement quand un gros plein d'IGMP se pointe, c'est là 
que le modem semble déclarer forfait. Piste intéressante donc…

Après, j'ai pas le même modèle donc pas la même interface ouaibe que 
toi. Tout ce que je peux activer concernant IGMP sur le LAN est 
l'IGMP-snooping (mais surement que ton option correspond au final à ça 
aussi…). Pourrais-tu me donner la sortie de "dumpcfg" sur ton modem (en 
s'y connectant en telnet), que je voie à quels paramètres ça correspond 
cette histoire d'IGMP (attention, y'a peut-être des password dans le 
dump, pense à les virer…).

Sinon j'ai pas bien pigé le lien entre IGMP et le fait qu'un device 
Ubiquiti répondait à la place du TPLINK. C'était 2 problèmes différents 
ou le même ?

Je vous tiens au jus…merci d'avance, ciao,

Jocelyn

On 29/01/2012 20:29, Laurent GUERBY wrote:
> 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
>>>>>
> _______________________________________________
> technique mailing list
> technique at lists.tetaneutral.net
> http://lists.tetaneutral.net/listinfo/technique
>




Plus d'informations sur la liste de diffusion technique