os anúncios do roteador não passam pela ponte com fio / sem fio

Question

A configuração completa:

• Um cable modem + roteador Netgear CVBG834G (4 * Ethernet + WiFi)
  • configurado no modo bridge (e o Wi-Fi é desligado)
  • cujo único papel é servir um endereço IPv4 público em sua porta LAN para ...
• um Apple Time Capsule:
  • fornecendo um AP Wi-Fi
  • configurada como a ponte LAN de Ethernet + WiFi usual
  • NAT do IPv4 público acima mencionado para a referida LAN
  • distribuindo concessões DHCP IPv4 para a ponte LAN
• um Linksys NSLU2 com o Debian Lenny:
  • conectado corretamente na parte de trás do Time Capsule
  • gerenciando um túnel IPv6 Sixxs
  • lidando com conexões TAP openvpn sobre UDP (tap0) e TCP (tap1)
  • conectando sua eth0 com interfaces de tap * em br0
  • anunciando um prefixo Sixxs / 64 em br0 via radvd
  • ter um IPv6 do prefixo referido estaticamente atribuído a br0
• um monte de máquinas da Apple (3 * Macs, 2 * iPhones, 1 * iPad)

O problema:

Os clientes IPv6 sem fio não recebem um endereço IPv6. Se conectado via Ethernet à parte de trás do Time Capsule, os mesmos clientes recebem um endereço IPv6 e configuração do roteador, e são capazes de fazer ping6 e navegar por sites IPv6.

Etapas de diagnóstico:

• 'radvdump' quando o ssh'd no NSLU2 mostra RAs adequados
• quando associado ao AP:
  • O NSLU2 pode ser pingado com seu endereço local de link
  • se for fornecido qualquer endereço IPv6 estático do prefixo / 64 anunciado, o NSLU2 será ping6''cabo
  • 'sudo tcpdump -i en1 icmp6' mostra cargas de RS de todas as máquinas, mas não de uma única RA
• enquanto conectado via Ethernet 'sudo tcpdump -i en0 icmp6' mostra RAs, mas não RS (exceto, é claro, o computador conectado)

Conclusão:

• Os anúncios de roteador e as Sollicitations do roteador não cruzam a ponte de LAN do Time Capsule.
• Todo o resto faz (incluindo ICMPv6 e IPv6)

Fatos históricos:

• o Time Capsule é um substituto fácil para um WRT54Gv5 habilitado para DDWRT (cujo hardware tornou-se gradualmente não confiável) e com o qual toda a configuração estava funcionando perfeitamente.
• dada a falta de confiabilidade do WRT, foi realizada uma experimentação para descartá-lo sem nenhum custo usando apenas o Netgear como um modem + roteador + AP. O mesmo problema apareceu, finalmente revertendo temporariamente para a configuração de trabalho do WRT, enquanto aguardava o TC.
• logo após abandonar o WRT em favor do TC, experimentei o 6to4 configurado no TC, mas ele está abaixo do ideal por vários motivos: os RTTs são ruins, o cabo WAN IPv4 é realmente dinâmico e o Mac OS X 10.6.5 agora prioriza IPv4 sobre 6to4.
• a configuração funcionou por um bom tempo
• parando o radvd no NSLU2 e usando o 6to4 através do TC atualmente funciona tanto com fio quanto sem fio (eu vejo RAs em ambos os links), mas como dito antes é muito abaixo do ideal.

Nota: encontrei apenas algumas referências de pessoas com problemas semelhantes com o radvd e pontes construídas manualmente (openwrt, even solaris)

Então, ideias?

    

Answer 1

Eu suspeito que o TC esteja intencionalmente filtrando RAs para impedir que hosts Windows mal configurados (o Connection Sharing ativado) atrapalhe o tráfego e forneça roteamentos abaixo do ideal ou completamente quebrados. Eu não tenho um TC / aeroporto extremamente útil, mas pode haver uma configuração em algum lugar para desativá-lo (pode ser chamado de RA Guard, antispoofing IPv6 ou algo parecido). Caso contrário, você provavelmente está sem sorte.

Uma alternativa seria usar um corretor de túneis com encapsulamento direto de 6 em 4; o TC suporta-o com o modo "Tunnel" IPv6. Você pode configurar um túnel www.tunnelbroker.net, configurá-lo estaticamente no TC e fazer com que um script atinja o URL apropriado para atualizar seu IP sempre que ele for alterado.