linux-stable.git/include/linux/ieee80211.h, branch linux-2.6.38.y Linux kernel stable tree ieee80211: correct IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK macro 2011-01-13T20:46:45+00:00 Amitkumar Karwar akarwar@marvell.com 2011-01-12T00:14:24+00:00 8d661f1e462d50bd83de87ee628aaf820ce3c66c It is defined in include/linux/ieee80211.h. As per IEEE spec. bit6 to bit15 in block ack parameter represents buffer size. So the bitmask should be 0xFFC0. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Cc: stable@kernel.org Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
It is defined in include/linux/ieee80211.h. As per IEEE spec.
bit6 to bit15 in block ack parameter represents buffer size.
So the bitmask should be 0xFFC0.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Cc: stable@kernel.org
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: Remove unused third address from mesh address extension header. 2010-12-20T19:49:47+00:00 Javier Cardona javier@cozybit.com 2010-12-17T01:23:34+00:00 61ad5394590c5c5338ab4ec50553d809a9996d50 The Mesh Control header only includes 0, 1 or 2 addresses. If there is one address, it should be interpreted as Address 4. If there are 2, they are interpreted as Addresses 5 and 6 (Address 4 being the 4th address in the 802.11 header). The address extension used to hold up to 3 addresses instead of the current 2. I'm not sure which draft version changed this, but it is very unlikely that it will change again given the state of the approval process of this draft. See section 7.1.3.6.3 in current draft (8.0). Also, note that the extra address that I'm removing was not being used, so this change has no effect on over-the-air frame formats. But I thought I better remove it before someone does start using it. Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
The Mesh Control header only includes 0, 1 or 2 addresses. If there is
one address, it should be interpreted as Address 4.  If there are 2,
they are interpreted as Addresses 5 and 6 (Address 4 being the 4th
address in the 802.11 header).

The address extension used to hold up to 3 addresses instead of the current 2.
I'm not sure which draft version changed this, but it is very unlikely that it
will change again given the state of the approval process of this draft.  See
section 7.1.3.6.3 in current draft (8.0).

Also, note that the extra address that I'm removing was not being used, so this
change has no effect on over-the-air frame formats.  But I thought I better
remove it before someone does start using it.

Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: Let userspace enable and configure vendor specific path selection. 2010-12-20T19:46:57+00:00 Javier Cardona javier@cozybit.com 2010-12-17T01:37:49+00:00 c80d545da3f7c0e534ccd4a780f322f80a92cff1 Userspace will now be allowed to toggle between the default path selection algorithm (HWMP, implemented in the kernel), and a vendor specific alternative. Also in the same patch, allow userspace to add information elements to mesh beacons. This is accordance with the Extensible Path Selection Framework specified in version 7.0 of the 802.11s draft. Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
Userspace will now be allowed to toggle between the default path
selection algorithm (HWMP, implemented in the kernel), and a vendor
specific alternative.  Also in the same patch, allow userspace to add
information elements to mesh beacons.  This is accordance with the
Extensible Path Selection Framework specified in version 7.0 of the
802.11s draft.

Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ieee80211: add Parameter Set Count bitmask 2010-12-13T20:23:30+00:00 Bing Zhao bzhao@marvell.com 2010-12-10T02:24:41+00:00 44316cb1e97a1e7f76eb3f07e5b0ba91d72e9693 WMM IE QoS Info field lower 4 bits: Parameter Set Count Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
WMM IE QoS Info field lower 4 bits: Parameter Set Count

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
cfg80211: add some element IDs in enum ieee80211_eid 2010-12-08T20:38:45+00:00 Amitkumar Karwar akarwar@marvell.com 2010-12-07T21:43:03+00:00 b7e8941b2df518186d9f7679c007f6b619bb4e89 1)WLAN_EID_BSS_COEX_2040 2)WLAN_EID_OVERLAP_BSS_SCAN_PARAM 3)WLAN_EID_EXT_CAPABILITY Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
1)WLAN_EID_BSS_COEX_2040
2)WLAN_EID_OVERLAP_BSS_SCAN_PARAM
3)WLAN_EID_EXT_CAPABILITY

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: Update mesh constants to approved IEEE ANA values 2010-10-11T19:04:21+00:00 Steve deRosier steve@cozybit.com 2010-10-10T00:23:28+00:00 cfdfa4d3a0c7aa1287c61326a7714f262466157a This patch updates IEEE802.11 mesh constants to be consistent with newly approved values. It modifies some values, as well as adds many new constants in preparation for updating mesh code to the current 802.11s drafts. ANA numbers were taken from: https://mentor.ieee.org/802.11/dcn/09/11-09-0031-12-0000-ana-database-assigned-number-authority.xls A few notes are in order: 1. This will break backwards compatibility with existing Linux kernels as over-the-air constants have changed. 2. Some old and obsolete constants have been retained for now as the mesh code itself hasn't been updated yet to the new 802.11s draft. This was desired to keep the existing mesh scheme working until it can be updated. Adding the approved values is the first step in updating the mesh code. 3. Obsolete constants have been clearly marked. 4. All ANA approved 802.11s constants have been added. Signed-off-by: Steve deRosier <steve@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
This patch updates IEEE802.11 mesh constants to be consistent with newly
approved values. It modifies some values, as well as adds many new constants
in preparation for updating mesh code to the current 802.11s drafts. ANA
numbers were taken from:
https://mentor.ieee.org/802.11/dcn/09/11-09-0031-12-0000-ana-database-assigned-number-authority.xls

A few notes are in order:
1. This will break backwards compatibility with existing Linux kernels as
over-the-air constants have changed.
2. Some old and obsolete constants have been retained for now as the mesh code
itself hasn't been updated yet to the new 802.11s draft. This was desired to
keep the existing mesh scheme working until it can be updated. Adding the
approved values is the first step in updating the mesh code.
3. Obsolete constants have been clearly marked.
4. All ANA approved 802.11s constants have been added.

Signed-off-by: Steve deRosier <steve@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: add flags for STBC (Space-Time Block Coding) 2010-04-20T15:52:21+00:00 Felix Fietkau nbd@openwrt.org 2010-04-19T17:57:35+00:00 f79d9bad37cb1e7ef23d60b1dd0b7859957ced9e Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: Moved mesh action codes to a more visible location 2010-04-08T19:24:07+00:00 Javier Cardona javier@cozybit.com 2010-03-29T18:00:21+00:00 97ad9139fd68b5c71f44d28d3f9788d89cfd4916 Grouped mesh action codes together with the other action codes in ieee80211.h. Signed-off-by: Javier Cardona <javier@cozybit.com> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
Grouped mesh action codes together with the other action codes in
ieee80211.h.

Signed-off-by: Javier Cardona <javier@cozybit.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: clean up/fix aggregation code 2010-04-07T18:38:05+00:00 Johannes Berg johannes@sipsolutions.net 2010-04-06T09:18:47+00:00 098a607091426e79178b9a6c318d993fea131791 The aggregation code has a number of quirks, like inventing an unneeded WLAN_BACK_TIMER value and leaking memory under certain circumstances during station destruction. Fix these issues by using the regular aggregation session teardown code and blocking new aggregation sessions, all before the station is really destructed. As a side effect, this gets rid of the long code block to destroy aggregation safely. Additionally, rename tid_state_rx which can only have the values IDLE and OPERATIONAL to tid_active_rx to make it easier to understand that there is no bitwise stuff going on on the RX side -- the TX side remains because it needs to keep track of the driver and peer states. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
The aggregation code has a number of quirks, like
inventing an unneeded WLAN_BACK_TIMER value and
leaking memory under certain circumstances during
station destruction. Fix these issues by using
the regular aggregation session teardown code and
blocking new aggregation sessions, all before the
station is really destructed.

As a side effect, this gets rid of the long code
block to destroy aggregation safely.

Additionally, rename tid_state_rx which can only
have the values IDLE and OPERATIONAL to
tid_active_rx to make it easier to understand
that there is no bitwise stuff going on on the
RX side -- the TX side remains because it needs
to keep track of the driver and peer states.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: Account HT Control field in Data frame hdrlen according to 802.11n-2009 2010-01-22T21:11:27+00:00 Andriy Tkachuk andrit@ukr.net 2010-01-20T11:55:06+00:00 d0dd2de0d055f0ffb1e2ecdc21380de9d12a85e2 ieee80211_hdrlen() should account account new HT Control field in 802.11 data frame header introduced by IEEE 802.11n standard. According to 802.11n-2009 HT Control field is present in data frames when both of following are met: 1. It is QoS data frame. 2. Order bit is set in Frame Control field. The change might be totally compatible with legacy non-11n aware frames, because 802.11-2007 standard states that "all QoS STAs set this subfield to 0". Signed-off-by: Andriy V. Tkachuk <andrit@ukr.net> Acked-by : Benoit Papillault <benoit.papillault@free.fr> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
ieee80211_hdrlen() should account account new HT Control field in 802.11
data frame header introduced by IEEE 802.11n standard.

According to 802.11n-2009 HT Control field is present in data frames
when both of following are met:

   1. It is QoS data frame.
   2. Order bit is set in Frame Control field.

The change might be totally compatible with legacy non-11n aware frames,
because 802.11-2007 standard states that "all QoS STAs set this subfield
to 0".

Signed-off-by: Andriy V. Tkachuk <andrit@ukr.net>
Acked-by : Benoit Papillault <benoit.papillault@free.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>