[2026-09-15] eagle: family/how-to/home-automation.md family/how-to/rasputin-router.md

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/<port>/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
 

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.