@wellnw - Not sure if you looked at the captures back in August, but I’m uploading a simple case of one chromebook which works and one which didn’t.
2019-08-21 Chromebook Testing Revised.zip (433.4 KB)
There are noticeable differences int he Association Requests. If you take a simple text comparison tool (say BBEdit) and compare the files “Successful Conection R13.txt” with “Failed Connection Spin 11-Reordered.txt”, you can see just what’s different. Obviously, ignore the stuff that doesn’t matter like times stamps, time measurements, sequence numbers, addresses and the like.
Note: the “Failed Connection Spin 11-Reordered” file had some Association Request elements reordered simply to line them up side by side and make a text comparison (diff) work better. The file “Failed Connection Spin 11.txt” has the original decode.
[The pcap files are also included if you want to see the whole sessions.]
I don’t think it’s caused by anything simply contained in the request - we have chromebooks which sometimes connect very quickly and sometimes which take forever to connect and sometimes never connect - yet send identical Association Requests. It could be the number of them or the timing of them or a combination of the request contents and timing.
For example, I can see that many devices (such as my iPhone) will send multiple Association Requests. The iPhone SE happens to send one AssReq. Then up to 3 more (flagged as retransmits using the same sequence number, not new requests) every 4 milliseconds. Then it stops and eventually the mango starts the key exchange.
Some chromebooks, send way more than 4 requests. The number and timing doesn’t seem to be in any particular pattern. Look at the failing pcap in WireShark, using the display filter “wlan.addr == 20:79:18:ec:20:39” starting at packet 1161 and ending at 1833. Lots of resends (verify by flag and the same SN). There are 9 AssReq’s over the course of about 50 msec, then over 6 seconds before the mango deauthenticates.
There are additional elements in the failing Association requests that are not in the failing ones.
Something is preventing the mango from advancing to the key exchange after this burst of Association requests and responses.
The Association Responses are identical in the successful and unsuccessful case. So the “end result” of the association negotiation is probably the same.
Looking at the successful case, There’s only a single Association Request sent followed by a key exchange 114 msec later. Wow…t that’s a long time.
This makes me wonder if there’s just a different resend threshold (remember, the iPhone also sent multiple times and still connected).
Or if the chromebook is really not receiving all those Association Responses correctly, causing the resends. It can’t really be anything “fixed” in the response since there are cases when the connection fails sometimes but not others and the response contents are identical. Just different timing or internal state.
Of course, there’s no guarantee that what my wifi monitor captured was successfully captured by the chromebook. Maybe the mango has some frame timing that’s marginal during the connection setup. The chromebooks could be doing all those resends because they aren’t receiving the Association Responses. That is, however, no excuse for the mango not to start key negotiation after sending an Association Response.