[Bug 264238] wpa_supplicant 2.10 fails to associate to open secondary VAP when primary VAP is WPA

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 03 Jul 2022 07:21:27 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238

--- Comment #182 from J.R. Oldroyd <fbsd@opal.com> ---
I think that the workaround patch is the wrong approach.

If there are many folk clamoring for a fix, then okay, commit it.  But I don't
get the sense that this is that urgent is it?

What I found in yesterday and Friday's debugging is that the code in the area I
am looking at, in wpas_populate_assoc_ies(), appears to be generating our IE
for outbound transmission.  It isn't parsing the AP's incoming IE.  The section
that adds the IE that breaks things has the comment:

         * Workaround: Add Extended Capabilities element only if the AP
         * included this element in Beacon/Probe Response frames. Some older
         * APs seem to have interoperability issues if this element is
         * included, so while the standard may require us to include the
         * element in all cases, it is justifiable to skip it to avoid
         * interoperability issues.

As Cy pointed out, this code has been there for ages.  So, the question is, why
are we now triggering the addition of this Extended Capabilities IE when we
apparently didn't in earlier versions?

And, a second question is, given that we do add this ExtCapab IE with the
cotents that I showed in comment #176, why does that cause our own driver to
select WPA mode?

Given that the comment says that adding this IE can be skipped, I would suggest
that a better temporary fix is to put "#if 0 ... #endif" around this section of
the code in wpas_populate_assoc_ies().

I am just sitting back down again today and will look more at these now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.