Interesting. I don’t have that error, is it a particular client causing the issue or is it a difference in network design?
(no wifi, dawn installed, no adjustments to umdns)
| eth eth \
r7800 AP r7800 AP
Separate 5ghz SSID and 2.4ghz SSID, different channels
(dawn installed and wan added to umdns for both)
Dawn looks really nice. Still waiting for my 2nd access point to arrive to try it.
Does anyone know if 802.11r works well in mixed wifi vendor environments with openwrt?
E.g having a router with an aetheros chipset and a mediatek wifi one?
My 2 cents (I am not using DAWN at the moment). In my scenario, 802.11r works perfectly in an environment with WR841 (ath79) and Archer C2 - v1 (mediatek).
When the configuration is the same, no problems should arise at all.
A week or so ago I started looking at how to use the 802.11k+v features to help steer various devices around the house to the AP that can best support them at any given time. I thought I was going to write a few scripts to aggregate the current station / client status, process that on my most powerful AP (others are simple 4+32 devices) to look for "outliers" and then tell relevant APs what disassoc frames to send.
Every time I reach the next step I find myself back at this thread which seems to be the main resource for understanding various elements: neighbor report gathering and sharing, beacon requests, using hostapd to gather them, etc. My next step was to untangle the beacon report binary blob that hostapd dumps into the logs. And when I look for guidance on the structures used it brings me here again :)!
So it's looking like the best way forwards for me for now is to get DAWN up and running and see how close what it does is to what I want, and maybe contribute some changes if we have slightly different goals that can use the same lower level capabilities. For example, I can imagine that some will want to optimise use and stability of tens - hundreds APs in a large site, while others (like me :)) are more interested in client experience across a few lightly loaded APs.
I'm newish to OpenWRT dev, but have ported a few new devices (that are very similar to existing ones) into my local builds, backported packages to similar, etc. I'm a decent C coder having started my career working (perhaps ironically) on early comms infrastructure management. If I get things up and running let me know what ic an do to help nudge things forwards.
Yep, that RRM thread was very useful as well :). And I saw the hostapd-cli / subscription pieces and PRs. Basically all a part of the journey I was / am on.
I see the balance of AP vs client decision making as perhaps some form of top level policy: "AP loading", "client experience", "blended" that we could develop. We won't need lots of real APs - we can simulate that for the algorithms if needed. It'd be interesting to see if that can still be a distributed model for resilience and not creating too much management traffic going back to a central point - which would be ironic.
You can drop a lot of information with 802.11v and 802.11k and make the stuff "on-demand". All that management traffic I'm currently exchanging is because of legacy clients... If I switch to 802.11v, I can immediately decrease the complexity.
I was thinking of the overhead of all APs sending information back to a central decision making node in the 100s of AP case. It'd be silly if so much information was flying back and forwards that it was slowing things down. I don't think it would be so bad, but there are still reasons to think about a distributed model where you can just turn on 20-100 devices pre-configured to know about each other via (say) MAC address and let them self-organise for the target outcome.
It would be interesting to have different toggles in the dawn luci app to be able to turn on and off sections of the code. This would make your code a little more complicated but would be interesting.
As an example I have no legacy hardware on either band and no roaming devices on 2.4ghz - so I would toggle off all the legacy compatibility + 2.4 ghz mapping to optimize the setup for the best performance.
I could help with the luci page coding and descriptions if you’re interested:
I've added DAWN to the flashed in packages for my local builds. I'll play with it a bit to understand what it does and perhaps look over the code to help me. I have a few busy days ahead, but will be back when I can be.
Is there another discussion of DAWN somewhere on what situations it aims to support, backlog requests, etc?
So if client is reporting (say) RCPI = 100 (-60dBm) the AP connected to it could easily be saying -50dB to -70dB RSSI due to the inaccuracy, and perhaps that one end is broadcasting more power than the other. I think that last effect would tend to make the AP RSSI lower (more negative dB) than (converted) device RCPI as AP will be broadcasting stronger signal.
That looks like it roughly fits the Samsung data above. No idea what Apple are doing though...