Wifi Problems (client connects inconsistently)

[shm0]

hi!
One of my clients wont connect consistently.
My router log is spammed with:

Mon Dec 25 04:43:38 2017 daemon.info hostapd: wlan1-1: STA 00:00:00:00:00:00 IEEE 802.11: authenticated
Mon Dec 25 04:43:38 2017 daemon.info hostapd: wlan1-1: STA 00:00:00:00:00:00 IEEE 802.11: associated (aid 2)
Mon Dec 25 04:43:38 2017 daemon.info hostapd: wlan1-1: STA 00:00:00:00:00:00 IEEE 802.11: disassociated
Mon Dec 25 04:43:39 2017 daemon.info hostapd: wlan1-1: STA 00:00:00:00:00:00 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mon Dec 25 04:43:42 2017 daemon.info hostapd: wlan1-1: STA 00:00:00:00:00:00 IEEE 802.11: authenticated
Mon Dec 25 04:43:42 2017 daemon.info hostapd: wlan1-1: STA 00:00:00:00:00:00 IEEE 802.11: associated (aid 2)
Mon Dec 25 04:43:42 2017 daemon.info hostapd: wlan1-1: STA 00:00:00:00:00:00 IEEE 802.11: disassociated
Mon Dec 25 04:43:43 2017 daemon.info hostapd: wlan1-1: STA 00:00:00:00:00:00 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mon Dec 25 04:43:56 2017 daemon.info hostapd: wlan1-1: STA 00:00:00:00:00:00 IEEE 802.11: authenticated
Mon Dec 25 04:43:56 2017 daemon.info hostapd: wlan1-1: STA 00:00:00:00:00:00 IEEE 802.11: associated (aid 2)
Mon Dec 25 04:43:56 2017 daemon.info hostapd: wlan1-1: STA 00:00:00:00:00:00 IEEE 802.11: disassociated
Mon Dec 25 04:43:57 2017 daemon.info hostapd: wlan1-1: STA 00:00:00:00:00:00 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

But after some time the client connects properly.

Is this somekind of deauth attack?

merry christmas everyone!

[anon57995562]

See the solution by "ptaking" in this github thread...

https://github.com/openwrt/openwrt/issues/453

[shm0]

thank you jwoods.
i will test it and report back

[shm0]

Sadly it doesnt work

[anon57995562]

cat /etc/config/wireless

Make sure to obscure the "option key" value(s) in the wireless config results before posting.

[shm0]

config wifi-device 'radio0'
	option type 'mac80211'
	option channel '36'
	option hwmode '11a'
	option path 'soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0'
	option htmode 'VHT80'
	option country 'DE'

config wifi-device 'radio1'
	option type 'mac80211'
	option channel '11'
	option hwmode '11g'
	option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
	option htmode 'HT20'
	option legacy_rates '0'
	option antenna_gain '4'
	option country 'DE'

config wifi-iface
	option device 'radio1'
	option network 'removed'
	option mode 'ap'
	option ssid 'removed'
	option isolate '1'
	option encryption 'psk2+ccmp'
	option key 'removed'
	option ieee80211w '0'
	option macaddr 'removed'
	option disassoc_low_ack '0'
	option wps_pushbutton '0'

config wifi-iface
	option device 'radio1'
	option network 'removed'
	option mode 'ap'
	option ssid 'removed'
	option hidden '1'
	option encryption 'psk2+ccmp'
	option key 'removed'
	option ieee80211w '1'
	option macaddr 'removed'
	option disassoc_low_ack '0'
	option wps_pushbutton '0'

i think 802.11w is the problem here.

pmf=1 is set in wpa_supplicant.conf on the client. (android lineage)

[anon57995562]

Could be...

I don't see a wifi interface for 'radio 0'...I see two for 'radio 1'.

I would also add option disassoc_low_ack '0’ to both the 2.4 and 5 Ghz interfaces.

[shm0]

With 802.11w enabled:
connects immediately and sometimes takes like 2minutes.

with 802.11w disabled:
connects everytime.

so yeah i think 802.11w is bugged.
either on client or the router. sadly i only have this device to test.

i dont use 5ghz wifi cause it gives me headache :>

[anon57995562]

so yeah i think 802.11w is bugged.

Others have reported issues with it...

Wpad 802.11w no longer working in trunk?

Hi, I began running into a problem involving wpad when compiling from source.git. This issue only popped up for me about 7 days ago. When wpad (not wpad-mini) is used, and /etc/config/wireless is set to use “option ieee80211w ‘1’” in either wifi-iface, neither radio will start and log will show errors. If “option ieee80211w ‘1’” is removed the radios will start normally as expected. I have been building LEDE from source.git for many months using wpad for 802.11w functionality without issue. …

https://forum.openwrt.org/t/802-11w-not-working-with-1043nd/955

[shm0]

thanks for pointing these threads out.
i already found them too.

But they have nothing to do with my problem since my wifi interfaces come up fine.

If i had a client that i knew would support 802.11w correctly debugging would be easier.

[anon57995562]

But they have nothing to do with my problem since my wifi interfaces come up fine.

My point was there could be multiple issues...

[shm0]

I did some adb debugging on my device (first time uh):

WPA: IE in 3/4 msg does not match with IE in Beacon/ProbeResp (src=ap-mac-here)
CTRL-DEBUG: ctrl_sock-sendmsg: sock=9 sndbuf=163840 outq=0 send_len=85
CTRL_IFACE monitor sent successfully to /data/misc/wifi/sockets/wpa_ctrl_862-12\x00
WPA: RSN IE in Beacon/ProbeResp - hexdump(len=26): 00 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00
WPA: RSN IE in 3/4 msg - hexdump(len=26): 00 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00
wlan0: Request to deauthenticate - bssid=ap-mac-here pending_bssid=00:00:00:00:00:00 reason=17 state=4WAY_HANDSHAKE
TDLS: Tear down peers
wpa_driver_nl80211_disconnect(reason_code=17)

i nulled the hexdumps.
the pending_bssid was actually all 0s.

Reson 17
Information element in 4-Way Handshake different from (Re)Association Request/Probe
Response/Beacon frame
or
Reson 18 Invalid group cipher
Association denied due to requesting STA not supporting all of the data rates in the BSSBasicRateSet parameter

Source:

Linux WiFi Reason Codes - Disconnection & De-Authentication Issues

[knacky]

I use 802.11w here (2.4GHz radio set optional, 5GHz radio set required) from trunk builds without any issue on 10+ different devices. This is using ath9k though. I have found ath10k is buggy and 11w enabled radios will crash randomly between 5 mins and 5 days. I think flyspray #333 is still open regarding this, though I suspect this is a bug in closed atk10k driver and not LEDE.

Anyway, based on the debug codes, perhaps you can try adding the following and see if it makes any difference for you:

config wifi-device 'radio1'
        option country 'DE'
        option country_ie '1'

config wifi-iface 'radio1'
        option ieee80211d '1'

[shm0]

This is also not working.

I looked at the log again. Maybe i should not have nulled the hexdumps:

WPA: RSN IE in Beacon/ProbeResp - hexdump(len=26): 30 18 01 00 00 0f ac 04 01 00 00 0f ac 04 02 00 00 0f ac 02 00 0f 00 00 00 00
WPA: RSN IE in 3/4 msg - hexdump(len=26): 30 18 01 00 00 0f ac 04 01 00 00 0f ac 04 02 00 00 0f ac 02 00 0f ac 06 8c 00

They match, expect for the last four blocks. After some googling i found out that the last blocks are used for as a rsn capabilities field.
I guess the first hexdump belongs to the ap and the second dump is what the client did expect?
So this is maybe a mwlwifi driver or hostapd bug?

i found this (from 2006?):
http://lists.shmoo.com/pipermail/hostap/2006-May/013392.html

[Anusha]

I have configured wifi as client and but i am not able to ping .
Below is the error i have found when i enter the command /etc/init.d/network restart
Build used is openwrt 18.06.1

[ 4619.753171] wlan0: deauthenticated from be:2f:3d:df:1d:df (Reason: 3=DEAUTH_LEAVING)
[ 4674.489826] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready