git_admin/obsidian-vault
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b290eec03bfbab3076bcb3e25bdbbd9741d9ecfa
obsidian-vault/family/how-to/kraken-network.md
T

16 KiB
Executable File
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-23 tech personal
infra
kraken
ssh
wireguard
network
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, ребут роутера не делали. Как проверить:

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

Reference in new issue View Git Blame Copy Permalink