On Mon, Jan 14 2019 15:34:22 +0100, Stefan Sperling wrote:
> > why doesn't SUBTYPE_CF_ACK_CF_POLL have NODATA in the name? it has the
> > NODATA bit set (ie. & 0x40), and "QoS CF-Ack + CF_Poll (no data)" is
> > explicitly listed in 9.2.4.1.9.
>
> Yes, that was a mistake. See this follow-up patch:
> https://marc.info/?l=openbsd-tech&m=154747407319373&w=2
yeah, I saw it right after hitting send. sorry for the noise on that
part, and thanks :)
> > > +
> > > + /*
> > > + * "no data" frames are used for various MAC coordination functions,
> > > + * particularly in the context of QoS. We do not implement related
> > > + * features yet so do not process "no data" frames any further.
> > > + */
> > > + if (subtype & (IEEE80211_FC0_SUBTYPE_NODATA |
> > > + IEEE80211_FC0_SUBTYPE_CF_POLL_NODATA |
> > > + IEEE80211_FC0_SUBTYPE_CF_ACK_NODATA)) {
> >
> > 1) shouldn't we first check that type is data here?
> > 2) isn't this a false positive for subtype ==
> > IEEE80211_FC0_SUBTYPE_DATA_CF_ACK and subtype ==
> > IEEE80211_FC0_SUBTYPE_DATA_FC_POLL, since the _NODATA versions are just
> > the _DATA_ bits ORed with FC0_SUBTYPE_NODATA? I think we should either
> > check (subtype & IEEE80211_FC0_SUBTYPE_NODATA), or test subtype's
> > equality to each of the possible NODATA macros.
> > 3) where is IEEE80211_FC0_SUBTYPE_CF_ACK_CF_POLL?
>
> Indeed, my diff was bad as well. Thanks for spotting these issues.
> I hadn't run this diff yet cause I was still building a new snapshot
> to test it. Could you also test this new version please?
I'm not currently physically near my AP, but the diff looks good and I
can test it later today.
--
Lauri Tirkkonen | lotheac @ IRCnet
