Can you try increasing this value?
1 Like
Both of those are normal.
Rather than kick a client the first time it dips below the target DAWN waits for consecutive 3 (or as config) times to ensure it really has moved away. So you should see 1, 2 and then kick. Or 1, (possibly 2) then "best AP" which will reset the count and not disrupt the session.
RxRate is a guide as to whether a device would be kicked in the middle of downloading data. If the device is not busy that rate can come down to ~1.0. If you prefer strong connections with some interruption as you wander around watching Netflix then set the rate higher.
1 Like
Actually I do have it set to 0 already.
option bandwidth_threshold '0'
...and actually I got even kick confirmation which confirms it takes current value...so maybe there is indeed a glitch
Thu Jan 6 22:29:23 2022 daemon.info dawn[3429]: Station xx:xx:xx:43:DF:FD: Kicking as no active transmission data for client, but bandwidth_threshold=0 is OK.
That is clear to me...I was just wondering, that's it's interesting coincidence it's almost always "6.000" ?
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 '1'
option vht_support '1'
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 '0'
option use_station_count '0'
option max_station_diff '0'
option eval_probe_req '0'
option eval_auth_req '0'
option eval_assoc_req '0'
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'
config local
option loglevel '1'
**reason for edit ** - I thought my config got truncated but I just didn't scroll terminal ... 
Btw, looking on this condition, is this right when option bandwidth_threshold is actually '0' - it's always true, or ?
I don't think it should be 0 by default. Did you set it that way a few days ago when I said this to work around the bug that was there until fixed in the most recent updates?
2 Likes
Try setting it higher than 6. Maybe in your settings the RX-Rate will not go to 1.
1 Like
Probably yes but I'm on the latest version from you - https://github.com/berlin-open-wireless-lab/DAWN/pull/158, I thought this has been fixed ? So basically it means to avoid using for now
option bandwidth_threshold '0'
Actually it does go above 1, please see my screenshot from above - just not so often, so probably tuning right level is required, will try 7 for example 
Also another interesting "bug" but I understood that values returned might be sometimes inconsistent.
I don't know how you did the upgrade, but it may well not have overwritten the config that you had - so the zero value has stayed there. It was only a (bad) way to work around the bug in the previous version with bandwidth reports. That bug is now fixed and zero is probably not a good value to run with for normal behaviour.
1 Like
Hi, I'm sorry but would love some help please to identify a specific issue I'm having...
I acquired a new router (a Xiaomi AX3600) which is running Robi Marko's master build.
Things are almost fully setup / working well - a couple of things to figure out still.
One is related to DAWN and 2 IOT devices that are acting strange.
My WLAN is setup with this config:
config wifi-iface 'default_radio2'
option device 'radio2'
option network 'lan'
option mode 'ap'
option dtim_period '1'
option max_inactivity '15'
option encryption 'psk2+ccmp'
option key 'REMOVED-KEY'
option ieee80211r '1'
option mobility_domain '1111'
option reassociation_deadline '20000'
option ft_over_ds '0'
option ft_psk_generate_local '1'
option pmk_r1_push '1'
option ieee80211k '1'
option bss_transition '1'
option he_su_beamformer '1'
option he_su_beamformee '1'
option he_mu_beamformer '1'
option he_bss_color '8'
option ssid 'MYSSID'
DAWN is running with default configuration. Except for "kicking" which I flip as part of this test.
If DAWN is running with Kicking = 1, my 2 IOT devices are unable to connect. I get this error:
Sat Jan 15 23:48:23 2022 daemon.info hostapd: wlan2: STA 34:ea:34:XX:XX:XX IEEE 802.11: deauthenticated due to local deauth request
If I turn Kicking = 0, the devices don't connect still, but I don't (think) I see messages. I hope I'm not wrong about the messages, but the devices definitely don't connect.
If I stop the DAWN process, the 2 devices connect immediately.
Here's where it also gets interesting, with the devices now connected (as DAWN wasn't running):
- If I start DAWN with Kicking = 0, both of the devices stay connected.
- If I start DAWN with Kicking = 1, both of the devices are immediately kicked.
To be specific about the 2 devices, they are Broadlink A1 environment sensors. They are 2.4Ghz 802.11b/g/n. They aren't sold any longer, and this is the only link with any sort of specs I could find: https://www.amazon.ca/BroadLink-A1-wireless-Environment-Detector/dp/B06VXNY27G
Any guidance or help would be really appreciated.. Would love to understand why it is being decided that they should not be allowed to connect (and kicked if =1) so I can stop the behaviour.
I want to share an update. I have upgraded to Robi's latest codebase (K5.15). As part of the compile, the updated Dawn from master was pulled down and built.
I have noticed that with the updated DAWN, these 2 clients are connecting without my having to stop DAWN first as described above.
I'll keep an eye on this, but looking good right now.
3 Likes
New sub-topic - target use of DAWN. Over in the DAWN git area I've asked what aspirations potential / current users have for DAWN, specifically in terms of scale: https://github.com/berlin-open-wireless-lab/DAWN/issues/161#issue-1117389014.
Not everyone will see it there, so thought I'd cross link to here (but not repeat the whole post 
) to invite answers on that here or there (or maybe other aspects of usage scenarios, as opposed to usability).
For example, it may turn out that most users only want a handful of APs in their network, so scalabiltiy will never be an issue.
3 Likes
I was asked to backport changes to 21.02.
2 Likes
Awesome! Will I get these backported updates if I update?
opkg list-upgradable | grep dawn dawn - 2021-10-26-ddc007e3-2 - 2022-01-17-7a726740-1
I guess so?
root@OpenWrt:~# opkg upgrade dawn
Upgrading dawn on root from 2021-10-26-ddc007e3-2 to 2022-01-17-7a726740-1...
Downloading https://downloads.openwrt.org/releases/21.02-SNAPSHOT/packages/arm_cortex-a15_neon-vfpv4/packages/dawn_2022-01-17-7a726740-1_arm_cortex-a15_neon-vfpv4.ipk
Configuring dawn.
Starting Service...
UMDNS with port 1026
Dawn instance started!
Collected errors:
* resolve_conffiles: Existing conffile /etc/config/dawn is different from the conffile in the new package. The new conffile will be placed at /etc/config/dawn-opkg.
Hi,
I insalled DAWN, and looks nice. I See all the clients on my bot accesspoints but I only see the mac address in the dawn interface.
Is there a way that it also shows the ip adresses of the clients, and maybe also resolve the dns hostname. On the AP I have running addrwach that updates the /etc/ethers every 2 min, and the default openwrt overview I see all the clients on that AP with IP and DNS, so it should be nice that it is also be possible in DAWN, so I can what client connects to what AP in 1 overview.
Some insperation what I should want that Aruba made with his Instant APs as overview with connected clients. And I hope that something is possible with DAWN
maybe you need to sync the contents of the /tmp/dhcp.leases file between all the devices.
see this post and the following ones for more info and some scripts that can do that DHCP in VRRP cluster, how to configure properly? - #8 by bobafetthotmail
The AP's are not de DHCP servers. In the default view of openwrt get the cliets , ip adresses (I did that with addwatch for the vlans)
On the dawn view, I only see tha mac addresses. And you want to see all the clients (mac, ip , hostname) from all your AP's in one view
For anyone interested, I made further updates to my fork of DAWN: https://github.com/Ian-Clowes/DAWN.
Main things likely to be of interest:
- New "soft" kicking algorithm that will ask 802.11v devices to move to a another AP if they dip below a threshold RSSI, without DAWN knowing exactly which device should be better. Set the
kickingparameter to 3 to enable it alongside the "traditional" algorithm. Use 2 to enable only the soft kick. - Updated documentation, revised defaults, and sample config file to help reduce confusion on current parameter set
I'll PR to main repository after a few more days of succesful running.
10 Likes
the new option 3 is a great enhancement here. All around great job!
1 Like
Now that 21.02.2 is out, if I use image builder for 21.02.2 and include the dawn package, will it include any of the updates by @IanC ?