Re: [PATCH 6/8] mac80211: A-MPDU Rx adding BAR handling capability

["Ron Rindjunsky" <ron.rindjunsky@intel.com>]

>
> > -u8 *ieee80211_get_bssid(struct ieee80211_hdr *hdr, size_t len);
> > +u8 *ieee80211_get_bssid(struct ieee80211_hdr *hdr, size_t len,
> > +                     unsigned int type);
>
> Please use the proper enum.

will do.

> > @@ -1680,6 +1725,7 @@ ieee80211_rx_handler ieee80211_rx_handlers[] =
> >       ieee80211_rx_h_remove_qos_control,
> >       ieee80211_rx_h_amsdu,
> >       ieee80211_rx_h_data,
> > +     ieee80211_rx_h_ctrl,
> >       ieee80211_rx_h_mgmt,
>
> Maybe we should have a single rx_h_frame function that passes it to
> three control/data/mgmt functions depending on the frame type? Not sure
> though since data comes first and that's the hot path.

especially in A-MPDU, data is the most traffic you'll see in these
handlers (lets put aside the AP that bombed me with 749 BARs over 30
seconds ;-) i really think it was a buggy functionality of the AP
there)

>
>
> > @@ -163,6 +164,15 @@ u8 *ieee80211_get_bssid(struct ieee80211_hdr *hdr, size_t len)
> >       case IEEE80211_FTYPE_CTL:
> >               if ((fc & IEEE80211_FCTL_STYPE) == IEEE80211_STYPE_PSPOLL)
> >                       return hdr->addr1;
> > +             else if ((fc & IEEE80211_FCTL_STYPE) ==
> > +                                             IEEE80211_STYPE_BACK_REQ) {
> > +                     switch (type) {
> > +                     case IEEE80211_IF_TYPE_STA:
> > +                             return hdr->addr2;
> > +                     case IEEE80211_IF_TYPE_AP:
> > +                             return hdr->addr1;
> > +                     }
>
> Doesn't that result in a compiler warning? And what does happen if we
> receive a BACK_REQ when we're an IBSS/MESH?
>

IBSS is not supporting 802.11n currently (spec decision)
MESH i am not familier enough yet to answer. are you sure it supports 11n?