diff --git a/family/how-to/home-automation.md b/family/how-to/home-automation.md index 92e661d4..d9887d72 100644 --- a/family/how-to/home-automation.md +++ b/family/how-to/home-automation.md @@ -38,7 +38,7 @@ updated: 2026-09-15 └── [USB3-1] Logitech 046d:0825 (камера) — ТОЛЬКО xHCI! ``` -> 🔴 **Камера обязана сидеть на xHCI (`USB3-1`), Zigbee — на OHCI (`USB1-2`).** См. §3.1 — почему. +> 🔴 **Камера обязана сидеть на xHCI (`USB3-1`), Zigbee — на OHCI (`USB1-2`).** См. §3.1 — но читать её **вместе с §3.3**: перестановка портов **не является достаточным фиксом**, проверено чистым стартом. --- @@ -182,10 +182,10 @@ rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected be 1. Пинг + ARP хоста (`/sbin/ping`, `/usr/sbin/arp -an`) — жив ли вообще. `ARP no entry` = L2-ответа нет. 2. Если не отвечает — питание. Если отвечает — `ssh root@192.168.2.176`. 3. `uptime` + `top -b -n 1 | head -5` — смотреть **`% io` и `% sirq`**, не только usr/sys. -4. `dmesg | grep -iE "usb|reset"` — вся причина обычно здесь. +4. `dmesg | grep -iE "usb|reset"` — **обязательно с `| tail`, см. §3.3 — без хвоста эта команда врёт**. 5. `/sys/bus/usb/devices//power/runtime_suspended_time` — растёт = устройство засыпает и не просыпается. -> ⚠️ На t610 **BusyBox**, не GNU coreutils: нет `ping`/`arp`/`netstat`/`ifconfig` в PATH Mac-стороны (на Mac звать `/sbin/ping`, `/usr/sbin/arp`); **на t610** нет `dmesg -T`, `top -b -n1` есть, `fuser -v` НЕТ (`fuser -m` только), `ps -eo` работает, `cat /proc/interrupts` может быть пуст (не поломка). `lsusb -t` — есть. +> ⚠️ На t610 **BusyBox**, не GNU coreutils: нет `ping`/`arp`/`netstat`/`ifconfig` в PATH Mac-стороны (на Mac звать `/sbin/ping`, `/usr/sbin/arp`); **на t610** нет `dmesg -T`, `top -b -n1` есть, `fuser -v` НЕТ (`fuser -m` только), `ps -eo` работает, `cat /proc/interrupts` может быть пуст (не поломка). `lsusb -t` — есть. **`docker` на хосте НЕТ** — контейнеры поднимает `hassio-supervisor`, всё через `ha` CLI / Supervisor API. ### 3.2. Перезапуск Zigbee2MQTT после перестановки USB diff --git a/family/how-to/rasputin-router.md b/family/how-to/rasputin-router.md index e0b89fe5..b6b35773 100644 --- a/family/how-to/rasputin-router.md +++ b/family/how-to/rasputin-router.md @@ -1,7 +1,7 @@ --- title: Rasputin OpenWrt router created: '2026-07-22' -updated: '2026-07-22' +updated: '2026-09-15' tags: - openwrt - router @@ -411,7 +411,7 @@ counter packets 19 bytes 27636 This confirms that Mac `cloudflared` QUIC traffic was hitting the direct-WAN exception. -### Upstream LAN Bypass +### Upstream LAN Bypass (`Allow-upstream-LAN`) ```text firewall.@rule[10].name='Allow-upstream-LAN' @@ -421,7 +421,47 @@ firewall.@rule[10].target='ACCEPT' firewall.@rule[10].dest_ip='192.168.2.0/24' '192.168.0.1' ``` -### Downstream LAN Access +--- + +## 🔴 ICMP к недоступному хосту в 192.168.2.0/24 отдаёт `Destination Port Unreachable` от САМОГО роутера + +**Наблюдение 2026-09-15 (подтверждено дважды в одной сессии).** С Mac (`192.168.6.104`) при пинге выключенного хоста верхнего сегмента: + +```text +$ /sbin/ping -c 3 192.168.2.176 +92 bytes from rasputin.lan (192.168.6.1): Destination Port Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst + 4 5 00 5400 a0a3 0 0000 3f 01 509d 192.168.6.104 192.168.2.176 +--- 192.168.2.176 ping statistics --- +3 packets transmitted, 0 packets received, 100.0% packet loss +``` + +**Как это читать (и как НЕ читать):** + +| Признак | Значение | +|---|---| +| `Request timeout for icmp_seq N` | нормальный признак «хост выключен» | +| `Destination Port Unreachable` от `rasputin.lan (192.168.6.1)` | **это роутер отбивает попытку, а не ответ хоста** | +| Полный дамп IP-заголовка (`Vr HL TOS … Src/Dst`) | ответ сгенерирован ICMP-модулем роутера, а не удалённой машиной | +| `100.0% packet loss` | хост не ответил | + +```text +/usr/sbin/arp -an | grep 176 +? (192.168.6.176) at (incomplete) on en8 ifscope [ethernet] +``` + +`(incomplete)` = ARP-запрос ушёл, ответа нет → **L2-ответа нет вообще**, хост мёртв или вне сети. Это правильный признак для вывода «машина недоступна». + +> ⚠️ **ПИТФОЛЛ ДИАГНОСТИКИ:** строка `Destination Port Unreachable` от роутера легко читается как «порт закрыт, машина жива». Это НЕВЕРНО. Она одинаково выглядит и для хоста, который выключен, и для хоста, который висит в kernel lockup без сетевого стека. Опираться нужно на **`arp (incomplete)` + 100% loss**, а не на текст ICMP-ошибки. + +> ⚠️ Проверять достижимость узлов `192.168.2.0/24` из `192.168.6.0/24` надёжнее всего **тем же каналом, которым потом будете работать**: SSH по ключу. `ssh -o ConnectTimeout=10 -o BatchMode=yes root@192.168.2.176 'uptime'` — если отвечает, хост жив, и всё дальнейшее снимается через него. Пинг/веб-порты могут врать (см. `Reject to LAN` ниже), SSH — нет. + +**Границы прав внутри сегментов (напоминание):** +- Router transit `192.168.6.0/24 ↔ 192.168.2.0/24` — разрешён правилами выше. +- Между сегментами есть санитарный `Reject to LAN` в `forward_lan` → произвольные порты не пройдут, ICMP-эхо тоже. +- Порты HA (`8123`) и SSH (`22`) через транзит роутера **не проверять как индикатор живости** — индикатор это сам факт ответа SSH-сессии. + +## Downstream LAN Access ```text firewall.@rule[11].name='Allow-downstream-LAN' @@ -654,4 +694,6 @@ uci commit dhcp - The firewall allow alone would not be sufficient, because policy routing rule `101` sends LAN ingress to `table vpn`. The direct `ip rule`s at priorities `98` and `99` must remain before priority `101`. - Rule order in `forward_lan` matters: Cloudflare direct allow must stay above `KillSwitch`. - `eth0` was down at the 2026-07-22 capture; `usb0` was active and part of the `wan` firewall zone. +- 🔴 **Ping from Mac to an unreachable `192.168.2.x` host returns `Destination Port Unreachable` from `rasputin.lan (192.168.6.1)`, NOT a plain timeout.** This is the router rejecting the attempt — it does **not** mean the host is up with a closed port. Use `arp (incomplete)` + `100% packet loss` as the liveness signal. Confirmed 2026-09-15 (see the dedicated section above). +- Liveness of `192.168.2.0/24` hosts is best verified with the channel you intend to work through: key-based SSH (`ssh -o BatchMode=yes root@192.168.2.176 'uptime'`). Ping and web ports can mislead; an answered SSH session cannot. - Secrets are redacted here intentionally. Consult the live router files only when the actual VLESS or Cloudflare credentials are needed.