Currently, get_wireless_stats is racy by _design_. This is
because it returns a buffer, which needs to be statically
allocated since it cannot be freed if it was allocated
dynamically. Also, SIOCGIWSTATS and /proc/net/wireless use
no common lock, and /proc/net/wireless accesses are not
synchronised against each other. This is a design flaw in
get_wireless_stats since the beginning.
This patch fixes it by wrapping /proc/net/wireless accesses
with the RTNL so they are protected against each other and
SIOCGIWSTATS. The more correct method of fixing this would
be to pass in the buffer instead of returning it and have
the caller take care of synchronisation of the buffer, but
even then most drivers probably assume that their callback
is protected by the RTNL like all other wext callbacks.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On non-AP interfaces userspace has no business interfering with
the station management, this can confuse mac80211 (and other
drivers probably wouldn't support it anyway). Allow adding and
removing stations only on AP interfaces.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
To make it more apparent in the code what is for wext
only (and needs to be #ifdef'ed) put all the info for
wext into a substruct in each wireless_dev.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The address pointed to by mac_addr can be marked as const.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When we disassociate, we set the channel to non-HT which
obviously invalidates any ht_operation_mode setting. But
when we then associate with the next AP again, we might
still have the ht_operation_mode from the previous AP
cached and fail to configure the hardware with the new
(but unchanged) operation mode. This patch fixes it by
separately tracking whether our cache is valid.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There really is no need to have a separate struct for a
single variable. The fact that it exists is due to the
code legacy, but we can remove that now. Very simple.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The call to ieee80211_hw_config() is supposed to apply changes
synchronously, so once it returns the parameters are applied to
the hardware. Thus, there really is no need to delay the probing
by the channel switch time again since the channel switch has
already happened once we get to this code.
Additionally, there is no need to wait for a NAV update (probe
delay) when the channel is passively scanned. Remove that extra
time too.
This cuts scanning time from over 7 seconds to under 4 on ar9170,
which is due to the number of channels scanned and ar9170's switch
time being advertised as 135ms (my test now indicates it is about
77ms with the current driver, but the difference might also be due
to using a different machine with different USB controllers).
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When management frame protection (IEEE 802.11w) is used, unprotected
Robust Action frames are not allowed prior to key configuration.
However, unprotected Deauthentication and Disassociation frames are
allowed at that point, but not after key configuration.
Make ieee80211_drop_unencrypted() handle the special cases for MFP by
separating the basic Data frame case from Management frame processing
and handle the Management frames only if MFP has been negotiated. In
addition, do not use sdata->drop_unencrypted for Management frames
since the decision on whether to accept the frame depends on the key
being configured.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When using nl80211, we do not have a mechanism to set
sdata->drop_unencrypted. Currently, this breaks code that is supposed
to drop unencrypted frames when protection is expected since
ieee80211_rx_h_decrypt() is optimized to not set rx->key when the
frame is not protected.
This patch modifies ieee80211_rx_h_decrypt() to set rx->key for all
frames and only skip decryption if the frame is not protected. This
allows ieee80211_drop_unencrypted() to correctly drop frames even if
drop_unencrypted is not set.
The changes here are not enough to handle all cases, though. Additional
patches will be needed to implement proper IEEE 802.1X PAE for station
mode (currently, this is only used for AP mode) and some additional
rules are needed for MFP to drop unprotected Robust Action frames prior
to having PTK and IGTK configured.
In theory, the unprotected frames could and should be dropped in
ieee80211_rx_h_decrypt(). However, due to the special case with EAPOL
frames that have to be allowed to be received unprotected even when
keys are set, it is simpler to only set rx->key and allow the
ieee80211_frame_allowed() function to handle the actual dropping of
data frames after 802.11->802.3 header conversion. In addition,
unprotected robust management frames are dropped before they are
processed.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The function to parse a struct iw_freq has a stupid bug,
it returns NULL when the channel cannot be found at all,
but NULL is supposed to mean "auto". Fix this by checking
the return value of ieee80211_get_channel() and returning
ERR_PTR(-EINVAL) if it returned NULL (channel not found).
This fixes an issue where you could say (in IBSS mode)
iwconfig wlan0 channel 21
and it would use channel 1 instead because that's the
first available channel with IBSS allowed (which is what
the "auto" setting uses).
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We've never really cared about the default QoS (WMM) values, but
we really should if the AP doesn't send any. This patch makes
mac80211 use the default values according to 802.11-2007, and
additionally syncs the default values when we disassociate so
whatever the last AP said gets "unconfigured".
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When a software scan starts, it first sets sw_scanning, but
leaves the scan_channel "unset" (it currently actually gets
initialised to a default). Now, when something else tries
to (re)configure the hardware in the window between these two
events (after sw_scanning = true, but before scan_channel is
set), the current code switches to the (unset!) scan_channel.
This causes trouble, especially when switching bands and
sending frames on the wrong channel.
To work around this, leave scan_channel initialised to NULL
and use it to determine whether or not a switch to a different
channel should occur (and also use the same condition to check
whether to adjust power for scan or not).
Additionally, avoid reconfiguring the hardware completely when
recalculating idle resulted in no changes, this was the problem
that originally led us to discover the race condition in the
first place, which was helpfully bisected by Pavel. This part
of the patch should not be necessary with the other fixes, but
not calling the ieee80211_hw_config function when we know it to
be unnecessary is certainly a correct thing to do.
Unfortunately, this patch cannot and does not fix the race
condition completely, but due to the way the scan code is
structured it makes the particular problem Pavel discovered
(race while changing channel at the same time as transmitting
frames) go away. To fix it completely, more work especially
with locking configuration is needed.
Bisected-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
NL80211_CMD_ASSOCIATE request must be able to indicate whether
management frame protection (IEEE 802.11w) is being used. mac80211 was
able to use MFP in client mode only with WEXT, but the new
NL80211_ATTR_USE_MFP attribute will allow this to be done with
nl80211, too.
Since we are currently using nl80211 for MFP only with drivers that
use user space SME, only MFP disabled and required values are
used. However, the NL80211_ATTR_USE_MFP attribute is an enum that can
be extended with MFP optional in the future, if that is needed with
some drivers (e.g., if the RSN IE is generated by the driver).
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add missed checking of dev_addr_init return value in alloc_netdev_mq.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
net/core/dev.c | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit ead2ceb0ec ("Network Drop Monitor:
Adding kfree_skb_clean for non-drops and modifying end-of-line points
for skbs") established new conventions for identifying dropped packets.
Align skb_kill_datagram() with these conventions so that packets that
get dropped just before the copy to userspace are properly tracked.
Signed-off-by: John Dykstra <john.dykstra1@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ashish Karkare <akarkare@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
By separating the freeing code from the refcounting decrementing.
Probably reducing icache pressure when we still have reference counts to
go.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit ac45f602ee ("net: infrastructure
for hardware time stamping") added two skb initialization actions to
__alloc_skb(), which need to be added to skb_recycle_check() as well.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When no limit is given, the bfifo uses a default of tx_queue_len * mtu.
Packets handled by qdiscs include the link layer header, so this should
be taken into account, similar to what other qdiscs do.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a new wimax_dev is created, it's state has to be __WIMAX_ST_NULL
until wimax_dev_add() is succesfully called. This allows calls into
the stack that happen before said time to be rejected.
Until now, the state was being set (by mistake) to UNINITIALIZED,
which was allowing calls such as wimax_report_rfkill_hw() to go
through even when a call to wimax_dev_add() had failed; that was
causing an oops when touching uninitialized data.
This situation is normal when the device starts reporting state before
the whole initialization has been completed. It just has to be dealt
with.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
When sending a message to user space using wimax_msg(), if nla_put()
fails, correctly interpret the return code from wimax_msg_alloc() as
an err ptr and return the error code instead of crashing (as it is
assuming than non-NULL means the pointer is ok).
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
We are currently processing block ack reordering as a separate task
before all other RX handlers. In theory, this is wrong since this step
should be done only after duplicate removal (see Figure 6-1 in IEEE
802.11n). However, moving this needs some work and the current
situation is not too bad. Add a comment here so that this small detail
does not get forgotten and who knows, maybe someone has some extra
time to take a look at cleaning this up.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch allows skbs to be released from the RX reorder buffer in
case they have been there for an unexpectedly long time without us
having received the missing frames before them. Previously, these
frames were only released when the reorder window moved and that could
take very long time unless new frames were received constantly (e.g.,
TCP connections could be killed more or less indefinitely).
This situation should not happen very frequently, but it looks like
there are some scenarious that trigger it for some reason. As such,
this should be considered mostly a workaround to speed up recovery
from unexpected siutation that could result in connections hanging for
long periods of time.
The changes here will only check for timeout situation when adding new
RX frames to the reorder buffer. It does not handle all possible
cases, but seems to help for most cases that could result from common
network usage (e.g., TCP retrying at least couple of times). For more
completely coverage, a timer could be used to periodically check
whether there are any frames remaining in the reorder buffer if no new
frames are received.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
No need to duplicate the same code in two places (and that would be
three after the followup patch).
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
net/mac80211/mlme.c:2079:28: warning: symbol 'ssid_len' shadows an earlier one
net/mac80211/mlme.c:2022:12: originally declared here
ssid_len is already being declared and checked above so there is
no need for it again.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It's not very helpful to see, in iwconfig, the current frequency
the card is tuned to if that frequency is currently somewhere
across the board because we're scanning. Since we keep track of
the frequency the user wants, display that instead.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fixes sparse complaint:
CHECK net/wireless/nl80211.c
net/wireless/nl80211.c:3694:6:
warning: symbol 'nl80211_send_mlme_timeout'
was not declared. Should it be static?
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When we aren't doing anything in mac80211, we can turn off
much of the hardware, depending on the driver/hw. Not doing
anything, aka being idle, means:
* no monitor interfaces
* no AP/mesh/wds interfaces
* any station interfaces are in DISABLED state
* any IBSS interfaces aren't trying to be in a network
* we aren't trying to scan
By creating a new function that verifies these conditions and calling
it at strategic points where the states of those conditions change,
we can easily make mac80211 tell the driver when we are idle to save
power.
Additionally, this fixes a small quirk where a recalculated powersave
state is passed to the driver even if the hardware is about to stopped
completely.
This patch intentionally doesn't touch radio_enabled because that is
currently implemented to be a soft rfkill which is inappropriate here
when we need to be able to wake up with low latency.
One thing I'm not entirely sure about is this:
phy0: device no longer idle - in use
wlan0: direct probe to AP 00:11:24:91:07:4d try 1
wlan0 direct probe responded
wlan0: authenticate with AP 00:11:24:91:07:4d
wlan0: authenticated
> phy0: device now idle
> phy0: device no longer idle - in use
wlan0: associate with AP 00:11:24:91:07:4d
wlan0: RX AssocResp from 00:11:24:91:07:4d (capab=0x401 status=0 aid=1)
wlan0: associated
Is it appropriate to go into idle state for a short time when we have
just authenticated, but not associated yet? This happens only with the
userspace SME, because we cannot really know how long it will wait
before asking us to associate. Would going idle after a short timeout
be more appropriate? We may need to revisit this, depending on what
happens.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
To deter future rate scaling algorithm writers from requesting NO_ACK
packets to be retried, throw a WARN_ON_ONCE if the algorithm hands us
a try count over 1 for NO_ACK packet.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Make PID check for IEEE80211_TX_CTL_NO_ACK instead of
is_multicast_ether_addr when determining whether to use the lowest
rate, and set the retry count to 0 (total try count = 1) if
IEEE80211_TX_CTL_NO_ACK is set.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Make the retry count zero (total try count = 1) for frames with
IEEE80211_TX_CTL_NO_ACK set.
Also remove the check for is_multicast_ether_addr in use_low_rate,
which is redundant because all multicasts have IEEE80211_TX_CTL_NO_ACK
set.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If the IE buffer was allocated, the pub.information_elements pointer
was also changed to the allocated space. So we must not assume anymore
that the pointer points at the "found" tail.
So if it was allocated previously, take the codebranch that grows the
buffer size (if necessary) and put the data into the allocated buffer.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This removes an unnecessary ksize() call. krealloc() will do this
test internally and won't perform any allocation if the space is
already sufficient to hold the data.
So remove the redundant check.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
net/rfkill/rfkill.c: In function 'update_rfkill_state':
net/rfkill/rfkill.c:99: error: implicit declaration of function 'rfkill_led_trigger'
Caused by
: commit 492301fb5d
: Author: Larry Finger <Larry.Finger@lwfinger.net>
: Date: Thu Apr 9 22:14:19 2009 -0500
:
: rfkill: Fix broken rfkill LED in 2.6.30-rc1
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: Michael Buesch <mb@bu3sch.de>
Cc: David S. Miller <davem@davemloft.net>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit 0ad8acaf "cfg80211: fix NULL pointer deference in
reg_device_remove()" added a check that last_request is non-NULL,
rendering the 2nd check superfluous. While there, rearrange the code a
bit so it's a little more straight forward.
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Due to the use of a _REQ_DIRECT_PROBE bit, which is
unnecessary (and I wonder why it was done that way),
an interesting situation can arise:
1) we try to probe an access point
2) the AP doesn't response in time
3) we tell userspace that we gave up
4) the AP suddenly responds
5) we auth/assoc with the AP
I've seen 4) happen in testing with hostapd SIGSTOPped,
and when SIGCONTinued it processes the probe requests
that came in and send responses. But 5) is not supposed
to happen after we tell everybody we've given up on the
AP.
To fix this, remove the _REQ_DIRECT_PROBE request bit,
and process probe responses when we're in the relevant
MLME state, namely IEEE80211_STA_MLME_DIRECT_PROBE.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If the direct probe times out, we need to send the authentication
timeout event to notify SME in the same way as we notify on timeout
with authentication frames since the direct probe is run as part of
the authentication attempt.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In order to later add tracing or verifications to the driver
calls mac80211 makes, this patch adds static inline wrappers
for all operations.
All calls are now written as
drv_<op>(local, ...);
instead of
local->ops-><op>(&local->hw, ...);
Where necessary, the wrappers also do existence checking and
return default values as appropriate.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The config_interface method is a little strange, it contains the
BSSID and beacon updates, while bss_info_changed contains most
other BSS information for each interface. This patch removes
config_interface and rolls all the information it previously
passed to drivers into bss_info_changed.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We currently have two beacon interval configuration knobs:
hw.conf.beacon_int and vif.bss_info.beacon_int. This is
rather confusing, even though the former is used when we
beacon ourselves and the latter when we are associated to
an AP.
This just deprecates the hw.conf.beacon_int setting in favour
of always using vif.bss_info.beacon_int. Since it touches all
the beaconing IBSS code anyway, we can also add support for
the cfg80211 IBSS beacon interval configuration easily.
NOTE: The hw.conf.beacon_int setting is retained for now due
to drivers still using it -- I couldn't untangle all
drivers, some are updated in this patch.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are some places marked
/* XXX maybe racy? */
and they really are racy because there's no locking.
This patch reworks much of the scan code, and introduces proper
locking for the scan request as well as the internal scanning
(which is necessary for IBSS/managed modes). Helper functions
are added to call the scanning code whenever necessary. The
scan deferring is changed to simply queue the scanning work
instead of trying to start the scan in place, the scanning work
will then take care of the rest.
Also, currently when internal scans are requested for an interface
that is trying to associate, we reject such scans. This was not
intended, the mlme code has provisions to scan twice when it can't
find the BSS to associate with right away; this has never worked
properly. Fix this by not rejecting internal scan requests for an
interface that is associating.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the IBSS code wants to scan, but that fails, we can
get stuck in a situation where you can never scan again.
Fix this by properly notifying ourselves when the scan
request has failed.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Kalle points out that max_sleep_interval is somewhat confusing
because the value is measured in beacon intervals, and not in
TU. Rename it to max_sleep_period to be consistent with things
like DTIM period that are also measured in beacon intervals.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When somebody changes the PS parameters while scanning
is in progress, we enable PS -- during the scan. This
is clearly not desirable, and we can just abort enabling
PS when scanning since when the scan finishes it will
be taken care of.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Reviewed-by: Kalle Valo <kalle.valo@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are a few problems in the IBSS code:
a) it tries to activate interfaces that are down after scanning
b) it crashes after scanning on an IBSS iface that isn't active
c) since the ssid_len is used as a flag, need to make it visible
only after all other settings are set, this helps protect
against b)
For b), we get a system crash:
wlan0: Creating new IBSS network, BSSID ce:f9:88:76:1e:4d
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<...>] ieee80211_sta_find_ibss+0x294/0x37d [mac80211]
Call Trace:
[<...>] ieee80211_ibss_notify_scan_completed+0x0/0x88 [mac80211]
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg