Hi Jouni, Thanks for the pointers. I did observed some peculiar behavior of the assoc state machine. It's mostly at the client side (mac80211 MLME), but I thought you may be interested as well. In the experiment, 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. The jamming policy I used was to jam the ack of the ASSOC_REQ packet and it's retransmision, such that the client thinks the ASSOC_REQ failed but the AP actually received the ASSOC_REQ packet. That is: - ASSOC_REQ - ACK <--- jammed - ASSOC_REQ_RETRY <--- jammed - ASSOC_RESP - ACK - ... I'm attaching the sniffer trace during this jamming session. From the AP (hostapd)'s perspective, the client sends another ASSOC_REQ packet after already acknowledging the ASSOC_RESP packet. And the EAPOL handshake process seems confused too. I'll ping the mac80211 mail list about why the client's behavior. It'll be great if you can comment on the hostapd's logic in this situation as well. Thanks, Jinghao On Fri, Jan 13, 2017 at 5:14 PM, Jouni Malinen <j@xxxxx> wrote: > On Fri, Jan 13, 2017 at 12:15:01PM -0500, Jinghao Shi wrote: >> To give you some background, we're working on formal validation of >> wireless protocol implementations. The approach is to utilize a >> real-time reactive packet jammer (implemented on USRP) to drive the >> protocol state machine into certain state to observe how the >> implementation reacts. In this particular case, we used the jammer to >> jam the ACK to AUTH_RESP packet and all following retransmissions of >> the AUTH_RESP packet. We were trying to create a test-case where the >> AP and the client disagree on the auth/assoc state. But apparently >> this was taken into consideration in the protocol spec. > > While Authentication frame exchange is not applicable for that, you > should be able to find difference in deployed AP implementations for > association processing. I'd guess that number of APs do not really > follow strictly the standard description on when the station becomes > associated (when the AP receives the ACK frame to its Association > Response frame with Status Code 0).. Not that this necessarily causes > much issues in practice, but if you are looking for strict compliance > with the standard, that would be one of the few cases where the ACK > frame makes significant different for this type of management operation > behavior. > >> Does this make sense? Is there any other aspects where you envision >> such technique might be useful? > > I haven't really considered doing such testing by jamming frames over > air. It's an interesting concept and can help with some testing cases. > My main focus in testing protocol behavior is to use mac80211_hwsim and > test builds that allow frame corruption or loss to be simulated. > > -- > Jouni Malinen PGP id EFC895FA
Attachment:
repeated_assoc_req.pcap
Description: application/vnd.tcpdump.pcap
_______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
