On Fri, Aug 24, 2018 at 12:01:29PM -0700, greearb@xxxxxxxxxxxxxxx wrote: > This provides a work-around for cases where the AP (most likely) > has bugs when this element exists and/or has 5Ghz elements when > the AP is evidently unexpecting that. > > Test case that required this fix is a DPC3941 AP, configured with > 2.4G radio to have WPA2 PSK. Client station is ath10k 9880. > The symptom is that the client radio does not ack the 1/4 eapol. > I do not know exactly why, but maybe it is corrupted in some suble > way that I did not notice. This sounds really strange. I cannot think of many reasons of the Supported Operating Classes element having impact for EAPOL-Key msg 1/4.. Some kind of really strange corruption that hits completely unrelated area, etc. Have you seen this with any other AP devices? In general, I don't really like user configurable parameters for this type of workarounds, i.e., it would be much better for users not to have to know about this in the first place. Most users would have no idea how to enable something like this in wpa_supplicant (and in most cases, they would not even have means of editing the configuration file on a device that uses wpa_supplicant). In other words, this should really be detected and enabled automatically only if the AP really needs this. Unfortunately, there is not much details here to determine what exactly is behind this and the particular AP you mention here seems to be out-of-life, so there may not be much of a chance of getting support from the vendor either. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
