>
> > -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?
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
