[2/2] supplicant: Support disabling the supported-oper-class IE.

From: Ben Greear <greearb@candelatech.com>

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.

Signed-off-by: Ben Greear <greearb@candelatech.com>
---
 wpa_supplicant/config.c            |  1 +
 wpa_supplicant/config.h            | 10 ++++++++++
 wpa_supplicant/sme.c               | 10 ++++++----
 wpa_supplicant/wpa_supplicant.c    |  2 +-
 wpa_supplicant/wpa_supplicant.conf |  9 +++++++++
 5 files changed, 27 insertions(+), 5 deletions(-)

On 01/07/2019 03:23 PM, Jouni Malinen wrote:
> On Fri, Aug 24, 2018 at 12:01:29PM -0700, greearb@candelatech.com 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.
>

Evidently there are other APs that this happens on, though they use the same
(or similar enough) 2.4Ghz ath chip (and presumably similar vendor driver/firmware).

I don't know of a good way to auto-detect this...it was painful to debug this
to begin with.  At least one large company
is using these currently in their lab and appear to be developing
new stuff with them.  I also managed to get pertinent info to a
QCA support person but that was a black hole so no idea if they plan to
fix it or not.

Considering these APs are in the wild, I think you need an option to
enable this hack-around.  At least then there is a chance to work
around it by configuration instead of recompile, and maybe someone
else can find a better way to auto-detect this problem.

Thanks,
Ben

On Fri, Aug 24, 2018 at 12:01:29PM -0700, greearb@candelatech.com 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.