[Bug 264238] wpa_supplicant 2.10 fails to associate to open secondary VAP when primary VAP is WPA
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.