Forum Linux.noyau Bug noyau dans le module ipv6 ?

Posté par  .
Étiquettes :
3
23
mar.
2010

Bonjour forum,



Alors voilà, je me suis acheté une toute nouvelle carte mère pour mon petit serveur, une supermicro X7SPA-HF (super classe surtout avec l'IPMI qui permet de la contrôler à distance). Je récupère mon install de debian stable, et une recompilation via make-kpkg d'un noyau tout frais (2.6.33.1) plus tard, tout est fin prêt, le serveur est en route.



Le problème est arrivé quand j'ai voulu réactivé la conf IPv6 sur mon réseau (côté serveur ça n'avait pas bougé, mais l'IPv6 était désactivé depuis un certain temps sur les clients). Tentative de chargement de google en IPv6 depuis un PC sur le réseau local => Kernel Panic.



Voici en gros la conf :
Le serveur fait passerelle/NAT vers l'extérieur. Je suis chez Free, j'utilise une adresse IPv6 dans mon subnet alloué par eux. Pour IPv6 je ne natte pas, mais j'ai configuré du proxy Neighbour Discovery pour que les machines à l'intérieur puissent discuter en IPv6 avec la freebox. Les IP dans le LAN local sont autoconfigurées par radvd.



Le /etc/network/interfaces :




allow-hotplug eth0


iface eth0 inet static


        address 192.168.13.254


        netmask 255.255.255.0


iface eth0 inet6 static


        address 2a01:e35:xxxx:xxxx:1::fffe


        netmask 64


	# serveur


        post-up /sbin/ip -6 neigh add proxy 2a01:e35:xxxx:xxxx::2 dev eth0


        # freebox


	post-up /sbin/ip -6 neigh add proxy 2a01:e35:xxxx:xxxx::1 dev eth0





allow-hotplug eth1


iface eth1 inet dhcp


iface eth1 inet6 static


        address 2a01:e35:xxxx:xxxx::2


        netmask 126


        post-up /sbin/ip -6 route add default via 2a01:e35:xxxx:xxxx::1 dev eth1


        # serveur


        post-up /sbin/ip -6 neigh add proxy 2a01:e35:xxxx:xxxx:xxxx:90ff:fe01:xxxx dev eth1


        # client1


        post-up /sbin/ip -6 neigh add proxy 2a01:e35:xxxx:xxxx:xxxx:cbff:fea7:xxxx dev eth1


        # client2


        post-up /sbin/ip -6 neigh add proxy 2a01:e35:xxxx:xxxx:xxxx:4bff:fea5:xxxx dev eth1



Tout fonctionne bien, jusqu'à ce qu'un client essaye d'accéder à l'extérieur en IPv6 : Kernel panic direct :




[ 3180.848040] BUG: unable to handle kernel NULL pointer dereference at 0000000000000068


[ 3180.852002] IP: [] ndisc_send_na+0x9a/0x1a0 [ipv6]


[ 3180.852002] PGD 13d881067 PUD 13da3e067 PMD 0


[ 3180.852002] Oops: 0000 [#1] SMP


[ 3180.852002] last sysfs file: /sys/devices/platform/w83627ehf.3232/cpu0_vid


[ 3180.852002] CPU 0


[ 3180.852002] Pid: 0, comm: swapper Not tainted 2.6.33.1 #1 X7SPA-HF/X7SPA-HF


[ 3180.852002] RIP: 0010:[]  [] ndisc_send_na+0x9a/0x1a0 [ipv6]


[ 3180.852002] RSP: 0018:ffff880028203cf0  EFLAGS: 00010246


[ 3180.852002] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff880028203d20


[ 3180.852002] RDX: ffff88013d4c2900 RSI: 00000000fffffffe RDI: ffff880028203d20


[ 3180.852002] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000


[ 3180.852002] R10: ffff88013e131f40 R11: 0000000000000003 R12: 0000000000000001


[ 3180.852002] R13: ffff88012fc31c60 R14: ffff88013fbb8000 R15: 0000000000000000


[ 3180.852002] FS:  0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000


[ 3180.852002] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b


[ 3180.852002] CR2: 0000000000000068 CR3: 00000013db85000 CR4: 00000000000006f0


[ 3180.852002] DR0: 0000000000000000 DR1: 000000000000000 DR2: 0000000000000000


[ 3180.852002] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400


[ 3180.852002] Process swapper (pid: 0, threadinfo ffffffff8130e000, task ffffffff8132b020)


[ 3180.852002] Stack:


[ 3180.852002]  ffff88012af029c0 ffffffff811e0a87 0000000100000000 000000012830df50


[ 3180.852002]  ffff88012fc31c38 ffff88012af029c0 00000000000080fe df3101feff902502


[ 3180.852002]  0000000000000088 0000000400000000 ffff88013e7551c0 ffff88012af029c0


[ 3180.852002] Call Trace:


[ 3180.852002]  


[ 3180.852002]  [] ? neigh_update+0x2c7/0x560


[ 3180.852002]  [] ? ndisc_recv_ns+0x2d3/0x5d0 [ipv6]


[ 3180.852002]  [] ? pndisc_redo+0x9/0x20 [ipv6]


[ 3180.852002]  [] ? neigh_proxy_process+0x112/0x130


[ 3180.852002]  [] ? neigh_proxy_process+0x0/0x130


[ 3180.852002]  [] ? run_timer_softirq+0x13c/0x200


[ 3180.852002]  [] ? ktime_get+0x61/0xe0


[ 3180.852002]  [] ? __do_softirq+0xa7/0x130


[ 3180.852002]  [] ? call_softirq+0x1c/0x30


[ 3180.852002]  [] ? do_softirq+0x4d/0x80


[ 3180.852002]  [] ? irq_exit+0x75/0x90


[ 3180.852002]  [] ? smp_apic_timer_interrupt+0x6c/0xa0


[ 3180.852002]  [] ? apic_timer_interrupt+0x13/0x20


[ 3180.852002]  


[ 3180.852002]  [] ? mwait_idle+0x62/0x70


[ 3180.852002]  [] ? cpu_idle+0x5a/0xc0


[ 3180.852002]  [] ? start_kernel+0x34a/0x410


[ 3180.852002]  [] ? x86_64_start_kernel+0xe1/0xf2


[ 3180.852002] Code: c0 48 89 c5 0f 84 d7 00 00 00 31 db f6 40 25 04 0f 84 ab 00 00 00 48 8d 45 1c f0 ff 08 0f 94 c2 84 d2 4c 89 ef 0f 85 a6 00 00 00  8b 45 68 0f b6 54 24 1c 4c 8d 44 24 40 4d 89 e9 44 0b a0 08


[ 3180.852002] RIP  [] ndisc_send_na+0x9a/0x1a0 [ipv6]


[ 3180.852002]  RSP 


[ 3180.852002] CR2: 0000000000000068


[ 3181.144381] ---[ end trace 7503f2cdcfc75884 ]---


[ 3181.149083] Kernel panic - not syncing: Fatal exception in interrupt


[ 3181.155522] Pid: 0, comm: swapper Tainted: G      D    2.6.33.1 #1


[ 3181.161773] Call Trace:


[ 3181.164286]    [] ? panic+0x86/0x154


[ 3181.170004]  [] ? irq_exit+0x43/0x90


[ 3181.175211]  [] ? ret_from_intr+0x0/0xa


[ 3181.180679]  [] ? vgacon_cursor+0x0/0x240


[ 3181.186321]  [] ? kmsg_dump+0x7e/0x140


[ 3181.191704]  [] ? oops_end+0x95/0xa0


[ 3181.196911]  [] ? no_context+0x100/0x270


[ 3181.202467]  [] ? __bad_area_nosemaphore+0x155/0x230


[ 3181.209086]  [] ? ndisc_rcv+0xc4c/0x1040 [ipv6]


[ 3181.215253]  [] ? page_fault+0x1f/0x30


[ 3181.220644]  [] ? ndisc_send_na+0x9a/0x1a0 [ipv6]


[ 3181.226986]  [] ? neigh_update+0x2c7/0x560


[ 3181.232724]  [] ? ndisc_recv_ns+0x2d3/0x5d0 [ipv6]


[ 3181.239156]  [] ? pndisc_redo+0x9/0x20 [ipv6]


[ 3181.245143]  [] ? neigh_proxy_process+0x112/0x130


[ 3181.251479]  [] ? neigh_proxy_process+0x0/0x130


[ 3181.257639]  [] ? run_timer_softirq+0x13c/0x200


[ 3181.263803]  [] ? ktime_get+0x61/0xe0


[ 3181.269096]  [] ? __do_softirq+0xa7/0x130


[ 3181.274737]  [] ? call_softirq+0x1c/0x30


[ 3181.280293]  [] ? do_softirq+0x4d/0x80


[ 3181.285675]  [] ? irq_exit+0x75/0x90


[ 3181.290885]  [] ? smp_apic_timer_interrupt+0x6c/0xa0


[ 3181.297479]  [] ? apic_timer_interrupt+0x13/0x20


[ 3181.303726]    [] ? mwait_idle+0x62/0x70


[ 3181.309787]  [] ? cpu_idle+0x5a/0xc0


[ 3181.314995]  [] ? start_kernel+0x34a/0x410


[ 3181.320724]  [] ? x86_64_start_kernel+0xe1/0xf2



J'ai essayé de rebooter avec le kernel 2.6.26-2-amd64 fournit avec debian stable, et là tout fonctionne. Une recherche google sur mon problème avec des bouts de traces n'a pas donné grand chose...



Je pencherais donc pour un bug qui aurait été introduit dans le noyau depuis...
Bon problème, je ne suis pas un habitué des kernel mailing list...



Cher forum, sais tu donc comment je peux faire pour signaler ce problème et si il manque des choses pour pouvoir faire une analyse de ce bug ?



Merci !

  • # Paquet responsable

    Posté par  . Évalué à 2.

    Salut,

    Ce bug à l'air intéressant, pour ce qui est des LKML je ne pourrais pas t'aider.
    Par contre, il serait peut etre utile de capturer le trafic réseau avec tcpdump ou wireshark et d'en extraire les paquets responsable afin de pouvoir facilement rejouer le scénario.

    mes 2 centimes

    • [^] # Re: Paquet responsable

      Posté par  . Évalué à 1.

      Yep. J'arrive sans pb à rejouer le scénario, puisqu'il suffit que j'active l'ipv6 sur une machine dans le LAN et d'accéder à google pour faire planter le serveur.

      Pour la trace c'est une bonne idée, mais je devrais la faire entre le serveur et la freebox et je n'ai pas trop le matériel (il me faudrait un pauv' hub 10).

  • # oubli ?

    Posté par  . Évalué à 2.

    tu n'as pas oublié un module dans ta recompile perso du kernel ?

    • [^] # Re: oubli ?

      Posté par  . Évalué à 2.

      et sans le proxy ca donne quoi ?

      pcq la premiere ligne du kernel panic ca commence par
      [ 3180.852002] [] ? neigh_update+0x2c7/0x560

      et ca ressemble à ton neigh utiliser par ton proxy ;)

      • [^] # Re: oubli ?

        Posté par  . Évalué à 1.

        Oui merci ça j'avais bien vu. Le problème c'est que si je supprime ces lignes, le routage LAN <-> Extérieur ne fonctionne plus :(

        • [^] # Re: oubli ?

          Posté par  . Évalué à 2.

          en gros tu as un reseau comme ca ?

          M1
          |
          Switch - Serveur - Freebox - Internet
          |
          M2

          et ton serveur fait "proxy/routeur", c'est ca ton scenar ?

  • # si tu veux t'amuser...

    Posté par  . Évalué à 4.

    On dirait qu'il oops dans le code chargé d'envoyer un neighbor discovery.
    Si ça t'intéresse, voici comment voir exactement où il plante : http://kerneltrap.org/node/3648
    La fonction n'est pas bien longue, il n'y a pas d'inline, ça devrait être relativement facile. Par contre après il faut remonter...

    • [^] # Re: si tu veux t'amuser...

      Posté par  . Évalué à 1.

      Merci, je vais voir ce que je peux en tirer. Bon par contre je ne suis pas certain que mes talents de programmeur soient suffisants pour établir le diagnostic !

  • # ip neigh add proxy déprécié

    Posté par  . Évalué à 4.

    Tes commandes d'ip neigh add proxy sont dépréciées depuis ... 2001 : http://linux-ip.net/html/tools-ip-neighbor.html

    Je ne sais pas exactement à quoi ça te sert ; c'est peut-être dû au fait que Free servait seulement un /64 directement depuis la Freebox ? Il me semble qu'ils ont changé ça et que maintenant tu as un /56 et que tu pourras ainsi faire un subnet correct (/64) sur ton serveur. (perso chez FDN j'ai un /48 ...)

    • [^] # Re: ip neigh add proxy déprécié

      Posté par  . Évalué à 1.

      Hello,

      Merci pour l'info.
      Je vais éplucher ta page et voir si je peux trouver une commande équivalente qui ne fasse pas planter le noyau. En fait j'avais plus ou moins suivi ce tutoriel http://en.gentoo-wiki.com/wiki/IPV6_And_Freebox et effectivement ça me sert car je n'avais qu'un /64.

      C'est une bonne nouvelle si maintenant c'est un /56 (mais j'ai trouvé l'info nulle part, je vérifierai sur ma machine quand je peux), ça évitera ces bidouilles...

      • [^] # Re: ip neigh add proxy déprécié

        Posté par  . Évalué à 1.

        Ah bé non, après vérification, c'est toujours un /64 qui est envoyé :

        Internet Control Message Protocol v6
        Type: 134 (Router advertisement)
        Code: 0
        Checksum: 0x707a [correct]
        Cur hop limit: 64
        Flags: 0x00
        0... .... = Not managed
        .0.. .... = Not other
        ..0. .... = Not Home Agent
        ...0 0... = Router preference: Medium
        Router lifetime: 1800
        Reachable time: 0
        Retrans timer: 0
        ICMPv6 Option (Prefix information)
        Type: Prefix information (3)
        Length: 32
        Prefix length: 64
        Flags: 0xc0
        1... .... = Onlink
        .1.. .... = Auto
        ..0. .... = Not router address
        ...0 .... = Not site prefix
        Valid lifetime: 86400
        Preferred lifetime: 86400
        Prefix: 2a01:e35:xxxx:xxxx::

        • [^] # Re: ip neigh add proxy déprécié

          Posté par  . Évalué à 3.

          Ce n'est pas parce que la freebox annonce seulement un /64 que tu ne peux pas router plus. D'après http://www.freenews.fr/spip.php?article5813 chaque abonné aurait un /60. Tu peux donc utiliser les 4 bits en rab pour router un sous-réseau. Genre tu mets une route statique dans la freebox vers ton routeur (genre 2a01:e35:xxxx:xxx(x+1)::/64 si la freebox prend bien le premier /64 dispo). Ton routeur servira ce sous-réseau en l'annonçant avec son radvd. Plus besoin de bidouiller avec les ip neigh add proxy.

          • [^] # Re: ip neigh add proxy déprécié

            Posté par  . Évalué à 2.

            Je viens de lire http://www.ripe.net/ripe/meetings/ripe-58/content/presentati(...) et à priori c'est ça : tu disposes des 4 derniers bits du Link Prefix pour faire tes sous-réseaux /64, et la box a l'air de prendre le premier (0) par défaut. Vérifie quand même. Et pour la route statique, j'espère que c'est possible avec la freebox ... Par contre, j'ai vu aussi que RADVD peut advteriser une route statique (en en mettant du côté freebox sur ton routeur) mais j'ai aussi vu que par défaut linux refusait les advertisements de routes statiques (faut changer /proc/sys/net/ipv6/conf/all/accept_ra_rt_info_max_plen).

            • [^] # Re: ip neigh add proxy déprécié

              Posté par  . Évalué à 1.

              Merci, c'est super intéressant !
              Alors j'ai essayé de pinguer de l'extérieur 2a01:e35:xxxx:xxx(x+1)::1, mais ça n'arrive pas jusque mon serveur. Il faut donc très certainement ajouter la route sur la freebox.
              Pas encore testé la conf RADVD pour advertiser la route statique. Je vous tiendrai au courant !

              Merci !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.