Skip to content

Instantly share code, notes, and snippets.

@thiagokokada
Last active November 13, 2024 01:46
Show Gist options
  • Save thiagokokada/9505cbb0ce311e8ffd076d8805feb997 to your computer and use it in GitHub Desktop.
Save thiagokokada/9505cbb0ce311e8ffd076d8805feb997 to your computer and use it in GitHub Desktop.
[Vivo Fibra] Usando RTF3507VW-N1 em modo bridge

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

@gbc921
Copy link

gbc921 commented Jan 11, 2022

Show de bola o script Thiago!

Me ajudou a reconfigurar o meu WDR4300 aqui. Obrigado!
Queria dizer também sobre o MTU, que dá pra setar ele em 1500, depois do pppd estabelecer a conexão (tem um bug se setar ali direto no arquivo). E por incrível que pareça a vivo suporta, é só fazer os ajustes. O que eu fiz foi:

  1. Defina as outras interfaces (e a VLAN 10 também) com MTU de 1508 (ou maior, para suportar os headers adicionais)
  2. Defina o MTU da interface pppoe-wan em 1500:
    • Para automatizar, crie a pasta /etc/ppp/ip-up.d
    • Crei o script abaixo com um nome desejável, como 99-mtu-wan:
#!/bin/sh
# When the ppp link comes up, this script is called with the following
# parameters
#       $1      the interface name used by pppd (e.g. pppoe-wan)
#       $2      the tty device name
#       $3      the tty device speed
#       $4      the local IP address for the interface
#       $5      the remote IP address
#       $6      the parameter specified by the 'ipparam' option to pppd

# continue only if interface is "pppoe-wan":
[ "$1" = "pppoe-wan" ] || exit 0

# change interface mtu
ip link set dev $1 mtu 1500

Eu faço o teste nesse link (recarregando sem cache), e consigo ter MTU de 1500. 😃

Fontes:

@gbc921
Copy link

gbc921 commented Jan 11, 2022

UPDATE: Não utilize a mudança do MTU!

Pelo que entendi o set na interface atrapalha alguma coisa no flow offloading do roteador.
Não conseguia velocidades acima de 100Mbps depois disso, e o processo ksoftirqd utilizava 100% da CPU do router.

Fontes:

@mikha4
Copy link

mikha4 commented Jul 12, 2022

Primeiramente obrigado pelo post! Gostaria de contribuir com o meu relato.
Segui o procedimento até a parte da configuração do OpenWRT. Configurei o protocolo PPPoE pela interface web mesmo sem nenhuma customização (MTU etc). Também não editei o arquivo de configuração via SSH.
A autenticação e navegação funcionaram de primeira, porém os testes de velocidade estavam muito ruins, batendo no máximo 60Mbps.
Para resolver a baixa performance, no OpenWRT naveguei em Network -> Firewall -> General Settings -> Routing/NAT Offloading e habilitei Software flow offloading.
Após esta ação os testes de velocidade ficaram perfeitos, atingindo a banda que contratei.
Pelo que entendi o problema da performance pobre era a baixa capacidade de CPU no meu roteador. Habilitar o offload aliviou a carga da CPU.

@gbc921
Copy link

gbc921 commented Jul 16, 2022

Show! Realmente essa função é nova nos Openwrt.
Eu recentemente troquei meu WDR por um ArcherC7 e ele suporta flow offloading por hardware, o que permite fazer NAT acima de 300Mbit.
Abraços

@mbastida43
Copy link

Thiago, possuo um router da VIVO com esse modelo, gostaria de saber se poderia me auxiliar a configurar um RV600VPN como roteador sem perder a TV?

@alfxp
Copy link

alfxp commented Feb 18, 2023

Esse roteador é muito ruim. Askey-RTF3507VW-N1
Eu já sabia que tinha algo de errado com ele... usava o meu da asus... porém hoje eu tenho certeza que os Recursos como "Port Forwarding", "UPnP" e "Virtual Server" REALMENTE não funcionam como deveria. '

@ggatto
Copy link

ggatto commented Jan 18, 2024

So passando aqui para agradecer, usei partes desse passo-a-passo para conectar meu Ubiquiti USG 3P diretamente no MitraStar GPT-2741GNAC-N2 da Vivo e funcionou perfeitamente, nao precisei mudar o MTU, somente configurar o PPPoE no USG e colocar o modem no WAN mode Bridge. Finalmente vou poder corrigir o duplo-nat na minha rede.

@debemdeboas
Copy link

Passando aqui pra agradecer. OP meu querido, tu é foda!

@brkr1
Copy link

brkr1 commented Apr 30, 2024

Pior que eles atualizaram o firmware e não deixam mais acessar o /padrão. Tentei resetar sem fibra via ssh, pois após isso algumas pessoas relataram conseguir acessar o /padrao novamente, mas no meu caso não funcionou.
Nessa nova firmware as redes wi-fi estão horríveis!!

@TuSKan
Copy link

TuSKan commented May 1, 2024

(https://forum.adrenaline.com.br/threads/banda-larga-vivo-xdsl-fibra-optica.594503/post-1077022158)
Eu consegui desbloquear o acesso pelo /padrão.

Já fica o aviso, a HGU vai ser resetada.

O primeiro passo é desconectar a fibra da HGU

Segundo passo, acessa o endereço de instalador com o login support e a senha da HGU.
192.168.15.1/instalador

Ao acessar, você vai ver as opções Vivo 1 e Vivo 2.
É simples, você altera a opção e clica em aplicar (Se o seu HGU for Vivo 1, você altera para Vivo 2 e vice versa).

Vai reiniciar sozinho após você aplicar. Assim que ligar, você abre novamente o endereço de instalador, volta para a região que estava antes e aplica. Isso é muito importante, pq se ficar na região errada você não vai conseguir conectar na internet.

Após a reinicialização, você já vai ter acesso ao /padrão. Então é só fazer todas as configurações necessárias e dar um reboot ao concluir.

Você pode desabilitar o TR069 nas configurações pelo /padrão. Isso vai evitar o bloqueio do endereço/padrão.
Em alguns modelos de HGU essa opção fica cinza e não tem como desativar. ( De acordo com relatos aqui no fórum, é possível alterar via SSH, mas não sei como fazer isso)

Feito tudo isso, você pode plugar a fibra novamente e após estabelecer o sinal você dá reboot e pode usar normalmente.

@brkr1
Copy link

brkr1 commented May 2, 2024

De acordo com relatos aqui no fórum, é possível alterar via SSH, mas não sei como fazer isso)

Vi la no Adrenaline:

Talvez pelo SSH dá pra desabilitar. Tenta o seguinte:

  1. Conecta via SSH [[email protected]] - senha padrão
  2. Digita "sh" Aperta entrer
  3. Digita "cd /bin" > enter
  4. Digita "cwmp_util set enablecwmp disable" > enter

@alnviana
Copy link

alnviana commented May 14, 2024

No meu estava cinza a opção, porém funcionou inspecionar o elemento, tirar a opção "disabled", selecionar "disabled" e aplicar.
Edit: Além de remover o "disabled" da opção, para poder aplicar, também tem que remover do botão "Apply".

image

@filipemp17
Copy link

Alguém consegue me ajudar a descobrir qual VLAN esta configurado em um HGU Askey RTF8225VW?
É a VLAN usada pela VIVO, não a VLAN 10 que é usada internamente
Já acessei ele por SSH mas não encontro.

@alnviana
Copy link

Hm, não sei se vai te ajudar, mas você já tentou olhar a sessão "Bridging Setup" da página /padrao?
image
image
image

Por aqui tem informações de VLAN, daria pra dar uma fuçada nessas telas e nos itens presentes e ver se alguma delas funciona pra você.

@filipemp17
Copy link

Por qual url? 192.168.15.1/padrao ?

@alnviana
Copy link

Exato. E com o usuário support, a senha é a mesma do admin que vem embaixo do roteador.

@onealll
Copy link

onealll commented Oct 25, 2024

Pessoal para quem está com o http://192.168.15.1/padrao dando acesso negado

image

Basta entrar no http://192.168.15.1/instalador

usuário: support
senha: mesmo do admin

Faça login

Pelo firefox aperte F12 para abrir as Ferramentas de Desenvolvedor (Developer Tools)

Va em Armazenamento - > cookies
Como você ja fez login com o instalador com o login de support vai ter um cookie chamado
name: "httpdSessionId", value: sessionId, httpOnly: true
esse valor do sessionId ja vai estar preenchido voce vai precisar dele abaixo

Adicione esses 2 cookies

name: "LoginRole", value: "system"
name: "SessionID", value: sessionId

apos os cookies preenchidos, na mesma pagina acesse: http://192.168.15.1/avanzada.asp

image

image

image

Pronto!!!

Créditos, achei um script completo em um git hub estudei ele e fiz na mão

https://github.com/Izurii/modem-vivo-avancado

@negri
Copy link

negri commented Oct 30, 2024

Graças a informação que compartilharam aqui consegui fazer o meu Askey RTF8225VW ficar em Bridge apenas da Internet, mantendo o telefone no modem deles (o que realmente precisava), contornando o bloqueio deles.

De fato tem de mexer um pouco nas configurações de Bridging, mas não é nada drástico.

Escrevi um resumo, na esperança de ajudar outros com o mesmo problema.

@danilomkt
Copy link

Pessoal para quem está com o http://192.168.15.1/padrao dando acesso negado

image

Basta entrar no http://192.168.15.1/instalador

usuário: support senha: mesmo do admin

Faça login

Pelo firefox aperte F12 para abrir as Ferramentas de Desenvolvedor (Developer Tools)

Va em Armazenamento - > cookies Como você ja fez login com o instalador com o login de support vai ter um cookie chamado name: "httpdSessionId", value: sessionId, httpOnly: true esse valor do sessionId ja vai estar preenchido voce vai precisar dele abaixo

Adicione esses 2 cookies

name: "LoginRole", value: "system" name: "SessionID", value: sessionId

apos os cookies preenchidos, na mesma pagina acesse: http://192.168.15.1/avanzada.asp

image

image

image

Pronto!!!

Créditos, achei um script completo em um git hub estudei ele e fiz na mão

https://github.com/Izurii/modem-vivo-avancado

E para o modem modelo RTF3505VW-N1 - REV4_B4? Não consegui com sucesso com essa dos cookies.

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