From 8e4f6ec743abf7373526c193ad3588e9a0a8bdae Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Wed, 23 Sep 2026 00:56:43 +0600 Subject: [PATCH] [2026-09-23] eagle: family/how-to/htpc-webos-luna.md family/how-to/kraken-network.md family/how-to/rasputin-router.md family/how-to/router-bishkek-asus.md --- family/how-to/htpc-webos-luna.md | 21 ++++++++++- family/how-to/kraken-network.md | 55 +++++++++++++++++++++++++--- family/how-to/rasputin-router.md | 38 ++++++++++++++++--- family/how-to/router-bishkek-asus.md | 54 +++++++++++++++++++++++++++ 4 files changed, 155 insertions(+), 13 deletions(-) diff --git a/family/how-to/htpc-webos-luna.md b/family/how-to/htpc-webos-luna.md index 236f3097..f9f8d52a 100644 --- a/family/how-to/htpc-webos-luna.md +++ b/family/how-to/htpc-webos-luna.md @@ -88,13 +88,32 @@ ssh root@192.168.1.70 'rm -f /tmp/f.txt; script -q -c \ | Параметр | Значение | |---|---| | IP | `192.168.1.70` (проводной eth0); старый `.75` больше не отвечает | -| SSH | `root@192.168.1.70`, ключ `~/.ssh/konka_webos`, `StrictHostKeyChecking no` | +| SSH | `root@192.168.1.70`, **ключ `~/.ssh/id_rsa`**, `StrictHostKeyChecking no` | | Порты | `22` SSH, `3000`/`3001` Luna | | webOS | **5.4.2**, ядро `4.4.84`, image `starfish-dvb-secured`, build 2602 | +| eth0 link | **100 Mbit/s full duplex** (проверено 2026-09-22, `cat /sys/class/net/eth0/speed` → `100`) | | Кастомные приложения | `org.webosbrew.hbchannel` 0.7.2, `org.webosbrew.inputhook`, `me.wouterdek.magic4pc`, **`com.lampac.tv`** | ⚠️ SSH печатает `post-quantum key exchange` warning — **это норма**, не ошибка. +🔴 **Ключ `~/.ssh/konka_webos` ОТКЛОНЁН (проверено 2026-09-22).** `Permission denied (publickey,password)` +на всех вариантах (`konka_webos`, `konka_webos.bak`, `988d8c6ece`, `webos_emul`). +**Рабочий ключ — `~/.ssh/id_rsa`.** В `~/.ssh/config` при этом есть хвост `Host 192.168.1.76` с +`IdentityFile ~/.ssh/konka_webos` — этот хост **не ТВ** (ТВ = `.70`), не путать. + +Рабочая команда: +```bash +ssh -o StrictHostKeyChecking=no -o IdentitiesOnly=yes -i ~/.ssh/id_rsa \ + -o HostkeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa \ + root@192.168.1.70 'cat /sys/class/net/eth0/speed; cat /sys/class/net/eth0/duplex' +# → 100 +# full +``` + +⚠️ **Только ключ `id_rsa`.** Опция `-o PasswordAuthentication=no` + `-o BatchMode=yes` рвёт соединение +раньше, чем успевает пройти pubkey-аутентификация на этой прошивке — не использовать как «проверку», +что ключа нет. + ## Связанные заметки - [[family/how-to/tv-luna-send]] — враппер `~/Automation/tv-luna-send.sh` diff --git a/family/how-to/kraken-network.md b/family/how-to/kraken-network.md index 9c2567bc..857869db 100644 --- a/family/how-to/kraken-network.md +++ b/family/how-to/kraken-network.md @@ -24,21 +24,64 @@ ssh kraken SSH alias `kraken` resolves via `~/.ssh/config`. -## Актуальная сеть (проверено 2026-09-02) +## Актуальная сеть (проверено 2026-09-22) -> Оба интерфейса живы. **eth0 — активный uplink** (default route metric 100), wlan0 — fallback (metric 600). +> ⚠️ **Кра́кен теперь достаётся по двум адресам на ОДНОМ MAC.** ARP на роутере: и `192.168.1.14`, и `192.168.1.15` → `lladdr 2c:cf:67:64:03:f3` (один и тот же eth0 MAC). То есть `.15` числится за eth0, отдельного WiFi-MAC в ARP нет. Два default route (eth0 metric 100, wlan0 metric 600) **сосуществуют** — часть трафика может утечь в Wi-Fi. `ping` с самого Кра́кена уходил через **wlan0**, не через кабель. | Интерфейс | IP | MAC | Uplink role | |---|---|---|---| -| **eth0** (Ethernet, Gigabit RPi5 rp1-gem/macb) | `192.168.1.14/24` (DHCP) | `2c:cf:67:64:03:f3` | **primary** — default via `192.168.1.1`, metric 100 | +| **eth0** (Ethernet, Gigabit RPi5 rp1-gem/macb) | `192.168.1.14/24` (DHCP) | `2c:cf:67:64:03:f3` | primary — default via `192.168.1.1`, metric 100 | | **wlan0** (WiFi) | `192.168.1.15/24` (DHCP) | `2c:cf:67:64:03:f4` | fallback — metric 600 | -- Ethernet link на boot: **1000 Mbit/s full duplex** (как и ожидалось для Gigabit-порта RPi5), carrier up. -- ⚠️ **2026-09-02 ~16:30: eth0 ПЕРЕСОГЛАСОВАЛСЯ ВНИЗ до 100 Mbit/s full** (dmesg: `Link is Down → Link is Up - 100Mbps/Full`) и стабильно висел на 100M (проверялось 2026-09-04 по SSH: speed=100). Счётчики eth0 чистые (rx_errors=1 суммарно, свежих CRC нет) — не электрический шум, а downshift линка (кабель/коннектор/порт роутера). **Симптом:** 4K UHD Blu-ray Remux (~99 Mbit/s) при Direct Play дёргался — 99M видео по 100M линку ≈ 100% занятие канала без запаса. -- ✅ **РЕШЕНО 2026-09-04: замена патч-корда вернула eth0 на 1000 Mbit/s full duplex** (проверено по SSH: speed=1000, duplex=full, carrier=up). Причина — неисправный/некачественный кабель, а не порт роутера или настройки. Carrier_changes = 5 на момент проверки. 4K Remux больше не должен дёргаться. +- ✅ **eth0 линк на 2026-09-22 = 1000 Mbit/s full duplex** (`ethtool eth0`: `Speed: 1000Mb/s`, `Duplex: Full`, `Link detected: yes`, master-slave status: slave). Роутерный порт (Port 3) тоже `1000FD`. Гигабит восстановлен после замены патч-корда 2026-09-04. - Router/gateway: `192.168.1.1` (`f0:79:59:77:9b:70`). eth0 MAC соответствует static lease в доке [[family/how-to/openmediavault-rpi5|openmediavault-rpi5]]. - ⚠️ Ранее эта заметка утверждала «wlan0 = .15 primary» — устарело (см. таблицу выше). +## Измерения латентности через роутер (2026-09-22) + +Снято с **Rasputin** (OpenWrt, `192.168.6.1`, WAN `192.168.1.50` — см. [[family/how-to/rasputin-router]]): + +``` +Rasputin → Кра́кен eth 192.168.1.14: 0.499 / 0.639 / 0.897 ms 10/10, 0% loss +Rasputin → Кра́кен 192.168.1.15: 0.444 / 0.641 / 1.037 ms 10/10, 0% loss +``` + +С Mac (`192.168.1.57`, Wi-Fi en0 802.11ac 5GHz 80MHz): + +``` +Mac → роутер 192.168.1.1: 0.622 / 1.006 / 1.308 ms 0% loss +Mac → ТВ 192.168.1.70: 0.596 / 2.295 / 26.874 ms 0% loss (через Wi-Fi ТВ) +Mac → Кра́кен 192.168.1.15: 1.321 / 3.169 / 4.233 ms 0% loss +``` + +🔴 **Пропускная способность нигде не измерена** — `iperf3` не установлен ни на Mac, ни на Rasputin, ни на Кра́кене. Все цифры выше — **латентность**, не скорость. Для Мбит/с нужен `iperf3`: на OpenWrt `opkg install iperf3`, на Mac `brew install iperf3`. + +## Проверка скорости линка — команды (проверено 2026-09-22) + +```bash +# Кра́кен (RPi5, ethtool есть) +ssh kraken 'ethtool eth0 | grep -E "Speed|Duplex|Link detected"' + +# ТВ (webOS, ethtool НЕТ → только sysfs) +ssh -i ~/.ssh/id_rsa root@192.168.1.70 'cat /sys/class/net/eth0/speed; cat /sys/class/net/eth0/duplex' + +# Роутер Бишкек (Merlin) — скорость порта свитча +ssh admin@192.168.1.1 'robocfg show' + +# Rasputin (OpenWrt) — скорость WAN +ssh root@192.168.6.1 'cat /sys/class/net/eth0/speed' +``` + +🔴 **`robocfg show` на Merlin показывает `1000FD` по порту, но это НЕ значит, что партнёр на гигабите.** Порт 4 показывал `1000FD`, при этом USB-адаптер Mac отдавал `100baseTX` — рассинхрон. Доверять надо цифре **на клиенте** (`ethtool` / `/sys/class/net/*/speed`), а `robocfg` — только как второе мнение. + +## ETH-линк ТВ: 100 Мбит (обнаружено 2026-09-22) + +ТВ `192.168.1.70` (MAC `ac:5a:f0:25:11:c6`) подключён **кабелем**, и его eth0 держит **100 Mbit/s full duplex** (подтверждено чтением `/sys/class/net/eth0/speed` → `100`). Гигабитные порты роутера при этом дают `1000FD` на других клиентах. + +⚠️ На роутере порт ТВ «мигает» между состояниями в течение сессии: сначала MAC ТВ виден на **Port 1** (`DOWN` в `robocfg`, но MAC присутствует в FDB моста `br0`), затем порт ТВ переехал в **Port 4** (`1000FD`). То есть кабель ТВ перекладывали. **Вывод о линке всегда проверять заново** — он менялся прямо в ходе диагностики. + +⚠️ **Порт 1 у Merlin может показывать `DOWN` и одновременно держать MAC клиента в `brctl showmacs br0`.** Это не противоречие в данных — это признак, что интерфейс был перенесён; MAC удерживается ageing-таймером FDB. Не строить вывод на одном `robocfg`. + ## Хранилище Kraken — USB (проверено 2026-09-04) Единственный диск `sda` (Toshiba **MQ01UBB200**, 1.8TB) подключён **напрямую в порт USB3/SS RPi5, НЕ через хаб** — Sysfs путь `/.../xhci-hcd.0/usb2/2-1`, speed **5000 Mbps**. lsusb -t: Dev 2 на Bus 02 (5000M). Линк USB3 настоящий (не USB2). diff --git a/family/how-to/rasputin-router.md b/family/how-to/rasputin-router.md index 99d07108..867528ba 100644 --- a/family/how-to/rasputin-router.md +++ b/family/how-to/rasputin-router.md @@ -12,7 +12,7 @@ tags: --- # Rasputin R5S OpenWrt router -> Status as of 2026-09-17: Rasputin is the OpenWrt edge/LAN router, routing normal LAN traffic through a VLESS/Xray tunnel via `tun0`, with explicit direct-WAN exceptions for upstream LAN access and Mac `cloudflared` QUIC traffic. ⚠️ **WAN переехал на `eth0` (`192.168.2.157/24`, gw `192.168.2.2`)** — см. раздел «WAN-интерфейс изменился» ниже. Транзит в GPON-сегмент `192.168.0.0/24` **сломан** — см. одноимённый раздел. +> Status as of 2026-09-22: Rasputin is the OpenWrt edge/LAN router, routing normal LAN traffic through a VLESS/Xray tunnel via `tun0`, with explicit direct-WAN exceptions for upstream LAN access and Mac `cloudflared` QUIC traffic. 🔴 **WAN СНОВА ПЕРЕЕХАЛ (2026-09-22): `eth0` теперь `192.168.1.50/24`, gw `192.168.1.1`** — Распутин воткнут в сегмент `192.168.1.0/24`, где живут Кра́кен (`.14`/`.15`), ТВ (`.70`) и Мак (`.57`/`.69`). Прежний `192.168.2.157/24` (gw `192.168.2.2`) больше не активен. Линк WAN — `1000/full`, MAC `36:ae:87:04:08:dc`. Транзит в GPON-сегмент `192.168.0.0/24` — см. одноимённый раздел. ## Identity @@ -534,16 +534,42 @@ meta l4proto udp ip daddr { 192.168.0.1, 192.168.0.50, 192.168.2.0/24 } counter > ⚠️ Из-за п.3 **пинг не является индикатором** доступности `192.168.0.0/24` из LAN. Проверять только тем каналом, которым будете работать (SSH/TCP). -### WAN-интерфейс изменился (факт 2026-09-17) +### WAN-интерфейс изменился ДВАЖДЫ (2026-09-17 → 2026-09-22) -Ранее (capture 2026-07-22) WAN был `usb0` с адресом `10.252.240.230`. Сейчас **WAN = `eth0`**: +**Текущее состояние (2026-09-22, проверено вживую):** ```text -inet 192.168.2.157/24 scope global eth0 -default via 192.168.2.2 dev eth0 proto static src 192.168.2.157 +eth0: 192.168.1.50/24, MAC 36:ae:87:04:08:dc, link 1000/full +br-lan: 192.168.6.1/24 +default: via 192.168.1.1 dev eth0 proto static src 192.168.1.50 ``` -То есть Rasputin получает адрес `192.168.2.157` **от роутера `192.168.2.2`** и выходит в интернет через него, а `192.168.2.2` — через GPON `192.168.0.1`. Топология запроса подтверждена: `rasputin → 192.168.2.2 → 192.168.0.1 (GPON) → 192.168.0.50`. +🔴 **Распутин теперь воткнут в сегмент `192.168.1.0/24`** — тот же, где Кра́кен (`.14`/`.15`), ТВ (`.70`) и Mac (`.57`/`.69`). Прежний `192.168.2.157/24` (gw `192.168.2.2`) **больше не активен**. + +Доступ: `ssh root@192.168.6.1` (LAN-адрес бранча, работает с Mac, хотя Mac в другом сегменте — через `192.168.1.50`). + +Историческая хронология WAN: + +| Дата | WAN-интерфейс | Адрес | GW | +|---|---|---|---| +| 2026-07-22 | `usb0` | `10.252.240.230` | `10.252.240.133` | +| 2026-09-17 | `eth0` | `192.168.2.157/24` | `192.168.2.2` | +| **2026-09-22** | **`eth0`** | **`192.168.1.50/24`** | **`192.168.1.1`** | + +Топология запроса (2026-09-17): `rasputin → 192.168.2.2 → 192.168.0.1 (GPON) → 192.168.0.50`. После переезда 2026-09-22 цепочка аплинка изменилась — `192.168.2.2` из пути выпал. + +### Измерения Rasputin → Кра́кен (2026-09-22) + +```text +Rasputin → 192.168.1.14: 0.499 / 0.639 / 0.897 ms 10/10, 0% loss +Rasputin → 192.168.1.15: 0.444 / 0.641 / 1.037 ms 10/10, 0% loss +``` + +ARP на Rasputin: и `.14`, и `.15` резолвятся в **один** lladdr `2c:cf:67:64:03:f3` (eth0 Кра́кена). + +⚠️ На OpenWrt **`ping -i 0.3` не поддерживается** — busybox-ping отдаёт `ping: invalid number '0.3'`. Использовать `ping -c N` без `-i` или с целым числом. + +🔴 **Пропускная способность не измерена** — `iperf3` на Распутине НЕТ. Для Мбит/с: `opkg install iperf3` (нужен интернет через WAN). ### ✅ ЧТО СДЕЛАНО (2026-09-17) — правило `ip rule` добавлено и работает diff --git a/family/how-to/router-bishkek-asus.md b/family/how-to/router-bishkek-asus.md index 3830b155..726ff572 100644 --- a/family/how-to/router-bishkek-asus.md +++ b/family/how-to/router-bishkek-asus.md @@ -120,6 +120,60 @@ ifconfig | awk '/^[a-z]/{ifc=$1} /100baseTX|1000baseT/{print ifc, $NF}' > 📌 Тот же линк 100 Mbit/s у ТВ был отмечен ещё 2026-09-04 (см. таблицу устройств). Тест 20.09 подтвердил причину — **кабель**. +## Диагностика линков 2026-09-22 — раскладка портов ИЗМЕНИЛАСЬ + +Пользователь «поменял конфигурацию сети». Фактическое состояние на момент проверки: + +| Порт | Скорость | MAC | Устройство | +|---|---|---|---| +| 0 | 1000FD | `6c:44:2a:9d:76:c5` | CPU / аплинк | +| 1 | **DOWN** ⚠️ | `00:00:00:00:00:00` в robocfg, но MAC ТВ в FDB | (ранее ТВ) | +| 3 | 1000FD | `2c:cf:67:64:03:f3` | **Kraken** (LAN-порт) | +| 4 | 1000FD | менялся: сначала USB-eth Mac `00:e0:4c:68:04:88`, затем **ТВ `ac:5a:f0:25:11:c6`** | ТВ (после перекладки) | +| 5 | 1000FD | `f0:79:59:77:9b:70` | WAN | + +🔴 **Порт ТВ переехал: было Port 3 → стало Port 1 → затем Port 4.** Кабель физически перекладывали в ходе сессии. Любой вывод о линке ТВ из прошлых сессий считать устаревшим. + +### 🔴 Порт может быть `DOWN` и одновременно держать MAC клиента в FDB + +``` +robocfg show | grep "Port 1" → Port 1: DOWN mac: 00:00:00:00:00:00 +brctl showmacs br0 | grep ac:5a → 1 ac:5a:f0:25:11:c6 no 28.13 +``` + +Это **не** противоречие данных и **не** признак живого линка. MAC-адрес удерживается ageing-таймером таблицы моста `br0` после того, как устройство переехало в другой порт или линк упал. `robocfg` (состояние PHY) — источник истины для «линка нет/есть», `brctl showmacs` — только для «где его видели последний раз». + +**Не строить вывод «порт работает» на наличии MAC в FDB.** + +### 🔴 `1000FD` на порту роутера ≠ партнёр работает на гигабите + +Симптом: `robocfg` показывает `Port 4: 1000FD`, а USB-адаптер Mac на этом кабеле отдаёт `100baseTX`. Это **рассинхрон**, не норма. + +Гигабиту нужны все 4 пары. Когда пара оборвана, **обе** стороны обычно падают в 100 — если роутер при этом показывает `1000FD`, значит рассинхрон внутри клиента, и смотреть надо на клиента. + +**Доверять цифре на КЛИЕНТЕ** (`ethtool` / `/sys/class/net/*/speed`), `robocfg` — второе мнение. + +### Mac: кабельного линка в этой сессии не было + +``` +en8 (USB 10/100/1000 LAN, Realtek, MAC 00:e0:4c:68:04:88): + в начале сессии → status: active, 192.168.1.69, Active: 100baseTX + к концу сессии → interface does not exist (адаптер отключён) +en1–en6: status: inactive +default route: via 192.168.1.1, interface en0 (Wi-Fi) +``` + +**Весь трафик Mac идёт через Wi-Fi `en0`** — 802.11ac, канал 149 (5 GHz, 80 MHz), country RU, IP `192.168.1.57`. Встроенного Ethernet у этой модели нет (все `en*` — Thunderbolt/USB). + +🔴 **Урок диагностики:** `ifconfig en0 | grep media` даёт `media: autoselect` — это **не** признак Ethernet. `en0` на этом Mac — **Wi-Fi**. Проверять `networksetup -listallhardwareports` перед выводами о типе линка. + +### Измеренные RTT (Mac, через en0 Wi-Fi) + +``` +Mac → роутер 192.168.1.1: 0.622 / 1.006 / 1.308 ms (20 pkts, 0% loss) +Mac → ТВ 192.168.1.70: 0.596 / 2.295 / 26.874 ms (20 pkts, 0% loss) +``` + ## Кастомный dnsmasq Файл: `/jffs/configs/dnsmasq.conf.add`