Data: 2026-10-13 (atualizado em 2026-10-14)
Uma ressalva antes de tudo: os testes mostram que o GitHub e alguns endpoints da AWS não são alcançados pela conexão principal e funcionam por outra operadora. Isso não prova que o provedor os bloqueie de propósito.
A causa pode ser roteamento, peering, filtragem ou algum equipamento no meio do caminho. Por isso o texto trata o caso como falha de conectividade.
1. A descoberta
O link principal (wlan0, DEMOSTENES-5G) não chega ao GitHub: curl --interface wlan0 https://github.com
dá timeout (000, 8 s), enquanto o Google responde 200 pelo mesmo link. O celular (hotspot demos-moto) chega ao GitHub normalmente. Objetivo: só os destinos com problema saem pelo hotspot, todo o resto fica no wlan0.
O padrão se repetiu na AWS (seção 4): o DNS resolve, mas o TCP nunca conecta. Isso aponta para o caminho de rede.
2. Duas conexões, uma única máquina
Hardware e estado inicial:
- wlan0: Wi‑Fi principal (192.168.18.9).
- wlan1: Wi‑Fi do dongle combo Bluetooth/Wi‑Fi (RTL8723BU, driver rtl8xxxu). Estava "não gerenciável" por
causa de /etc/NetworkManager/conf.d/90-unmanaged-wlan1.conf, criado pelo scripts/bt-dongle-fix.sh para evitar o travamento do Bluetooth no dongle compartilhado.
- Risco conhecido: ligar o wlan1 pode trazer de volta o travamento do Bluetooth (mouse/caixa de som).
O que foi feito:
- Removido 90-unmanaged-wlan1.conf e reiniciado o NetworkManager (sudo rc-service NetworkManager restart).
- Conectado o wlan1 ao hotspot: nmcli --ask device wifi connect demos-moto ifname wlan1
(não havia perfil salvo; a senha foi pedida). IP 10.25.217.91, gateway 10.25.217.13.
- Perfil sem rota padrão, para que só o tráfego roteado explicitamente use o hotspot:
nmcli connection modify demos-moto ipv4.never-default yes ipv6.never-default yes e reconexão.
- scripts/github-via-wlan1.sh cria as rotas do GitHub pelo wlan1 (usa scripts/github-ranges.txt,
gerado de https://api.github.com/meta: web, api e git, só IPv4). Rodar com sudo; del remove as rotas.
Por que havia dois default gateways
Cada interface com DHCP instala a própria rota padrão; vence a menor métrica. No IPv4 o wlan0 tinha 602 e o wlan1 20601; no IPv6 o wlan1 tinha 601 contra 602 do wlan0, e por isso o IPv6 preferia o hotspot (gastando franquia). Resolvido com never-default no perfil demos-moto.
O controle é por IP de destino
Rotear uma faixa do GitHub não roteia só o tráfego do GitHub. Qualquer outro serviço cujo endereço caia dentro da faixa também sai pelo hotspot. O controle é por destino IP, não por domínio nem por aplicação.
3. A armadilha do IPv6: NAT64
As primeiras rotas, só em IPv4, não resolveram. O hotspot usa NAT64/DNS64: o DNS devolve github.com como 64:ff9b::4e4:1f96, um IPv6 sintético, porque o GitHub não tem IPv6 próprio. O prefixo 64:ff9b::/96 é o definido na RFC 6052 para embutir um endereço IPv4 nos 32 bits finais de um IPv6.
A rota IPv4 estava correta, mas o cliente tentava o endereço IPv6 sintético, e esse pacote seguia outra decisão de roteamento, que não passava pelo wlan1. Uma rota para 140.82.112.0/20 não diz nada sobre 64:ff9b::8c52:7000.
A correção: para cada faixa IPv4, o script cria também a rota NAT64 equivalente (prefixo 64:ff9b::/96 mais a faixa; ex.: 140.82.112.0/20 vira 64:ff9b::8c52:7000/116) via o gateway IPv6 do wlan1.
Como o wlan1 não tem rota padrão, os gateways não vêm da tabela de rotas. O script pega:
- IPv4: opção routers do DHCP (nmcli -g DHCP4.OPTION device show wlan1), removendo espaços.
- IPv6: vizinho fe80::… marcado router em ip -6 neigh show dev wlan1.
4. A AWS também entrou na brincadeira
O wlan0 também não alcança o endpoint bedrock-runtime.us-east-1.amazonaws.com: o DNS resolve, mas o TCP nunca conecta (timeout em 8 s, em 3 IPs diferentes). Também falham bedrock.us-east-1 e bedrock-runtime.us-west-2. bedrock-runtime.sa-east-1 funciona normalmente pelo wlan0 (404 em 36 ms, sem credenciais). O problema, então, é regional e não atinge a AWS inteira.
Teste pelo hotspot (rota temporária sudo ip route replace 34.203.84.72/32 via 10.25.217.13 dev wlan1):
404 em ~0,5 s, 3 de 3.
O 404 é evidência de conectividade HTTP: o TCP e o TLS fecham e o serviço responde. Sem credencial, é o resultado esperado. Autenticação e acesso aos modelos não foram testados; o teste foi só de rede.
As rotas são /32 porque os IPs da Bedrock caem em 16 faixas grandes de EC2 (/11, /12, /13;
ex.: 100.48.0.0/12, 44.192.0.0/11). Rotear isso pelo hotspot desviaria muito tráfego que não é da Bedrock e gastaria franquia. scripts/bedrock-via-wlan1.sh cria rotas /32 para os IPs do endpoint: resolve o DNS 10 vezes (ele rotaciona) e soma a lista semente scripts/bedrock-ips.txt (21 IPs). Reexecutar atualiza a lista.
Alternativa sem hotspot: usar sa-east-1.
5. O que funcionou, o que não funcionou e o que falta
Verificação (2026-10-13)
O domínio do stream ao vivo do Alares Play é carregado por JavaScript e não foi verificado.
Reverificado em 2026-10-14 depois de reconectar o wlan1: ip route get mostra GitHub e Bedrock saindo por
via 10.25.217.13 dev wlan1; GitHub 200, Bedrock 404.
Falhas encontradas em campo (2026-10-14)
- Hotspot conectado, sem internet. O wlan1 pegou IP e o gateway respondia ao ping, mas nem o Google nem
o 8.8.8.8 passavam. Causa: dados móveis desligados no celular. Ligados, tudo voltou. O ping ao gateway não prova que há internet por trás dele.
- Dongle travado. Depois de cair, o wlan1 ficou em NO-CARRIER e o scan voltou vazio, sem enxergar nenhuma rede, nem as dos vizinhos. O rfkill não mostrava bloqueio. Resolveu recarregando o driver Wi‑Fi:
sudo modprobe -r rtl8xxxu && sudo modprobe rtl8xxxu. O Bluetooth usa outro módulo (btusb) e não foi afetado.
- Rotas somem quando o wlan1 cai. Sem as rotas, o GitHub e a Bedrock voltam a sair pelo wlan0 e dão timeout. Testar logo após reconectar, sem reaplicar os scripts, dá falso negativo.
Limitações e pendências
- As rotas valem até reiniciar ou reconectar o wlan1. Reaplicar com
sudo ~/Desenvolvimento/local_machine/scripts/github-via-wlan1.sh e .../bedrock-via-wlan1.sh. Ideia
pendente: dispatcher do NetworkManager para reaplicar sozinho.
- Retestar o wlan0 de tempos em tempos; se o GitHub voltar, remover as rotas (... github-via-wlan1.sh del).
- A lista de IPs do GitHub muda; regenerar github-ranges.txt de api.github.com/meta se algo deixar de sair pelo wlan1.
- A cobertura da Bedrock não é contínua. A lista semente de 21 IPs e as dez consultas DNS reduzem a chance de falha, mas um IP novo fora da lista cai no wlan0 e dá timeout até reexecutar o script.
- A Bedrock transmite bastante dado e consome franquia do hotspot.
- Sem rota padrão no wlan1, ele não serve de reserva para o resto do tráfego se o wlan0 cair.
Fragilidades conhecidas dos scripts
Revisados e confirmados no código; ainda não corrigidos:
- del exige gateway. O github-via-wlan1.sh sai com erro se o wlan1 não tem gateway IPv4, mesmo no
modo del. Com a interface desconectada não dá para limpar as rotas por ele. (Quando a interface cai, o kernel já descarta as rotas, então o risco prático é pequeno.)
- Gateway IPv6 pelo cache de vizinhos. ip -6 neigh show dev wlan1 só lista o roteador se ele já foi
visto recentemente. Se a entrada expirou, gw6 fica vazio e as rotas NAT64 simplesmente não são criadas; o script avisa só no resumo final (v6 via n/a).
- Bedrock sem NAT64. O bedrock-via-wlan1.sh só resolve IPv4 (getent ahostsv4) e não cria rotas
64:ff9b::. Funciona hoje porque o cliente usa o DNS do wlan0, que devolve IPv4. Se o resolvedor passar a devolver o endereço sintético do DNS64 do hotspot, valeria a pena repetir o tratamento feito para o GitHub.
Apêndice: scripts
Sem segredos: Os IPs privados são os do hotspot
(10.25.217.x).
scripts/github-via-wlan1.sh
scripts/github-via-wlan1.sh
#!/bin/sh
# Roteia o GitHub pelo wlan1 (hotspot demos-moto); o resto segue pelo wlan0.
# Cobre IPv4 e o caminho NAT64 (64:ff9b::/96) que o hotspot usa p/ IPv4-only.
# Uso: sudo ./github-via-wlan1.sh [del] (rotas valem até reiniciar/reconectar)
set -e
dir=$(dirname "$0")
# wlan1 não tem rota padrão (never-default): gateways vêm do DHCP e do vizinho "router"
gw4=$(nmcli -g DHCP4.OPTION device show wlan1 | tr '|' '\n' | awk -F' = ' '$1 ~ /^ *routers$/ {gsub(/ /,"",$2); print $2; exit}')
gw6=$(ip -6 neigh show dev wlan1 | awk '/^fe80/ && /router/ {print $1; exit}')
[ -n "$gw4" ] || { echo "wlan1 sem gateway (conectado ao demos-moto?)"; exit 1; }
for r in $(cat "$dir/github-ranges.txt"); do
r6=$(python3 -I -c "
import ipaddress,sys
n=ipaddress.ip_network(sys.argv[1])
print(ipaddress.ip_network((ipaddress.IPv6Address('64:ff9b::')+int(n.network_address), 96+n.prefixlen)))" "$r")
if [ "$1" = del ]; then
ip route del "$r" dev wlan1 2>/dev/null || true
ip -6 route del "$r6" dev wlan1 2>/dev/null || true
else
ip route replace "$r" via "$gw4" dev wlan1
[ -n "$gw6" ] && ip -6 route replace "$r6" via "$gw6" dev wlan1
fi
done
echo "ok ($1 v4 via $gw4, v6 via ${gw6:-n/a})"scripts/bedrock-via-wlan1.sh
#!/bin/sh
# Roteia a AWS Bedrock (us-east-1) pelo wlan1 (hotspot demos-moto) com rotas /32.
# O wlan0 não alcança esses IPs; o DNS rotaciona, então resolve várias vezes e soma
# a lista semente (bedrock-ips.txt). Reexecute para atualizar.
# Uso: sudo ./bedrock-via-wlan1.sh [del]
set -e
dir=$(dirname "$0")
gw4=$(nmcli -g DHCP4.OPTION device show wlan1 | tr '|' '\n' | awk -F' = ' '$1 ~ /^ *routers$/ {gsub(/ /,"",$2); print $2; exit}')
[ -n "$gw4" ] || { echo "wlan1 sem gateway (conectado ao demos-moto?)"; exit 1; }
ips=$({
cat "$dir/bedrock-ips.txt"
for i in $(seq 1 10); do
for h in bedrock-runtime.us-east-1.amazonaws.com bedrock.us-east-1.amazonaws.com bedrock-runtime-fips.us-east-1.amazonaws.com; do
getent ahostsv4 "$h" | awk '{print $1}'
done
sleep 1
done
} | sort -u)
n=0
for ip in $ips; do
if [ "$1" = del ]; then ip route del "$ip/32" dev wlan1 2>/dev/null || true
else ip route replace "$ip/32" via "$gw4" dev wlan1; fi
n=$((n+1))
done
echo "ok ($1 $n IPs via $gw4)"scripts/github-ranges.txt (faixas do GitHub, de api.github.com/meta) e scripts/bedrock-ips.txt (IPs
semente da Bedrock) são listas públicas de IPs; ficam ao lado dos scripts.