Search Linux Wireless

Strange Behaviors in 802.11 Association MLME

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

We're working on a formal validation framework for wireless protocol
implementations. We have performed experiments on the 802.11
association state machine and have found peculiar association
behaviors.We'd like to share our findings to the community and confirm
whether they reveal potential implementation bugs.

TLDR version: the client sends association request despite having
received association response from the AP, is this a bug?

We utilized a real time reactive packet jammer to create the following
packet loss pattern (the rate control policy was set to re-transmit
the packet at most once before reporting the packet as failed. This
may not be realistic in practice but helps reveal interesting
behaviors faster.)

 - ASSOC_REQ (received by the AP, confirmed by the following ASSOC_RESP)
 - ACK <---- JAMMED
 - ASSOC_REQ_RETRY <----- JAMMED, the driver will declare this packet as failed
 - ASSOC_RESP (received by the client, confirmed by the following ACK)
 - ACK
 - ASSOC_REQ <--- problematic packet
 - ...

I'm also attaching a pcap capture during this session. Our current
conjecture is that the failure status of the ASSOC_REQ was delivered
to the mac80211 MLME entity before the reception of the ASSOC_RESP
packet.

Let us know if there's any other information we can collect to help
tracing down the issue.

Regards,
Jinghao Shi
PhD Student
University at Buffalo



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux