On Sat, Dec 12, 2015 at 11:56:47AM +0100, Martin Pieuchot wrote:
> On 12/12/15(Sat) 00:19, Stefan Sperling wrote:
> > Index: net80211/ieee80211_input.c
> > ===================================================================
> > RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
> > retrieving revision 1.142
> > diff -u -p -r1.142 ieee80211_input.c
> > --- net80211/ieee80211_input.c 15 Nov 2015 11:14:17 -0000 1.142
> > +++ net80211/ieee80211_input.c 11 Dec 2015 22:43:24 -0000
> > @@ -1569,10 +1597,13 @@ ieee80211_recv_probe_resp(struct ieee802
> > */
> > if (ni->ni_flags & IEEE80211_NODE_QOS) {
> > /* always prefer EDCA IE over Wi-Fi Alliance WMM IE */
> > - if (edcaie != NULL)
> > - ieee80211_parse_edca_params(ic, edcaie);
> > - else if (wmmie != NULL)
> > - ieee80211_parse_wmm_params(ic, wmmie);
> > + if ((edcaie != NULL &&
> > + ieee80211_parse_edca_params(ic, edcaie) == 0) ||
> > + (wmmie != NULL &&
> > + ieee80211_parse_wmm_params(ic, wmmie) == 0))
> > + ni->ni_flags |= IEEE80211_NODE_QOS;
> > + else
> > + ni->ni_flags &= ~IEEE80211_NODE_QOS;
>
> I like the code unification but I find a bit confusing that
> IEEE80211_NODE_QOS is checked/set twice.
>
> What should a client do if QoS has been negotiated during
> association and then the kernel fails tp parse EDCA/WMMIE
> params? Is it correct to unset IEEE80211_NODE_QOS here?
This change is not about what happens during association,
but about what happens earlier.
My iwlwifi AP sends no EDCA but WME, and it does so only in
beacons and probe responses, but *not* during assocation
(i.e. not in assoc response frames).
These elements can exist in any management frame so we have to
check twice, once in the beacon/probe response RX code path, and
once in the assoc response RX code path. The latter check already
exists in CVS today and I'm not removing it. Perhaps damien@ got
this wrong and these elements are never actually sent in assoc
responses, but who knows -- they are vendor-specific elements.
If we do not set the NODE_QOS flag for some reason, 11n won't work.
So if we fail to parse the elements even though they were provided,
11n won't work. I hope such elements are not compliant with Wifi
Alliance requirements but I cannot read their documents...
> You have my ok.
Does this apply to the split up versions I'm sending, too?
They're slightly different since I found some small bugs while
splitting up the diff. I intend to commit the smaller patches.
