[2026-09-23] eagle: family/how-to/htpc-webos-luna.md family/how-to/kraken-network.md family/how-to/rasputin-router.md family/how-to/router-bishkek-asus.md
This commit is contained in:
1 parent
66dd5b1f5e
commit
8e4f6ec743
4 files changed
+155
-13
No files matched your search
@@ -88,13 +88,32 @@ ssh root@192.168.1.70 'rm -f /tmp/f.txt; script -q -c \
|
||||
| Параметр | Значение |
|
||||
|---|---|
|
||||
| IP | `192.168.1.70` (проводной eth0); старый `.75` больше не отвечает |
|
||||
| SSH | `root@192.168.1.70`, ключ `~/.ssh/konka_webos`, `StrictHostKeyChecking no` |
|
||||
| SSH | `root@192.168.1.70`, **ключ `~/.ssh/id_rsa`**, `StrictHostKeyChecking no` |
|
||||
| Порты | `22` SSH, `3000`/`3001` Luna |
|
||||
| webOS | **5.4.2**, ядро `4.4.84`, image `starfish-dvb-secured`, build 2602 |
|
||||
| eth0 link | **100 Mbit/s full duplex** (проверено 2026-09-22, `cat /sys/class/net/eth0/speed` → `100`) |
|
||||
| Кастомные приложения | `org.webosbrew.hbchannel` 0.7.2, `org.webosbrew.inputhook`, `me.wouterdek.magic4pc`, **`com.lampac.tv`** |
|
||||
|
||||
⚠️ SSH печатает `post-quantum key exchange` warning — **это норма**, не ошибка.
|
||||
|
||||
🔴 **Ключ `~/.ssh/konka_webos` ОТКЛОНЁН (проверено 2026-09-22).** `Permission denied (publickey,password)`
|
||||
на всех вариантах (`konka_webos`, `konka_webos.bak`, `988d8c6ece`, `webos_emul`).
|
||||
**Рабочий ключ — `~/.ssh/id_rsa`.** В `~/.ssh/config` при этом есть хвост `Host 192.168.1.76` с
|
||||
`IdentityFile ~/.ssh/konka_webos` — этот хост **не ТВ** (ТВ = `.70`), не путать.
|
||||
|
||||
Рабочая команда:
|
||||
```bash
|
||||
ssh -o StrictHostKeyChecking=no -o IdentitiesOnly=yes -i ~/.ssh/id_rsa \
|
||||
-o HostkeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa \
|
||||
root@192.168.1.70 'cat /sys/class/net/eth0/speed; cat /sys/class/net/eth0/duplex'
|
||||
# → 100
|
||||
# full
|
||||
```
|
||||
|
||||
⚠️ **Только ключ `id_rsa`.** Опция `-o PasswordAuthentication=no` + `-o BatchMode=yes` рвёт соединение
|
||||
раньше, чем успевает пройти pubkey-аутентификация на этой прошивке — не использовать как «проверку»,
|
||||
что ключа нет.
|
||||
|
||||
## Связанные заметки
|
||||
|
||||
- [[family/how-to/tv-luna-send]] — враппер `~/Automation/tv-luna-send.sh`
|
||||
|
||||
@@ -24,21 +24,64 @@ ssh kraken
|
||||
|
||||
SSH alias `kraken` resolves via `~/.ssh/config`.
|
||||
|
||||
## Актуальная сеть (проверено 2026-09-02)
|
||||
## Актуальная сеть (проверено 2026-09-22)
|
||||
|
||||
> Оба интерфейса живы. **eth0 — активный uplink** (default route metric 100), wlan0 — fallback (metric 600).
|
||||
> ⚠️ **Кра́кен теперь достаётся по двум адресам на ОДНОМ 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 |
|
||||
| **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 больше не должен дёргаться.
|
||||
- ✅ **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
|
||||
```
|
||||
|
||||
🔴 **Пропускная способность нигде не измерена** — `iperf3` не установлен ни на Mac, ни на Rasputin, ни на Кра́кене. Все цифры выше — **латентность**, не скорость. Для Мбит/с нужен `iperf3`: на OpenWrt `opkg install iperf3`, на Mac `brew install iperf3`.
|
||||
|
||||
## Проверка скорости линка — команды (проверено 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`). Гигабитные порты роутера при этом дают `1000FD` на других клиентах.
|
||||
|
||||
⚠️ На роутере порт ТВ «мигает» между состояниями в течение сессии: сначала 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).
|
||||
|
||||
@@ -12,7 +12,7 @@ tags:
|
||||
---
|
||||
# Rasputin R5S OpenWrt router
|
||||
|
||||
> Status as of 2026-09-17: Rasputin is the OpenWrt edge/LAN router, routing normal LAN traffic through a VLESS/Xray tunnel via `tun0`, with explicit direct-WAN exceptions for upstream LAN access and Mac `cloudflared` QUIC traffic. ⚠️ **WAN переехал на `eth0` (`192.168.2.157/24`, gw `192.168.2.2`)** — см. раздел «WAN-интерфейс изменился» ниже. Транзит в GPON-сегмент `192.168.0.0/24` **сломан** — см. одноимённый раздел.
|
||||
> Status as of 2026-09-22: Rasputin is the OpenWrt edge/LAN router, routing normal LAN traffic through a VLESS/Xray tunnel via `tun0`, with explicit direct-WAN exceptions for upstream LAN access and Mac `cloudflared` QUIC traffic. 🔴 **WAN СНОВА ПЕРЕЕХАЛ (2026-09-22): `eth0` теперь `192.168.1.50/24`, gw `192.168.1.1`** — Распутин воткнут в сегмент `192.168.1.0/24`, где живут Кра́кен (`.14`/`.15`), ТВ (`.70`) и Мак (`.57`/`.69`). Прежний `192.168.2.157/24` (gw `192.168.2.2`) больше не активен. Линк WAN — `1000/full`, MAC `36:ae:87:04:08:dc`. Транзит в GPON-сегмент `192.168.0.0/24` — см. одноимённый раздел.
|
||||
|
||||
## Identity
|
||||
|
||||
@@ -534,16 +534,42 @@ meta l4proto udp ip daddr { 192.168.0.1, 192.168.0.50, 192.168.2.0/24 } counter
|
||||
|
||||
> ⚠️ Из-за п.3 **пинг не является индикатором** доступности `192.168.0.0/24` из LAN. Проверять только тем каналом, которым будете работать (SSH/TCP).
|
||||
|
||||
### WAN-интерфейс изменился (факт 2026-09-17)
|
||||
### WAN-интерфейс изменился ДВАЖДЫ (2026-09-17 → 2026-09-22)
|
||||
|
||||
Ранее (capture 2026-07-22) WAN был `usb0` с адресом `10.252.240.230`. Сейчас **WAN = `eth0`**:
|
||||
**Текущее состояние (2026-09-22, проверено вживую):**
|
||||
|
||||
```text
|
||||
inet 192.168.2.157/24 scope global eth0
|
||||
default via 192.168.2.2 dev eth0 proto static src 192.168.2.157
|
||||
eth0: 192.168.1.50/24, MAC 36:ae:87:04:08:dc, link 1000/full
|
||||
br-lan: 192.168.6.1/24
|
||||
default: via 192.168.1.1 dev eth0 proto static src 192.168.1.50
|
||||
```
|
||||
|
||||
То есть Rasputin получает адрес `192.168.2.157` **от роутера `192.168.2.2`** и выходит в интернет через него, а `192.168.2.2` — через GPON `192.168.0.1`. Топология запроса подтверждена: `rasputin → 192.168.2.2 → 192.168.0.1 (GPON) → 192.168.0.50`.
|
||||
🔴 **Распутин теперь воткнут в сегмент `192.168.1.0/24`** — тот же, где Кра́кен (`.14`/`.15`), ТВ (`.70`) и Mac (`.57`/`.69`). Прежний `192.168.2.157/24` (gw `192.168.2.2`) **больше не активен**.
|
||||
|
||||
Доступ: `ssh root@192.168.6.1` (LAN-адрес бранча, работает с Mac, хотя Mac в другом сегменте — через `192.168.1.50`).
|
||||
|
||||
Историческая хронология WAN:
|
||||
|
||||
| Дата | WAN-интерфейс | Адрес | GW |
|
||||
|---|---|---|---|
|
||||
| 2026-07-22 | `usb0` | `10.252.240.230` | `10.252.240.133` |
|
||||
| 2026-09-17 | `eth0` | `192.168.2.157/24` | `192.168.2.2` |
|
||||
| **2026-09-22** | **`eth0`** | **`192.168.1.50/24`** | **`192.168.1.1`** |
|
||||
|
||||
Топология запроса (2026-09-17): `rasputin → 192.168.2.2 → 192.168.0.1 (GPON) → 192.168.0.50`. После переезда 2026-09-22 цепочка аплинка изменилась — `192.168.2.2` из пути выпал.
|
||||
|
||||
### Измерения Rasputin → Кра́кен (2026-09-22)
|
||||
|
||||
```text
|
||||
Rasputin → 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
|
||||
```
|
||||
|
||||
ARP на Rasputin: и `.14`, и `.15` резолвятся в **один** lladdr `2c:cf:67:64:03:f3` (eth0 Кра́кена).
|
||||
|
||||
⚠️ На OpenWrt **`ping -i 0.3` не поддерживается** — busybox-ping отдаёт `ping: invalid number '0.3'`. Использовать `ping -c N` без `-i` или с целым числом.
|
||||
|
||||
🔴 **Пропускная способность не измерена** — `iperf3` на Распутине НЕТ. Для Мбит/с: `opkg install iperf3` (нужен интернет через WAN).
|
||||
|
||||
### ✅ ЧТО СДЕЛАНО (2026-09-17) — правило `ip rule` добавлено и работает
|
||||
|
||||
|
||||
@@ -120,6 +120,60 @@ ifconfig | awk '/^[a-z]/{ifc=$1} /100baseTX|1000baseT/{print ifc, $NF}'
|
||||
|
||||
> 📌 Тот же линк 100 Mbit/s у ТВ был отмечен ещё 2026-09-04 (см. таблицу устройств). Тест 20.09 подтвердил причину — **кабель**.
|
||||
|
||||
## Диагностика линков 2026-09-22 — раскладка портов ИЗМЕНИЛАСЬ
|
||||
|
||||
Пользователь «поменял конфигурацию сети». Фактическое состояние на момент проверки:
|
||||
|
||||
| Порт | Скорость | MAC | Устройство |
|
||||
|---|---|---|---|
|
||||
| 0 | 1000FD | `6c:44:2a:9d:76:c5` | CPU / аплинк |
|
||||
| 1 | **DOWN** ⚠️ | `00:00:00:00:00:00` в robocfg, но MAC ТВ в FDB | (ранее ТВ) |
|
||||
| 3 | 1000FD | `2c:cf:67:64:03:f3` | **Kraken** (LAN-порт) |
|
||||
| 4 | 1000FD | менялся: сначала USB-eth Mac `00:e0:4c:68:04:88`, затем **ТВ `ac:5a:f0:25:11:c6`** | ТВ (после перекладки) |
|
||||
| 5 | 1000FD | `f0:79:59:77:9b:70` | WAN |
|
||||
|
||||
🔴 **Порт ТВ переехал: было Port 3 → стало Port 1 → затем Port 4.** Кабель физически перекладывали в ходе сессии. Любой вывод о линке ТВ из прошлых сессий считать устаревшим.
|
||||
|
||||
### 🔴 Порт может быть `DOWN` и одновременно держать MAC клиента в FDB
|
||||
|
||||
```
|
||||
robocfg show | grep "Port 1" → Port 1: DOWN mac: 00:00:00:00:00:00
|
||||
brctl showmacs br0 | grep ac:5a → 1 ac:5a:f0:25:11:c6 no 28.13
|
||||
```
|
||||
|
||||
Это **не** противоречие данных и **не** признак живого линка. MAC-адрес удерживается ageing-таймером таблицы моста `br0` после того, как устройство переехало в другой порт или линк упал. `robocfg` (состояние PHY) — источник истины для «линка нет/есть», `brctl showmacs` — только для «где его видели последний раз».
|
||||
|
||||
**Не строить вывод «порт работает» на наличии MAC в FDB.**
|
||||
|
||||
### 🔴 `1000FD` на порту роутера ≠ партнёр работает на гигабите
|
||||
|
||||
Симптом: `robocfg` показывает `Port 4: 1000FD`, а USB-адаптер Mac на этом кабеле отдаёт `100baseTX`. Это **рассинхрон**, не норма.
|
||||
|
||||
Гигабиту нужны все 4 пары. Когда пара оборвана, **обе** стороны обычно падают в 100 — если роутер при этом показывает `1000FD`, значит рассинхрон внутри клиента, и смотреть надо на клиента.
|
||||
|
||||
**Доверять цифре на КЛИЕНТЕ** (`ethtool` / `/sys/class/net/*/speed`), `robocfg` — второе мнение.
|
||||
|
||||
### Mac: кабельного линка в этой сессии не было
|
||||
|
||||
```
|
||||
en8 (USB 10/100/1000 LAN, Realtek, MAC 00:e0:4c:68:04:88):
|
||||
в начале сессии → status: active, 192.168.1.69, Active: 100baseTX <full-duplex>
|
||||
к концу сессии → interface does not exist (адаптер отключён)
|
||||
en1–en6: status: inactive
|
||||
default route: via 192.168.1.1, interface en0 (Wi-Fi)
|
||||
```
|
||||
|
||||
**Весь трафик Mac идёт через Wi-Fi `en0`** — 802.11ac, канал 149 (5 GHz, 80 MHz), country RU, IP `192.168.1.57`. Встроенного Ethernet у этой модели нет (все `en*` — Thunderbolt/USB).
|
||||
|
||||
🔴 **Урок диагностики:** `ifconfig en0 | grep media` даёт `media: autoselect` — это **не** признак Ethernet. `en0` на этом Mac — **Wi-Fi**. Проверять `networksetup -listallhardwareports` перед выводами о типе линка.
|
||||
|
||||
### Измеренные RTT (Mac, через en0 Wi-Fi)
|
||||
|
||||
```
|
||||
Mac → роутер 192.168.1.1: 0.622 / 1.006 / 1.308 ms (20 pkts, 0% loss)
|
||||
Mac → ТВ 192.168.1.70: 0.596 / 2.295 / 26.874 ms (20 pkts, 0% loss)
|
||||
```
|
||||
|
||||
## Кастомный dnsmasq
|
||||
|
||||
Файл: `/jffs/configs/dnsmasq.conf.add`
|
||||
|
||||
Reference in new issue
Block a user