When in world roaming mode, allow 40 MHz to be used
on channels 12 and 13 so that an AP that is, e.g.,
using HT40+ on channel 9 (in the UK) can be used.

Cc: stable@vger.kernel.org
Reported-by: NEddie Chapman <eddie@ehuk.net>
Tested-by: NEddie Chapman <eddie@ehuk.net>
Acked-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Fixes more wifi status skb leaks, leading to hostapd/wpa_supplicant hangs.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

On resume or firmware recovery, mac80211 sends a null
data packet to see if the AP is still around and hasn't
disconnected us. However, it always does this even if
it wasn't even connected before, leading to a warning
in the new channel context code. Fix this by checking
that it's associated.

Cc: stable@vger.kernel.org
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When removing a UUID from the list in the remove_uuid() function we must
also kfree the entry in addition to removing it from the list.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Added Atheros AR3011 internal bluetooth device found in Sony VAIO VPCEH to the
devices list.
Before this, the bluetooth module was identified as an Foxconn / Hai bluetooth
device [0489:e027], now it claims to be an AtherosAR3011 Bluetooth
[0cf3:3005].

T:  Bus=01 Lev=02 Prnt=02 Port=04 Cnt=02 Dev#=  4 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0489 ProdID=e027 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
Signed-off-by: NMarcos Chaparro <marcos@mrkindustries.com.ar>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

It is important that the monitor interface gets notified about
a new device before its power on procedure has been started.

For some reason that is no longer working as expected and the power
on procedure runs first. It is safe to just notify about device
registration and trigger the power on procedure afterwards.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

When pairing fails due to wrong confirm value, the management layer
doesn't report a proper error status. It sends
MGMT_STATUS_CONNECT_FAILED instead of MGMT_STATUS_AUTH_FAILED.

Most of management functions that receive a status as a parameter
expects for it to be encoded as a HCI status. But when a SMP pairing
fails, the SMP layer sends the SMP reason as the error status to the
management layer.

This commit maps all SMP reasons to HCI_ERROR_AUTH_FAILURE, which will
be converted to MGMT_STATUS_AUTH_FAILED in the management layer.
Reported-by: NClaudio Takahasi <claudio.takahasi@openbossa.org>
Reviewed-by: NJoão Paulo Rechi Vita <jprvita@openbossa.org>
Signed-off-by: NPaulo Sérgio <paulo.sergio@openbossa.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

The mgmt_read_index_list uses one loop to calculate the max needed size
of its response with the help of an upper-bound of the controller count.
The second loop is more strict as it checks for HCI_SETUP (which might
have gotten set after the first loop) and could result in some indexes
being skipped. Because of this the function needs to readjust the event
length and index count after filling in the response array.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

If the cipher suites need to be allocated, but this
allocation fails, this leaks the internal scan request.
Fix that by going to the correct error handling label.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

To let mac80211 clean up any TX information when
a frame is dropped, use ieee80211_free_txskb().
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The RX replenish code doesn't handle DMA mapping failures,
which will cause issues if there actually is a failure. This
was reported by Shuah Khan who found a DMA mapping framework
warning ("device driver failed to check map error").

Cc: stable@vger.kernel.org
Reported-by: NShuah Khan <shuah.khan@hp.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

These are accessed without a lock when ending STA PSM. If the
sta_cleanup timer accesses these lists at the same time, we might crash.

This may fix some mysterious crashes we had during
ieee80211_sta_ps_deliver_wakeup.

Cc: stable@vger.kernel.org
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NIdo Yariv <ido@wizery.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In case that there is an unsupported band, the ie will be
unallocated and the free will crash.

Cc: stable@vger.kernel.org
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Drivers are not expected to handle it before drv_start has been called. It
will be called again after an interface has been brought up.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The ath9k xmit functions for AMPDUs can send frames as non-aggregate in case
only one frame is currently available. The client will then answer using a
normal Ack instead of a BlockAck. This acknowledgement has no TID stored and
therefore the hardware is not able to provide us the corresponding TID.

The TID set by the hardware in the tx status descriptor has to be seen as
undefined and not as a valid TID value for normal acknowledgements. Doing
otherwise results in a massive amount of retransmissions and stalls of
connections.

Users may experience low bandwidth and complete connection stalls in
environments with transfers using multiple TIDs.

This regression was introduced in b11b160d
("ath9k: validate the TID in the tx status information").
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Cc: stable@vger.kernel.org
Acked-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some hardware has correct (!= 0xff) value of tssi_bounds[4] in the
EEPROM, but step is equal to 0xff. This results on ridiculous delta
calculations and completely broke TX power settings.
Reported-and-tested-by: NPavel Lucik <pavel.lucik@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

bf->bf_next is only while buffers are chained as part of an A-MPDU
in the tx queue. When a tid queue is flushed (e.g. on tearing down
an aggregation session), frames can be enqueued again as normal
transmission, without bf_next being cleared. This can lead to the
old pointer being dereferenced again later.

This patch might fix crashes and "Failed to stop TX DMA!" messages.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The code to allow EAPOL frames even when the station
isn't yet marked associated needs to check that the
incoming frame is long enough and due to paged RX it
also can't assume skb->data contains the right data,
it must use skb_copy_bits(). Fix this to avoid using
data that doesn't really exist.

Cc: stable@vger.kernel.org
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

A number of places in the mesh code don't check that
the frame data is present and in the skb header when
trying to access. Add those checks and the necessary
pskb_may_pull() calls. This prevents accessing data
that doesn't actually exist.

To do this, export ieee80211_get_mesh_hdrlen() to be
able to use it in mac80211.

Cc: stable@vger.kernel.org
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Due to pskb_may_pull() checking the skb length, all
non-management frames are checked on input whether
their 802.11 header is fully present. Also add that
check for management frames and remove a check that
is now duplicate. This prevents accessing skb data
beyond the frame end.

Cc: stable@vger.kernel.org
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The mesh header can have address extension by a 4th
or a 5th and 6th address, but never both. Drop such
frames in 802.11 -> 802.3 conversion along with any
frames that have the wrong extension.

Cc: stable@vger.kernel.org
Reviewed-by: NJavier Cardona <javier@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The 'ssid' field of the cfg80211_ibss_params is a u8 pointer and
its length is likely to be less than IEEE80211_MAX_SSID_LEN most
of the time.

This patch fixes the ssid copy in ieee80211_ibss_join() by using
the SSID length to prevent it from reading beyond the string.

Cc: stable@vger.kernel.org
Signed-off-by: NAntonio Quartulli <ordex@autistici.org>
[rewrapped commit message, small rewording]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Per IEEE Std. 802.11-2012, Sec 8.2.4.4.1, the sequence Control field is
not present in control frames.  We noticed this problem when processing
Block Ack Requests.

Cc: stable@vger.kernel.org
Signed-off-by: NJavier Cardona <javier@cozybit.com>
Signed-off-by: NJavier Lopez <jlopex@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Prior this fix, those frames were not received, nor forwarded.  Fix
this to receive and not forward.
Signed-off-by: NJavier Cardona <javier@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Doing otherwise is wrong, and may wreak havoc on the mpp tables,
specially if the frame is encrypted.

Cc: stable@vger.kernel.org
Reported-by: NChaoxing Lin <Chaoxing.Lin@ultra-3eti.com>
Signed-off-by: NJavier Cardona <javier@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When b43 fails to find firmware when loaded, a subsequent unload will
oops due to calling ieee80211_unregister_hw() when the corresponding
register call was never made.

Commit 2d838bb6 fixed the same problem
for b43legacy.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Tested-by: NMarkus Kanet <dvmailing@gmx.eu>
Cc: Stable <stable@vger.kernel.org> [V3.3.0+ (the patch will need to be refactored)]
Cc: Markus Kanet <dvmailing@gmx.eu>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

De-reference and deallocate scan state on failure.
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NPaul Stewart <pstew@chromium.org>
Tested-by: NPaul Stewart <pstew@chromium.org>
Reviewed-by: NRyan Cairns <rtc@chromium.org>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Previous patch "mwifiex: return -EBUSY if scan request cannot.."
corrected regular scan request only. There is another case for
specific scan that needs the same handling.

Also, removed !req_ssid check as it has already been validated
by caller.
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NPaul Stewart <pstew@chromium.org>
Reviewed-by: NRyan Cairns <rtc@chromium.org>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix a samtch warnings catched by Fengguang's 0-DAY system:
+ drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c:3572 brcmf_cfg80211_sched_scan_start() error: we previously assumed 'request' could be null (see line 3571)

Cc: John W. Linville <linville@tuxdriver.com>
Signed-off-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
Acked-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts commit a240dc7b.

This commit is reducing tx power by at least 10 db on some devices,
e.g. the Buffalo WZR-HP-G450H.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Cc: rmanohar@qca.qualcomm.com
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Roger says, Ubiquiti produce 2 versions of their WiFiStation USB adapter.  One
has an internal antenna, the other has an external antenna and
name suffix EXT.  They have separate USB ids and in distribution
openSUSE 12.2 (kernel 3.4.6), file /usr/share/usb.ids shows:

  0cf3  Atheros Communications, Inc.
       ...
       b002  Ubiquiti WiFiStation 802.11n [Atheros AR9271]
       b003  Ubiquiti WiFiStationEXT 802.11n [Atheros AR9271]

Add b002 Ubiquiti WiFiStation in the PID/VID list.
Reported-by: NRoger Price <ath9k@rogerprice.org>
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Patch fixes warnings like below happened on resume:

WARNING: at net/mac80211/driver-ops.h:12 check_sdata_in_driver+0x32/0x34()

Problem is that in __ieee80211_susped() we remove sdata (i.e wlan0
interface) and then during resume we call usb_unbind_interface() ->
ieee80211_unregister_hw() with sdata removed.

Patch fixes problem by adding .reset_resume calback, hence we do not
unbind usb device on resume. This callback can be the same as normal
.resume callback, sice we do all needed initalization during interface
start, which is performed on resume [ ieee80211_resume() ->
ieee80211_reconfig() -> rt2x00mac_start() -> rt2x00lib_start ].

Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=48041Reported-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Reported-and-tested-by: NStephen Boyd <bebarino@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If _rtl_usb_receive fails, the device is
probably not ready. Hence the error code
should be passed to the caller, so it can
react accordingly and notify the user.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of the current whitelist which accepts duplicates
only for the quiet and vendor IEs, use a blacklist of all
IEs (that we currently parse) that can't be duplicated.

This avoids detecting a beacon as corrupt in the future
when new IEs are added that can be duplicated.

Cc: stable@vger.kernel.org
Signed-off-by: NPaul Stewart <pstew@chromium.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

A few places touch chan->max_power based on updated tx power rules, but
forget to do the same to chan->max_reg_power.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

No driver initializes chan->max_antenna_gain to something sensible, and
the only place where it is being used right now is inside ath9k. This
leads to ath9k potentially using less tx power than it can use, which can
decrease performance/range in some rare cases.

Rather than going through every single driver, this patch initializes
chan->orig_mag in wiphy_register(), ignoring whatever value the driver
left in there. If a driver for some reason wishes to limit it independent
from regulatory rulesets, it can do so internally.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>