This patch makes mac80211 warn (once) when the driver passes up a
frame in which the payload data is not aligned on a four-byte
boundary, with a long comment for people who run into the condition
and need to know what to do.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
struct ieee80211_sub_if_data *prev = NULL;
struct sk_buff *skb_new;
u8 *bssid;
struct ieee80211_sub_if_data *prev = NULL;
struct sk_buff *skb_new;
u8 *bssid;
/*
* key references and virtual interfaces are protected using RCU
/*
* key references and virtual interfaces are protected using RCU
rx.fc = le16_to_cpu(hdr->frame_control);
type = rx.fc & IEEE80211_FCTL_FTYPE;
rx.fc = le16_to_cpu(hdr->frame_control);
type = rx.fc & IEEE80211_FCTL_FTYPE;
+ /*
+ * Drivers are required to align the payload data to a four-byte
+ * boundary, so the last two bits of the address where it starts
+ * may not be set. The header is required to be directly before
+ * the payload data, padding like atheros hardware adds which is
+ * inbetween the 802.11 header and the payload is not supported,
+ * the driver is required to move the 802.11 header further back
+ * in that case.
+ */
+ hdrlen = ieee80211_get_hdrlen(rx.fc);
+ WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3);
+
if (type == IEEE80211_FTYPE_DATA || type == IEEE80211_FTYPE_MGMT)
local->dot11ReceivedFragmentCount++;
if (type == IEEE80211_FTYPE_DATA || type == IEEE80211_FTYPE_MGMT)
local->dot11ReceivedFragmentCount++;