Commit Graph

67 Commits

Author SHA1 Message Date
Avraham Stern 6e46d8ce89 mac80211: flush hw_roc_start work before cancelling the ROC
When HW ROC is supported it is possible that after the HW notified
that the ROC has started, the ROC was cancelled and another ROC was
added while the hw_roc_start worker is waiting on the mutex (since
cancelling the ROC and adding another one also holds the same mutex).
As a result, the hw_roc_start worker will continue to run after the
new ROC is added but before it is actually started by the HW.
This may result in notifying userspace that the ROC has started before
it actually does, or in case of management tx ROC, in an attempt to
tx while not on the right channel.

In addition, when the driver will notify mac80211 that the second ROC
has started, mac80211 will warn that this ROC has already been
notified.

Fix this by flushing the hw_roc_start work before cancelling an ROC.

Cc: stable@vger.kernel.org
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2017-09-05 16:25:07 +02:00
Johannes Berg 59ae1d127a networking: introduce and use skb_put_data()
A common pattern with skb_put() is to just want to memcpy()
some data into the new space, introduce skb_put_data() for
this.

An spatch similar to the one for skb_put_zero() converts many
of the places using it:

    @@
    identifier p, p2;
    expression len, skb, data;
    type t, t2;
    @@
    (
    -p = skb_put(skb, len);
    +p = skb_put_data(skb, data, len);
    |
    -p = (t)skb_put(skb, len);
    +p = skb_put_data(skb, data, len);
    )
    (
    p2 = (t2)p;
    -memcpy(p2, data, len);
    |
    -memcpy(p, data, len);
    )

    @@
    type t, t2;
    identifier p, p2;
    expression skb, data;
    @@
    t *p;
    ...
    (
    -p = skb_put(skb, sizeof(t));
    +p = skb_put_data(skb, data, sizeof(t));
    |
    -p = (t *)skb_put(skb, sizeof(t));
    +p = skb_put_data(skb, data, sizeof(t));
    )
    (
    p2 = (t2)p;
    -memcpy(p2, data, sizeof(*p));
    |
    -memcpy(p, data, sizeof(*p));
    )

    @@
    expression skb, len, data;
    @@
    -memcpy(skb_put(skb, len), data, len);
    +skb_put_data(skb, data, len);

(again, manually post-processed to retain some comments)

Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 11:48:37 -04:00
Michael Braun 1d4de2e222 mac80211: fix CMD_FRAME for AP_VLAN
When using IEEE 802.11r FT OVER-DS roaming with AP_VLAN, hostapd needs to
send out a frame using CMD_FRAME for a station assigned to an AP_VLAN
interface.

Right now, the userspace needs to give the exact AP_VLAN interface index
for CMD_FRAME; hostapd does not do this. Additionally, userspace cannot
use GET_STATION to query the AP_VLAN ifidx, as while GET_STATION finds
stations assigned to AP_VLAN even if the AP iface is queried, it does not
return AP_VLAN ifidx (it returns the queried one).

This breaks IEEE 802.11r over_ds with vlans, as the reply frame does not
get out. This patch fixes this by using get_sta_bss for CMD_FRAME.

Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-10-12 09:19:12 +02:00
Ayala Beker 708d50edb1 mac80211: add boilerplate code for start / stop NAN
This code doesn't do much besides allowing to start and
stop the vif.

Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-09-30 13:21:19 +02:00
Ayala Beker cb3b7d8765 cfg80211: add start / stop NAN commands
This allows user space to start/stop NAN interface.
A NAN interface is like P2P device in a few aspects: it
doesn't have a netdev associated to it.
Add the new interface type and prevent operations that
can't be executed on NAN interface like scan.

Define several attributes that may be configured by user space
when starting NAN functionality (master preference and dual
band operation)

Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-09-30 13:21:14 +02:00
Eliad Peller 470f4d613b mac80211: avoid ROC during hw restart
Defer ROC requests during hw restart, as the driver
might not be fully configured in this stage (e.g.
channel contexts were not added yet)

Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-01-14 11:10:14 +01:00
Johannes Berg e6a8a3aaaa mac80211: fix remain-on-channel cancellation
Ilan's previous commit 1b894521e6 ("mac80211: handle HW
ROC expired properly") neglected to take into account that
hw_begun was now always set in the software implementation
as well as the offloaded case.

Fix hw_begun to only apply to the offloaded case to make
the check in Ilan's commit safe and correct.

Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-01-14 11:10:10 +01:00
Johannes Berg e9db455787 mac80211: recalculate SW ROC only when needed
The current (new) code recalculates the new work timeout
for software remain-on-channel whenever any item started.
In two of the callers of ieee80211_handle_roc_started(),
this is completely pointless since they're for hardware
and will skip the recalculation entirely; it's necessary
only in the case of having just added a new item to the
list, as in the last remaining case the recalculation had
just been done.

This last case, however, is also problematic - if one of
the items on the list actually expires during the recalc
the list iteration outside becomes corrupted and crashes.

Fix this by moving the recalculation to the only place
where it's required.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-01-14 11:10:09 +01:00
Ilan Peer 1b894521e6 mac80211: handle HW ROC expired properly
In case of HW ROC, when the driver reports that the ROC expired,
it is not sufficient to purge the ROCs based on the remaining
time, as it possible that the device finished the ROC session
before the actual requested duration.

To handle such cases, in case of ROC expired notification from
the driver, complete all the ROCs which are marked with hw_begun,
regardless of the remaining duration.

Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-12-07 11:06:37 +01:00
Johannes Berg 7d37fcd409 mac80211: reject zero cookie in mgmt-tx/roc cancel
When cancelling, you can cancel "any" (first in list) mgmt-tx
or remain-on-channel operation by using the value 0 for the
cookie along with the *opposite* operation, i.e.
 * cancel the first mgmt-tx by cancelling roc with 0 cookie
 * cancel the first roc by cancelling mgmt-tx with 0 cookie

This isn't really that bad since userspace should only pass
cookies that we gave it, but could lead to hard-to-debug
issues so better prevent it and reject zero values since we
never hand those out.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-12-04 14:43:32 +01:00
Johannes Berg aaa016ccd5 mac80211: rewrite remain-on-channel logic
Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.

Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.

There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.

Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.

This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.

TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-12-04 14:43:32 +01:00
Johannes Berg 5ee00dbd52 mac80211: simplify ack_skb handling
Since the cookie is assigned inside ieee80211_make_ack_skb()
now, we no longer need to return the ack_skb as the cookie
and can simplify the function's return and the callers. Also
rename it to ieee80211_attach_ack_skb() to more accurately
reflect its purpose.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-12-04 14:43:32 +01:00
Johannes Berg a2fcfccbad mac80211: move off-channel/mgmt-tx code to offchannel.c
This is quite a bit of code that logically depends here since
it has to deal with all the remain-on-channel logic.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-12-04 14:43:32 +01:00
Johannes Berg e673a65952 mac80211: fix mgmt-tx abort cookie and leak
If a mgmt-tx operation is aborted before it runs, the wrong
cookie is reported back to userspace, and the ack_skb gets
leaked since the frame is freed directly instead of freeing
it using ieee80211_free_txskb(). Fix that.

Fixes: 3b79af973c ("mac80211: stop using pointers as userspace cookies")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-12-04 14:43:32 +01:00
Johannes Berg 076cdcb12f mac80211: use bool argument to ieee80211_send_nullfunc
Instead of int with 0/1, use bool with false/true for the
powersave argument to ieee80211_send_nullfunc().

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-09-29 15:56:52 +02:00
Johannes Berg 30686bf7f5 mac80211: convert HW flags to unsigned long bitmap
As we're running out of hardware capability flags pretty quickly,
convert them to use the regular test_bit() style unsigned long
bitmaps.

This introduces a number of helper functions/macros to set and to
test the bits, along with new debugfs code.

The occurrences of an explicit __clear_bit() are intentional, the
drivers were never supposed to change their supported bits on the
fly. We should investigate changing this to be a per-frame flag.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-06-10 16:05:36 +02:00
Emmanuel Grumbach 3b24f4c653 mac80211: let flush() drop packets when possible
When roaming / suspending, it makes no sense to wait until
the transmit queues of the device are empty. In extreme
condition they can be starved (VO saturating the air), but
even in regular cases, it is pointless to delay the roaming
because the low level driver is trying to send packets to
an AP which is far away. We'd rather drop these packets and
let TCP retransmit if needed. This will allow to speed up
the roaming.

For suspend, the explanation is even more trivial.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-01-14 09:31:18 +01:00
Luciano Coelho cca07b00a5 mac80211: introduce refcount for queue_stop_reasons
Sometimes different vifs may be stopping the queues for the same
reason (e.g. when several interfaces are performing a channel switch).
Instead of using a bitmask for the reasons, use an integer that holds
a refcount instead.  In order to keep it backwards compatible,
introduce a boolean in some functions that tell us whether the queue
stopping should be refcounted or not.  For now, use not refcounted for
all calls to keep it functionally the same as before.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-06-23 14:22:25 +02:00
Johannes Berg b4b177a555 mac80211: fix on-channel remain-on-channel
Jouni reported that if a remain-on-channel was active on the
same channel as the current operating channel, then the ROC
would start, but any frames transmitted using mgmt-tx on the
same channel would get delayed until after the ROC.

The reason for this is that the ROC starts, but doesn't have
any handling for "remain on the same channel", so it stops
the interface queues. The later mgmt-tx then puts the frame
on the interface queues (since it's on the current operating
channel) and thus they get delayed until after the ROC.

To fix this, add some logic to handle remaining on the same
channel specially and not stop the queues etc. in this case.
This not only fixes the bug but also improves behaviour in
this case as data frames etc. can continue to flow.

Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen <j@w1.fi>
Tested-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-14 15:48:38 +02:00
Johannes Berg 115b943a6e mac80211: fix software remain-on-channel implementation
Jouni reported that when doing off-channel transmissions mixed
with on-channel transmissions, the on-channel ones ended up on
the off-channel in some cases.

The reason for that is that during the refactoring of the off-
channel code, I lost the part that stopped all activity and as
a consequence the on-channel frames (including data frames)
were no longer queued but would be transmitted on the temporary
channel.

Fix this by simply restoring the lost activity stop call.

Cc: stable@vger.kernel.org
Fixes: 2eb278e083 ("mac80211: unify SW/offload remain-on-channel")
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-09 10:47:47 +02:00
Jouni Malinen 22c4ceed01 mac80211: Run deferred scan if last roc_list item is not started
mac80211 scan processing could get stuck if roc work for pending, but
not started when a scan request was deferred due to such roc item.
Normally the deferred scan would be started from
ieee80211_start_next_roc(), but ieee80211_sw_roc_work() calls that only
if the finished ROC was started. Fix this by calling
ieee80211_run_deferred_scan() in the case the last ROC was not actually
started.

This issue was hit relatively easily in P2P find operations where Listen
state (remain-on-channel) and Search state (scan) are repeated in a
loop.

Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-09-30 12:36:56 +02:00
John W. Linville 655d8e2328 Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
Conflicts:
	drivers/net/wireless/ath/carl9170/debug.c
	drivers/net/wireless/ath/carl9170/main.c
	net/mac80211/ieee80211_i.h
2013-04-10 14:09:54 -04:00
John W. Linville 6fe5468f45 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
Conflicts:
	drivers/net/wireless/rt2x00/rt2x00pci.c
2013-04-10 09:31:39 -04:00
Johannes Berg c8f994eec2 mac80211: purge remain-on-channel items when suspending
They can't really be executed while suspended and could
trigger work warnings, so abort all ROC items. When the
system resumes the notifications about this will be
delivered to userspace which can then act accordingly
(though it will assume they were canceled/finished.)

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-04-08 09:17:00 +02:00
Johannes Berg 3fbd45ca8d mac80211: fix remain-on-channel cancel crash
If a ROC item is canceled just as it expires, the work
struct may be scheduled while it is running (and waiting
for the mutex). This results in it being run after being
freed, which obviously crashes.

To fix this don't free it when aborting is requested but
instead mark it as "to be freed", which makes the work a
no-op and allows freeing it outside.

Cc: stable@vger.kernel.org [3.6+]
Reported-by: Jouni Malinen <j@w1.fi>
Tested-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-03-25 13:50:33 +01:00
Johannes Berg 445ea4e83e mac80211: stop queues temporarily for flushing
Sometimes queues are flushed in the middle of
operation, which can lead to driver issues.
Stop queues temporarily, while flushing, to
avoid transmitting new packets while they are
being flushed.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-03-18 20:15:05 +01:00
Johannes Berg 39ecc01d1b mac80211: pass queue bitmap to flush operation
There are a number of situations in which mac80211 only
really needs to flush queues for one virtual interface,
and in fact during this frames might be transmitted on
other virtual interfaces. Calculate and pass a queue
bitmap to the driver so it knows which queues to flush.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-03-18 20:15:03 +01:00
Ilan Peer d339d5ca8e mac80211: Allow drivers to differentiate between ROC types
Some devices can handle remain on channel requests differently
based on the request type/priority. Add support to
differentiate between different ROC types, i.e., indicate that
the ROC is required for sending managment frames.

Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-03-06 16:35:49 +01:00
Seth Forshee 9c35d7d236 mac80211: Add flushes before going off-channel
We've got a couple of races when enabling powersave with an AP for
off-channel operation. The first is fairly simple. If we go off-channel
before the nullfunc frame to enable PS is transmitted then it may not be
received by the AP. Add a flush after enabling off-channel PS to prevent
this from happening.

The second race is a bit more subtle. If the driver supports QoS and has
frames queued when the nullfunc frame is queued, those frames may get
transmitted after the nullfunc frame. If PM is not set then the AP is
being told that we've exited PS before we go off-channel and may try to
deliver frames. To prevent this, add a flush after stopping the queues
but before passing the nullfunc frame to the driver.

Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-11 22:52:21 +01:00
Seth Forshee 6c17b77b67 mac80211: Fix tx queue handling during scans
Scans currently work by stopping the netdev tx queues but leaving the
mac80211 queues active. This stops the flow of incoming packets while
still allowing mac80211 to transmit nullfunc and probe request frames to
facilitate scanning. However, the driver may try to wake the mac80211
queues while in this state, which will also wake the netdev queues.

To prevent this, add a new queue stop reason,
IEEE80211_QUEUE_STOP_REASON_OFFCHANNEL, to be used when stopping the tx
queues for off-channel operation. This prevents the netdev queues from
waking when a driver wakes the mac80211 queues.

This also stops all frames from being transmitted, even those meant to
be sent off-channel. Add a new tx control flag,
IEEE80211_TX_CTL_OFFCHAN_TX_OK, which allows frames to be transmitted
when the queues are stopped only for the off-channel stop reason. Update
all locations transmitting off-channel frames to use this flag.

Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-11 22:52:21 +01:00
John W. Linville 9ebea3829f Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
Conflicts:
	drivers/net/wireless/ath/ath9k/main.c
	drivers/net/wireless/iwlwifi/dvm/tx.c
2013-01-28 13:54:03 -05:00
Stanislaw Gruszka aacde9ee45 mac80211: synchronize scan off/on-channel and PS states
Since:

commit b23b025fe2
Author: Ben Greear <greearb@candelatech.com>
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 <sgruszka@redhat.com>
Tested-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-16 15:06:18 +01:00
Johannes Berg d6a8322882 mac80211: track enable_beacon explicitly
Instead of calculating in ieee80211_bss_info_change_notify()
whether beaconing should be enabled or not, set it in the
correct places in the callers. This simplifies the logic in
this function at the expense of offchannel, but is also more
robust.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-03 13:01:35 +01:00
John W. Linville 55cb0797fa This is an NFC LLCP fix for 3.7 and contains only one patch.
It fixes a potential crash when receiving an LLCP HDLC frame acking a frame
 that is not the last sent one. In that case we may dereference an already
 freed pointer.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iQIcBAABAgAGBQJQt0kOAAoJEIqAPN1PVmxKpxoQAJwbaylVz/miDjJLPekDhQ+z
 YkDmtBWJD9oy5GS/EUZPRIIEj+Ftaao0lAJDP4couYiZPQbrRBY1llBOxcIzkCqR
 fsAaD8jnPRGHwWtdqws8txFePh4Hn5WXHmJbcsOyVGt4gmy/xT06gme4p3VdIQIP
 XIkbss5mz29OdQwOLHzH4zva7JtZm9XOEWYWAbbFsrgNxXLBt7GhfF92TT29K4Wt
 UxFalwMYrpowY+BCBWzS1H31wVvNaDcsBRSO0hqvUZb7DgWM2b25B4Xnx3LiyLHR
 9A17LWYso6mRhQPSqqhT5wWlKNT1G5VKZ8/X0i69ZLXi040NzpvMbvq41RhM9SwN
 bmWZNUWGrGkQJY6VPAdXeraoSmSNwOD4KnLXNV8rWmmg+NSzf8ZPWNCcxNEdIMnK
 oBe7vvk3j5z6QGNPeMB5C3hfpyRwyvRTqC9O5/dO7DOYD0lb0O6tuj1/MzhsOR2L
 pzBUjkvfJBA0FXdeDD7gFwR062uJZL4hinRpFPj4qTtFWPYypirWdnRpCSZbvbeW
 ZB3k7+8oNOGhn1TYPUmWsN1GNk2EJ4ZSpAf7BUI5Vb1KmcSpUQA6BN6yPlS/WQ4U
 eowwW+sUYPu5LixMCO/LtuUllJ/RCTzdQJH6j/hZlEqmfYs00emKNa08tk15XjGF
 zn2jXJjTykbYiVRirBR5
 =tpAI
 -----END PGP SIGNATURE-----

Merge tag 'nfc-fixes-3.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-3.0

This is an NFC LLCP fix for 3.7 and contains only one patch.

It fixes a potential crash when receiving an LLCP HDLC frame acking a frame
that is not the last sent one. In that case we may dereference an already
freed pointer.
2012-12-06 14:55:57 -05:00
Johannes Berg 6bdd253f63 mac80211: fix remain-on-channel (non-)cancelling
Felix Liao reported that when an interface is set DOWN
while another interface is executing a ROC, the warning
in ieee80211_start_next_roc() (about the first item on
the list having started already) triggers.

This is because ieee80211_roc_purge() calls it even if
it never actually changed the list of ROC items. To fix
this, simply remove the function call. If it is needed
then it will be done by the ieee80211_sw_roc_work()
function when the ROC item that is being removed while
active is cleaned up.

Cc: stable@vger.kernel.org
Reported-by: Felix Liao <Felix.Liao@watchguard.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-11-26 14:41:40 -05:00
Johannes Berg 42d97a599e cfg80211: remove remain-on-channel channel type
As mwifiex (and mac80211 in the software case) are the
only drivers actually implementing remain-on-channel
with channel type, userspace can't be relying on it.
This is the case, as it's used only for P2P operations
right now.

Rather than adding a flag to tell userspace whether or
not it can actually rely on it, simplify all the code
by removing the ability to use different channel types.
Leave only the validation of the attribute, so that if
we extend it again later (with the needed capability
flag), it can't break userspace sending invalid data.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-26 12:42:58 +01:00
Eliad Peller 4988456862 mac80211: make remain_on_channel() op pass vif param
Drivers (e.g. wl12xx) might need to know the vif
to roc on (mainly in order to configure the
rx filters correctly).

Add the vif to the op params, and update the current
users (iwlwifi) to use the new api.

Signed-off-by: Eliad Peller <eliad@wizery.com>
[fix hwsim]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-11-19 16:20:37 +01:00
Johannes Berg 50febf6a1a mac80211: use a counter for remain-on-channel cookie
Instead of using the pointer which can be re-used
fairly quickly due to allocator patterns and then
makes debugging difficult, maintain a counter and
use its value. Since it's a 64-bit value it can't
really wrap, but catch that case anyway since it
most likely points to a bug somewhere.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-10-30 09:33:40 +01:00
Johannes Berg 55de908ab2 mac80211: use channel contexts
Instead of operating on a single channel only,
use the new channel context infrastructure in
all mac80211 code.

This enables drivers that want to use the new
channel context infrastructure to use multiple
channels, while nothing should change for all
the other drivers that don't support it.

Right now this disables both TX power settings
and spatial multiplexing powersave. Both need
to be re-enabled on a channel context basis.

Additionally, when channel contexts are used
drop the connection when channel switch is
received rather than trying to handle it. This
will have to be improved later.

[With fixes from Eliad and Emmanuel incorporated]
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-10-17 11:02:09 +02:00
Johannes Berg fe57d9f5c0 mac80211: track whether to use channel contexts
Depending on the driver, channel contexts may be used or
not. If they are used, the driver must have support for
hardware scan and remain-on-channel; otherwise the driver
must not advertise support for multiple channels.

Also prohibit WDS type interfaces when channel contexts
are to be used as there's no clear definition of which
channel they use.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-10-16 20:22:46 +02:00
Wei Yongjun a4ed53466a mac80211: use list_move instead of list_del/list_add
Using list_move() instead of list_del() + list_add().

spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-09-06 11:55:47 +02:00
Johannes Berg f142c6b906 mac80211: support P2P Device abstraction
After cfg80211 got a P2P Device abstraction, add
support to mac80211. Whether it really is supported
or not will depend on whether or not the driver has
support for it, but mac80211 needs to change to be
able to support drivers that need a P2P Device.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-08-20 13:58:22 +02:00
Alan Cox 4b4b8229ae mac80211: fix use after free
roc is destroyed then roc->started is referenced. Keep a local cache.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-13 16:15:54 +02:00
Johannes Berg 71bbc99438 cfg80211: use wdev in mgmt-tx/ROC APIs
The management frame and remain-on-channel APIs will be
needed in the P2P device abstraction, so move them over
to the new wdev-based APIs. Userspace can still use both
the interface index and wdev identifier for them so it's
backward compatible, but for the P2P Device wdev it will
be able to use the wdev identifier only.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-09 14:51:47 +02:00
Johannes Berg 011ad0e9f8 mac80211: rename driver-trace file
This file will contain more soon, so
rename it to just trace.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-24 11:32:38 +02:00
Johannes Berg 0f6b3f597d mac80211: fix double-start of remain-on-channel
When a remain-on-channel item is deleted, we remove it
from the list and then start the next item. However,
if it wasn't actually the first item then calling
ieee80211_start_next_roc() is wrong as it will start
the first item -- even if that was already started.

Fix the two places that do this and add a warning to
prevent the problem from reoccurring.

Reported-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-20 20:12:12 +02:00
Rajkumar Manoharan 559cef996d mac80211: cleanup offchannel_ps_enable argument
The 'tell_ap' argument is always true. So that remove it
and simplify the function.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-20 10:53:34 +02:00
Johannes Berg cef28271be mac80211: remove unneeded ieee80211_run_deferred_scan()
Ilan pointed out to me that ieee80211_start_next_roc()
already calls ieee80211_run_deferred_scan() if the list
of ROC items is empty, so there's no need to call it
again after calling ieee80211_start_next_roc().

Reported-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-11 17:01:17 +02:00
Johannes Berg 2eb278e083 mac80211: unify SW/offload remain-on-channel
Redesign all the off-channel code, getting rid of
the generic off-channel work concept, replacing
it with a simple remain-on-channel list.

This fixes a number of small issues with the ROC
implementation:
 * offloaded remain-on-channel couldn't be queued,
   now we can queue it as well, if needed
 * in iwlwifi (the only user) offloaded ROC is
   mutually exclusive with scanning, use the new
   queue to handle that case -- I expect that it
   will later depend on a HW flag

The bigger issue though is that there's a bad bug
in the current implementation: if we get a mgmt
TX request while HW roc is active, and this new
request has a wait time, we actually schedule a
software ROC instead since we can't guarantee the
existing offloaded ROC will still be that long.
To fix this, the queuing mechanism was needed.

The queuing mechanism for offloaded ROC isn't yet
optimal, ideally we should add API to have the HW
extend the ROC if needed. We could add that later
but for now use a software implementation.

Overall, this unifies the behaviour between the
offloaded and software-implemented case as much
as possible.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-06 15:31:18 -04:00
Johannes Berg 196ac1c13d mac80211: do remain-on-channel while idle
The IDLE handling in HW off-channel is broken right
now since we turn off IDLE only when the off-channel
period already started. Therefore, all drivers that
use it today (only iwlwifi!) must support off-channel
while idle, so playing with idle isn't needed at all.

Off-channel in general, since it's no longer used for
authentication/association, shouldn't affect PS, so
also remove that logic.

Also document a small caveat for reporting TX status
from off-channel frames in HW remain-on-channel.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-06 15:20:33 -04:00