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
