Sim, IPv6 é necessário, é o futuro e já devíamos estar todos usando. Se você se julga com algum conhecimento de redes e não conhece IPv6, já passou da hora de estudar. Mas não é sobre isto este artigo.
Sou um entusiasta do IPv6 faz alguns anos. Sempre sonhei poder conectar da internet em qualquer equipamento da minha rede interna sem todos os "artifícios técnicos" para contornar o NAT (encaminhamento de porta, túnel sobre SSH, etc). Bastaria o firewall não bloquear. Por este motivo, em 2010 eu já utilizava túneis para obter conectividade IPv6. Era lento, deixava minha navegação pior, mas funcionava perfeitamente.
Em 2015, finalmente chegou o tão sonhado IPv6 pelo provedor! Logo reconfigurei meus equipamentos para utilizar a nova pilha IPv6. E então apareceram os problemas. Este é o tema deste artigo.
Administro duas redes ligadas a Net. Testei a configuração em uma... funcionou! Perfeito. Copiei para a segunda... funcionou novamente! Porém, depois de alguns minutos, notei que as máquinas da primeira rede não mais conversavam IPv6 com o mundo. No roteador da rede, ele estava sem rota padrão para o IPv6. Desliguei alguma coisa? E a segunda rede continuava a funcionar. Recarreguei a interface WAN e tudo voltou a funcionar. Mais alguns minutos... novamente sem IPv6 na primeira rede! (e a segunda rede continuava a funcionar...). Como as duas redes usavam o mesmo equipamento, mesma configuração, seria problema do equipamento do provedor? Vamos a investigação.
A NET distribui IPv6 por DHCPv6. O comportamento é similar ao IPv4: você ganha um endereço WAN para falar com a internet. A diferença é que, como não temos mais NAT, não iremos esconder os computadores da rede interna nem usar endereços falsos (192.168.x.x). Nesta mesma requisição do DHCPv6, a NET também informa uma rede com endereços IPv6 reais para suas máquinas internas (LAN), chamado de prefixo delegado. O roteador usa este endereço para que sejam definidos os endereços IPv6 (reais) da LAN. Tudo está funcionando perfeitamente quando, então, a tabela de roteamento IPv6 que era:
root@router:~# ip -6 r
default from 2804:14d:????:1000:204c:36a0:daed:f2d7 via fe80::217:10ff:fe87:5c9c dev eth0.2 proto static metric 512
default from 2804:14d:????:8417::/64 via fe80::217:10ff:fe87:5c9c dev eth0.2 proto static metric 512
2804:14d:????:1000::/64 dev eth0.2 proto static metric 256
2804:14d:????:1010::/64 dev eth0.2 proto static metric 256
2804:14d:????:8417::/64 dev br-lan proto static metric 1024
Vira:
root@router:~# ip -6 r
2804:14d:????:1000::/64 dev eth0.2 proto static metric 256
2804:14d:????:1010::/64 dev eth0.2 proto static metric 256
2804:14d:????:8417::/64 dev br-lan proto static metric 1024
Se você está enfrentando isto e quer apenas "resolver", para usuários do OpenWRT, basta subir novamente a interface wan6 a cada 20 minutos. A cron é excelente para isto:
root@router:~# crontab -l
*/20 * * * * /sbin/ifup wan6
Isto não era suficiente. Eu queria mais: mas porquê? E eu tinha um trunfo: acesso a duas redes com comportamentos diferentes. O primeiro passo é sempre dar uma "cheirada" na rede. O roteador das duas redes são OpenWRT. Desta forma, posso instalar o tcpdump(-mini) e capturar os pacotes durante a negociação do endereço. Podemos fazer isto de forma assíncrona:
root@router:~# tcpdump -i eth0.2 -U -s 0 -w /tmp/dump-ipv6.pcap ip6
E analisar o arquivo dump-ipv6.pcap, ou mesmo já jogar a captura para dentro do wireshark local.
luiz@minhamaquina:~$ ssh root@router tcpdump -i eth0.2 -U -s 0 -w - ip6 | wireshark -k -i -
Observando as duas capturas, já é possível notar que estamos em equipamentos diferentes da NET. Na que para de funcionar, o roteador que responde é o 2804:14d:baa6:1000::1 (vou chamar de baa6). Na segunda, que continua a funcionar, 2804:14d:baa5:1000::1 (vou chamar de baa5).
Na rede que para de funcionar depois de um tempo, a requisição de roteador (router solicitation - RS) que ocorre antes do DHCPv6 é respondida, enquanto na outra, não. Aparentemente o baa6 está configurado para enviar RA (route advertisement) e o baa5 não. Mas responder (ou não) com um RA não deveria ser um problema, desde que ele continue a respondê-lo e enviá-lo periodicamente. De resto, os dois tráfegos são equivalentes, exceto que a rede que funciona (conectada no baa6) tenta novamente após 10s uma nova solicitação de roteador (também sem resposta).
Olhando com carinho, o tempo de vida do RA (router lifetime) é de 1800s (30 min), muito próximo ao tempo até a queda da rota padrão. Interessante. Pode ser por aí o problema. O RA é enviado voluntariamente pelo roteador em um período aleatório mas dentro de um intervalo máximo e mínimo. Pelo que eu entendi da RFC 4861, o cliente não deve enviar um novo RS em situações normais, apenas aguardar o próximo RA que deveria chegar antes de estourar o tempo de vida da rota (router lifetime). Então, onde está meu RA não solicitado? Será que o roteador não está enviando? Ou será que ele está sendo bloqueado? Eu monitorei o tráfego e não achei qualquer outro RA chegando na minha interface WAN.
Bem, vamos simular uma situação onde o baa6 não responderia o RS. Isto pode ser feito bloqueando qualquer RA que chega no roteador pela WAN.
root@router:~# ip6tables -A INPUT -i eth0.2 -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m comment --comment "bloqueia RA da NET" -j DROP
Ou para usuário do OpenWRT:
Atualizando: a recarga das regras do firewall ocorria justamente quando o RA estava chegando. Por isto, o RA poderia ser aceito neste tempo. Melhor usar uma regra em um chain que o fw3 não limpa ao recarregar (somente ao reiniciar). Coloque isto em /etc/firewall.user:
if ! ip6tables -L INPUT | grep -q "bloqueia RA da NET"; then
echo "Primeira vez que esta rodando... adicionando filtro do RA e recarregando WAN"
ip6tables -t filter -I INPUT -i $(uci get network.wan.ifname) -p icmpv6 -m icmp6 --icmpv6-type 134 -m comment --comment "bloqueia RA da NET" -j DROP
ifup wan6
fi
Você saberá que funcionou quando o comando abaixo mostrar no primeiro número (número de pacotes casados) um valor diferente de zero (normalmente 4):
root@router:~# ip6tables -L -nv | grep 'bloqueia RA da NET'
4 544 DROP icmpv6 eth0.2 * ::/0 ::/0 ipv6-icmptype 134 /* bloqueia RA da NET */
Depois de 30 minutos nossas rotas devem ainda estar vivas. Estamos no caminho certo. Sem RA, a rota padrão vem apenas do DHCPv6 e sem validade de 30 minutos. Falta apenas descobrir o porquê de não receber o RA. Se o equipamento for um Cisco, eu chutaria que ele usou "ipv6 nd ra suppress" quando deveria ter usado "ipv6 nd ra suppress all". Mas vamos a mais alguns testes novamente com o sniffer ligado.
Pelo DHCPv6, recebo o endereço WAN e uma rede para a LAN. Esta rede para LAN vai gerar todos os endereços de equipamentos da minha rede local, inclusive para a interface LAN do roteador. No meu caso, ela é <prefixo recebido>::1/64. Quando eu realizava um teste com o ping6 para endereços na internet, eles respondiam sem problemas. Porém, eu notei que o roteador estava usando o endereço da LAN e não da WAN. E se eu escolher o endereço que o ping deve usar? Ex:
root@router:~# ping -6 -I <endereço IPv6 WAN e não o nome da interface!> ipv6.br
Bingo! Na rede que sempre funcionou o IPv6 (ligada ao baa5), consigo usar tanto o endereço LAN como o WAN e ambos funcionam. Na rede que não funciona (ligada ao baa6), não tenho resposta. Agora a dúvida: eu não consigo enviar ou receber? Novamente vamos usar o trunfo de ter administração em duas redes. Ligando o sniffer na rede sem problemas, podemos ver a chegada e a saída de pacotes:
02:50:15.246987 IP6 [IP:LAN:baa6] > [IP:WAN:baa5] ICMP6, echo request, seq 0, length 64
02:50:15.247433 IP6 [IP:WAN:baa5] > [IP:LAN:baa6] ICMP6, echo reply, seq 0, length 64
02:50:40.377930 IP6 [IP:WAN:baa6] > [IP:WAN:baa5] ICMP6, echo request, seq 0, length 64
02:50:40.378262 IP6 [IP:WAN:baa5] > [IP:WAN:baa6] ICMP6, echo reply, seq 0, length 64
root@router:~# ping -6 -I <endereço IPv6 WAN e não o nome da interface!> ipv6.br
Bingo! Na rede que sempre funcionou o IPv6 (ligada ao baa5), consigo usar tanto o endereço LAN como o WAN e ambos funcionam. Na rede que não funciona (ligada ao baa6), não tenho resposta. Agora a dúvida: eu não consigo enviar ou receber? Novamente vamos usar o trunfo de ter administração em duas redes. Ligando o sniffer na rede sem problemas, podemos ver a chegada e a saída de pacotes:
02:50:15.246987 IP6 [IP:LAN:baa6] > [IP:WAN:baa5] ICMP6, echo request, seq 0, length 64
02:50:15.247433 IP6 [IP:WAN:baa5] > [IP:LAN:baa6] ICMP6, echo reply, seq 0, length 64
02:50:40.377930 IP6 [IP:WAN:baa6] > [IP:WAN:baa5] ICMP6, echo request, seq 0, length 64
02:50:40.378262 IP6 [IP:WAN:baa5] > [IP:WAN:baa6] ICMP6, echo reply, seq 0, length 64
Opa! O "echo request" chegou nos dois casos e foram respondidos prontamente. Agora olhando no lado da origem:
02:50:15.246987 IP6 [IP:LAN:baa6] > [IP:WAN:baa5] ICMP6, echo request, seq 0, length 64
02:50:15.247433 IP6 [IP:WAN:baa5] > [IP:LAN:baa6] ICMP6, echo reply, seq 0, length 64
02:50:40.377930 IP6 [IP:WAN:baa6] > [IP:WAN:baa5] ICMP6, echo request, seq 0, length 64
Faltou chegar o pacote da resposta. Tentando o ping vindo da outra rede, nada chegou. Tentei também ping vindos de fora das duas redes e o comportamento foi o mesmo. Na rede que sempre funcionou, recebi os pacotes sem problemas. Na outra, nenhum pacote chegou.
Para confirmar esta suspeita, liguei o cabo do NetVirtua diretamente em um computador. Assim, ele assumiria o endereço WAN para uso normal (sem usar o prefixo delegado). O resultado: ganhei o endereço IPv6 mas, fora isto, nada relacionado a IPv6 funcionou pois nunca recebi pacotes vindos da internet do IPv6. Para que serve uma conexão com a internet se só posso enviar pacotes e não receber?
Em suma: a NET está com um roteador que não permite enviar dados para o endereço IPv6 WAN. Por mera coincidência, ele também responde o RS com um RA, o que exigiria o envio de um novo RA antes de estourar a validade da rota (30 min). Como não recebo qualquer pacote, o novo RA nunca chega e perco a rota padrão. Se o RA estivesse desligado, isto dificilmente seria notado pois é raro que os roteadores recebam pacotes (exceto se usar OpenWRT).
Enviei tudo isto para a Net e esta foi a sua grande resposta:
Atualizando: entrei em contato novamente para a NET. A nova resposta:
Legal! Querem agora me cobrar por uma falha deles! Ao menos não disseram que não tenho esse tal de IPv6. Agora vamos a argumentação: EMTA 2.0 deve ser DOCSIS 2.0, que realmente não teria suporte ao IPv6. Porém, No local onde funcionava (ligado ao baa5), o modem era realmente diferente (Cisco DPC2203) do meu (Thomson DHG534B). Porém, ambos com suporte somente a DOCSIS 2.0. Também consegui testar em um terceiro ponto com o modem IGUAL ao meu. Surpresa?! Funcionou perfeitamente! Mas este ponto está ligado a um terceiro roteador na Net (baa1). Então, de três pontos diferentes da Net, 2 funcionam e 1 não. Os roteadores tem o mesmo sistema operacional (OpenWRT) e configuração IPv6 (default). Todos os modems são DOCSIS 2.0 e com o mesmo modelo de modem, de um lugar funciona e outro não. Dá para afirmar com uma certa segurança que o problema é a configuração do baa6. Como se argumenta com a NET desta forma? Vou ligar para eles e tentar falar com alguém que entende...
Alguém aí trabalha na Net ou conhece alguém da área técnica? Compartilha este link ;-) Não queria ter que começar mais uma batalha com a ANATEL.
Para os afetados, sugiro adicionar a regra do firewall e configurar qualquer serviço divulgado na rede (ex: torrent) confirma se ele está usando o endereço IPv6 da LAN e não da WAN.
Dúvidas? Use o fórum deste blog!
Até a próxima.
02:50:15.246987 IP6 [IP:LAN:baa6] > [IP:WAN:baa5] ICMP6, echo request, seq 0, length 64
02:50:15.247433 IP6 [IP:WAN:baa5] > [IP:LAN:baa6] ICMP6, echo reply, seq 0, length 64
02:50:40.377930 IP6 [IP:WAN:baa6] > [IP:WAN:baa5] ICMP6, echo request, seq 0, length 64
Faltou chegar o pacote da resposta. Tentando o ping vindo da outra rede, nada chegou. Tentei também ping vindos de fora das duas redes e o comportamento foi o mesmo. Na rede que sempre funcionou, recebi os pacotes sem problemas. Na outra, nenhum pacote chegou.
Para confirmar esta suspeita, liguei o cabo do NetVirtua diretamente em um computador. Assim, ele assumiria o endereço WAN para uso normal (sem usar o prefixo delegado). O resultado: ganhei o endereço IPv6 mas, fora isto, nada relacionado a IPv6 funcionou pois nunca recebi pacotes vindos da internet do IPv6. Para que serve uma conexão com a internet se só posso enviar pacotes e não receber?
Em suma: a NET está com um roteador que não permite enviar dados para o endereço IPv6 WAN. Por mera coincidência, ele também responde o RS com um RA, o que exigiria o envio de um novo RA antes de estourar a validade da rota (30 min). Como não recebo qualquer pacote, o novo RA nunca chega e perco a rota padrão. Se o RA estivesse desligado, isto dificilmente seria notado pois é raro que os roteadores recebam pacotes (exceto se usar OpenWRT).
Enviei tudo isto para a Net e esta foi a sua grande resposta:
Protocolo de Atendimento:08815.12620.98631Depois dessa como vou argumentar?! Meu endereço IPv6 e o roteamento com a internet deve ter brotado por abiogênese!
Prezado cliente,
Informo que nesse momento não há viabilidade técnica para instalação dos produtos IPV6 e infelizmente não há previsão de adequação da rede e liberação da mesma para comercialização dos produtos.
Agradecemos o seu contato.
Atenciosamente,
MARCKSON FERNANDO DE DEUS
Atualizando: entrei em contato novamente para a NET. A nova resposta:
Protocolo de Atendimento: 08816.14500.66951
Prezado cliente,
Recebemos o seu e-mail e conforme verificado em sistema informamos que o seu EMTA 2.0 não é compatível com protocolo IPV6. É necessário a troca do equipamento para obter o IPV6, ressaltamos que a visita será cobrada o valor de R$ 90,00, caso tenha interesse será necessário realizar uma nova solicitação através de nossos canais de atendimento, que agendaremos uma visita técnica em sua residência.
Agradecemos o seu contato.
Atenciosamente,
LARISSA RIBEIRO SANTOS
Legal! Querem agora me cobrar por uma falha deles! Ao menos não disseram que não tenho esse tal de IPv6. Agora vamos a argumentação: EMTA 2.0 deve ser DOCSIS 2.0, que realmente não teria suporte ao IPv6. Porém, No local onde funcionava (ligado ao baa5), o modem era realmente diferente (Cisco DPC2203) do meu (Thomson DHG534B). Porém, ambos com suporte somente a DOCSIS 2.0. Também consegui testar em um terceiro ponto com o modem IGUAL ao meu. Surpresa?! Funcionou perfeitamente! Mas este ponto está ligado a um terceiro roteador na Net (baa1). Então, de três pontos diferentes da Net, 2 funcionam e 1 não. Os roteadores tem o mesmo sistema operacional (OpenWRT) e configuração IPv6 (default). Todos os modems são DOCSIS 2.0 e com o mesmo modelo de modem, de um lugar funciona e outro não. Dá para afirmar com uma certa segurança que o problema é a configuração do baa6. Como se argumenta com a NET desta forma? Vou ligar para eles e tentar falar com alguém que entende...
Alguém aí trabalha na Net ou conhece alguém da área técnica? Compartilha este link ;-) Não queria ter que começar mais uma batalha com a ANATEL.
Para os afetados, sugiro adicionar a regra do firewall e configurar qualquer serviço divulgado na rede (ex: torrent) confirma se ele está usando o endereço IPv6 da LAN e não da WAN.
Dúvidas? Use o fórum deste blog!
Até a próxima.
Excelente artigo, muito obrigado por compartilhar, gostaria de saber qual roteador esta utilizando com Openwrt, utilizo alguns aqui ,mas a maioria tem pouca memoria o que impede implementação de muita coisa.
ResponderExcluirRodrigo, tenho um modesto tplink 2543 com 64 MB de RAM e 8 MB de armazenamento.
ExcluirO esquema é usar uma unidade USB para aumentar o armazenamento e também usar como swap. Funciona bem.
Eu ando descobrindo e tentando resolver problemas com IPv6 na NET com diferentes modems e é fato sim que alguns modelos até bem mais antigos suportam e outros não. Apesar de ser da Comcast a listagem deste site é bem precisa: http://mydeviceinfo.xfinity.com
ResponderExcluirEu testei o Motorola SB5101 e o Scientific Atlanta DPC2100R2 e funcionaram normalmente com IPv6 e um Motorola SVG1202, mesmo sendo DOCSIS 2 não funcionou.
A questão é que o DOCSIS 2.0 em si só não suporta IPv6, foi um aprimoramento posterior que adicionou o suporte. Este é o problema principal de outros modelos.
É Micael... agora explica como um modem do mesmo modelo, com a mesma firmware, na mesma cidade, um funciona 100% e outro (o meu) apresenta os problemas... :-)
ExcluirUsando com meu ddwrt, percebi que estava tendo o mesmo sintoma que você descreveu. Minha solução no momento é basicamente criar a rota na mão, e usar o cron pra garantir que tudo está funcional.
ResponderExcluirO complicado é que realmente não existe como explicar o problema pra NET haha :-)
Ricardo, também utilizo o DD-WRT pode me passar o que fez para resolver?
ExcluirSim Ricardo, criar a rota na "mão" funciona. Só precisa ser "dinâmica" se a operadora mudar o seu endereço IPv6.
ExcluirApós investigar o problema um pouco mais, eu consegui confirmar que o gateway da NET realmente não está mandando as mensagens de router advertisement, porém também percebi que ele responde quando meu roteador pergunta mandando um router solicitation (quando conecta ou após um if down/up na interface).
ExcluirSabendo que ele sempre responde aos meus requests de RS, eu instalei um aplicativo chamado rdisc6 (via o repositório do kong/dd-wrt) que pode ser usado para enviar a mensagem, e assim receber um RA do gateway da NET.
Exemplo:
root@domosys:~# ip -6 route | grep 'default via'
default via fe80::217:10ff:fe8b:a78b dev vlan2 proto ra metric 1024 expires 1248sec hoplimit 64
root@domosys:~# rdisc6 -1 -q vlan2
2804:14d:badb:1000::/64
2804:14d:badb:1010::/64
root@domosys:~# ip -6 route | grep 'default via'
default via fe80::217:10ff:fe8b:a78b dev vlan2 proto ra metric 1024 expires 1797sec hoplimit 64
Dai foi só colocar '/opt/usr/bin/rdisc6 -1 -q vlan2' no cron (e.g. a cada 5 minutos), e pronto, resolvido :-)
Paulo Calixto, criei um post descrevendo meu setup em https://rsalveti.wordpress.com/2016/07/27/netgear-r7000-dd-wrt-ipv6-and-the-lack-of-a-stable-gateway/.
ExcluirBoa noite Luiz! Sabe me dizer se e possível colocar outro roteador numa porta lan do openwrt e configura-lo para ter acesso ao dlna samba e transmission, um access point ou repetidor como se estivesse conectado nele. Procurei no seu blog e na net não achei nada. E se for possível, que tipo de configuração faço.
ResponderExcluirFabiano, está meio off-topic neste post ;)
ExcluirVocê sempre pode criar tópicos novos em http://luizluca.blogspot.com.br/p/forum.html
Eu agradeceria.
Não entendi exatamente o que você quer mas criar um repetidor wireless, inclusive permitindo o uso das portas físicas do lado remoto, já foi tema deste blog.:
http://luizluca.blogspot.com.br/2013/05/openwrt-utilizando-conexoes-wireless_18.html
Luiz boa noite, eu não consegui achar algum topico sobre uso do firewall, eu estou precisando bloquear sites para o meu filho menor não acessar, vc tem alguma dica? Andei vendo o tinyproxy mas não consegui instala-lo.
ResponderExcluirVocê precisa de um proxy e não o firewall. Não fiz um tópico sobre isto mas o caminho é esse aí mesmo.
ExcluirO tópico principal na wiki é este:
https://wiki.openwrt.org/doc/howto/proxy.overview
Como qualquer filtragem desse tipo, ela é falha por princípio. Você terá quer configurar o proxy nos navegadores (e bloquear as portas padrão) ou usar proxy transparente (que só funciona para http). Ainda com o proxy configurado, você não vai conseguir bloquear parte de um conteúdo dentro de um site https.
Boa tarde Luca ... Sou leigo no que se refere à redes ... Por isso vou falar pra vc o problema que eu tenho ... Tenho NET Combo (TV, telefone fixo e internet) de 10MBPS e um roteador disponibilizado por eles (THOMSON DWG850-4B), não tenho problemas com o wi-fi mas tenho muitos problemas pra jogar o FIFA17 no PS3 mesmo via cabo ... Difícil de achar jogadores, cai a conexão com o adversário toda hora e muito lag ... Principalmente se alguém estiver conectado com o wi-fi em outro ponto da casa (NETFLIX, ou uso de celular que seja) ... Tenho muitas dúvidas se eu comprar outro modem resolveria meus problemas ... Gostaria de saber o que vc me indicaria ... Outro tipo de modem (Um com DUAL BAND AC)? Ou eu tenho que trocar de prestadora de serviço mesmo ? Rsrs
ExcluirAgradeço a atenção desde já ... Se puder me dar um retorno te agradeço e muito
Santosfc, é um tanto offtopic...
ExcluirSe quiser discutir isso, por favor, abra um tópico no fórum do blog (links no topo e fim da página)
Aqui em Vix eu pego o IPv6 utilizando um e900 com Tomato, mas nunca consegui pingar um IPv6. Gateway padrão nunca respondeu.
ResponderExcluirAnalisando os logs aqui:
ExcluirOct 10 17:35:18 E900 daemon.info dnsmasq-dhcp[1283]: RTR-ADVERT(br0) 2804:14d:ae80:b6e::
Oct 10 17:43:12 E900 daemon.info dnsmasq-dhcp[1283]: RTR-ADVERT(br0) 2804:14d:ae80:b6e::
Oct 10 17:51:48 E900 daemon.info dnsmasq-dhcp[1283]: RTR-ADVERT(br0) 2804:14d:ae80:b6e::
Douglas, o roteador padrão com endereço f* geralmente não vai responder mesmo.
ExcluirMas pela msg, as máquinas da sua rede interna deveriam pegar um endereço 2804:14d:ae80:b6e:[algo parecido com o Mac]. Se o roteador não pinga o mundo, pode ser o problema que relatei aqui
Se as máquinas internas não estiverem pegando endereço IP, pode ser problemas do seu roteador. Talvez ele não esteja pronto para ipv6.
As máquinas da rede interna pegam IPv6 sim, acredito que o problema é parecido com o seu.
ExcluirEstou deixando o IPv6 desligado aqui pois o acesso a internet fica muito lento (já que ninguém responde no IPv6), acredito que depois o router tente em IPv4.
O modem aqui é um Motorola SBV5122 que só funciona como Bridge. Fiz o teste e realmente nem o Router (e900 com Tomato) consegue pingar qualquer endereço ip.
Excluirhttp://pt-br.tinypic.com/r/24g7rk1/9
http://tinypic.com/r/2ajrn02/9
http://tinypic.com/r/140xkwn/9
Douglas,
ExcluirRealmente tenho pouco conhecimento sobre o Tomato. Talvez ele nem suporte o IPv6 fornecido pela telecom.
Luiz, troquei de equipamento aqui E900 com Tomato Shibby para Mi Router 3 com Padavan e agora as estações pegam o IP e navegam normalmente, porém depois de 30 minutos para. Tentei rodar o comando "ip6tables -A INPUT -i eth0.2 -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m comment --comment "bloqueia RA da NET" -j DROP" mas dá o seguinte erro:
Excluir"ip6tables v1.4.16.3: Couldn't find match `comment'
Try `ip6tables -h' or 'ip6tables --help' for more information."
Não conheço o Tomato mas provavelmente você não tenha o módulo comment. Tire o '-m comment --comment "bloqueia RA da NET"'. É só comentário...
ExcluirEste comentário foi removido pelo autor.
ResponderExcluirEste comentário foi removido pelo autor.
ResponderExcluirOlá luiz, adoro seus posts, ja aprendi bastante com eles!
ResponderExcluirvou tentar explicar oq acontece aqui: descolei um segundo roteador, instalei openwrt15 e pretendo usá-lo como repetidor na minha rede
configuro Client tudo ok consigo acesso pelo cabo de rede,
ocorre que quando vou criar o ssdid para repetir, não funciona, como se perdesse a conexão com o gateway, fica sem acesso até pelo cabo :(
mas com WDS funciona corretamente, oq pode estar acontecendo? alguma conf faltando?
abraço
paulo, está fora do assunto do post. Seria melhor um tópico no fórum (links no topo e no fim da página).
ExcluirNão sei o que poderia ser. Tome cuidado que a parte do rádio nas duas redes será a mesma (canal, potência, etc.) Se mudar uma, a outra não funciona. Na verdade, o canal é até travado pela conexão cliente...
Abra o tópico no fórum que é mais fácil colar confs. As configurações no caso seriam /etc/config/wireless e /etc/config/network. Só retira qualquer senha antes de postar, ok?
Ola Luiz estou com um problema uso telefonica e meu roteador tem ipv6 mas não consigo delegar para a lan ja tente diversas configurações e estou apanhando o pior é que tinha conseguido configurar facilmente usando a luci restaurei e não estou conseguindo configurar alguma dica?
ResponderExcluirGustavo, você poderia abrir um tópico no fórum? Link está lá em baixo.
ExcluirInclua sua configuração (arquivo network) e a saída de 'ifconfig' e 'route -A inet6"
Olá, estamos passando pelo mesmo problema! ! Após nas reclamações realizadas junto a NET, que não foram poucas,pedi que um técnico fosse enviado, para que o problema fosse solucionado, só que para isso uma taxa de 90 reais seria cobrado!!!! Foi qdo resolvemos levar o problema a ANATEL. Hj, segunda 29/05, após ter realizado uma reclamação junto a ANATEL, a NET resolveu dar importância a nossas reclamações e enviaram um técnico. Na visita o problema foi constatado, então o modem foi trocado e o IPV6 desconectado. Até então não houve perda de pacote, mas percebo através do PING que há atraso nos pacotes. Agora até qdo ficará neste chove não molha, não sabemos, só sei que não irá demorar muito tempo o problema retornará novamente!!!
ResponderExcluirCélia, desligar o ipv6 não é uma boa solução. É eficaz agora mas vai puxar seu pé novamente. É equivalente a desativar a tv digital e voltar para a analogia porque está com recepção ruim. Uma hora ela vai ser desligada e você ficará sem nada.
ResponderExcluirA tendência do IPv4 é ficar cada vez pior com a falta de endereços e o uso de NAT na operadora.
Já resolvi problemas via a Anatel mas é triste chegar a esse ponto.
Olá Luiz, sempre leio seus artigos e são muito bons, parabéns.
ResponderExcluirPois bem, estou com um problema com o IPv6 aqui também com a NET, mas é um pouco diferente do seu aqui do tópico e acho que é alguma coisa aqui no meu roteador. Oque acontece é que não consigo com que meus HOSTs adquiram um IPv6 em Ralay mode, já ativei o ralay na interface LAN para Router Advertisement-Service, DHCPv6-Service, NDP-Proxy e mesmo assim nada funciona. Pensei ser meu firewall bloqueando ou descartando os pacotes mas vi e já há exceções geradas para os pacotes ICMPv6 tanto para entrada como para encaminhamento dos tipos 133, 134 e etc. Tambem recebo dois IPv6, um /128 (Modem) e um /64 este atribuído a minha interface LAN. Ai que ta o problema, se eu coloco para meu roteador entregar os IPv6s em Stateful ou Stateless ou com a soma deles tudo funciona. Estou tendo problemas com alguns dispositivos Android e as vezes tenho que fazer VPN do DNS no dispositivo para que funcionar, quando ligo ele pelo wifi do modem e desabilito o modo bridge todos os hosts funcionam o IPv6 normalmente funciona normalmente, então acho que se o CMTS da operadora entregar o IP ao invés do meu roteador esse problema sanado.
Uma observação é que tenho rodando aqui mwan3 na versão 1.4-3, mas este não da suporte para IPv6, nesse caso é indiferente.
Gostaria de uma ajuda sua.
Olá Eric,
ExcluirSim, é meio off-topic. :) Você pode abrir um tópico no fórum.
http://luizluca.blogspot.com.br/p/forum.html
Se está usando OpenWRT/LEDE, não é do SEU roteador (exceto se for uma falha de HW), mas algo para todos os roteadores. O software é praticamente o mesmo, em especial essas partes genéricas como tratamento de IPv6.
Vamos ao básico: a net fornece 1 único ipv6 para seu roteador falar com o outro lado. Nesta requisição, ele também passa uma faixa de ipv6 para você delegar a seus clientes. Em versões novas do OpenWRT/LEDE, isso deveria ser automático. A interface LAN usaria essa rede dinâmica (normalmente algo como 2804::...::1). Quando seus equipamentos pedirem IPv6, o DHCP (dnsmasq) irá fornecer um IP nesta faixa.
Ralay mode irá repassar a requisição de ip dos clientes para a NET. Para eles, será como se o teu roteador e os demais clientes fossem máquinas ligadas por um switch diretamente na porta do modem (sem roteador). A NET não gosta de fornecer IPs para dois MACs, tanto é que precisamos reiniciar o modem ao trocar o roteador. Não deve funcionar.
Eu uso modo server e funciona.
Fechou Luiz, muito obrigado por esclarecer essas duvidas, tinha essa suspeita também.
ExcluirEste comentário foi removido pelo autor.
ResponderExcluirBoa Luiz, realmente existe algo estranho nesse setup da NET. Eu rodo meu firmware custom no meu AP, (sou developer embarcado) e depois de escutar com o tcpdump a interface da net descobri que o gateway enviado pela solicitacao RA vem errado,
ResponderExcluirSegue:
# rdisc6 -1 eth1
Soliciting ff02::2 (ff02::2) on eth1...
Hop limit : 64 ( 0x40)
Stateful address conf. : Yes
Stateful other conf. : Yes
Mobile home agent : No
Router preference : medium
Neighbor discovery proxy : No
Router lifetime : 1800 (0x00000708) seconds
Reachable time : unspecified (0x00000000)
Retransmit time : unspecified (0x00000000)
Source link-layer address: 00:17:10:98:7D:34
MTU : 1500 bytes (valid)
Prefix : 2804:14d:7481::/64
On-link : Yes
Autonomous address conf.: No
Valid time : infinite (0xffffffff)
Pref. time : infinite (0xffffffff)
from fe80::217:10ff:fe98:7d34
recebo fe80::217:10ff:fe98:7d34, mas o mesmo nao responde ping, nem broadcast, mas interessantemente no fe80::217:10ff:fe98:7d33 temos resposta normal, e roteamento normal.
# ping6 fe80::217:10ff:fe98:7d34%eth1
PING fe80::217:10ff:fe98:7d34%eth1 (fe80::217:10ff:fe98:7d34): 56 data bytes
^C
--- fe80::217:10ff:fe98:7d34%eth1 ping statistics ---
8 packets transmitted, 0 packets received, 100% packet loss
Agora no 7d33:
# ping6 fe80::217:10ff:fe98:7d33%eth1
PING fe80::217:10ff:fe98:7d33%eth1 (fe80::217:10ff:fe98:7d33): 56 data bytes
64 bytes from fe80::217:10ff:fe98:7d33: seq=0 ttl=64 time=20.003 ms
64 bytes from fe80::217:10ff:fe98:7d33: seq=1 ttl=64 time=10.001 ms
64 bytes from fe80::217:10ff:fe98:7d33: seq=2 ttl=64 time=0.000 ms
64 bytes from fe80::217:10ff:fe98:7d33: seq=3 ttl=64 time=10.001 ms
^C
--- fe80::217:10ff:fe98:7d33%eth1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.000/10.001/20.003 ms
Net? o que voce tem dizer sobre isso?
Abraco!
Olá Cassiano,
ExcluirOs endereços fe80::/64 são endereços que a própria máquina gera a partir do seu endereço MAC (com um pequeno cálculo) de forma independente, mesmo se estiver sozinha na rede. O escopo desses endereços é o enlace local e, normalmente, servem apenas para tarefas "administrativas", como endereço de origem para perguntas como: tem um roteador aí? Quem tem esse IP? Tem um servidor DHCPv6? É normal que não respondam ping ou qualquer outro serviço. Ele também pode ser usado como destino de rotas pois, no fim, você só quer o endereço MAC para onde mandar o pacote(quadro).
Se você só tem endereços fe80::/64, você não tem um endereço IPv6 de verdade. Só indica que a máquina está com o IPv6 habilitado. Não foi a NET que os gerou, mas sim a máquina onde eles estão.
Para a mesma interface onde está fe80::217:10ff:fe98:7d34, o endereço usável,0usando configuração sem estado e com base no prefixo que você recebeu, seria 2804:14d:7481:217:10ff:fe98:7d34.