802.11r/k DAWN /etc/config/dawn

ZebraOnPC · February 14, 2022, 1:36pm

I know about device decision that is why i try agressive kicking to apply
the last config sugestion didnt work well at some places i got disconected fo 2 seconds although i was standing 1-2 meters away to alredy connected AP
so i make back settings to

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 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 '2'
	option rssi_center '0'
	option initial_score '0'
	option kicking_threshold '10'
	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 '-70'
	option chan_util_val '0'
	option max_chan_util_val '0'
	option min_probe_count '0'
	option bandwidth_threshold '128'
	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 kicking '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 min_number_to_kick '1'

config metric '802_11g'
        option rssi_weight '2'
        option rssi_center '-60'
        option initial_score '80'
	option max_chan_util_val '-10'

config local
	option loglevel '1'

and it works better no random disconnection
but i still dont understand this option
option broadcast_ip '192.168.1.255' looks like it doesnt mater what IP i put there i dont have such network in my network but DAWN seem works

IanC · February 14, 2022, 1:39pm

If you a config that works for you then that's great.

DAWN can use TCP, multicast or broadcast. If you select option 2 you are using TCP and the broadcast settings don't get used.

ZebraOnPC · February 15, 2022, 12:05pm

After reading some more https://github.com/Ian-Clowes/DAWN/blob/master/CONFIGURE.md
i decided to use

Mechanism 2 is "graduated". For each dB that the RSSI signal differs from the rssi_centre value the increment rssi_weight is applied. This can provide a more refined score, but may require more effort to get the parameters optimised. To disable this mode set the increment value to zero.

Also i decided no not use values

	option ht_support '0'
	option vht_support '0'
	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 '0'
	option max_chan_util '0'

in global and '802_11g' metric sections so mechanism Mechanism 1 is also disabled
So the DAWN supposed to calculate score only on RSSI values
As i understand correctly
config metric '802_11g' option rssi_weight '3' option rssi_center '-80' option initial_score '100'
for example

  -75 to  AP1 gives [-80 - (-75)]*3=15 points
  -45 to AP2 gives [-80 - (-45)]*3=120 points

with option kicking_threshold '15' it supposed to kick even with 3dB diffrence beetwin 2 APs

so hear is my config wich supposed to work

config times
	option update_client '15'
	option remove_client '17'
	option remove_probe '15'
	option remove_ap '233'
	option update_hostapd '8'
	option update_tcp_con '10'
	option update_chan_util '300'
	option update_beacon_reports '5'

config metric 'global'
	option rssi_weight '3'
	option rssi_center '-80'
	option initial_score '100'
	option kicking_threshold '15'
	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 '0'
	option low_rssi_val '0'
	option chan_util_val '0'
	option max_chan_util_val '0'
	option min_probe_count '0'
	option bandwidth_threshold '128'
	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 kicking '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 min_number_to_kick '1'

config metric '802_11g'
	option rssi_weight '3'
	option rssi_center '-80'
	option initial_score '100'
	option ht_support '0'
	option vht_support '0'
	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 '0'
	option max_chan_util '0'

Do i understand corectly that DAWN actually works on scores not on RSSI levels?
so if i stand 1meter to AP2 and my phone connected to AP1 wich has -75dB level to AP1 it wont kick the qwestion is why...
both metods dont work
and even it is - 75dB to curent AP in log i see

daemon.info dawn[1698]: AP BSSID F8:5E:3C:0C:59:10: Looking for candidates to kick
daemon.info dawn[1698]: Station 0E:46:FF:CD:9F:C0: Compared 0 alternate AP candidates
      .info dawn[1698]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:

Why 0 alternative AP candidats if it is 1 meter away to alternative candidate
Is there some parametras we dont know that wont let kicking work?
or DAWN simply dont work with "graduated" method
what else can be done to make DAWN work?

IanC · February 15, 2022, 12:36pm

Take a look in the hearing map when that happens to see if the client has reported its status to both APs. If DAWN only has information for on AP then it can't decide if another is better.

Is it a modern client, with 802.11k? You might get some insight if you look at the log messages for it across hostapd and DAWN. Different software uses upper and lower case hex in the MAC address, so something like:

logread -f | grep -i aa:bb:cc:dd:ee:ff

You should see local and remote PROBE messages, plus local BEACONs. It is PROBEs that are most important as they have the RSSI information. Although BEACONs should help they use a different form of signal strength called RCPI. In principle RCPI can be correlated with RSSI, but many devices provide the data in inconsistent ways. It'd be interesting if you see RCPI values for the devices as well as RSSI as a "next round" enhancement I'd like to try out is using RCPI when a client consistently reports it to all APs, and also getting the RSSI from the BEACON (as it is a little buried).

ZebraOnPC · February 15, 2022, 12:52pm

Clent sees only 1 AP wich is curent

"0E:46:FF:CD:9F:C0": {
                        "F8:5E:3C:0C:59:10": {
                                "signal": -84,
                                "rcpi": 72,
                                "rsni": 255,
                                "freq": 2437,
                                "ht_capabilities": true,
                                "vht_capabilities": true,
                                "channel_utilization": 0,
                                "num_sta": 2,
                                "ht_support": true,
                                "vht_support": false,
                                "score": 88
                        }
                },

the device is modern has android 10 on it and device can see R K V advirtising

root@33:~# logread -f | grep -i 0E:46:FF:CD:9F:C0
Tue Feb 15 15:49:06 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 251 ack=1
Tue Feb 15 15:49:06 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 251 87
Tue Feb 15 15:49:11 2022 daemon.info dawn[1701]: Station 0E:46:FF:CD:9F:C0: Compared 0 alternate AP candidates
Tue Feb 15 15:49:11 2022 daemon.info dawn[1701]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Tue Feb 15 15:49:11 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 253 ack=1
Tue Feb 15 15:49:11 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 253 7f
Tue Feb 15 15:49:16 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 255 ack=1
Tue Feb 15 15:49:16 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 255 1f
Tue Feb 15 15:49:21 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 2 ack=1
Tue Feb 15 15:49:21 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 2 e7
Tue Feb 15 15:49:26 2022 daemon.info dawn[1701]: Station 0E:46:FF:CD:9F:C0: Compared 0 alternate AP candidates
Tue Feb 15 15:49:26 2022 daemon.info dawn[1701]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Tue Feb 15 15:49:26 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 4 ack=1
Tue Feb 15 15:49:26 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 4 87
Tue Feb 15 15:49:31 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 6 ack=1
Tue Feb 15 15:49:31 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 6 07
Tue Feb 15 15:49:36 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 8 ack=1
Tue Feb 15 15:49:36 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 8 07
Tue Feb 15 15:49:41 2022 daemon.info dawn[1701]: Station 0E:46:FF:CD:9F:C0: Compared 0 alternate AP candidates
Tue Feb 15 15:49:41 2022 daemon.info dawn[1701]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Tue Feb 15 15:49:41 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 10 ack=1
Tue Feb 15 15:49:41 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 10 00 5106fffedd270000000004000444fff85e3c0c5910014f10de27
Tue Feb 15 15:49:46 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 12 ack=1
Tue Feb 15 15:49:46 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 12 07
Tue Feb 15 15:49:51 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 14 ack=1
Tue Feb 15 15:49:51 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 14 0f
Tue Feb 15 15:49:56 2022 daemon.info dawn[1701]: Station 0E:46:FF:CD:9F:C0: Compared 0 alternate AP candidates
Tue Feb 15 15:49:56 2022 daemon.info dawn[1701]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Tue Feb 15 15:49:56 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 16 ack=1
Tue Feb 15 15:49:56 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 16 07

just reinstall evrything and got

root@33:~# ubus call dawn get_hearing_map
{
        "Open22Wrt": {
                "0E:46:FF:CD:9F:C0": {
                        "68:15:90:E7:59:FC": {
                                "signal": -32,
                                "rcpi": 126,
                                "rsni": 255,
                                "freq": 2462,
                                "ht_capabilities": false,
                                "vht_capabilities": false,
                                "channel_utilization": 0,
                                "num_sta": 1,
                                "ht_support": false,
                                "vht_support": false,
                                "score": 176
                        },
                        "F8:5E:3C:0C:59:10": {
                                "signal": -64,
                                "rcpi": -1,
                                "rsni": -1,
                                "freq": 2437,
                                "ht_capabilities": true,
                                "vht_capabilities": true,
                                "channel_utilization": 9,
                                "num_sta": 2,
                                "ht_support": true,
                                "vht_support": false,
                                "score": 112
                        }
                },

Next i activated kicking (1) and logging and option bandwidth_threshold '128' then /etc/init.d/dawn restart
and now it doesnt show other AP
if my client just moved by 802.11r from one AP to the other AP i can see the client can see both APs
and after few seconds id doesnt see other AP anymore any place anytime till the client moves by itself on low signal like -80dB and lower i think it is a bag or wrong configuration
So here we are device defentlly dicent , DAWN gets information from both APs only when client moved byitself and in 10 seconds DAWN dowsn get information from any other AP but curent.
How to bug report on DAWN?
That is the funny bug if you move from one AP to another withn 10 seconds u can actully see all the kicking and work but what if a client a real person and stay near one AP more than 10 seconds so he will never be kickied by DAWN only if its client switched by itself and run back so he can see kicking

IanC · February 15, 2022, 8:16pm

if I follow you correctly then a lot of that makes sense, and is arguably reasonable behaviour.

I have an Amazon FireTV stick plugged in to my TV. It has a ~-60dB signal and never (as far as I've seen) sends anything to see if it can get a better connection. It has no 802.11k/v/r capabilities. It is therefore known to one AP, but not the others. If I go into its management menu and scan networks then it does become known to the other APs.

You device sounds similar. Once it has settled on an AP it doesn't send PROBE messages, so nothing else knows about the device RSSI (because it is not in BEACON messages). Like many devices as the signal it sees declines to -80dB (because you're moving it - unlike my FireTV) it starts looking for a better AP. It is actively doing that, so will be faster at identifying a better place to connect than DAWN is, or can be.

The "sweet spot" for DAWN is devices that are happy in themselves to stay attached to a signal between (say) -60dB and -80dB, but will still send reasonably frequent PROBE and BEACON reports to multiple APs. DAWN can then ask them to go from a -70dB connection to a -55dB one.

Devices can be very strange. This afternoon I was watching my less than 12 months old Samsung Android phone sending BEACON messages. It then went to sleep for a while, and since it came back hasn't sent any, but it started sending PROBE frames a lot more regularly than before sleeoing. I don't know if it or OpenWrt have got a bit confused about their mutual RRM capabilites.

If there are extra OpenWrt configuration parameters that I'm unaware of that improve the rate of PROBE and BEACON exchange I'd consider that to be a documentation bug, but I'm not sure I can determine a DAWN app bug in your comments.

One thing that would be useful is better "symmetry" between how PROBE and BEACON signal information is handled. That is probably enhancement rather than bug - but one that I indent do look at.

ZebraOnPC · February 15, 2022, 9:46pm

i started monitor logred -f and what i have notice

turn on WIFI on client it connects to 33.mydom
log shows Compared 0 alternate AP candidates (every 5 seconds)

moved to 44.mydom it wont be kicked so on level -80dB the client switches to 44.mydom
log shows Compared 1 alternate AP candidates (every 5 seconds) but for 1 min max, then Compared 0 alternate AP candidates again

i moved the client back to 33.mydom -80dB switches to 33.mydom
log shows Compared 1 alternate AP candidates (every 5 seconds) forever non stop ,so it constantly monitored and it works! and i got kicked even from -65dB to -53dB so this means somthing wrong somwhere in DAWN system , client defently works

in log i can see

Wed Feb 16 00:31:58 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 55 ack=1
Wed Feb 16 00:31:58 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 55 57

couldnt find anything in documentation about this parametr
NExt thing ive noticed
client on 44.mydom
evalueting 1 AP
client moves itself (low signal) to 33.mydom
44.mydom still compered and then perform kicking but there is no client on 44,mydom but it says

Station 0E:46:FF:CD:9F:C0: Kicking as probably NOT in active transmisison. RxRate is: 1.000000and also it keeps compering on both APs
I dont thing such behavior has somthing to do with client , if it was a client there wouldnt be such things like it randomly stops compering and keep compare after client moved
why it stops compering that is the qwestion that makes DAWN workig or absolutly useless

IanC · February 16, 2022, 9:44am

I'm not sure what that bit means, as it sounds like the right thing if you have set some aggressive parameters. Apart from that everythng your saying is entirely expected behaviour. Device doesn't say much about how well it sees APs other than the one it is connected to, so DAWN can't make comparisons to help steer it. When the device decides to move itself it does briefly share information with 2 APs, and you see that in DAWN but effectively after the event.

DAWN is heavily reliant on PROBE messages, largely because its roots go back to pre-802.1k and those devices are harder to steer (which is exactly why 802.11k came along). It would be interesting to see a hearing_map from your devices where they are more actively sharing signal data via BEACON frames. That would mean no -1 values against RCPI and RSNI for the same device against multiple APs. An alternate BEACON based steering could then step in there.

Having said all that you did inspire me to add a new alternate kicking algorithm. The new option will help 802.11v enabled clients stay well conected even if they are not sending lots of signal state information (which is a typical power saving approach). It simply looks at whether a station's RSSI value with the current AP (so only one measurement is needed) has gone below a set limit. I think this is similar to what some of the other purely 802.11k/r/v daemons do - since that is an easier space to manage than legacy devices. If the signal is below the set level DAWN will send an 802.11v "please consider moving" request. This is different to the normal message which is "you should move quickly, as I'm about to disconnect you", hence it will only affect 602.11v devices that want to play nicely and have no effect (for better or worse) on legacy devices. It'll be a bit experimental, but I'll add it to the (continuingly delayed) PR.

ZebraOnPC · February 16, 2022, 11:38am

well i see what are you saying now , it looks like it ,
and i see this behavior (active sending only when signal on device about to drop to critical , even befor it hits -80dB and lower) .

The only thing that is not understandble why my device likes to share information with 33 constantly but with 44 for 20-60seconds and then stops

also

Why when device connected to 33 and stays 1 meter away has best signal hearing map calculetes wrong score for APs and as results got kicked all the time.
What is RCPI and RSNI somtimes they have -1

the client connected to 33

both logreads

33

Wed Feb 16 14:43:41 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 57 ack=1
Wed Feb 16 14:43:41 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 57 1f
Wed Feb 16 14:43:44 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:43:44 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: kickcount 1 below threshold of 3!
Wed Feb 16 14:43:49 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:43:49 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:43:54 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:43:54 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: kickcount 1 below threshold of 3!
Wed Feb 16 14:43:56 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 59 07
Wed Feb 16 14:43:56 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 59 ack=0
Wed Feb 16 14:43:59 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:43:59 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:44:04 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:04 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: kickcount 1 below threshold of 3!
Wed Feb 16 14:44:09 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:09 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: kickcount 2 below threshold of 3!
Wed Feb 16 14:44:11 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 61 ack=0
Wed Feb 16 14:44:14 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:14 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:44:19 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:19 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:44:24 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:24 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:44:26 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 63 ack=1
Wed Feb 16 14:44:27 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 63 00
Wed Feb 16 14:44:29 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:29 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:44:34 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:34 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:44:39 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:39 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: kickcount 1 below threshold of 3!
Wed Feb 16 14:44:42 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 65 ack=1
Wed Feb 16 14:44:42 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 65 07
Wed Feb 16 14:44:44 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:44 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: kickcount 2 below threshold of 3!
Wed Feb 16 14:44:49 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:49 2022 daemon.info dawn[1618]: Station 0E:46:FF:CD:9F:C0: Kicking as probably NOT in active transmisison. RxRate is: 19.500000

44

Wed Feb 16 14:44:06 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 13 ack=0
Wed Feb 16 14:44:08 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:08 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:44:13 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:13 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:44:18 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:18 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:44:21 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 14 ack=0
Wed Feb 16 14:44:23 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:23 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:44:28 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:28 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:44:33 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:33 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:44:36 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 15 ack=0
Wed Feb 16 14:44:38 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:38 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:44:44 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:44 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:44:49 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Compared 1 alternate AP candidates
Wed Feb 16 14:44:49 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:44:49 2022 daemon.info dawn[1610]: bssid_addr: 68:15:90:E7:59:FC, client_addr: 0E:46:FF:CD:9F:C0, signal : -37, freq : 2462

but when the client connectet to 44

33
nothing about client mac addr 0E:46:FF:CD:9F:C0

44

Wed Feb 16 14:51:47 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Compared 0 alternate AP candidates
Wed Feb 16 14:51:47 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:51:51 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 0e:46:ff:cd:9f:c0 44 ack=1
Wed Feb 16 14:51:51 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 0e:46:ff:cd:9f:c0 44 07
Wed Feb 16 14:51:52 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Compared 0 alternate AP candidates
Wed Feb 16 14:51:52 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:51:57 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Compared 0 alternate AP candidates
Wed Feb 16 14:51:57 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:
Wed Feb 16 14:52:02 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Compared 0 alternate AP candidates
Wed Feb 16 14:52:02 2022 daemon.info dawn[1610]: Station 0E:46:FF:CD:9F:C0: Current AP is best. Client will stay:

i thought it is supposed to be simetrical

when client on 33 and has like -60dB and sees 44 like -53dB i am not sure if kickking does it or somthing else but on wifiman graphic it is almost strait line with no gaps and it is perfect , but once client moved to 44 there it has 10 seconds to decide after that nothing to compare

ZebraOnPC · February 16, 2022, 10:51pm

now i got
Station 0E:46:FF:CD:9F:C0: No active transmission data for client. Don't kick!
why it doesnt kcik ? No transmition good ! kick it!
Also compering on 44 now much longer
alright now i see option bandwidth_threshold '64' cant be more than 64 it was 128

0E:46:FF:CD:9F:C0	F8:5E:3C:0C:59:10	2.437 GHz Channel: 6	True	False	-78	98	255	1.96 %	2	84
                    68:15:90:E7:59:FC	2.462 GHz Channel: 11	False	False	-80	-1	-1	0.00 %	1	80

the signal from 68:15:90:E7:59:FC cant be -80dB it is 20 cantimeters away from 68:15:90:E7:59:FC

i just notices that when cleent moved from AP33 to AP44 in 5 secinds i got messsege on AP33

wlan0: STA 0e:46:ff:cd:9f:c0 IEEE 802.11: disassociated due to inactivity

and after that no more to compare
and AP44 disassociated due to inactivity in 5 minutes
and AP 33 disassociated due to inactivity in 5 seconds
after that no more compering , i am trying to find this parametr to change it at least to 600 seconds
added these options in wireless

	option disassoc_low_ack '0'
	option max_inactivity '600'

the same result nothing changed
so firmware the same but 44 much older sagecome
amd 33 is new zbt-8305rt

we need to find somwhere in hostapd IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE) parametrs! and change it to 1 hour

IanC · February 17, 2022, 5:11pm

No data means no idea if it is transmitting, which is different to having data saying it is zero.

There is actually a change in this area that I added to the latest code while reviewing your messages. Setting bandwidth_threshold to zero will remove this test, so DAWN will happily kick clients regardless of data transfer status.

There is also a new kicking algorithm inspired by you. It simply looks if the device RSSI is below the rssi_centre value, and if so sends an 802.11v suggesting a change to an alternate AP. But it won't enforce the switch so should be harmless to non-802.11v devices.

You can try the code by building from https://github.com/Ian-Clowes/DAWN. You'd need to set the kicking parameter to 3 to use both old and new algorithms, or 2 to use just the new one.

ZebraOnPC · February 17, 2022, 5:21pm

well i dont know how to build i guees i have to learn it now
but what about deauthenticated due to inactivity (timer DEAUTH/REMOVE) i still have hope it is possible to change this parametr , i woudnt care if i had the same result on both AP
but 33 makes deauthenticated due to inactivity (timer DEAUTH/REMOVE) in 5 secionds and it is bad
and 44 makes deauthenticated due to inactivity (timer DEAUTH/REMOVE) in 5 -10 minutes it is good time when you move

IanC · February 17, 2022, 5:23pm

Do you build OpenWrt? If so then then there are instructions in the DEVELOPER.md documentation file that should help with the local build of DAWN.

ZebraOnPC · February 17, 2022, 5:27pm

No i just download firmware and install pakets
i will try to build

IanC · February 17, 2022, 5:30pm

Do you download from SNAPSHOT? If not you'll already be running a quite old version of DAWN from the stable branch, which may mean I've been describing newer things than you have running.

IanC · February 17, 2022, 5:35pm

Is that when DAWN kicks the device? have a look at the DAWN and hostapd messages at the same time. I use something like this:

logread -f | grep -B 10 deauthenticated

ZebraOnPC · February 17, 2022, 6:10pm

No.
When device moved from AP1 to AP2 it still auntificated for a while on both APs.
While device auntificated on both devices DAWN can compare signals , but eventually device gets deauntificated on AP1 so DAWN can't compare anymore .
And this "while" can be 5 seconds or 10 minutes
So the question is how to make this time 10 minutes for both APs or how to turn off deauntification at all

ZebraOnPC · February 18, 2022, 4:04am

no, DEVELOPER.md is for people who alredy know how to build, there no information how to build for people who never build or did it long time ago
i am gonna study how to build in openwrt and then read the DEVELOPER.md
As i understand that i have to make firmware myself with dawn installed?
the thing is i tryed to do that many times but newer got working firmware
there is nothing works for me there is no just a program that can make frimware
https://openwrt.org/docs/guide-developer/buildserver_virtualbox

4. Initial Debian setup
Select the OpenWrtDev image and click Start (FROM WHERE? and WHERE?)
Wait for it to finish booting and click osboxes.org (WHER IS THIS BUTTON I HAVE TO clik)
Password: osboxes.org (really from where the password appered)
Click Activities, type term in the search field and click terminal
The interface for changing the keyboard is a bit weird, but you can find the correct place like this:

Click Activites, type reg, click Region & Language
Click + under Input Sources and then the vertical dots
Click Other, select the language and click Add. You can now delete English.
From now on, whenever you should be in the terminal to type a command the syntax will look like this:

Nothing makes sence here
i use windows virtual box maybe i shouldnt

IanC · February 18, 2022, 8:06am

Yes, as it "...assumes you have some familiarity with building OpenWrt, so is more of an 'aide memoir' than specific steps. In other words, just copying and pasting the below will not work!"

I was helping someone else with a problem the other day and pointed them to these two links which enabled them to have a running build a few hours later. That will depend on your starting system and knowledge of course.

IanC · February 18, 2022, 8:09am

Not quite. Once you have the build working you can simply copy the DAWN binary from the build tree. Use something like find -type f -name dawn to locate it and SCP to the device.

I copy it to /tmp and have this at the top of my init.d file:

if [ -f /tmp/dawn ]; then
    PROG=/tmp/dawn
else
    PROG=/usr/sbin/dawn
fi