Dawn: a decentralized wireless controller

How do I setup DAWN so a few IoT devices won't get kicked off if there's only one AP providing 2.4GHz?

I have four dumb AP's. All provide the 5GHz band for wireless roaming of mobile client devices such as laptops, smartphones, tablets and so on. On one dumb AP I have also enabled the 2.4GHz band so IoT devices can connect to that particular dumb AP. Some of the IoT devices are Shelly devices and are stationary, so they don't move around the house.

How do I exclude those devices from being kicked? A Chromecast is also a nice example that is also stationary and thus doesn't move around the house.

Can I change some settings for example on the 2.4GHz band? Or perhaps is there a possibility to use whitelisting of MAC addresses so devices don't get kicked? I use the default DAWN config BTW.

I've got the following version installed:

root@ap-groundfloor:~# opkg info dawn                                                                                 │led
Package: dawn                                                                                                         │Tue Nov  1 07:52:13 2022 daemon.warn dawn: Client / BSSID = 76:03:EA:C7:25:A4 / A4:2B:B0:FA:AD:44: BEACON REQUEST fai
Version: 2022-07-24-9e8060ea-1                                                                                        │led
Depends: libc, libubus20220601, libubox20220515, libblobmsg-json20220515, libuci20130104, libgcrypt, libiwinfo20210430│Tue Nov  1 07:52:15 2022 daemon.warn dawn: Client / BSSID = 76:03:EA:C7:25:A4 / B0:7F:B9:F8:23:B0: BEACON REQUEST fai
, umdns                                                                                                               │led
Status: install user installed                                                                                        │Tue Nov  1 07:52:17 2022 daemon.warn dawn: Client / BSSID = 76:03:EA:C7:25:A4 / DC:EF:09:F2:76:02: BEACON REQUEST fai
Section: net                                                                                                          │led
Architecture: arm_cortex-a15_neon-vfpv4                                                                               │Tue Nov  1 07:52:32 2022 daemon.warn dawn: Client / BSSID = 76:03:EA:C7:25:A4 / 8C:3B:AD:2D:25:26: BEACON REQUEST fai
Size: 45218                                                                                                           │led
Filename: dawn_2022-07-24-9e8060ea-1_arm_cortex-a15_neon-vfpv4.ipk                                                    │Tue Nov  1 07:52:33 2022 daemon.warn dawn: Client / BSSID = 76:03:EA:C7:25:A4 / A4:2B:B0:FA:AD:44: BEACON REQUEST fai
Conffiles:                                                                                                            │led
 /etc/config/dawn 2260741f55e7b4cda2eda09cdd8ca466e1437144e03cd3fbf9736ae067c199af                                    │Tue Nov  1 07:52:35 2022 daemon.warn dawn: Client / BSSID = 76:03:EA:C7:25:A4 / B0:7F:B9:F8:23:B0: BEACON REQUEST fai
Description: This package implements a decentralized wireless daemon.                                                 │led
Installed-Time: 1663346813                                    
Current default DAWN config
config local
	option loglevel '0'

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 hostapd
	option hostapd_dir '/var/run/hostapd'

config times
	option con_timeout '60'
	option update_client '10'
	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 '20'

config metric 'global'
	option min_probe_count '3'
	option bandwidth_threshold '6'
	option use_station_count '0'
	option max_station_diff '1'
	option eval_probe_req '0'
	option eval_auth_req '0'
	option eval_assoc_req '0'
	option kicking '3'
	option kicking_threshold '20'
	option deny_auth_reason '1'
	option deny_assoc_reason '17'
	option min_number_to_kick '3'
	option chan_util_avg_period '3'
	option set_hostapd_nr '0'
	option duration '0'
	option rrm_mode 'pat'

config metric '802_11g'
	option initial_score '80'
	option ht_support '5'
	option vht_support '5'
	option no_ht_support '0'
	option no_vht_support '0'
	option rssi '15'
	option rssi_val '-60'
	option low_rssi_val '-80'
	option low_rssi '-15'
	option chan_util '0'
	option chan_util_val '140'
	option max_chan_util '-15'
	option max_chan_util_val '170'
	option rssi_weight '0'
	option rssi_center '-70'

config metric '802_11a'
	option initial_score '100'
	option ht_support '5'
	option vht_support '5'
	option no_ht_support '0'
	option no_vht_support '0'
	option rssi '15'
	option rssi_val '-60'
	option low_rssi_val '-80'
	option low_rssi '-15'
	option chan_util '0'
	option chan_util_val '140'
	option max_chan_util '-15'
	option max_chan_util_val '170'
	option rssi_weight '0'
	option rssi_center '-70'

I've read the configure section on GitHub but I'm not sure what I need to set for example those "legacy devices" under note 1.

For the record, we mostly have Apple devices on our WiFi network, occasionally there's an Android phone connected or a Nintendo Switch.

Apologies that I suddenly disappeared - a few events overtook my ability to stay engaged.

I'm not expecting to have much time to look at DAWN topics any time soon, but wanted to thank everyone who gave me ideas and support to add to the original work of @PolynomialDivision.

3 Likes

I am inexpecienced with DAWN, so it might be my suggestion cannot be implemented: have you tried either not managing the 2.4 wifi via DAWN or adding a non-managed secondary SSID to 2.4 wifi. To me it looks like the wrong direction, to first put a distributed management layer on top of everything and then adding even more complexity by adding opt-out exclusions in that layer. I would rather try to keep such opt-out devices on a different logical network config which is not managed

Now... why didn't I think of that? I guess I was to deeply focused in the matter I overlooked this completely. I used to have the SSID for my client devices such as laptop, smartphone and tablet roam freely on both 2.4GHz and 5GHz radios on all dumb AP's. But I recently moved all my client devices to strictly 5GHz radios and use 2.4GHz on only one dumb AP that is serving all the IoT devices.

Well, thank you :smile:

Hello,
A very newbie question. I am using DAWN 2022-07-24-9e8060ea-1 on OpenWrt SNAPSHOT, r21380-5429411f73, installed on Banana PI R3. I have one 2.4GHz and one 5GHz radios that I would like clients to switch between. I have wpad-openssl installed, but I have only bss_transition_request option. According to the documentation in this situation DAWN would use Absolute RSSI algorithm. However it seems DAWN is not able to kick the clients. If I manually do bss_transition_request, then the client responds and switch to the other frequency. Any idea what do I do wrong or how to configure better?

root@R3pi:~# ubus -v list hostapd.phy0-ap0
'hostapd.phy0-ap0' @a36d1cb0
        "reload":{}
        "get_clients":{}
        "get_status":{}
        "del_client":{"addr":"String","reason":"Integer","deauth":"Boolean","ban_time":"Integer"}
        "update_airtime":{"sta":"String","weight":"Integer"}
        "list_bans":{}
        "wps_start":{}
        "wps_status":{}
        "wps_cancel":{}
        "update_beacon":{}
        "get_features":{}
        "switch_chan":{"freq":"Integer","bcn_count":"Integer","center_freq1":"Integer","center_freq2":"Integer","bandwidth":"Integer","sec_channel_offset":"Integer","ht":"Boolean","vht":"Boolean","he":"Boolean","block_tx":"Boolean","force":"Boolean"}
        "set_vendor_elements":{"vendor_elements":"String"}
        "notify_response":{"notify_response":"Integer"}
        "bss_mgmt_enable":{"neighbor_report":"Boolean","beacon_report":"Boolean","link_measurement":"Boolean","bss_transition":"Boolean"}
        "rrm_nr_get_own":{}
        "rrm_nr_list":{}
        "rrm_nr_set":{"list":"Array"}
        "rrm_beacon_req":{"addr":"String","mode":"Integer","op_class":"Integer","channel":"Integer","duration":"Integer","bssid":"String","ssid":"String"}
        "link_measurement_req":{"addr":"String","tx-power-used":"Integer","tx-power-max":"Integer"}
        "bss_transition_request":{"addr":"String","disassociation_imminent":"Boolean","disassociation_timer":"Integer","validity_period":"Integer","neighbors":"Array","abridged":"Boolean","dialog_token":"Integer","mbo_reason":"Integer","cell_pref":"Integer","reassoc_delay":"Integer"}

And here is my DAWN configuration:

config local
	option loglevel '2'

config network
	option broadcast_ip '192.168.1.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 hostapd
	option hostapd_dir '/var/run/hostapd'

config times
	option con_timeout '60'
	option update_client '10'
	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 '20'

config metric 'global'
	option min_probe_count '3'
	option bandwidth_threshold '180'
	option use_station_count '0'
	option max_station_diff '1'
	option eval_probe_req '0'
	option eval_auth_req '0'
	option eval_assoc_req '0'
	option kicking '2'
	option kicking_threshold '9'
	option deny_auth_reason '1'
	option deny_assoc_reason '17'
	option min_number_to_kick '3'
	option chan_util_avg_period '3'
	option set_hostapd_nr '0'
	option duration '0'
	option rrm_mode 'pat'

config metric '802_11g'
	option initial_score '80'
	option ht_support '5'
	option vht_support '5'
	option no_ht_support '0'
	option no_vht_support '0'
	option rssi '0'
	option rssi_val '0'
	option low_rssi_val '0'
	option low_rssi '0'
	option chan_util '0'
	option chan_util_val '140'
	option max_chan_util '-15'
	option max_chan_util_val '170'
	option rssi_weight '0'
	option rssi_center '-20'

config metric '802_11a'
	option initial_score '100'
	option ht_support '5'
	option vht_support '5'
	option no_ht_support '0'
	option no_vht_support '0'
	option rssi '0'
	option rssi_val '0'
	option low_rssi_val '0'
	option low_rssi '0'
	option chan_util '0'
	option chan_util_val '140'
	option max_chan_util '-15'
	option max_chan_util_val '170'
	option rssi_weight '0'
	option rssi_center '-100'

Some log output of DAWN when it tries to kick a client:

Tue Dec  6 19:20:11 2022 daemon.info dawn: RSSI PROBE used to update client / BSSID = 4A:37:51:D0:B7:4D / 00:0C:43:26:60:00
Tue Dec  6 19:20:11 2022 daemon.info dawn: Client 4A:37:51:D0:B7:4D: Low asolute RSSI - proposing other APs
Tue Dec  6 19:20:11 2022 daemon.info dawn: Client 4A:37:51:D0:B7:4D: Kicking due to low active data transfer: RX rate 24.000000 below 180 limit
Tue Dec  6 19:20:11 2022 daemon.debug dawn: bssid_addr: 00:0C:43:26:60:00, client_addr: 4A:37:51:D0:B7:4D, freq: 2412, ht_supported: 1, vht_supported: 0, ht: 1, vht: 0, kick: 3
Tue Dec  6 19:20:11 2022 daemon.notice hostapd: phy0-ap0: BSS-TM-RESP 4a:37:51:d0:b7:4d status_code=1 bss_termination_delay=0
Tue Dec  6 19:20:11 2022 daemon.notice hostapd: phy0-ap0: BEACON-REQ-TX-STATUS 4a:37:51:d0:b7:4d 169 ack=1
Tue Dec  6 19:20:11 2022 daemon.debug dawn: hostapd sent bss-transition-response = {"address":"4a:37:51:d0:b7:4d","dialog-token":true,"status-code":true,"bss-termination-delay":false}
Tue Dec  6 19:20:11 2022 daemon.notice hostapd: phy0-ap0: BSS-TM-RESP 4a:37:51:d0:b7:4d status_code=1 bss_termination_delay=0
Tue Dec  6 19:20:11 2022 daemon.debug dawn: hostapd sent bss-transition-response = {"address":"4a:37:51:d0:b7:4d","dialog-token":true,"status-code":true,"bss-termination-delay":false}
Tue Dec  6 19:20:11 2022 daemon.notice hostapd: phy0-ap0: BEACON-RESP-RX 4a:37:51:d0:b7:4d 169 04
Tue Dec  6 19:20:21 2022 daemon.info dawn: RSSI PROBE used to update client / BSSID = 4A:37:51:D0:B7:4D / 00:0C:43:26:60:00
Tue Dec  6 19:20:21 2022 daemon.info dawn: Client 4A:37:51:D0:B7:4D: Low asolute RSSI - proposing other APs
Tue Dec  6 19:20:21 2022 daemon.info dawn: Client 4A:37:51:D0:B7:4D: Kicking due to low active data transfer: RX rate 24.000000 below 180 limit
Tue Dec  6 19:20:21 2022 daemon.debug dawn: bssid_addr: 00:0C:43:26:60:00, client_addr: 4A:37:51:D0:B7:4D, freq: 2412, ht_supported: 1, vht_supported: 0, ht: 1, vht: 0, kick: 4
Tue Dec  6 19:20:21 2022 daemon.notice hostapd: phy0-ap0: BEACON-REQ-TX-STATUS 4a:37:51:d0:b7:4d 173 ack=1

And this is the response, when I try to send the transition request manually:

root@R3pi:~# ubus call hostapd.phy0-ap0 bss_transition_request '{"addr":"4A:37:51:D0:B7:4D"}'
----
root@R3pi:~# logread -f | grep -i 4A:37:51:D0:B7:4D
Tue Dec  6 20:22:18 2022 daemon.notice hostapd: phy0-ap0: BSS-TM-RESP 4a:37:51:d0:b7:4d status_code=0 bss_termination_delay=0 target_bssid=82:0c:43:26:60:00
Tue Dec  6 20:22:18 2022 daemon.info hostapd: phy1-ap0: STA 4a:37:51:d0:b7:4d IEEE 802.11: associated (aid 4)
Tue Dec  6 20:22:18 2022 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED 4a:37:51:d0:b7:4d auth_alg=ft
Tue Dec  6 20:22:18 2022 daemon.notice hostapd: phy0-ap0: Prune association for 4a:37:51:d0:b7:4d
Tue Dec  6 20:22:18 2022 daemon.notice hostapd: phy0-ap0: AP-STA-DISCONNECTED 4a:37:51:d0:b7:4d
Tue Dec  6 20:22:19 2022 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED 4a:37:51:d0:b7:4d
Tue Dec  6 20:22:19 2022 daemon.info hostapd: phy1-ap0: STA 4a:37:51:d0:b7:4d IEEE 802.11: associated (aid 4)
Tue Dec  6 20:22:19 2022 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED 4a:37:51:d0:b7:4d auth_alg=ft
Tue Dec  6 20:22:19 2022 daemon.notice hostapd: phy0-ap0: Prune association for 4a:37:51:d0:b7:4d
Tue Dec  6 20:22:19 2022 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED 4a:37:51:d0:b7:4d
Tue Dec  6 20:22:19 2022 daemon.info hostapd: phy1-ap0: STA 4a:37:51:d0:b7:4d IEEE 802.11: associated (aid 4)
Tue Dec  6 20:22:19 2022 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED 4a:37:51:d0:b7:4d auth_alg=ft
Tue Dec  6 20:22:19 2022 daemon.notice hostapd: phy0-ap0: Prune association for 4a:37:51:d0:b7:4d

Hello,

I think your problem comes from parameter 'duration' set to 0. Most devices don't like this parameter to be 0 and won't do anything in this case.
Please try to set it to a non 0 value (10 for example) and retry.

5 Likes

Hi Elmer,
You were absolutely right. That was the reason. Thanks a lot! :upside_down_face:

Hello again,
It seems I stumbled upon another problem. In the hearing map I constantly get 0 RSSI for a given radio and no kicking is hapening, although the device is very close to the AP itself. This behaviour is observed with a Android phone and also Windows machine, so I cannot relate it to a device.


Is there anything I can change to have a workaround of this?

I have several AP 2.4+5GHz.
No problem giving priority to 5GHz.
But some AP have less uplink bandwidth than the other.
How to give priority to one AP (all 5 GHz) for the same signal level ?
There was a deprecated parameter 'ap_weight'. It looked like what I need.

But now, how to achieve AP prioritization ?

I've actually 8 APs at home (big home, yes) of which 4 are from a "big brand" and the other 4 are OpenWRT enabled. All them support 5G, 2G and WIFI ax...

I'm interested in forming a single SSID with smooth roaming enabled.

The problem:
APs from the "big brand" are not 802.11r enabled (they don't announce a Mobility Domain) but they work relatively well. I can see they implemented "Neighbor Report" and "Link Measurement"

For the other APs with OpenWRT I enabled DAWN but, there is no "Link Measurement" and I don't know how to give priority to 5G over 2G and roaming is not as good as in the other group of APs

Another interesting thing is this:

root@chiton-ap1:~# ubus call hostapd.wlan0 rrm_nr_list
{
	"list": [

	]
}

Shall it be always empty?

I need some help to move forward.

Thanks in advance!

For the empty list in rrm_nr_list, that's because you have option set_hostapd_nr '0'. Set it to '2'.

1 Like

Hello @patrakov

Thank you! Indeed, that fixed the issue. I also installed DAWN https://openwrt.org/docs/guide-user/network/wifi/dawn to properly distribute the information among the other APs. The issue with the "Link Measurement" is still not resolved and I couldn't find information about if it is supported at all in OpenWRT.

Happy 2023!

Hi folks. What is the actual installation tutorial? Both of the differ very much.

A) https://openwrt.org/docs/guide-user/network/wifi/dawn
B) https://github.com/berlin-open-wireless-lab/DAWN/blob/master/INSTALL.md

A) only shows wpad as installed package
B) Wants wpad-wolfssl and wpad-openssl

Configuration HowTo is also different.

I am using a TP-Link Archer C7 v4 with OpenWrt 22.03.2 r19803-9a599fee93 / LuCI openwrt-22.03 branch git-22.361.69894-438c598

I think you will have to use a combination of two :slight_smile:
Wiki is OK, please follow guidance (especially regarding Wifi configuration)
Dawn install.md is providing details regarding wpad package to install (Wiki is only saying "install the full version of wpad"):

opkg update
opkg remove wpad-basic wpad-mini
# Use one of the following, or similar
opkg install wpad-wolfssl
opkg install wpad-openssl

You have to use wpad-wolfssl OR wpad-openssl not both.
wpad-wolfssl is the one to be used in your case.

I have questions regarding Resetting DAWN's Configuration from the install.md

Backup current config

cd /etc/config
mv dawn dawn.old

Remove current config

vi dawn # Delete all 'config metric' and 'config times' sections

Save and exit vi

On another DAWN instance

ubus call dawn reload_config

  1. Is it still actual?
  2. I expect the mv command is wrong, must be cp
  3. Do I have to delete 'config metric' and 'config times'
  4. How comes the Wiki has no informations about openssl/wolfssl and deleted sections in dawn config and install.md no informations about the wireless config changes? There is no chance to set dawn up for anyone not involved.

I've changed this on my two AP setup which operate on both 2.4GHz and 5GHz (so both wlan0 and wlan1), there's a neighbour list (of one as expected) on one of the networks on one of the APs, but not on any of the other three which show up empty. I've taken a look at umdns and each AP has a corresponding record for the other one.

Have you set the broadcast IP correctly in the config file?

Yes, both set to the same thing (and correct). Actually it turns out what I'm seeing is that one of the neighbour lists is always populated. The other three are sporadic. They are populated for short periods of time, and then there are longer periods of time when they are empty. There's no evidence of packet loss, and there should be plenty of bandwidth between the two APs.

Check time synchronization. Not sure if it will help, but...

ntpd -d -q -n -p 0.openwrt.pool.ntp.org

Yeah, they are both setup using chrony and within ms of each other.

2 Likes