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

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-22)

⚠️ Кра́кен теперь достаётся по двум адресам на ОДНОМ 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
wlan0 (WiFi)	192.168.1.15/24 (DHCP)	2c:cf:67:64:03:f4	fallback — metric 600

• ✅ 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.
• ⚠️ Ранее эта заметка утверждала «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. Команды:

# на Кра́кене
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)

# Кра́кен (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.