wifi: move hAP 5GHz from ch 149 to ch 36, fix doc drift

Channel 149 (UNII-3) is not permitted in Bulgaria/EU. The radio reached it
via country=United States, but BG-domain clients were power-restricted
there, giving a badly asymmetric link and ~38 Mbps at the desk.

Moving to 5180 MHz (ch 36), legal in BG and non-DFS, raised the same
client to ~241 Mbps.

Also corrected:
- CAP capdp datapath is vlan-id=30, not 40
- RouterOS versions: hAP, cAP XL and cAP AC are all on 7.23.3
- Added WAN baseline: ~880 Mbps down / ~720 Mbps up on a 1 Gbps ONT link

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Kaloyan DanchevandClaude Opus 5 committed 2026-09-27 16:55:29 +03:00
1 parent c2c7ffad1b
commit 1fba4673be
2 files changed
+31 -6

No files matched your search

+2 -2
View File
@@ -14,7 +14,7 @@
| **Location** | 19" Rack U3 (on shelf) |
| **IP** | 192.168.10.1 |
| **MAC** | 78:9A:18:2C:A5:48 |
| **OS** | RouterOS 7.20.6 |
| **OS** | RouterOS 7.23.3 |
| **Serial** | - |
**Ports:**
@@ -77,7 +77,7 @@
| **Location** | Corridor (ceiling) |
| **IP** | 192.168.10.2 |
| **MAC** | 18:FD:74:54:3D:BC |
| **OS** | RouterOS 7.21.1 |
| **OS** | RouterOS 7.23.3 |
| **Serial** | HCT085KBH8B |
| **SSH** | `ssh -i ~/.ssh/mikrotik_key -p 2222 xtrm@192.168.10.2` |
+29 -4
View File
@@ -23,7 +23,7 @@
| SSID | XTRM |
| Band | 5GHz |
| Mode | 802.11ax (WiFi 6) |
| Channel | 5745 MHz (ch 149) |
| Channel | 5180 MHz (ch 36) |
| Width | 20/40/80MHz |
| Security | WPA2-PSK + WPA3-PSK |
| Cipher | CCMP (AES) |
@@ -107,10 +107,10 @@ If devices still can't connect, use WPA-only with TKIP-only:
|---------|-------|
| caps-man-addresses | 192.168.10.1 |
| discovery-interfaces | bridgeLocal |
| slaves-datapath | capdp (bridge=bridgeLocal, vlan-id=40) |
| slaves-datapath | capdp (bridge=bridgeLocal, vlan-id=30) |
| Traffic processing | **On CAP only** (wifi-qcom-ac driver limitation) |
| certificate | request |
| RouterOS | 7.21.3 |
| RouterOS | 7.23.3 |
| SSH Port | 2222 |
| SSH (via proxy) | See ProxyJump command below |
@@ -168,7 +168,7 @@ The CAP runs bridge VLAN filtering to properly tag/untag WiFi client traffic bef
| 31 | C8:5C:CC:40:B4:AA | Xiaomi Air Purifier 2 | 30 |
| 32 | (any) | Default - VLAN40 | 40 (catch-all) |
**Default behavior:** Devices not in the access list get VLAN 40 (CatchAll) via the default rule and the datapath `vlan-id=40`.
**Default behavior:** Devices not in the access list get VLAN 40 (CatchAll) via the default rule. CAP clients instead take the CAP-side `capdp` datapath, which is **`vlan-id=30`** (verified live 2026-09-27).
### Show Full Access List
@@ -235,3 +235,28 @@ Per-client VLAN does not work on CAP — the cAP XL ac uses wifi-qcom-ac drivers
/interface wifi capsman print
/interface wifi capsman remote-cap print
```
---
## 5GHz Channel Change (2026-09-27)
`wifi1` (hAP 5GHz) moved from **5745 MHz (ch 149)** to **5180 MHz (ch 36)**.
Channel 149 sits in UNII-3, which is not permitted for Wi-Fi in Bulgaria/EU. The radio ran with `country=United States` to reach it. Clients in the BG regulatory domain were power-restricted there, producing a badly asymmetric link and very low throughput.
| Metric | Before (ch 149) | After (ch 36) |
|--------|-----------------|---------------|
| MacBook Wi-Fi download | ~38 Mbps | **~241 Mbps** |
| Client transmit rate | 17 Mbps (MCS 1) | 204-272 Mbps (MCS 2) |
| Signal at AP | -86 dBm | -86 dBm (unchanged; channel was the limit) |
Channel 36 is legal in BG and non-DFS, so `skip-dfs-channels=all` still applies.
### WAN baseline (2026-09-27)
Measured on `ether1` with real traffic from Unraid: **~880 Mbps down / ~720 Mbps up**. The 2.5G WAN port negotiates at 1 Gbps because the Vivacom ONT only advertises `1G-baseT-full`. No queues are configured, so nothing local shapes traffic.
### CAP 5GHz tested and reverted
`cap-wifi1` (cAP XL, corridor ceiling) was enabled to test desk coverage. It was not audible from the desk and was reverted to disabled. A datapath with `vlan-id=20` returned `vlan-id configured, but interface does not support assigning vlans`, re-confirming that wifi-qcom-ac CAPs cannot do per-interface VLAN assignment.