--- title: Kraken Network & Infra created: '2026-05-23' updated: '2026-09-04' type: tech namespace: personal tags: - infra - kraken - ssh - wireguard - network related: - '[[tech/arr-stack-kraken]]' --- # Kraken Network & Infra ## SSH Access ``` ssh kraken ``` SSH alias `kraken` resolves via `~/.ssh/config`. ## Актуальная сеть (проверено 2026-09-02) > Оба интерфейса живы. **eth0 — активный uplink** (default route metric 100), wlan0 — fallback (metric 600). | Интерфейс | 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) | `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 больше не должен дёргаться. - 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» — устарело (см. таблицу выше). ## Хранилище 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.