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

Laurent GUERBY laurent at guerby.net
Lun 30 Jan 10:23:46 CET 2012 

On Mon, 2012-01-30 at 04:13 +0100, Jocelyn Delalande wrote:
> 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 ?

Finalement on va acheter un autre modem pour Saint-Gaudens car meme
avec le reglage en place on est pas arrivé a stabiliser le modem
routeur.

L'option est dans interface / internet / LAN = multicast
a passer de disabled a IGMPv2 (ou v1). Il y a aussi
un multicast sur la partie "Internet" mais on a pas
joué avec.

Pour le probleme de MAC on a pas encore compris ce qu'il se
passe, je vais recuperer ce modem routeur chez moi
et essayer plus de choses.

Laurent

> 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
> >
> 
> _______________________________________________
> technique mailing list
> technique at lists.tetaneutral.net
> http://lists.tetaneutral.net/listinfo/technique

Plus d'informations sur la liste de diffusion technique