Skip to content

Instantly share code, notes, and snippets.

@ruyrocha

ruyrocha/LEIAME.md

Forked from thiagokokada/LEIAME.md
Created March 8, 2024 00:11
Show Gist options
  • Save ruyrocha/71e11b73978f74039a5929c555c18e2f to your computer and use it in GitHub Desktop.
Save ruyrocha/71e11b73978f74039a5929c555c18e2f to your computer and use it in GitHub Desktop.
Download ZIP
[Vivo Fibra] Usando RTF3507VW-N1 em modo bridge
Raw
LEIAME.md

[Vivo Fibra] Usando RTF3507VW-N1 em modo bridge

Por que usar o RTF3507VW-N1 em modo bridge?

O roteador Askey RTF3507VW-N1 fornecido pela Vivo tem vários problemas:

  • Existe um cache interno de DNS (usando o dnsmasq?) bugado: ao fazer a mesma requisição DNS duas vezes seguidas, a primeira resposta vem correta, porém na seguinte temos: 
    $ dig www.google.com @192.168.15.1
;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.16.16 <<>> www.google.com @192.168.15.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25023
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;www.google.com.   IN A

;; ANSWER SECTION:
.   0 CLASS4096 OPT 10 8 VBJ5C/ngW8o=

;; ADDITIONAL SECTION:
www.google.com.  77 IN A 142.250.219.36

;; Query time: 0 msec
;; SERVER: 192.168.15.1#53(192.168.15.1)
;; WHEN: sáb jul 03 20:23:04 -03 2021
;; MSG SIZE  rcvd: 71
    Como é possível perceber pela mensagem de warning, a resposta veio mal formada. Isso resulta em sites que não abrem de vez em quando, e é preciso esperar até o cache DNS expirar para conseguir uma resposta correta. É possível contornar esse problema setando um servidor DNS diferente do 192.162.15.1 via as configurações de DHCP, porém...
  • Via IPv6 o roteador publica (via RA eu acho) um servidor DNS apontando... pra ele mesmo. Ou seja, usar um servidor DNS diferente do 192.162.15.1 via DHCP (lembrando que DHCP só vale para IPv4) só funciona algumas vezes, enquanto outras vezes ele vai usar o servidor DNS interno (bugado). A única maneira que encontrei para contornar esse problema foi desligando o IPv6. Se você quiser seguir esse caminho, vá em http://192.168.15.1/padrao, Advanced Setup -> LAN e desative tudo relacionado ao IPv6.
  • O roteador aparentemente tem um firmware baseado no OpenWrt, porém é extremamente modificado. Por exemplo, é possível fazer SSH nele (usando ou [email protected] ou [email protected], no segundo com bem mais informações), porém ele usa um shell customizado e pouquíssimos comandos estão disponíveis (use ? para listar todos). Não encontrei uma maneira de desabilitar o servidor DNS dele, por exemplo.
  • Recursos como "Port Forwarding", "UPnP" e "Virtual Server" não funcionam como deveria. Isso é fácil de perceber com o "Plex Media Server": se você for em Settings -> Remote Access algumas vezes ele retorna que tá tudo bem com a conexão ("Fully accessible outside your network"), porém outras ele simplesmente não conseguia acesso direto.
  • O problema de cima não era resolvido mesmo habilitando a opção Full Cone NAT (indo em http://192.168.15.1/padrao e mexendo as configurações da WAN).

Então, se você quiser usar coisas como "Port Forwarding" e IPv6 sem ter os problemas de DNS, a única maneira é colocando o roteador em modo bridge e usando um outro roteador (usando OpenWrt, por exemplo) para conectar usando o protocolo PPPoE.

Colocando o RTF3507VW-N1 em modo bridge

Existem algumas maneiras diferentes para colocar esse roteador em modo bridge documentadas na Internet, mas elas nunca funcionaram bem para mim.

Vou descrever aqui a maneira que funcionou bem para mim, incluindo como restaurar os canais de TV e telefone (não testado:

  1. Reinicie as configurações do roteador. Não é necessário, mas isso evita muita dor de cabeça depois. Existem várias maneiras, mas a mais simples é usar um palito de dente para apertar e segurar o botão Reset (atrás do aparelho) durante uns 15 segundos (até as 4 luzes do roteador acenderem).
  2. Entre no endereço http://192.168.15.1, no menu do lado esquerdo e selecione Configurações -> Rede Wi-fi 2.4GHz/5GHz e desative o Wi-Fi. Isso é importante porque como vamos colocar o roteador em modo bridge o Wi-Fi dele não vai servir pra mais nada. Se pedir usuário e senha, o usuário é admin e a senha está escrita embaixo do roteador.
  3. Agora entre em Configurações -> Modo da WAN e mude para Bridge. Ele vai exibir um alerta que a TV e telefone não vão mais funcionar, mas é possível restaurar essa funcionalidade depois (pelo menos TV, meu plano não inclui telefone).
  4. Para restaurar a TV/telefone vamos precisar entrar numa área "secreta". Entre no endereço http://192.168.15.1/padrao. Existe um porém: ao mudar para modo bridge o roteador desativa o servidor DHCP. Se você está seguindo esse guia muito provavelmente você ainda tem um IP válido e tudo deve funcionar. Se não, é preciso configurar manualmente um endereço de IP usando as configurações do seu sistema operacional. Se for este o caso, use IP: 192.168.15.2, Gateway: 192.168.15.1 e Netmask: 255.255.255.0.
  5. Ao entrar no endereço http://192.168.15.1/padrao, o roteador vai pedir um novo usuário e senha. A senha é a mesma, porém o usuário agora é o support.
  6. No menu do lado esquerdo, entre em Advanced Setup -> LAN e reative o servidor DHCP. Agora mesmo se você reiniciar o aparelho de TV, ele deve conseguir um IP válido e a TV deve funcionar.
    • Uma observação importante: a interatividade da TV não vai funcionar. Existem algumas pessoas relatando que se você conectar o decodificador via cabo Ethernet e configurar corretamente você consegue restaurar essa funcionalidade, mas eu não ligo pois não uso (e também não tenho como conectar os decodificadores usando Ethernet, só via cabo coaxial).

Isso deve ser o suficiente para configurar o RTF3507VW-N1 em modo bridge.

Configurando o OpenWrt para conectar no RTF3507VW-N1 via PPPoE

Agora vem a parte mais chata do processo que é configurar o OpenWrt corretamente para funcionar com o RTF3507VW-N1. Algumas coisas que você precisa fazer antes de começar:

  1. Remova todos os cabos de rede com exceção do roteador que vai se conectar com o RTF3507VW-N1. Isso porque com vários dispositivos conectados o PPPoE pode não funcionar.
  2. Se você for querer fazer um teste usando um computador antes de conectar o roteador de fato, é possível sim. Porém, mantenha em mente que sempre que você terminar o teste é necessário desligar e ligar o RTF3507VW-N1. Isso porque uma vez que ele faz o discovery do PPPoE com um endereço MAC, ele só vai funcionar com aquele endereço MAC específico. Outra opção é clonar o endereço MAC do dispositivo que você realizou os testes, mas eu acho mais simples simplesmente desligar e ligar o RTF3507VW-N1.

Para de fato configurar o OpenWrt para conectar via PPPoE no RTF3507VW-N1, deixo um trecho do arquivo /etc/config/network usado num Xiaomi Mi Router 3G, usando o OpenWrt 21.02-rc3:

config interface 'wan'
        option device 'wan'
        option proto 'pppoe'
        option username 'cliente@cliente'
        option password 'cliente'
        option ipv6 'auto'
        option mtu '1492'
        option peerdns '0'
        list dns '8.8.4.4'
        list dns '8.8.8.8'

config interface 'wan6'
        option device 'wan'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'
        option peerdns '0'
        list dns '2001:4860:4860::8844'
        list dns '2001:4860:4860::8888'

As partes mais importantes:

  • O usuário é cliente@cliente e a senha cliente, como padrão para praticamente todas as instalações da Vivo.
  • MTU configurado para 1492. O MTU deve ser configurado na interface que vai fazer a conexão PPPoE (nesse caso, a interface wan), não no dispositivo (que seria br-lan nesse caso). Isso é bastante importante, ou a conexão não é concluída com sucesso. Se você olhar nos logs do OpenWrt com debug ligado (veja a observação abaixo), vai ver a mensagem Timeout waiting PAD0 packets.

    • Por que 1492? Se você usar o comando dumpsysinfo no SSH do RTF3507VW-N1, vai notar o seguinte comando nos logs:

      pppd -c ppp0.1 -i veip0.1 -u cliente@cliente -p ******* -f 0 -M 1492 -6

      O -M seta o MTU da conexão PPPoE. Além disso, o protocolo PPPoE tem um overhead de 8 bytes, enquanto o MTU típico da Ethernet é 1500. 1500 - 8 = 1492.

  • Opcional mas recomendado: usar um servidor DNS diferente do padrão da Vivo. Estou usando o Google DNS tanto no IPv4 quanto IPv6, mas fica ao seu critério qual o melhor servidor utilizar.

Se você tiver usando o OpenWrt, uma maneira de debugar problemas é remover a # da opção debug no arquivo /etc/ppp/options, reiniciar a interface wan e olhar os logs (usando logread via SSH, por exemplo).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment