Strange Behaviors in 802.11 Association MLME

Strange Behaviors in 802.11 Association MLME

[Jinghao Shi]

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

Re: Strange Behaviors in 802.11 Association MLME

[Johannes Berg]

On Mon, 2017-01-16 at 16:16 -0500, Jinghao Shi wrote:
> 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 don't really see a problem. We assume that the packet was lost due to
the missing ACK, so instead of waiting for a long time, we transmit a
new one. Typically, a missing ACK is far less likely than a missing
frame.

If, as here, the association response arrives, we should properly act
on it either way.

johannes