Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to configure DAWN to kick "legacy" devices? #215

Open
rany2 opened this issue Apr 9, 2023 · 2 comments
Open

How to configure DAWN to kick "legacy" devices? #215

rany2 opened this issue Apr 9, 2023 · 2 comments

Comments

@rany2
Copy link

rany2 commented Apr 9, 2023

I have a few devices that don't seem to respect the 802.11v signal to move to another AP. I thought that setting eval_probe_req, eval_auth_req, eval_assoc_req to 1 would have it properly kick these devices but it still seems to not work. It simply keeps trying to issue a kick (according to the system log) to no avail. (NOTE: forcibly disconnecting it using the hostapd ubus interface makes it roam to the nearest AP instantly)


OS: OpenWrt SNAPSHOT r22528-0c53801968 / LuCI Master git-23.093.56957-2145121
Using hostapd-wolfssl

@NODeeJay
Copy link

NODeeJay commented Jul 22, 2023

I also try to achieve that, I see constant kicks in the log, but the client stays happily connected. I also can confirm a disconnect in the UI or a
ubus call hostapd.***net24 del_client '{"addr":"**:**:**:0D:90:E0", "reason": 5, "deauth": true, "ban_time": 100}'
works immediately.

From what I understand auth, assoc and probe are responsible when the client reconnects, see here: https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/802.11_Association_Process_Explained. I found older Android devices (7/8) to fall into the stall "Saved" state for that network, when I activate additionally auth and assoc and then stay offline until I either reconnect them manually or disable WiFi for some time.

https://github.com/berlin-open-wireless-lab/DAWN/blob/master/CONFIGURE.md#note-1-legacy-clients mentions
"It can also force disconnection of a connected client by "tearing down" the connection, however this is quite brutal as the client then must start a search for a new AP, and it may just want to come back to the same AP."
but I have no clue which of the mentioned settings would now disconnect, is it kicking 1?

Mh, while reading https://github.com/berlin-open-wireless-lab/DAWN/blob/master/CONFIGURE.md#kicking-method-2-absolute-rssi again one may assume that kicking 2 is the wrong option???
[...]"value then a "soft" kick is done, which asks the device to look at other APs but does not enforce this through a disconnection.

dawn

config local
	option loglevel '0' # 0 debug, 5 info

config network
	option broadcast_ip '192.168.***.255'
	option broadcast_port '1025'
	option tcp_port '1026'
	option network_option '2' # 0 = Broadcast; 2 = Multicast; [2 = TCP with UMDNS discovery]; 3 = TCP w/out UMDNS discovery
	option shared_key '08fgzK42LUzx7132KLSF'
	option iv '08fgzK42LUzx7132KLSF' # regarding DAWN manual unused
	option use_symm_enc '0' #it seems there is an issue with encryption
	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 '360'
	option update_hostapd '5'
	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 '60'
	option use_station_count '0'
	option max_station_diff '1'
	option eval_probe_req '1'
	option eval_auth_req '0'
	option eval_assoc_req '0'
	option kicking '3'
	option kicking_threshold '15'
	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 '1'
	option duration '0'
	option rrm_mode 'pat'

config metric '802_11g'
	option initial_score '70'
	option ht_support '5'
	option vht_support '5'
	option no_ht_support '0'
	option no_vht_support '0'
	option rssi_val '-55
	option rssi '15'
	option low_rssi_val '-70'
	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_val '-60
	option rssi '15''
	option low_rssi_val '-75'
	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'

wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option hwmode '11a'
	option path 'pci0000:00/0000:00:00.0'
	option cell_density '0'
	option htmode 'VHT80'
	option channel 'auto'
	option country 'JP'
	option txpower '16'

config wifi-iface 'default_radio0'
	option bss_transition '1'
	option device 'radio0'
	option encryption 'psk2+ccmp'
	option ft_psk_generate_local '1'
	option ieee80211k '1'
	option ieee80211r '1'
	option ieee80211v '1'
	option ifname 'ndjnet5'
	option key '*****************'
	option max_inactivity '200'
	option mobility_domain '3f72'
	option mode 'ap'
	option network 'lan'
	option reassociation_deadline '20000'
	option ssid '**********'
	option time_advertisement '2'
	option time_zone 'GMT0'
	option wnm_sleep_mode '1'
	option wpa_disable_eapol_key_retries '1'
	option ft_over_ds '0'

OpenWrt 22.03.5 r20134-5f15225c1e / LuCI openwrt-22.03 branch git-23.119.80898-65ef406

@Flole998
Copy link
Contributor

Looks like the code to do that is currently commented out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants