user/sven/linux.git/net/mac80211, branch v3.8

mac80211: fix channel selection bug

2013-02-11T10:12:26Z

When trying to connect to an AP that advertises HT but not VHT, the mac80211 code erroneously uses the configuration from the AP as is instead of checking it against regulatory and local capabilities. This can lead to using an invalid or even inexistent channel (like 11/HT40+). Additionally, the return flags from downgrading must be ORed together, to collect them from all of the downgrades. Also clarify the message. Signed-off-by: Johannes Berg

mac80211: fix managed mode channel context use

2013-02-07T19:56:01Z

My commit f2d9d270c15ae0139b54a7e7466d738327e97e03 ("mac80211: support VHT association") introduced a very stupid bug: the loop to downgrade the channel width never attempted to actually use it again so it would downgrade all the way to 20_NOHT. Fix it. Signed-off-by: Johannes Berg

mac80211: fix error in sizeof() usage

2013-02-06T16:31:55Z

Using 'sizeof' on array given as function argument returns size of a pointer rather than the size of array. Cc: stable@vger.kernel.org Signed-off-by: Cong Ding Signed-off-by: Johannes Berg

mac80211: add encrypt headroom to PERR frames

2013-01-16T22:24:51Z

Mesh PERR action frames are robust and thus may be encrypted, so add proper head/tailroom to allow this. Fixes this warning when operating a Mesh STA on ath5k: WARNING: at net/mac80211/wpa.c:427 ccmp_encrypt_skb.isra.5+0x7b/0x1a0 [mac80211]() Call Trace: [] warn_slowpath_common+0x63/0x78 [] warn_slowpath_null+0xf/0x13 [] ccmp_encrypt_skb.isra.5+0x7b/0x1a0 [mac80211] [] ieee80211_crypto_ccmp_encrypt+0x1f/0x37 [mac80211] [] invoke_tx_handlers+0xcad/0x10bd [mac80211] [] ieee80211_tx+0x87/0xb3 [mac80211] [] ieee80211_tx_pending+0xcc/0x170 [mac80211] [] tasklet_action+0x3e/0x65 Signed-off-by: Bob Copeland Signed-off-by: Johannes Berg

mac80211: set NEED_TXPROCESSING for PERR frames

2013-01-16T22:22:21Z

A user reported warnings in ath5k due to transmitting frames with no rates set up. The frames were Mesh PERR frames, and some debugging showed an empty control block with just the vif pointer: > [ 562.522682] XXX txinfo: 00000000: 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 ................ > [ 562.522688] XXX txinfo: 00000010: 00 00 00 00 00 00 00 00 54 b8 f2 > db 00 00 00 00 ........T....... > [ 562.522693] XXX txinfo: 00000020: 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 ................ Set the IEEE80211_TX_INTFL_NEED_TXPROCESSING flag to ensure that rate control gets run before the frame is sent. Signed-off-by: Bob Copeland Signed-off-by: Johannes Berg

mac80211: fix monitor mode injection

2013-01-16T14:09:31Z

Channel contexts are not always used with monitor interfaces. If no channel context is set, use the oper channel, otherwise tx fails. Signed-off-by: Felix Fietkau [check local->use_chanctx] Signed-off-by: Johannes Berg

mac80211: synchronize scan off/on-channel and PS states

2013-01-16T14:06:18Z

Since: commit b23b025fe246f3acc2988eb6d400df34c27cb8ae Author: Ben Greear Date: Fri Feb 4 11:54:17 2011 -0800 mac80211: Optimize scans on current operating channel. we do not disable PS while going back to operational channel (on ieee80211_scan_state_suspend) and deffer that until scan finish. But since we are allowed to send frames, we can send a frame to AP without PM bit set, so disable PS on AP side. Then when we switch to off-channel (in ieee80211_scan_state_resume) we do not enable PS. Hence we are off-channel with PS disabled, frames are not buffered by AP. To fix remove offchannel_ps_disable argument and always enable PS when going off-channel and disable it when going on-channel, like it was before. Cc: stable@vger.kernel.org # 2.6.39+ Signed-off-by: Stanislaw Gruszka Tested-by: Seth Forshee Signed-off-by: Johannes Berg

mac80211: fix FT roaming

2013-01-16T14:03:37Z

During FT roaming, wpa_supplicant attempts to set the key before association. This used to be rejected, but as a side effect of my commit 66e67e418908442389d3a9e ("mac80211: redesign auth/assoc") the key was accepted causing hardware crypto to not be used for it as the station isn't added to the driver yet. It would be possible to accept the key and then add it to the driver when the station has been added. However, this may run into issues with drivers using the state- based station adding if they accept the key only after association like it used to be. For now, revert to the behaviour from before the auth and assoc change. Cc: stable@vger.kernel.org Reported-by: Cédric Debarge Tested-by: Cédric Debarge Signed-off-by: Johannes Berg

mac80211: fix maximum MTU

2013-01-03T12:00:01Z

The maximum MTU shouldn't take the headers into account, the maximum MSDU size is exactly the maximum MTU. Signed-off-by: T Krishna Chaitanya Signed-off-by: Johannes Berg

mac80211: fix dtim_period in hidden SSID AP association

2013-01-03T12:00:00Z

When AP's SSID is hidden the BSS can appear several times in cfg80211's BSS list: once with a zero-length SSID that comes from the beacon, and once for each SSID from probe reponses. Since the mac80211 stores its data in ieee80211_bss which is embedded into cfg80211_bss, mac80211's data will be duplicated too. This becomes a problem when a driver needs the dtim_period since this data exists only in the beacon's instance in cfg80211 bss table which isn't the instance that is used when associating. Remove the DTIM period from the BSS table and track it explicitly to avoid this problem. Cc: stable@vger.kernel.org Tested-by: Efi Tubul Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg