I am currently using the Morse Micro MM6108 HaLow in mesh mode.
I am looking a tool which monitors channel usage and occupancy. I found “OCS” Off Channel Scan comes with ‘morsectrl’ utility which temporarily switch to the off channel in question, and perform an assessment using the PHY channel metric.
I tried ocs commands but it throws error as below,
Unfortunately the ocs commands in morsectrl will only work when the device is in an AP mode. Reading the off channel scan report also requires the use of netlink to send and read the response of a specific vendor command. Let me know if you want more information on this.
I would have expected you to be able to perform scans on specific 802.11ac mapped channels (for example, with iw dev morse1 scan freq 5805) to build up survey data, and then read the information back with iw dev morse1 survey dump. This approach would cause a minor interruption to mesh connectivity.
Unfortunately this isn’t working in the 802.11s style mesh mode. I’ve raised this with the team.
I’ll update this thread if we identify a workaround for the scan approach. The chip firmware is collecting this data, it’s just not propagating up the stack.
Reading the off channel scan report also requires the use of netlink to send and read the response of a specific vendor command. Let me know if you want more information on this.
→ Can you share some information on this?
I would have expected you to be able to perform scans on specific 802.11ac mapped channels (for example, with iw dev morse1 scan freq 5805) to build up survey data, and then read the information back with iw dev morse1 survey dump. This approach would cause a minor interruption to mesh connectivity.
→ I tried this too in mesh mode but its only giving ‘channel active time’ and ‘channel receive time’.
Survey data from morse1
frequency: 5180 MHz
noise: -110 dBm
channel active time: 77 ms
channel receive time: 1 ms
It doesnt give ‘channel busy time’ stat like 802.11 n/ac.
Where can I find 802.11 ac to Halow frequency mapping?
There is a fairly simple channel mapping in the form of a csv file on our eval kits under /usr/share/morse-regdb/channels.csv. This is used by much of the OpenWrt user space tooling to unravel the 5g mapping.
The last column of that csv contains the 802.11ac mapped center channel. iw phy <phy> channels will let you map that center channel back to a frequency value.
Unfortunately we do not support the channel busy time metric. Historically this looks like it was implemented by Atheros chips. ACS in hostap falls back to use the channel RX time when the busy metric is unavailable.
Thanks @ajudge for the reply.
I could find CSV file in devkit and trying to get survey dump.
Can you please share information on below you mentioned for OCS ?
Reading the off channel scan report also requires the use of netlink to send and read the response of a specific vendor command. Let me know if you want more information on this.
As this tool does rely on libnl libraries and cross compilation. I found it easier to bundle it into a fairly empty OpenWrt feed to leverage the OpenWrt build system. You may choose to compile it however suits you. But feel free to follow the steps in the top level README for adding the repo to your OpenWrt feeds. Also see [OpenWrt Wiki] OpenWrt Feeds for specific information relating to OpenWrt feeds.
For your benefit, I kept most error handling and input validation to a minimum. I find this helps me better understand the fundamental structure and logic of a complex API like netlink without getting lost in the details of error handling. This does mean the tool is unsuitable for production use as-is. I highly encourage reviewing the source code and improving input validation and error handling throughout the source.
Usage example below:
root@ekh03-680889:~# ocs wlan0 922000 4 2 2
Triggering off-channel scan on wlan0 at 922000 kHz...
922000 kHz (bw: 4, pw: 2, pi: 2):
Listen time: 30847 us
RX time: 0 us
Noise: -88 dBm
Unfortunately, as mentioned earlier, off channel scan will only function when the device is in AP mode.
I have raised the request for mesh support internally with the team but am not able to provide a timeline for when it will be supported at this stage!
I will update this thread when I have more information I can share!
I took a look because I wanted to use this feature in mesh mode as well, but it looks like it’ll need to be a firmware level fix. morse_cmd_tx receives a ENOYOUMAYNOT back from the firmware when sending the command. +1 for requesting this feature as well.
I am testing your ocs implementation and it works with AP mode. But It needs Primary interface e.g wdev 0x1 to complete ocs. If AP mode is on secondary interface (anther virtual interface) e.g wdev 0x2 then it crashes the kernel.
I have gone through ocs src file and found ‘vif_id’ in ‘struct command_hdr’ which you’re not using anywhere. Does this cause an issue? If not what can be reason for the crash?
Crash logs:
`Triggering off-channel scan on m_ap0 at 910000 kHz…
[ 2111.362757] Unable to handle kernel read from unreadable memory at virtual address 0000000000000024
[ 2111.372014] Mem abort info:
[ 2111.374931] ESR = 0x0000000096000004
[ 2111.378902] EC = 0x25: DABT (current EL), IL = 32 bits
[ 2111.393833] SET = 0, FnV = 0
[ 2111.397084] EA = 0, S1PTW = 0
[ 2111.400326] FSC = 0x04: level 0 translation fault
[ 2111.405776] Data abort info:
[ 2111.408680] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 2111.414212] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 2111.419360] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 2111.424708] user pgtable: 4k pages, 48-bit VAs, pgdp=000000011dfbc000
[ 2111.431364] [0000000000000024] pgd=080000011df3d003, p4d=080000011df3d003, pud=080000011e457003, pmd=080000011ee06003, pte=0000000000000000
[ 2111.443936] Internal error: Oops: 0000000096000004 [#1] SMP
