Reinette found the reason for the warnings that
happened occasionally when a hw-offloaded scan
finished; her description of the problem:

  mac80211 will defer the handling of scan requests if it is
  busy with management work at the time. The scan requests
  are deferred and run after the work has completed. When
  this occurs there are currently two problems.

  * The scan request for hardware scan is not fully populated
    with the band and channels to scan not initialized.

  * When the scan is queued the state is not correctly updated
    to reflect that a scan is in progress. The problem here is
    that when the driver completes the scan and calls
    ieee80211_scan_completed() a warning will be triggered
    since mac80211 was not aware that a scan was in progress.

The reason is that the queued scan work will start
the hw scan right away when the hw_scan_req struct
has already been allocated. However, in the first
pass it will not have been filled, which happens
at the same time as setting the bits. To fix this,
simply move the allocation after the pending work
test as well, so that the first iteration of the
scan work will call __ieee80211_start_scan() even
in the hardware scan case.
Bug-identified-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We only reply to probe request if either the requested SSID is the
broadcast SSID or if the requested SSID matches our own SSID. This
latter case was not properly handled since we were replying to different
SSID with the same length as our own SSID.
Signed-off-by: NBenoit Papillault <benoit.papillault@free.fr>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Introduce TKIP_HDR_LEN define for code clarity (in the same way as
CCMP_HDR_LEN).

Also odd len variable (not used) dropped from lib80211_tkip_hdr().
Signed-off-by: NAndriy V. Tkachuk <andrit@ukr.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NAndriy V. Tkachuk <andrit@ukr.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Rate control should not be called to update the tx status
when HW does the RC.
Signed-off-by: NVasanthakumar <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When injecting frames, mac80211 currently looks for the first AP
interface that matches the source address of the injected frame.
This breaks when such a frame is directed at a STA that has been moved
to a VLAN. This patch fixes it by using sta_info_get_bss instead of
sta_info_get, which also finds stations belonging to a VLAN interface
of the same BSS as the AP interface.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When an injected frame gets buffered for a powersave STA or filtered
and retransmitted, mac80211 attempts to parse the radiotap header
again, which doesn't work because it's gone at that point.
This patch adds a new flag for checking the availability of a radiotap
header, so that it only attempts to parse it once, reusing the tx info
on the next call to ieee80211_tx().
This fixes severe issues with rekeying in AP mode.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When looking for a matching interface, __ieee80211_rx_handle_packet
loops over all active interfaces, looking for matching stations.
Because AP VLAN interfaces are not processed as part of this loop, it
needs to use sta_info_get_bss instead of sta_info_get in order to find
a STA that has been moved to a VLAN.
This fixes issues with aggregation setup/teardown.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use a more compact and readable format for "agg_status" to reduce the
stack frame to less than 1024 bytes.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The maximal size of the "ht_capa" file is 430 bytes.  In most cases,
it's much shorter.  Use a 512 byte long buffer.  1024 bytes is too much
and causes a warning with CONFIG_FRAME_WARN=1024.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds a new regulatory hint to be used when we know all
devices have been disconnected and idle. This can happen
when we suspend, for instance. When we disconnect we can
no longer assume the same regulatory rules learned from
a country IE or beacon hints are applicable so restore
regulatory settings to an initial state.

Since driver hints are cached on the wiphy that called
the hint, those hints are not reproduced onto cfg80211
as the wiphy will respect its own wiphy->regd regardless.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When cfg80211 starts it will send a core regulatory hint. This is
sent to the global workqueue but we force processing of it by
flushing the global workqueue. The flushing was done since
cfg80211 needs last_request to always be populated.

Avoid flushing the global workqueue by processing the work
required immediately instead of putting it into a linked
list and processing it after the flush.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Because DTIM information is required for powersave
but is only conveyed in beacons, wait for a beacon
before enabling powersave, and change the way the
information is conveyed to the driver accordingly.

mwl8k doesn't currently seem to implement PS but
requires the DTIM period in a different way; after
talking to Lennert we agreed to just have mwl8k do
the parsing itself in the finalize_join work.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This new function (previously a static function
called just "find_ie" can be used to find a
specific IE in a buffer of IEs.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I got below kernel oops when I try to bring down the network interface if
ftrace is enabled. The root cause is drv_ampdu_action() is passed with a
NULL ssn pointer in the BA session tear down case. We need to check and
avoid dereferencing it in trace entry assignment.

BUG: unable to handle kernel NULL pointer dereference
Modules linked in: at (null)
IP: [<f98fe02a>] ftrace_raw_event_drv_ampdu_action+0x10a/0x160 [mac80211]
*pde = 00000000
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
[...]
Call Trace:
 [<f98fdf20>] ? ftrace_raw_event_drv_ampdu_action+0x0/0x160 [mac80211]
 [<f98dac4c>] ? __ieee80211_stop_rx_ba_session+0xfc/0x220 [mac80211]
 [<f98d97fb>] ? ieee80211_sta_tear_down_BA_sessions+0x3b/0x50 [mac80211]
 [<f98dc6f6>] ? ieee80211_set_disassoc+0xe6/0x230 [mac80211]
 [<f98dc6ac>] ? ieee80211_set_disassoc+0x9c/0x230 [mac80211]
 [<f98dcbb8>] ? ieee80211_mgd_deauth+0x158/0x170 [mac80211]
 [<f98e4bdb>] ? ieee80211_deauth+0x1b/0x20 [mac80211]
 [<f8987f49>] ? __cfg80211_mlme_deauth+0xe9/0x120 [cfg80211]
 [<f898b870>] ? __cfg80211_disconnect+0x170/0x1d0 [cfg80211]

Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: stable@kernel.org
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Filtered frames not only need their control information
cleared to avoid wrong checks, but also need to have
jiffies and vif assigned so they can be processed or
expired.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently, the remain_on_channel work callback needs
to track in its own data structure whether the work
was just started or not. By reordering some code this
becomes unnecessary, the generic wk->started variable
can still be 'false' on the first invocation and only
be 'true' on actual timeout invocations, so that the
extra variable can be removed.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

What a stupid mistake. In

    commit 813d7669
    Author: Johannes Berg <johannes@sipsolutions.net>
    Date:   Sun Jan 17 01:47:58 2010 +0100

        mac80211: move control.hw_key assignment

I inserted code testing the wrong flags field,
which means that the test is almost always true
(it's really testing for the peer's WMM support)
and thus the later parts of the stack assume hw
crypto will be done even if that's not true.

Obviously, that broke software crypto. Maxim
said so specifically, and Jochen probably uses
some cipher that iwl3945 doesn't support in
hardware, which might also explain that Maxim
reports that even hw crypto is broken.

Fix this to test the right flags field.
Reported-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Reported-by: NJochen Friedrich <jochen@scram.de>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ieee80211_work_rx_mgmt currently enqueues various management frames,
including deauth and disassoc frames, however the function
ieee80211_work_rx_queued_mgmt does not handle these, as they should
only occur if the AP is buggy. It does emit a WARN_ON when this happens
though, and several users have reported such instances.
Fix the WARN_ON by not queueing such frames in the first place.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Johannes noticed that I had incorrectly documented the context of
update_tkip_key() driver operation. It must be atomic because all
RX code is run inside rcu critical section.
Reported-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NKalle Valo <kalle.valo@iki.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Pavel Roskin reported a crash in ieee80211_tx_h_select_key():

http://marc.info/?l=linux-wireless&m=126419655108528&w=2

This is a regression from patch "mac80211: move control.hw_key assignment".
Fix it as suggested by Johannes, adding an else statement to make sure
that tx->key is not accessed when it's null.

Compile-tested only.
Reported-by: NPavel Roskin <proski@gnu.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: NKalle Valo <kalle.valo@iki.fi>
Tested-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ieee80211_tx_h_select_key might decide that a frame
need not be encrypted at all, in which case it will
clear tx->key. In that case it may crash if a key
was previously selected, e.g. as the default key.

This is also due to my patch
"mac80211: move control.hw_key assignment".
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The loop that passes non-data frames to all relevant vifs inside the
__ieee80211_rx_handle_packet keeps a pointer to the previous sdata to
avoid having to make unnecessary copies of the frame it's handling.
This led to a bug that caused it to apply the ieee80211_rx_data state
to the wrong interface, thereby either missing the rx.sta pointer or
having it assigned where it shouldn't be.
This breaks (among other things) aggregation on some vifs, as action
frame exchages are dropped to the cooked monitor interface due to
rx->sta being NULL.
Fix this by restructuring the loop so that it prepares the rx data just
before making the skb copy and calling the rx handlers.

Cc: stable@kernel.org
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn 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: NAndriy V. Tkachuk <andrit@ukr.net>
Acked-by : Benoit Papillault <benoit.papillault@free.fr>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If a device has multiple MAC addresses, userspace will
need to know about that. Similarly, if it allows the
MAC addresses to vary by a bitmask.

If a driver exports multiple addresses, it is assumed
that it will be able to deal with that many different
addresses, which need not necessarily match the ones
programmed into the device; if a mask is set then the
device should deal addresses within that mask based
on an arbitrary "base address".

To test it all and show how it is used, add support
to hwsim even though it can't actually deal with
addresses different from the default.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When a TKIP key is updated, we should pass the station
pointer instead of just the address, since drivers can
use that to store their own data. We also need to pass
the virtual interface pointer.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

"mac80211: move control.hw_key assignment" changed an if-else into two
separate if statments, but the if-else is needed to prevent
dereferencing a null info->control.hw_key.  This fixes avoids a lock-up
during association on my machine when using WEP.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

nl80211_associate() was rejecting (re)association attempts with EBUSY
in some cases where we are currently associated with an AP that uses
different channel from the destination AP. Fix this by passing the
current wdev to rdev_fixed_channel() in the same way that was already
done for join-IBSS and connect commands. This allows the fixedchan
check to skipped for the current wdev and allows the reassociation to
proceed.
Signed-off-by: NJouni Malinen <j@w1.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

First, both beacons and probe responses can be used for IBSS merge.
Next, sdata->u.ibss.bssid was always true (and thus IBSS merge was
disabled). We should use sdata->u.ibss.fixed_bssid instead.
Signed-off-by: NBenoit Papillault <benoit.papillault@free.fr>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ieee82011_sta_find_ibss() and ieee80211_sta_merge_ibss() are always
called with a defined state. So it's useless to check it or set it in
those function.
Signed-off-by: NBenoit Papillault <benoit.papillault@free.fr>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Future code will need to look up rdev and wdev
within atomic sections, but currently we need
to lock a mutex for such lookups. Change the
list handling for both to be RCU-safe so that
we can look them up in rcu sections instead in
the future.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In an earlier commit,

    mac80211: disable software retry for now

    Pavel Roskin reported a problem that seems to be due to
    software retry of already transmitted frames. It turns
    out that we've never done that correctly, but due to
    some recent changes it now crashes in the TX code. I've
    added a comment in the patch that explains the problem
    better and also points to possible solutions -- which
    I can't implement right now.

I disabled software retry of failed/filtered frames
because it was broken. With the work of the previous
patches, it now becomes fairly easy to re-enable it
by adding a flag indicating that the frame shouldn't
be modified, but still running it through the transmit
handlers to populate the control information.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When mac80211 asks a driver to encrypt a frame, it
must assign the control.hw_key pointer for it to
know which key to use etc. Currently, mac80211 does
this whenever it would software-encrypt a frame.

Change the logic of this code to assign the hw_key
pointer when selecting the key, and later check it
when deciding whether to encrypt the frame or let
it be encrypted by the hardware. This allows us to
later simply skip the encryption function since it
no longer modifies the TX control.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There's no value in setting a flag that will
never be checked after this point, this seems
to be legacy code -- I think previously the
flag was used to check whether to encrypt the
frame or not. Now, however, the flag need not
be set, and setting it actually interferes if
the frame will be processed again later.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When an skb survived a round-trip through the driver
and needs to be re-used, its control information is
definitely not valid any more, the driver will have
overwritten it.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This TX handler is used only for assigning the
station pointer in the control information, so
give it a better name. Also move it before rate
control.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Code directly scaling by HZ and rounding can be more efficiently
and clearly performed with msecs_to_jiffies.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The WMM AC selection added to the monitor mode selection function
accidentally assigns non-QoS data frames to the same AC as mgmt frames
(VO). This is not serious, but should be fixed anyway. This patch
assigns them to the BE AC instead.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

While testing the pid rate controller in mac80211_hwsim, I noticed
that once the controller reached 54 Mbit rates, it would fail to
lower the rate when necessary.  The debug log shows:

1945 186786 pf_sample 50 3534 3577 50

My interpretation is that the fixed point scaling of the target
error value (pf) is incorrect: the error value of 50 compared to
a target of 14 case should result in a scaling value of
(14-50) = -36 * 256 or -9216, but instead it is (14 * 256)-50, or
3534.

Correct this by doing fixed point scaling after subtraction.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Acked-by: NStefano Brivio <stefano.brivio@polimi.it>
Acked-by: NMattias Nissler <mattias.nissler@gmx.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>