Dawn: a decentralized wireless controller

Community Builds, Projects & Packages
62

With the latest snapshot build of OpenWrt + Dawn on all of my routers (just two in total to be exact), plus the knowledge I have accumulated over the past two weeks or so particularly hostapd's ubus wnm_disassoc_imminent method, I can now consistently reproduce an issue with Dawn. I thought of opening an issue on GitHub, but this is such a basic core feature of Dawn that really shouldn't be failing so I am writing here first for @PolymomialDivision to see if I have overlooked anything first before filing a bug report.

Here is the crux of the issue: I cannot get Dawn to send out any wnm_disassoc_imminent command whatsoever.

  1. I have option kicking set to '1' on both of my routers.

  2. I can see the other AP with ubus call hostapd.wlan0-1 rrm_nr_list. So the neighbor list has been appropriately populated. I can also see both routers on "Network Overview" on luci interface with devices connected to each.

  3. I make sure my device (will expose the MAC addresses for the sake of clarity, fingers crossed no actual damage will be done by exposing MAC addresses) 9C:BC:F0:A1:10:B7 responds to roaming instructions by manually constructing and sending wnm_disassoc_imminent requests to the device. Sure enough each time it responds by switching to the other AP, plus I see a line like hostapd: wlan0-1: BSS-TM-RESP 9c:bc:f0:a1:10:b7 status_code=0 bss_termination_delay=0 target_bssid=10:6f:3f:3d:67:64 in syslog.

  4. I then make sure the device 9C:BC:F0:A1:10:B7 is connected to router 10:6F:3F:3D:6E:8D, and move the device to a place where 10:6F:3F:3D:6E:8D's signal is weaker than 10:6F:3F:3D:67:64.

  5. Check LUCI's Dawn Hearing Map, and it shows (appropriately) that 10:6F:3F:3D:6E:8D has a score 20 plus points lower than that of 10:6F:3F:3D:67:64, like so

Dawn_possible_bug
Dawn_possible_bug1406×167 12.6 KB

  1. Waited until I ran out of patience. Device is still connected to 10:6F:3F:3D:6E:8D and no sign of moving to 10:6F:3F:3D:67:64.

  2. Checked syslog. I do not see any BSS-TM-RESP message other than the ones that I have triggered manually like in step 3 above. This to me means Dawn is not generating any wnm_disassoc_imminent like it should not only for 9C:BC:F0:A1:10:B7, but for any of my other devices that are connected to my network as well that are eligible for switching according to the Hearing Map.

Like I said, I feel this is such a trivial function of Dawn to be able to issue wnm_disassoc_imminent messages, I am really surprised to find out zero BSS-TM-RESP syslog messages are appearing in either of my two routers. I am hesitant to file a bug at this stage... could very well be something that I have overlooked?

(note: I see lots of other Dawn-related hostapd logs like BEACON-REQ-TX-STATUS and BEACON-RESP-RX. I stop Dawn and these logs stop getting generated. So I think Dawn is functional)

1 Like
63

Thanks for all your great documentation and bug reports. I will later answer on it in more detail. Just to be sure DAWN is sending out wnm_disassoc_imminent you can just use "ubus monitor" to see if DAWN actually sends requests to hostapd over the bus.

And we already have debug messages. If you enable stdout in dawn-procd file you should also see those messages:

1 Like
64

Btw reading the discussion here, I have also enabled "kicking" with DAWN and changed min RSSI to 70dB still some clients are hanging to original AP even when stronger AP exists, while they report between 75-79dB...

config network
        option broadcast_ip '10.0.0.255'
        option broadcast_port '1025'
        option tcp_port '1026'
        option network_option '2'
        option shared_key 'Niiiiiiiiiiiiick'
        option iv 'Niiiiiiiiiiiiick'
        option use_symm_enc '0'
        option collision_domain '-1'
        option bandwidth '-1'

config ordering
        option sort_order 'cbfs'

config hostapd
        option hostapd_dir '/var/run/hostapd'

config times
        option update_client '10'
        option denied_req_threshold '30'
        option remove_client '15'
        option remove_probe '30'
        option remove_ap '460'
        option update_hostapd '10'
        option update_tcp_con '10'
        option update_chan_util '5'
        option update_beacon_reports '600'

config metric 'global'
        option rssi_weight '0'
        option rssi_center '0'
        option initial_score '0'
        option kicking_threshold '20'
        option duration '600'
        option rrm_mode 'apt'
        option ap_weight '0'
        option ht_support '0'
        option vht_support '0'
        option no_ht_support '0'
        option no_vht_support '0'
        option rssi '0'
        option low_rssi '0'
        option freq '0'
        option chan_util '0'
        option max_chan_util '0'
        option rssi_val '-60'
        option low_rssi_val '-75'
        option chan_util_val '0'
        option max_chan_util_val '0'
        option min_probe_count '0'
        option bandwidth_threshold '6'
        option use_station_count '0'
        option max_station_diff '0'
        option eval_probe_req '1'
        option eval_auth_req '1'
        option eval_assoc_req '1'
        option deny_auth_reason '1'
        option deny_assoc_reason '17'
        option use_driver_recog '1'
        option chan_util_avg_period '3'
        option set_hostapd_nr '1'
        option kicking '1'

config metric '802_11a'
        option rssi_weight '2'
        option rssi_center '-70'
        option initial_score '125'

config metric '802_11g'
        option rssi_weight '2'
        option rssi_center '-70'
        option initial_score '100'

Any idea why it's not kicked out and roam to another AP ? When I disconnect it manually, it immediately connects to other AP (on hearing map I see both APs), with Debug enabled I don't see roaming happening however.
Shall I further decrease option low_rssi_val or adjust other parameter ? Thank you.

65

Yet another observation that I'd like to bring to your attention.

(Dawn has no direct control over this, but...)

I have discovered the wnm_disassoc_imminent actually makes my Android phone's wifi performance much worse after a transition induced by it (bandwidth reduced to less than 30% of usual). My Apple "burner phone" doesn't seem to be impacted however. Problem reproducible every time.

I then tried the other methods exposed by hostapd, namely del_client and even the newest bss_transition_request. Of the three, only del_client allows my phone to retain its normal bandwidth after connecting to another AP.

(bss_transition_request downright doesn't work. After several transitions it totally breaks down. Clients disconnect before reconnecting to another AP).

I realize using del_client would mean sacrificing fast transition 802.11r (observed from my testing). But at least my phone still doesn't lose connection altogether during roaming, and I don't have to deal with reduced bandwidth.

So for now I won't be experimenting with Dawn anymore unfortunately. Will definitely keep an eye on further developments plus possibly improvements on hostapd so it will be compatible with (my model of) Android phones. I truly think Dawn has huge potential, when it becomes 100% stable and functional.

(for those interested, this tool does make use of del_client: Wi-Fi roaming recipe)

Edit 7 days later - I have since discovered that my Android phone does not play well with Openwrt's 802.11r. So I disabled it, and wnm_disassoc_imminent no longer makes an impact on my phone's data throughput anymore. So the culprit seems to be 802.11r and not wnm_disassoc_imminent. Also, I collaborated with the author of wifi-disconnect-low-signal (i.e. the tool I mentioned that's in this link: Wi-Fi roaming receipe) so now it makes use of wnm_disassoc_imminent instead of del_client. With it my wifi roaming solution is finally complete at least for now. Of course it is primitive compared with Dawn, but until Dawn can actually "kick" clients to other APs, I will stick with my current solution.

1 Like
66

I have noticed that there is no Settings menu item in DAWN menu in Luci in the latest snapshot realease, is it normal ? Settings for dawn were present previousely in luci

67

To be abandoned the LuCI app.

68

I try once more even nobody answered on my first question but anyway, I have two identical APs configs (HW wise it's Ubiquiti UniFi AC Lite and Ubiquiti UniFi AC Pro) and on AC Pro variant, I'm getting following error in the log quite often.

Tue Dec  7 20:51:46 2021 daemon.err dawn[15643]: Neighbor-Report is NULL!
Tue Dec  7 20:54:11 2021 daemon.err dawn[15643]: Neighbor-Report is NULL!
Tue Dec  7 20:54:11 2021 daemon.err dawn[15643]: Neighbor-Report is NULL!
Tue Dec  7 20:54:11 2021 daemon.err dawn[15643]: Neighbor-Report is NULL!
Tue Dec  7 20:55:37 2021 daemon.err dawn[15643]: Neighbor-Report is NULL!
Tue Dec  7 20:55:37 2021 daemon.err dawn[15643]: Neighbor-Report is NULL!
Tue Dec  7 20:55:44 2021 daemon.err dawn[15643]: Neighbor-Report is NULL!
Tue Dec  7 20:55:44 2021 daemon.err dawn[15643]: Neighbor-Report is NULL!
Tue Dec  7 20:56:19 2021 daemon.err dawn[15643]: Neighbor-Report is NULL!
Tue Dec  7 20:57:32 2021 daemon.err dawn[15643]: Neighbor-Report is NULL!
Tue Dec  7 20:57:32 2021 daemon.err dawn[15643]: Neighbor-Report is NULL!
Tue Dec  7 20:59:14 2021 daemon.err dawn[15643]: Neighbor-Report is NULL!
Tue Dec  7 21:00:53 2021 daemon.err dawn[15643]: Neighbor-Report is NULL!

Any idea what's wrong please ?

69

Just wanted to put this here in case others hit the same issue; It seems the root cause of Dawn not working (for some?) including myself out of the box, and throwing the below error:

daemon.err dawn[1111]: Failed to look up test object for umdns

was identified in this ticket as missing seccomp dependency in the builds.

The issue would be that Dawn would not be aware of the other Access Points also running Dawn (empty list, etc). Prior to this bit of info, I had the following command in my cron which worked around the issue:

*/5 * * * * test -f /etc/seccomp/umdns.json && rm /etc/seccomp/umdns.json; sync; /etc/init.d/umdns restart

Once i installed procd-seccomp, removed the above cron command, and restarted the Access Points, as soon as each came up, it could see the others.

@PolynomialDivision the user friendlier until upstream fixes things / defensive coding solution out of the box may be (as noted in the ticket), if Dawn either added procd-seccomp as a dependency, and/or Dawn does a validation to see if it's installed at runtime.

2 Likes
70

Thanks for the heads up. This fixed my issue.

72

@Edrikk Are you testing on master, or openwrt 21.02?

73

Okay, this should be already fixed by:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=520403cd4978fd2e3cca389e5009ca5c0ac26db9

or in 21.02:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=520403cd4978fd2e3cca389e5009ca5c0ac26db9

Please use Openwrt-Snapshot-21.02 or master builds and test again:
https://downloads.openwrt.org/releases/21.02-SNAPSHOT/targets/

74

Awesome will do.

I’m new to OpenWRT (main router is Tomato) so still on stable builds 21.02 while learning.

And thank you!

Edit: I just noticed that patch was from Nov 2020. Which I believe would have already been in the first release of 21.02. Am I misunderstanding? Because if that’s the case, the patch either didn’t capture all scenarios, or the DAWN specific dependencies patch may still be needed.

75

I was doing some pre-push testing of a revised logging approach, and seem to have stumbled across a potentially significant bug in the main tree.

I'm not really sure how kicking clients to better APs can have been working for anyone with this error - so I'm posting this partly to see if I'm misunderstanding something :slight_smile:. In my testing this week as I wander around the house I was always seeing a "No active transmission data for client. Don't kick!" message for my phone. Thinking that this was wrong I tracked down the apparent error and once changed I do now get sensible kicking.

It's caused by a change I made in June 2020: https://github.com/berlin-open-wireless-lab/DAWN/commit/67c3ed0d0aba4f9a55da32ded854d223e8e06e74.

In kick_clients() there was a test:

 float rx_rate, tx_rate;
 if (get_bandwidth_iwinfo(client_array[j].client_addr, &rx_rate, &tx_rate)) {
    // only use rx_rate for indicating if transmission is going on

which I changed to this, to add a bit more tracing info:

float rx_rate, tx_rate;
if (get_bandwidth_iwinfo(client_array[j].client_addr, &rx_rate, &tx_rate)) {
    printf("No active transmission data for client. Don't kick!\n");
}
else
{
    // only use rx_rate for indicating if transmission is going on

The mistake is that I didn't add a ! operator to keep the if / else sense correct. Although the code here has changed more since July 2020 it seems that the inverted logic that I added has been preserved.

Adding the negation to the current code made it work for me, changing:

bool have_bandwidth_iwinfo =
    !(get_bandwidth_iwinfo(j->client_addr, &rx_rate, &tx_rate));

to

bool have_bandwidth_iwinfo =
    get_bandwidth_iwinfo(j->client_addr, &rx_rate, &tx_rate);

The "natural reading" of this also makes more sense, since get_bandwidth_iwinfo() returns 1 if it gets the data.

It's a part of the big PR I'm preparing for the logging approach, but wanted to mention it separately.

2 Likes
76

These messages are a side effect of turning on evaluation of probe, association and authentication requests via the three eval_... options set to '1' in your config. They are harmless, and just reflect a specific code path that is perhaps a little confused :slight_smile:.

I've been working on some revisions to logging, and these will be eliminated by that if it makes it into the core code.

2 Likes
77

Thank you - I was just wondering why it happens only on one of my AP and not on the 2nd one having exactly the same DAWN config...
Anyway, looking forward for new version, I would really like to have DAWN functional but it seems in my specific case it does so far nothing, even with default configs...haven't seen low RSSI clients being kicked out, haven't seen active roaming with detailed logs etc.

Some setup guide for noob like me would be awesome.

78

The bug I mention just above may be the reason you don't see kicking happening. If you turn on stdout logging in /etc/init.d/dawn and see the "No active transmission" message then I'd say it is.

To work around it for now you can try setting option bandwidth_threshold '0' in /etc/config/dawn. it will avoid that specific bug. You might hit something else :frowning:, but hopefully not.

3 Likes
79

Heyho, @IanC published a lot of changes. :slight_smile: Thanks a lot.

I would be happy, if multiple people could test and review:

80

So far it's looking fine...

obrazek

I saw even some attempts for kicking but it was denied due to the ongoing data transfer.

Btw I'm using config with disabled evaluations (not sure it still somehow make difference)

2 Likes
81

Hopefully you will some device being kicked as well. If not then there may still be a path that stops them when it shouldn't.

I think this is fine. I see these as "advanced" steering to try and stop a client connecting if it could be using a different AP. Allowing it to connect (by disabling evaluation of those requests) and then letting it be kicked should be OK. From a pragmatic point of view ensuring the new code base works for kicking and then starting to check other features in more detail works for me.

EDIT: But it should be equally fine to use those if you want to :slight_smile:

1 Like
82

Thank you, I will be checking more, so far I see following I don't understand :
kickcount 1 below threshold of 3!
Any idea please what is meaning of it ? Is it due to the settings or it didn't reach certain level yet...

And also I see this quite often - and often with the same value, which is suspicious...

Client is probably in active transmisison. Don't kick! RxRate is: 6.000000

obrazek
obrazek1513×587 69.9 KB