Files
obsidian-vault/family/how-to/kraken-network.md
T

7.4 KiB
Raw Blame History

title, created, updated, type, namespace, tags, related
title created updated type namespace tags related
Kraken Network & Infra 2026-05-23 2026-09-04 tech personal
infra
kraken
ssh
wireguard
network
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.
  • ⚠️ Ранее эта заметка утверждала «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 ≈ 400500 Мбит/с при таком сигнале — это в разы больше 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.