The 802.11k standard specifies how the neighboring BSS' could report each other to a STA. OpenWRT's hostapd supports this feature, but the synchronization has to be done in a separate daemon such as this one.
It is more lightweight than DAWN (many thanks to Polynomdivision), basically it is based on this script How does rrm work? - #60 by ParanoidZoid although it is improved a bit so the neighbor report would include the other band interface for the same AP and some more fixes.
Tested on 20.02rc2 with 22 different AC1750. Using 802.11r configured roam over the air, and disabled the bss transition bit on the network it works like a charm. Walking with my 2,4GHz only phone wifiman show roaming well. My Arch based dual band laptop works even better. Cannot even notice that walking along the corridor my BSS changes nearly every second step.
I've plans to make a package from it and make it published as an ipk. I'll also add a sample config file for /etc/config/wireless so the whole test setup could be reconstructed.
I have it running across 4 AP's and it seems to handle the transition pretty smoothly. I noticed your repo lacks a sample wireless config, so I'm pasting the relevant bits from mine should anyone else want to give this a go.
For starters, each AP is configured as a "Dumb AP" according to the docs. I have also installed the following:
My time zone is explicitly specified so as to appear in the beacons although I've read in some threads this isn't necessary and would be handled automatically by hostapd. For that matter, I've read that 802.11v isn't required anymore either, but I've left it in anyway.
I've also disabled bss_transition and set FT to over-the-air as you indicated in your README.
Finally, I copied your rrm_nr scripts and started them up. This was running the latest rc4 of the 21.02 release.
This appears to be working, but aside from seeing FT skipping the handshake in the logs and my client roaming from one AP to the other as I walk about the space, I haven't done much else to prove it's working as designed.
Your seems to be right. I've updated the repo with my config file. (I've just recognized that the nasid is the same for the 2.4 GHz and the 5 GHz radio. I'm a bit uncertain if its good this way.)
Fixing umdns startap's seccomp section is also an issue in my devices.
As far as I know bss_transition should be disabled, since this package doesn't actively suggest roaming for the STAs.
For testing you can try ubus call hostapd.wlan0 rrm_nr_list. If it shows your other BSSes, than the daemon is working. You could try wifiman from Ubiquiti for eg. to test this on your android STA. Just connect to your AP at 2.4 GHz, and if the 5 GHz shows up immediately in the BSS list for the SSID, everything is okay. Getting the traffic with a laptop in monitoring mode and wireshark could also show what is in the air. The edge of this project is hostapd's nr_list. Capturing management traffic from the AP itself should also work.
@kissadamfkut This is a really slick tool! Thanks for putting it out there for others
I gave it a try yesterday and unfortunately hit an issue with the TXT record length given the number of SSIDs in my environment (details in the PR). So, I put together a PR with tested code that resolves this issue for me. Hopefully it can help others, too:
A secondary benefit to the proposed updates is that I switched to using a '+' as the delimiter instead of '|'. Therefore the previous known issue around not being able to use '|' in SSID names is resolved.
Sure thing! I'm excited to have stumbled on this thread and your project because I have been trying to find a good way to dynamically populate my WAP neighbors without using Dawn or Usteer. Very nice work!
FYI, I started another thread around umDNS and the hope that the latest commits in the mdnsd project get pulled into the OpenWrt branches soon. For anybody interested: Query, Fetch, and Browse with umDNS
If the latest commits get pulled in soon, the patch I included in the PR can be dropped.
I created another PR and welcome your review and testing of it prior to acceptance. It's a concept that came to mind as I was reviewing the code originally. Feel free to decline it if you feel it's not the right direction for your tool
UPDATE I am rethinking parts of this PR, so I have placed it in Draft for now.
This is a new PR that incorporates a few of the ready-to-go updates from PR#6. While I am mulling over that PR, I wanted to go ahead and bring forward some painless fixes:
Not to be cheeky, but static-neighbor-report is static and this script is dynamic. If someone desires to be more hands-on with their configuration of neighbor reporting, then static-neighbor-report is the better choice at the moment.
If, however, one desires to just start a service and let it do the work to dynamically create neighbor reports, then this script will do just that.