thiagokokada/LEIAME.md

## LEIAME.md

      
    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 admin@192.168.15.1 ou support@192.168.15.1, 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:

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).
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.
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).
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.
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.
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:

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.
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).