I'm using a TP-Link AC1750 (Archer C7) version 2 router.

I've deployed OpenWrt Chaos Calmer 15.05.1 to the router and have removed wpad-mini then installed hostapd.

radio0+SSID being used for testing is configured as follows:

config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11a'
    option path 'pci0000:01/0000:01:00.0'
    option channel '56'
    option htmode 'VHT20'
    option country 'US'
    option txpower '7'

config wifi-iface
    option device 'radio0'
    option mode 'ap'
    option network 'lan'
    option encryption 'wpa2'
    option server '10.0.20.12'
    option key '**************'
    option ssid 'openwrt_nps_win2012'

Connections to the SSID, auth'ing via PEAP/802.1X, work perfectly.

I'm trying to do some deauth testing based on another Community Documentation topic thread, OpenWrt → Community Documentation → How to kick/deauth a 802.11/WiFi client.

The ubus syntax is so close to working perfectly...

ubus call hostapd.wlan0 del_client '{"addr":"XX:XX:XX:XX:XX:XX", "reason":23, "deauth":true}'

OR

ubus call hostapd.wlan0 del_client '{"addr":"XX:XX:XX:XX:XX:XX", "reason":15, "deauth":true}'

So the testing I'm doing is very deauth reason code specific. I'm trying to send only reason code 15 (4-way handshake timeout) or 23 (802.1X auth failed) and the client application honors only those two reason codes.

Looking at an over-the-air capture, I see the intended reason code deauth frames being sent.

But directly after that deauth frame, a 2nd deauth frame with reason code 7 (class 3 frame from non-associated station) is sent from the OpenWRT router's radio.

The client device responds to the reason code 7 deauth. And unfortunately, this breaks the client application and nullifies the testing effort.

Any idea why the reason code 7 deauth is being sent by the OpenWRT device's radio?

Any thoughts on how best to debug this behavior on the OpenWRT side?

Curious to hear what people think. Thanks.

(Last edited by pteeter on 17 Jan 2018, 23:05)

When you del_client, one deauth frame with your reason code is sent at the client as a courtesy.  Like any radio transmission, that frame may or may not be received.  And if it is received, it is up to the client implementation how to act upon it.

Meanwhile at the AP, the del_client process has torn down the connection and deleted all client state information.  A frame (other than auth request) received from the now unknown client's MAC is out of sequence and will be responded to with a deauth.

Your client should handle deauths more gracefully and attempt to re-establish a connection from scratch.

Thanks mk24, appreciate the clarification.

Was hoping this would be a different (easier + more cost efficient) solution from what I have been using - injecting custom created deauth frames.

Fun investigation but ultimately...bummer.