Initial commit: inventário e documentação da rede doméstica

README, contexto da topologia (CLAUDE.md), inventário de dispositivos
(CSV) e manuais da mesh Mercusys Halo H80X. Tarball GPL e SDK do
firmware ficam fora do repo (redundantes com o site do fabricante e
acima do limite de tamanho do GitHub).

.gitignore

@@ -0,0 +1,2 @@
+*.tar.gz
+/sdk/

CLAUDE.md

@@ -0,0 +1,149 @@
+# Contexto: Rede Doméstica do Ronaldo
+
+Este arquivo dá contexto ao Claude Code sobre a infraestrutura de rede doméstica
+do Ronaldo (Fedora 44, KVM/libvirt, mesh Wi-Fi). Mantenha atualizado conforme a
+rede mudar.
+
+## Visão geral da topologia
+
+```
+Internet (fibra)
+    │
+    ▼
+ZTE ZXHN F6645P (ONT da Claro)
+    │  [modo BRIDGE — sem Wi-Fi, sem DHCP, apenas conversor óptico→Ethernet]
+    ▼
+Mesh Mercusys Halo H80X — Unidade SALA (router/DHCP/Wi-Fi principal)
+    │
+    ├─ Porta 1: ZTE (uplink/WAN)
+    ├─ Porta 2: OrangePi PC (cabeado)
+    ├─ Porta 3: Backhaul cabeado ──────────► Mesh Halo H80X — Unidade ESCRITÓRIO
+    │                                              ├─ Porta 1: Backhaul (recebido)
+    │                                              ├─ Porta 2: Laptop Fedora (cabeado)
+    │                                              └─ Porta 3: spare/livre
+    │
+    └─ Wi-Fi: celulares (Ronaldo, Juliana, Roberto), TV da sala,
+              2x Chromecast, Xbox (em teste — pode migrar para cabo
+              via switch Gigabit adicional se a performance não for boa)
+```
+
+### Notas da topologia
+
+- **ZTE F6645P**: ONT da Claro. Será colocado em **modo bridge** (função oficial
+  da Claro, sem necessidade de desbloqueio/hack). Em bridge, perde Wi-Fi e DHCP
+  próprios; só repassa o sinal da fibra como Ethernet puro por uma única porta.
+- **Mesh Mercusys Halo H80X** (kit com 2 unidades, Wi-Fi 6 AX3000, 3 portas
+  Gigabit cada): assume 100% do roteamento, DHCP e Wi-Fi da casa após o bridge
+  do ZTE. Tem **Address Reservation** nativo (DHCP Binding via app, em
+  More → Advanced → Address Reservation) — diferente do ZTE da Claro, que não
+  expõe essa opção na interface web.
+- **Backhaul cabeado** entre as duas unidades mesh (cabo já existente entre
+  sala e escritório) — preferível ao backhaul wireless padrão, pois libera o
+  espectro de rádio das duas unidades para os clientes em vez de gastar banda
+  com a comunicação entre nós.
+- **Xbox**: testando primeiro via Wi-Fi (Wi-Fi 6, deve ser suficiente). Se a
+  performance/latência não for boa, Ronaldo cogita comprar um **switch
+  Gigabit não-gerenciado** para a sala, já que as 3 portas da unidade da sala
+  estarão todas ocupadas (ZTE + OrangePi + backhaul). O switch permitiria
+  conectar Xbox, TV e eventualmente um Wii, tudo cabeado.
+- **TV da sala**: permanece no Wi-Fi.
+
+## Inventário de dispositivos (IPs e MACs)
+
+### Estado atual (antes da mesh — IPs fixos via `nmcli` manual)
+
+O ZTE F6645P da Claro **não expõe DHCP Binding na interface web** (limitação
+do firmware customizado pela operadora). Por isso, os dispositivos críticos
+têm IP fixo configurado manualmente no próprio SO (`nmcli ... ipv4.method
+manual`), fora da faixa DHCP dinâmica do roteador (`192.168.0.2`–`.50`).
+
+| Dispositivo            | MAC                 | IP fixo         | Método                          |
+|-------------------------|----------------------|------------------|----------------------------------|
+| fedora (Ethernet, `br0`) | `30:24:A9:FB:C7:6F`  | `192.168.0.60`   | `nmcli` manual (interface `br0`) |
+| fedora (Wi-Fi)           | `22:90:26:F9:0D:6F`  | `192.168.0.64`   | `nmcli` manual (`CLARO_F76183`)  |
+| orangepipc (`end0`)      | `02:81:49:3B:6E:5D`  | `192.168.0.61`   | `nmcli` manual (`Wired connection 1`) |
+| win11 (VM, KVM bridge)   | `52:54:00:D9:C3:41`  | `192.168.0.62`   | IP estático configurado no Windows |
+| sandbox (VM, KVM bridge) | `52:54:00:F5:4F:0E`  | `192.168.0.63`   | `nmcli` manual (`Wired connection 1`) |
+
+Gateway: `192.168.0.1` (ZTE). DNS: `1.1.1.1` / `1.0.0.1` (Cloudflare).
+Faixa DHCP dinâmica do ZTE: `192.168.0.2`–`192.168.0.50` (lease time 12h /
+43200s) — usada por celulares, Chromecasts, Xbox, TV, etc.
+
+### Plano para quando a mesh entrar
+
+- Migrar as reservas de IP para o **Address Reservation nativo da mesh**
+  (DHCP Binding de verdade, via MAC).
+- Possivelmente reverter `fedora` e `orangepi` de IP manual (`nmcli`) para
+  DHCP automático, já que a reserva da mesh garante o mesmo IP de qualquer
+  forma — mais simples de manter.
+- `win11` e `sandbox` (VMs no host Fedora, via bridge `br0` do libvirt)
+  também podem ser migradas para reserva via mesh.
+
+## Outras infraestruturas relevantes
+
+### VMs no host Fedora (KVM/libvirt)
+
+- Bridge `br0` no host Fedora, ligada à interface física `enp1s0`
+  (substituiu a rede NAT `default`/`virbr0` do libvirt).
+- `win11`: VM Windows 11, interface `type='bridge'` em `br0`, modelo
+  `e1000e`.
+- `sandbox`: VM Linux (Fedora Server), interface `type='bridge'` em `br0`,
+  modelo `virtio`. Tem Docker e Tailscale instalados.
+- Funções Fish criadas para gerenciar as VMs sem digitar `virsh` diretamente:
+  `win11start`, `win11stop`, `win11kill`, `sandboxstart`, `sandboxstop`,
+  `sandboxkill` (em `~/.config/fish/functions/`). `stop` = shutdown gracioso;
+  `kill` = `virsh destroy` (força bruta, só usar se a VM estiver travada).
+
+### Resolução de nomes (`/etc/hosts` no host Fedora)
+
+mDNS (Avahi) entre Fedora e OrangePi **não funciona de forma confiável**
+nessa rede (diagnosticado: a query mDNS chega ao OrangePi via tcpdump, mas o
+Avahi dele não responde — causa raiz não 100% confirmada, suspeita de
+dependência anterior do Tailscale para essa resolução). Solução adotada:
+entradas estáticas em `/etc/hosts`:
+
+```
+192.168.0.60   fedora
+192.168.0.61   orangepi
+192.168.0.62   win11
+192.168.0.63   sandbox
+137.131.145.213   oracle
+62.84.180.13   contabo
+```
+
+`win11` resolve nome via **NetBIOS/Samba** (`nmblookup`) como alternativa —
+funciona nativamente pois é Windows. Para isso ser possível, foi necessário
+liberar ICMP no Firewall do Windows Defender dentro da VM (perfil de rede
+"Público" bloqueia ping por padrão).
+
+### Servidores remotos (fora da LAN)
+
+| Nome      | IP               | Observação                                              |
+|-----------|------------------|-----------------------------------------------------------|
+| oracle    | `137.131.145.213` | Responde ping normalmente.                                |
+| contabo   | `62.84.180.13`    | Ping bloqueado por padrão pelo **Contabo Firewall** (firewall de borda, separado do `ufw` interno da VPS). Foi liberado via painel de controle da Contabo (regra de Inbound ICMP). |
+
+### Firewall do host Fedora (`firewalld`)
+
+- Zona ativa: `FedoraWorkstation`, aplicada às interfaces `wlp0s20f3`, `br0`,
+  `enp1s0`.
+- Serviço `mdns` foi adicionado a essa zona (`firewall-cmd --add-service=mdns
+  --permanent`) durante o diagnóstico de mDNS — mantido, mesmo que o mDNS
+  para o OrangePi não tenha funcionado por outro motivo.
+- Outros serviços liberados na zona: `dhcpv6-client`, `samba`,
+  `samba-client`, `ssh`.
+
+## Coisas a evitar / lições aprendidas
+
+- **Não usar `virsh edit` sem `EDITOR=nano`** — o padrão é `vim`, que o
+  Ronaldo não gosta de usar.
+- **STP da bridge `br0` demora a estabilizar** (`listening → learning →
+  forwarding`, ~15s por estágio) após qualquer mudança de configuração via
+  `nmcli`. Um estado momentâneo de `NO-CARRIER`/`state DOWN` logo após mudar
+  a bridge não é necessariamente um erro — pode só ser o STP em progresso.
+  Verificar com `bridge link show` antes de assumir que algo quebrou.
+- **Tailscale**: removido do Fedora (host). Ainda presente no OrangePi e na
+  VM `sandbox`. Avaliar se vale remover dos dois também por consistência.
+- Pretende-se criar um **repositório GitHub** para versionar este inventário
+  (provavelmente como `README.md` + um CSV com a tabela de dispositivos),
+  no lugar de (ou complementando) este arquivo.

README.md

@@ -0,0 +1,36 @@
+# Rede Doméstica
+
+Inventário e documentação da infraestrutura de rede doméstica (Fedora 44,
+KVM/libvirt, mesh Wi-Fi Mercusys Halo H80X).
+
+## Conteúdo
+
+- [`CLAUDE.md`](CLAUDE.md) — contexto completo da topologia, lições
+  aprendidas e decisões de configuração.
+- [`inventory/dispositivos.csv`](inventory/dispositivos.csv) — tabela de
+  dispositivos com IP fixo, MAC e método de reserva.
+- [`docs/manuals/`](docs/manuals/) — manuais e datasheets oficiais da mesh
+  Mercusys Halo H80X.
+
+## Topologia (resumo)
+
+```
+Internet (fibra)
+    │
+    ▼
+ZTE ZXHN F6645P (ONT da Claro, modo bridge)
+    │
+    ▼
+Mesh Mercusys Halo H80X — Unidade SALA (router/DHCP/Wi-Fi)
+    │
+    └─ Backhaul cabeado ──► Mesh Halo H80X — Unidade ESCRITÓRIO
+```
+
+Detalhes completos em [`CLAUDE.md`](CLAUDE.md).
+
+## Nota sobre o GPL do firmware
+
+O código-fonte GPL liberado pelo fabricante para a Halo H80X não está neste
+repositório (arquivo grande, redundante com o que o fabricante já publica).
+Disponível diretamente no site da Mercusys, na seção de suporte/GPL do
+produto Halo H80X.

inventory/dispositivos.csv

@@ -0,0 +1,6 @@
+dispositivo,mac,ip_fixo,metodo
+"fedora (Ethernet, br0)",30:24:A9:FB:C7:6F,192.168.0.60,"nmcli manual (interface br0)"
+"fedora (Wi-Fi)",22:90:26:F9:0D:6F,192.168.0.64,"nmcli manual (CLARO_F76183)"
+"orangepipc (end0)",02:81:49:3B:6E:5D,192.168.0.61,"nmcli manual (Wired connection 1)"
+"win11 (VM, KVM bridge)",52:54:00:D9:C3:41,192.168.0.62,"IP estático configurado no Windows"
+"sandbox (VM, KVM bridge)",52:54:00:F5:4F:0E,192.168.0.63,"nmcli manual (Wired connection 1)"