[2026-09-25] eagle: family/how-to/router-bishkek-asus.md personal/tech/home-network-config.md
This commit is contained in:
Alexey Martemyanov committed
1 parent
f2959d3df0
commit
ea6b4d9f3e
2 files changed
+138
-1
No files matched your search
@@ -236,3 +236,140 @@ address=/snu.lge.com.usgcac.cdnetworks.net/snu.lge.com/su.lge.com/192.168.1.1
|
||||
address=/htpc/192.168.1.86
|
||||
address=/tv/192.168.1.75
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📡 WiFi — карта интерфейсов и RF-диагностика (2026-09-25)
|
||||
|
||||
### Карта радиоинтерфейсов — НЕ ПУТАТЬ
|
||||
|
||||
| `wl` iface | Диапазон | `nvram` префикс | SSID | Канал (2026-09-25) |
|
||||
|---|---|---|---|---|
|
||||
| `eth1` | **2.4 GHz** | `wl0_*` | `GP2` | **1**, 20 MHz |
|
||||
| `eth2` | **5 GHz** | `wl1_*` | `ASUS5` | **149** (chanspec `155`), 80 MHz |
|
||||
|
||||
🔴 **`wl0_*` = 2.4 GHz (`eth1`), `wl1_*` = 5 GHz (`eth2`).** Мнемоника: `wl1_nband=1` = 5 GHz, `wl0_nband=2` = 2.4 GHz (`nband` = номер band, не «какой лучше»).
|
||||
|
||||
### ⚠️ ПИТФОЛЛ: `wl -i ethN scan_results` на этом билде возвращает ПУСТО
|
||||
|
||||
```
|
||||
wl -i eth1 scan_results → (пусто, 0 строк)
|
||||
wl -i eth1 scan → (пусто)
|
||||
wl -i eth1 scan -t passive → (пусто)
|
||||
wl -i eth1 scan_results → "wl: Unsupported" (после неудачного scan)
|
||||
wl -i eth2 scan_results → "wl: Unsupported"
|
||||
```
|
||||
|
||||
При этом `wl`, `wlceventd`, `nas`, `wlc_nt` **работают** (см. `ps w | grep -E "nas|wlc"`), а `wl -i eth1 status` / `sta_info` / `assoclist` отдают корректные данные. То есть **scan-подсистема через CLI недоступна, остальное — да.**
|
||||
|
||||
**Обход — брать список соседей с КЛИЕНТА, а не с роутера:**
|
||||
```bash
|
||||
# на Mac — список соседних сетей с каналами (только канал + PHY, без RSSI)
|
||||
system_profiler SPAirPortDataType
|
||||
# или агрегированно:
|
||||
system_profiler SPAirPortDataType 2>/dev/null \
|
||||
| grep -E 'Channel: [0-9]+ \(2GHz' | sort | uniq -c | sort -rn
|
||||
```
|
||||
🔴 `airport -s` на современных macOS **убран** (`No such file or directory`) — использовать `system_profiler SPAirPortDataType`.
|
||||
⚠️ Секции `Other Local Wi-Fi Networks` показывают **канал и PHY Mode, но НЕ RSSI** — судить о зашумлённости по количеству сетей на канале, а не по уровню.
|
||||
|
||||
### Ключевые команды RF-диагностики (проверенные)
|
||||
|
||||
```bash
|
||||
# Шум эфира на самом радио (source of truth по noise floor)
|
||||
wl -i eth1 status | grep -i noise # 2.4 GHz → noise: -85 dBm
|
||||
wl -i eth2 status | grep -i noise # 5 GHz → noise: -92 dBm
|
||||
|
||||
# Шум по антеннам + RSSI клиента
|
||||
wl -i eth1 sta_info <MAC> | grep -iE 'noise floor|per antenna rssi|rate of last|tx failures'
|
||||
|
||||
# Список подключённых станций
|
||||
wl -i eth1 assoclist # 2.4 GHz
|
||||
wl -i eth2 assoclist # 5 GHz
|
||||
|
||||
# Каналы, реально доступные радио (зависит от country!)
|
||||
wl -i eth1 channels # 2.4 → 1..11
|
||||
wl -i eth2 channels # 5 → 36 40 44 48 149 153 157 161 165 (нет 52-64, 100-144!)
|
||||
wl -i eth2 country # → US (US/0) UNITED STATES
|
||||
```
|
||||
|
||||
### 🔴 `country = US` при locale RU — режет половину 5 GHz
|
||||
|
||||
`nvram get wl0_country_code` / `wl1_country_code` → **`US`**, `wl -i eth2 country` → `US (US/0)`, `txpwr` → `31.75 dBm (1496 mW)`.
|
||||
|
||||
Следствие: в US-регуляторике **нет DFS-каналов** `52–64` и `100–144`. Доступны только **`36–48`** и **`149–165`**. Это вдвое сужает выбор 5 GHz и объясняет, почему при плотном эфире некуда уйти.
|
||||
|
||||
Клиенты при этом видят больше каналов (у Mac `Country Code: RU`, `Supported Channels` включает `52–64` и `132–144`) — потому что страну выбирает **клиентское радио** по своему локалу, а роутер вещает по US-плану. Расхождение допустимо, но при планировании канала ориентироваться на `wl -i eth2 channels`, т.е. на **роутер**.
|
||||
|
||||
### 📊 Замер 2026-09-25 — фактическая картина
|
||||
|
||||
| Параметр | 2.4 GHz (`eth1`, GP2) | 5 GHz (`eth2`, ASUS5) |
|
||||
|---|---|---|
|
||||
| Канал / ширина | 1, 20 MHz | 149 (chanspec 155), 80 MHz |
|
||||
| Noise floor | **−85 dBm** | **−92 dBm** |
|
||||
| Конкуренция (скан Mac) | канал 1 — 2 сети (+1 на 40 MHz); свободнее на 11 | 149 — 2 сети; 40 — 5 сетей; 44/56 — по 4 и 3 |
|
||||
| Клиентов | 5 | 5 |
|
||||
| Лучший клиент | −44 dBm, tx 65 Mbps | Mac −37/−92 dBm, tx **866 Mbps** |
|
||||
| Худший клиент | −70 dBm, **4585 tx failures** | — |
|
||||
|
||||
**Кто где сидит (2026-09-25):**
|
||||
|
||||
*2.4 GHz (`eth1`)* — только IoT:
|
||||
```
|
||||
04:CF:8C:F4:62:8A .81 zhimi-airpurifier RSSI −69/−69/−76
|
||||
24:18:C6:E2:8D:65 .55 1YN01929 RSSI −48/−46/−50
|
||||
EA:62:89:22:DA:AB .98 (неизвестно) RSSI −70/−70/−72 ← 4585 tx failures ⚠️
|
||||
64:90:C1:F2:CB:13 .59 zhimi-airpurifier RSSI −44/−44/−48
|
||||
18:69:D8:32:F8:26 .48 (неизвестно) RSSI −59/−61/−57
|
||||
```
|
||||
*5 GHz (`eth2`)* — все тяжёлые клиенты:
|
||||
```
|
||||
3A:2F:09:6E:49:1E .96 Galaxy-S23 tx 866 Mbps
|
||||
76:88:0D:B9:6A:CD .43 MacBookPro
|
||||
9A:DD:7D:55:2D:A7 .67 S25-pol-zovatela-Alexey tx 866 Mbps
|
||||
5A:FE:E7:BB:B3:D1 .57 Mac tx 866 / rx 433 Mbps
|
||||
F4:1B:A1:16:CE:93 .74 iPad-Alexey tx 150 Mbps
|
||||
```
|
||||
|
||||
### ✅ Вывод диагностики 2026-09-25 — канал 5 GHz МЕНЯТЬ НЕ НУЖНО
|
||||
|
||||
Тяжёлые клиенты **уже сидят на 5 GHz** и получают 866 Mbps при noise floor −92 dBm — это отличный результат. Деградации на 5 GHz нет.
|
||||
|
||||
Канал **149 оставить**:
|
||||
- 149 — 2 соседа;
|
||||
- альтернативы хуже: `40` — 5 сетей, `44`/`56` — 4 и 3, `36` — 2 сети + одна из них `ax 160 MHz`.
|
||||
|
||||
**2.4 GHz:** канал `1` делят 2 соседа на 40 MHz, канал `11` свободнее. Переключение `1 → 11` снизит коллизии **для IoT**, но выигрыша для Mac не даст (Mac на 5 GHz).
|
||||
|
||||
**Единственная реальная проблема** — клиент `EA:62:89:22:DA:AB` (`.98`, имя неизвестно): **4585 tx failures** при RSSI −70 dBm. Это устройство, а не эфир. Лечить приближением к точке доступа или переводом на 5 GHz.
|
||||
|
||||
### 📋 ПЛАН правки (ожидает подтверждения Alex — НЕ выполнен)
|
||||
|
||||
1. **Бэкап:** `nvram get wl0_channel > /jffs/wl.bak.$(date +%Y%m%d-%H%M%S)`
|
||||
2. **Сменить 2.4 GHz канал `1` → `11`**, ширина 20 MHz **оставить** (40 MHz в зашумлённом эфире даёт регресс).
|
||||
3. Применить: `nvram set wl0_channel=11 && nvram commit && service restart_wireless`
|
||||
4. **Проверка Alex в UI** — клиенты 2.4 GHz переподключились, канал 11 виден в веб-морде.
|
||||
5. Записать результат в этот документ.
|
||||
|
||||
Открытый вопрос: разбирать ли устройство `.98` отдельно.
|
||||
|
||||
### Прочие настройки радио (снято 2026-09-25)
|
||||
|
||||
| Параметр | 2.4 (`wl0_`) | 5 (`wl1_`) | Комментарий |
|
||||
|---|---|---|---|
|
||||
| `channel` | `0` (auto) | `0` (auto) | фактически сели на 1 и 149 |
|
||||
| `bw_cap` | `3` | `7` | 2.4 ограничен 20/40, 5 разрешён 80 |
|
||||
| `obss_coex` | `1` | `0` | ✅ для 2.4 при 40 MHz соседях — правильно |
|
||||
| `txpower` | `100` | `100` | 100 % |
|
||||
| `ampdu` / `itxbf` | `auto` / `1` | `auto` / `1` | ✅ включены |
|
||||
| `gmode` | `1` | `-1` | |
|
||||
| `plcphdr` | `long` | `long` | |
|
||||
| `frameburst` | `on` | `on` | |
|
||||
| `ap_isolate` | `0` | `0` | клиенты видят друг друга |
|
||||
| `crypto` | `aes` | `aes` | |
|
||||
|
||||
> ⚠️ `nvram get` по `wl0_ht_bw`, `wl1_vht_bw`, `wl0_mimo`, `wl0_11n`, `wl0_wmm` возвращает **пусто** — в этом билде соответствующие ключи отсутствуют (значения дефолтные). Не считать это «настройка сброшена».
|
||||
|
||||
### Страна/регуляторика — кандидат на смену, но не рекомендован
|
||||
|
||||
`wl0/wl1_country_code = US` при том, что клиенты в RU. Смена на `RU`/`Omsk` откроет DFS-каналы `52–64`, `100–144` — но добавит риск radar-переключений (DFS-событие = принудительный уход с канала, обрыв клиентов). При текущем состоянии 5 GHz (866 Mbps, −92 dBm) **смысла нет**. Не трогать.
|
||||
@@ -52,7 +52,7 @@ route -n get 192.168.2.197 # на Mac: какой gateway?
|
||||
|---|---|---|
|
||||
| Кра́кен `192.168.1.15` | ~~`ssh kraken`~~ | 🔴 **СЛОМАНА**: DNS отдаёт `.15` (wlan0, metric 600) → порт 22 открыт, но sshd рвёт на `banner exchange`. Рабочий адрес — `192.168.1.14` |
|
||||
| Кра́кен `192.168.1.14` | `ssh kraken@192.168.1.14` | ✅ **работает** именно так (eth0, активный) |
|
||||
| ASUS `192.168.1.1` | ~~`ssh -i ~/.ssh/id_rsa admin@192.168.1.1`~~ | ❌ **НЕ работает**: `Permission denied` → `Connection closed`. `nc -z 192.168.1.1 22` → closed. Маршруты — только веб-UI |
|
||||
| ASUS `192.168.1.1` | `ssh -i ~/.ssh/id_rsa admin@192.168.1.1` | ✅ **работает** (перепроверено 2026-09-25). 🔴 Прежняя запись «SSH НЕ работает» **ошибочна** — она была получена при попытке входа под `root@`, который даёт `Connection closed` при **открытом** порту 22. Пользователь — `admin`. См. [[family/how-to/router-bishkek-asus]] |
|
||||
| HTPC `192.168.1.86` | `ssh -i ~/.ssh/id_rsa bazzite@192.168.1.86` | (не проверялся в этой сессии) |
|
||||
| TrueNAS | `ssh truenas_admin@mallexxx.duckdns.org` | ✅ работает |
|
||||
| OpenWrt `192.168.2.2` | `ssh root@192.168.2.2` (прямой, по ключу) | (не проверялся в этой сессии) |
|
||||
|
||||
Reference in new issue
Block a user