supplicant logs, this is disconnecting due to CQM?

Ben Greear greearb at candelatech.com
Tue Jan 26 07:08:13 PST 2016



On 01/25/2016 10:34 PM, Janusz Dziedzic wrote:
> On 26 January 2016 at 00:22, Ben Greear <greearb at candelatech.com> wrote:
>> Someone asked me to investigate why their station cannot stay connected to
>> their AP.  A packet trace seems to show proper ACKs and such, but the logs
>> below may indicate otherwise?  Would supplicant be killing the connection
>> due to the CQM event?
>>
>>
>> 727.275722: RTM_NEWLINK: ifi_index=3 ifname=wlan0 operstate=6 linkmode=1
>> ifi_family=0 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])
>> 727.275790: nl80211: Event message available
>> 727.275830: nl80211: Drv Event 46 (NL80211_CMD_CONNECT) received for wlan0
>> 727.275854: nl80211: Ignore connect event (cmd=46) when using userspace SME
>> 729.000109: nl80211: Event message available
>> 729.000183: nl80211: Drv Event 64 (NL80211_CMD_NOTIFY_CQM) received for
>> wlan0
>> 730.000218: RTM_NEWLINK: ifi_index=3 ifname=wlan0 operstate=2 linkmode=1
>> ifi_family=0 ifi_flags=0x1003 ([UP])
>> 730.060155: nl80211: Event message available
>> 730.060229: nl80211: Drv Event 20 (NL80211_CMD_DEL_STATION) received [
>> 730.069076] cfg80211: Calling CRDA to update world regulatory domain for
>> wlan0
>> 730.060263: nl80211: Delete station 00:1a:70:88:72:6c
>> 730.064538: nl80211: Event message available
>> 730.064614: nl80211: Drv Event 39 (NL80211_CMD_DEAUTHENTICATE) received for
>> wlan0
>> 730.076483: nl80211: MLME event 39 (NL80211_CMD_DEAUTHENTICATE) on
>> wlan0(4c:5e:0c:11:73:2f) A1=00:1a:70:88:72:6c A2=4c:5e:0c:11:73:2f
>> 730.076526: nl80211: MLME event frame - hexdump(len=26): c0 00 00 00 00 1a
>> 70 88 72 6c 4c 5e 0c 11 73 2f 00 1a 70 88 72 6c 00 00 04 00
>> 730.076575: nl80211: Deauthenticate event
>> 730.076607: wlan0: Event DEAUTH (12) received
>> 730.076633: wlan0: Deauthentication notification
>> 730.076656: wlan0:  * reason 4 (locally generated)
>
> If that is mac80211 based driver :)
>
> mac80211 connection monitor send null frames/probe_req
> (IEEE80211_CONNECTION_IDLE_TIME) every 30 seconds
> when no RX. When no-ack then trigger deauth you see.
>
> Best check the driver logs, maybe you didn't get an ACK even sniffer
> show this frame ...

The kernel logs did not show any obvious disconnect call, but maybe there
is just not a debug message for that in the kernel these guys are using.

I'll try to figure out some more details on their kernel...

It is an ath9k based system.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



More information about the Hostap mailing list