--- title: Kraken Network & Infra created: '2026-05-23' updated: '2026-09-23' type: tech namespace: personal tags: - infra - kraken - ssh - wireguard - network related: - '[[tech/arr-stack-kraken]]' --- # Kraken Network & Infra ## 🔴 SSH-доступ: ходим по `.14` (провод). `.15` ОТКЛЮЧЁН (обновлено 2026-09-23) ``` ssh kraken # → DNS отдаёт .14 (провод) ✅ ssh kraken@192.168.1.14 # → провод, основной путь ``` **Alex (2026-09-23): «`.15` это wifi, мы по `.14` ходим».** WiFi `wlan0` в итоге **выключен** — `.15` больше не выдаётся. | Интерфейс | IP | MAC | Роль | |---|---|---|---| | **eth0** | `192.168.1.14/24` | `2c:cf:67:64:03:f3` | primary, default metric 100 | | **wlan0** | — (DOWN) | `2c:cf:67:64:03:f4` | отключён 2026-09-23 | 🔴 **`192.168.1.15` НЕ мёртвый** — прежний вывод «`.15` мёртвый» был ложным (один таймаут принят за факт). Причина обрывов ssh — **не адрес**: 1. перегрузка sshd после ребута (`load average: 4.69`); 2. 🔴 **`sudo` без `< /dev/null` рвёт соединение** — любая sudo-команда по SSH; 3. тяжёлый `jq` в одной строке с `ssh` (json 180 KB) — обрыв. Обход: короткие команды, тяжёлое — файлом-скриптом, `sudo … < /dev/null`. ### 🔴 DNS-имя `kraken` указывало на WiFi — ✅ РЕШЕНО (без ребута роутера) Причина: `dhcp_staticlist` нёс имя `kraken` у **обоих** интерфейсов, плюс `/jffs/configs/dnsmasq.conf.add` имел `address=/kraken/192.168.1.15`. ``` БЫЛО: <2C:CF:67:64:03:F3>192.168.1.14>kraken> ← eth0 <2C:CF:67:64:03:F4>192.168.1.15>kraken> ← wlan0, дубль имени address=/kraken/192.168.1.15 ← жёстко на WiFi СТАЛО: <2C:CF:67:64:03:F3>192.168.1.14>kraken> <2C:CF:67:64:03:F4>192.168.1.15> ← имя снято address=/kraken/192.168.1.14 ← на провод ``` 🔴 **Питфолл: живая DHCP-лиза ПЕРЕБИВАЕТ `address=`** — но решается БЕЗ ребута роутера. Рабочий лиз-файл dnsmasq лежит в **`/tmp/var/lib/misc/dnsmasq.leases`** (не в `/var/lib/`), и `service restart_dnsmasq` **не убивает процессы** — старый ответ остаётся в памяти. Фикс: почистить `/tmp`-файл + `killall -9 dnsmasq` + `service restart_dnsmasq`. ✅ Проверено 2026-09-23: `dig +short kraken` → `192.168.1.14`, ребут роутера не делали. Как проверить: ```bash ssh -i ~/.ssh/id_rsa admin@192.168.1.1 'grep kraken /etc/dnsmasq.conf' # применённый ssh -i ~/.ssh/id_rsa admin@192.168.1.1 'cat /tmp/var/lib/misc/dnsmasq.leases' # рабочий файл dig +short kraken @192.168.1.1 ``` Бэкапы: `/jffs/dhcp_staticlist.bak.20260923-214309`, `/jffs/configs/dnsmasq.conf.add.bak.20260923-214309`. Полный разбор — скилл `home-network-config` § «РЕШЕНО БЕЗ РЕБУТА», [[personal/plans/lampac-watched-to-watchlist]] §8.3.1. ✅ **ASUS `192.168.1.1` по SSH работает:** `ssh -i ~/.ssh/id_rsa admin@192.168.1.1` (не `root@`). Правки DNS/nvram — по SSH, веб-UI не нужен. ## SSH Access ``` ssh kraken@192.168.1.14 ``` SSH alias `kraken` резолвится через `~/.ssh/config` (proxy-команда: если есть `10.99.0.2` — идём на `10.99.1.2`, иначе `nc kraken 22` → DNS → `.15`). ⚠️ WG-туннель с Mac сейчас **не поднят** (`10.99.0.2` нет) → уходит в LAN-ветку. ## Актуальная сеть (уточнено 2026-09-23) > ✅ **У Кра́кена ДВА MAC — по одному на интерфейс.** Прежняя запись «`.15` > числится за eth0, отдельного WiFi-MAC в ARP нет» **неверна**: eth0 = `…:f3`, > wlan0 = `…:f4` (подтверждено `ip -br addr` и `dhcp_staticlist`). | Интерфейс | 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 | | **wlan0** (WiFi) | — **DOWN** (адрес снят 2026-09-23) | `2c:cf:67:64:03:f4` | отключён | - ✅ **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 ``` 🔴 **Пропускная способность (throughput) нигде не измерена** — все цифры выше это **латентность (RTT)**, не скорость. `1000FD` в `robocfg`/`ethtool` — это **link speed**, согласованная скорость линка, а НЕ реальные Мбит/с. Три разных величины, которые легко спутать: | Мера | Инструмент | Что отвечает | |---|---|---| | Link speed | `ethtool` / `robocfg` / `sysfs speed` | согласованная скорость линка (потолок) | | Throughput | `iperf3` | реальные Мбит/с через линк | | Интернет | speedtest | что даёт провайдер | **Состояние `iperf3` (2026-09-22):** ``` Распутин: iperf3 3.17.1 ✅ (opkg install iperf3) Кра́кен: iperf3 3.12 ✅ (apt-get install iperf3) Mac: НЕ установлен ``` ⚠️ На OpenWrt в комплекте уже были `libiperf3` и `python3-iperf3` — это **библиотеки, не бинарь**. Проверять `which iperf3`, а не `opkg list-installed | grep iperf`. **Замер ещё НЕ сделан.** Блокер: sshd на Распутине отказал (`Connection refused` при живом пинге). Партнёр готов, на Кра́кене сервер поднят на `:5201`. Команды: ```bash # на Кра́кене nohup iperf3 -s -p 5201 > /tmp/iperf3s.log 2>&1 & # на Распутине iperf3 -c 192.168.1.14 -p 5201 -t 10 ``` ⚠️ Гигабитный линк физически даёт максимум ~940–950 Мбит/с (оверхед Ethernet). На NanoPi R5S реальный потолок может быть ниже — упрётся в CPU. ## Проверка скорости линка — команды (проверено 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`). 🔴 **Это предел сетевой карты телевизора, а НЕ кабеля.** Проверено с **заведомо гигабитным патч-кордом** — ТВ всё равно отдаёт `100` и больше не даёт. Не диагностировать как «битый/полуживой кабель», не менять патч-корд, не искать гигабит: модель физически не умеет. ⚠️ Ранняя версия этой заметки (2026-09-04) объясняла 100M «downshift из-за плохого провода» по аналогии с Kraken — **это была неверная гипотеза**. Причина у ТВ другая: ограничение самой сетевой карты. У Kraken причина была своя (патч-корд, заменён 2026-09-04 → линк `1000 full`, подтверждено 2026-09-22). Не переносить вывод с одного устройства на другое. ⚠️ На роутере порт ТВ «мигает» между состояниями в течение сессии: сначала 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). **Скорость чтения диска ~95 МБ/с** (dd direct + buffered, по remux-файлу): это не USB-узкое место, а **физический предел 5400rpm 2.5" ноутбучного HDD** (максимум ~100–110 МБ/с на внешних дорожках). Для сравнения потолок USB2 ≈ 35–40 МБ/с. USB3.0 линк подтверждён (5000M). Вывод: для скорости >200 МБ/с нужен SSD/7200rpm, текущий механик упрется в ~95–110 МБ/с. Хабы (Super Top `1-1.2`, Huasheng «USB2.0 HUB» `1-1`) висят на **Bus 01 (USB2, 480M)** и **пустые** — к ним ничто не подключено. Монтирование: `/dev/sda1` (ext4, UUID `6194539b-03e0-4f33-986b-4da09834e82f`) → `/srv/dev-disk-by-uuid-6194539b-...`; старый путь `49e8f586...` — **symlink** на него. ## Клиент — LG webOS TV (192.168.1.75 WiFi / 192.168.1.70 Ethernet) (проверено 2026-09-04) По SSH `root@192.168.1.75` или `root@192.168.1.70` (`~/.ssh/config` .75, id_rsa; выводит post-quantum warning — ок). Host LGwebOSTV, ядро 4.4.84 armv7 (webOS). ТВ имеет **два MAC**: WiFi `54:77:87:ce:fb:b3`, Ethernet `ac:5a:f0:25:11:c6` (этот = static lease в роутере `.75`). **Состояние на конец сессии 2026-09-04:** ТВ переведён на **провод** (пользователь воткнул патч-корд в роутер) → WiFi `wlan0 DOWN`, `eth0 UP`. После этого IP сменился: проводной интерфейс получил **`192.168.1.70`** (старый `.75` больше не отвечает, ping 100% loss). ⚠️ **eth0 ТВ линк = 100 Mbit/s full duplex** (carrier up, speed=100) — то есть **тот же downshift на 100M**, какой был у Kraken (см. ниже). Провод 100M **медленнее**, чем WiFi (867 PHY ≈ 400+ реальных Мбит/с) → переключение на полуживой кабель — регресс., если не поменять патч-корд ТВ↔роутер на рабочий гигабитный. **Сводка по линкам ТВ (до переключения на провод, WiFi .75):** - Wi-Fi клиент был: SSID **ASUS5**, BSSID `f0:79:59:77:9b:74`, **канал 153 / 5765MHz / width 80MHz (5 GHz, 802.11ac)**, **signal -53 dBm** (отличный), **TX link rate 867.0 MBit/s PHY** (2-поток 80MHz AC — потолок карты), txpower 15 dBm. - Реальный TCP-пропуск ≈ 50–60% PHY ≈ **400–500 Мбит/с** при таком сигнале — это в разы больше 99 Мбит/с remux'а, так что **WiFi ТВ не узкое место**. Торможение 4K сохранялось и на WiFi, и позже подтверждено на сотне-проводе. **Forensics торможения (проведено вживую при воспроизведении Project Hail Mary, Direct Play):** - Транскода НЕТ: 0 ffmpeg-процессов, `/config/transcodes` пуст, CPU Kraken load ~0.1 — сервер простаивает. - Сервер отдаёт всего ~21 Мбит/с (eth0 tx) при файле ~27 Мбит/с — сеть и диск с запасом ×10+. - Wi-Fi ТВ-интерфейс за время стрима: **rx_crc_errors=0, tx_retries delta=0**, signal постоянно -53 dBm — радио чистое, не деградирует. - **Вывод: все сетевые/дисковые/радио-счётчики чисты, линки имеют запас, а Direct Play НИЗКОбитрейтного (24-27 Мбит/с) 4K всё равно подёргивается** → причина в **программном декодере/буфере клиента «Jellyfin for WebOS 1.2.2»**, а не в инфраструктуре. См. [[arr-stack-kraken]] «Известные проблемы». Плюс если смотреть через провод — линк ТВ сейчас 100M (тоже слабое место для remux). ## WireGuard Topology Split-tunnel: Eagle ↔ VPS ↔ Kraken. Full details: [[tech/wireguard-vpn]]. - Eagle: `10.99.0.2`, Kraken: `10.99.1.2`, VPS relay: `10.99.0.1`/`10.99.1.1` - `wg-auto.sh` on Eagle (LaunchDaemon) — up when off home Wi-Fi, down at home - VPS as relay; two interfaces (wg0/wg1) avoid hairpin forwarding ## Media Volume Mount Paths Docker containers on Kraken mount media from NAS over NFS/SMB. Paths were documented here — check docker-compose files in `/opt/media-toolbox-kraken` for current mount config.