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>
Remove not used any longer suspend/resume code.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The VHT MCSes we advertise to the AP were supposed to
be restricted to the AP, but due to a bug in the logic
mac80211 will advertise rates to the AP that aren't
even supported by the local device. To fix this skip
any adjustment if the NSS isn't supported at all.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some mlme work structs are not cancelled on disassociation
nor interface deletion, which leads to them running after
the memory has been freed
There is not a clean way to cancel these in the disassociation
logic because they must be canceled outside of the ifmgd->mtx
lock, so just cancel them in mgd_stop logic that tears down
the station.
This fixes the crashes we see in 3.7.9+. The crash stack
trace itself isn't so helpful, but this warning gives
more useful info:
WARNING: at /home/greearb/git/linux-3.7.dev.y/lib/debugobjects.c:261 debug_print_object+0x7c/0x8d()
ODEBUG: free active (active state 0) object type: work_struct hint: ieee80211_sta_monitor_work+0x0/0x14 [mac80211]
Modules linked in: [...]
Pid: 14743, comm: iw Tainted: G C O 3.7.9+ #11
Call Trace:
[<ffffffff81087ef8>] warn_slowpath_common+0x80/0x98
[<ffffffff81087fa4>] warn_slowpath_fmt+0x41/0x43
[<ffffffff812a2608>] debug_print_object+0x7c/0x8d
[<ffffffff812a2bca>] debug_check_no_obj_freed+0x95/0x1c3
[<ffffffff8114cc69>] slab_free_hook+0x70/0x79
[<ffffffff8114ea3e>] kfree+0x62/0xb7
[<ffffffff8149f465>] netdev_release+0x39/0x3e
[<ffffffff8136ad67>] device_release+0x52/0x8a
[<ffffffff812937db>] kobject_release+0x121/0x158
[<ffffffff81293612>] kobject_put+0x4c/0x50
[<ffffffff8148f0d7>] netdev_run_todo+0x25c/0x27e
Cc: stable@vger.kernel.org
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Re-order the quiesce code so that timers are always
stopped before work-items are flushed. This was not
the problem I saw, but I think it may still be more
correct.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Even when connecting to an AP that doesn't support VHT,
and even when the local device doesn't support it either,
the downgrade message gets printed. Suppress the message
if HT and/or VHT is disabled.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
A while ago, I made the mac80211 station code never change
the channel type after association. This solved a number of
issues but is ultimately wrong, we should react if the AP
changes the HT operation IE and switches bandwidth. One of
the issues is that we associate as HT40 capable, but if the
AP ever switches to 40 MHz we won't be able to receive such
frames because we never set our channel to 40 MHz.
This addresses this and VHT operation changes. If there's a
change that is incompatible with our setup, e.g. if the AP
decides to change the channel entirely (and for some reason
we still hear the beacon) we'll just disconnect.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The channel use is confusing, some uses the channel
context and some the bss_conf.chandef. The latter is
fine, so get rid of the channel context part.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Having HT/VHT operation IEs but not capability IEs
leads to a strange situation where we configure the
channel to an HT or VHT bandwidth and then can't
actually use it. Prevent this by checking that the
HT and VHT capability IEs are present as well as
the operation IEs; if not, disable HT and/or VHT.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In beacons and association response frames an AP may include an
operating mode notification element to advertise changes in the
number of spatial streams it can receive. Handle this using the
existing function that handles the action frame, but only handle
NSS changes, not bandwidth changes which aren't allowed here.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The code to disable HT and VHT if VHT was advertised
without VHT is wrong -- it accidentally uses the wrong
flags. Fix that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In case of connection, the station data is initialised from
the beacon/probe response first and then updated from the
association response. If the latter is different we update
the rate control algorithm and driver. Instead of doing it
this way, set the station data properly with data from the
association response before initializing rate control.
Also simplify the code by passing the station pointer.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For VHT, many more bandwidth changes are possible. As a first
step, stop toggling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 flag
in the HT capabilities and instead introduce a bandwidth field
indicating the currently usable bandwidth to transmit to the
station. Of course, make all drivers use it.
To achieve this, make ieee80211_ht_cap_ie_to_sta_ht_cap() get
the station as an argument, rather than the new capabilities,
so it can set up the new bandwidth field.
If the station is a VHT station and VHT bandwidth is in use,
also set the bandwidth accordingly.
Doing this allows us to get rid of the supports_40mhz flag as
the HT capabilities now reflect the true capability instead of
the current setting.
While at it, also fix ieee80211_ht_cap_ie_to_sta_ht_cap() to not
ignore HT cap overrides when MCS TX isn't supported (not that it
really happens...)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Like with HT, make things a bit simpler in future patches by
passing the station to ieee80211_vht_cap_ie_to_sta_vht_cap()
instead of the vht_cap pointer. Also disable VHT here if HT
isn't supported.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In some cases when disconnecting after (or during?) CSA
the queues might not recover, and then the only way to
recover is reloading the module.
Fix this by always unblocking the queue CSA reason when
disconnecting.
Cc: stable@vger.kernel.org
Reported-by: Jan-Michael Brummer <jan.brummer@tabos.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In my commit 1672c0e319
("mac80211: start auth/assoc timeout on frame status")
I broke auth/assoc timeout handling: in case we wait
for the TX status, it now leaves the timeout field set
to 0, which is a valid time and can compare as being
before now ("jiffies"). Thus, if the work struct runs
for some other reason, the auth/assoc is treated as
having timed out.
Fix this by introducing a separate "timeout_started"
variable that tracks whether the timeout has started
and is checked before timing out.
Additionally, for proper TX status handling the change
requires that the skb->dev pointer is set up for all
the frames, so set it up for all frames in mac80211.
Reported-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com>
Tested-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Function ieee80211_sta_reset_conn_monitor has been
resetting probe_send_count too early and nullfunc
check was never called after succesfull ack.
Reported-by: Magnus Cederlöf <mcider@gmail.com>
Tested-by: Magnus Cederlöf <mcider@gmail.com>
Signed-off-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add command to trigger radar detection in the driver/FW.
Once radar detection is started it should continuously
monitor for radars as long as the channel active.
If radar is detected usermode notified with 'radar
detected' event.
Scanning and remain on channel functionality must be disabled
while doing radar detection/scanning, and vice versa.
Based on original patch by Victor Goldenshtein <victorg@ti.com>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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>
When we get to association, the AP station already exists and
is marked authenticated, so moving it into IEEE80211_STA_AUTH
again is a NOP, remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Now that we have channel contexts, idle is (pretty
much) equivalent to not having a channel context.
Change the code to use this relation so that there
no longer is a need for a lot of idle recalculate
calls everywhere.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The functions were added for some sort of Bluetooth
coexistence, but aren't used, so remove them again.
Reviewed-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In order to be able to predict the next DTIM TBTT
in the driver, add the ability to use timing data
from beacons only with the new hardware flag
IEEE80211_HW_TIMING_BEACON_ONLY and the BSS info
value sync_dtim_count which is only valid if the
timing data came from a beacon. The data can only
come from a beacon, and if no beacon was received
before association it is updated later together
with the DTIM count notification.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
While technically the TSF isn't an IE, it can be
necessary to distinguish between the TSF from a
beacon and a probe response, in particular in
order to know the next DTIM TBTT, as not all APs
are spec compliant wrt. TSF==0 being a DTIM TBTT
and thus the DTIM count needs to be taken into
account as well.
To allow this, move the TSF into the IE struct
so it can be known whence it came.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The messages currently refer to probe request probes,
but on some devices null data packets will be used
instead. Make the messages more generic.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This prepares for using the spinlock instead of krefs
which is needed in the next patch to track the refs
of combined BSSes correctly.
Acked-by: Bing Zhao <bzhao@marvell.com> [mwifiex]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When trying to connect to an AP that advertises HT but not
VHT, the mac80211 code erroneously uses the configuration
from the AP as is instead of checking it against regulatory
and local capabilities. This can lead to using an invalid
or even inexistent channel (like 11/HT40+).
Additionally, the return flags from downgrading must be
ORed together, to collect them from all of the downgrades.
Also clarify the message.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
My commit f2d9d270c1
("mac80211: support VHT association") introduced a
very stupid bug: the loop to downgrade the channel
width never attempted to actually use it again so
it would downgrade all the way to 20_NOHT. Fix it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the driver determined the connection was lost or that
it couldn't securely maintain the connection when coming
out of WoWLAN, send a deauth frame to the AP to also let
it know.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
With multi-channel, there's a corner case where a driver
doesn't receive a beacon soon enough to be able to sync
its timers with the AP. In this case, the only recovery
(after trying again) is to disconnect from the AP. Allow
calling ieee80211_connection_loss() for such cases. To
make that possible, modify the work function to not rely
on the IEEE80211_HW_CONNECTION_MONITOR flag but use new
state kept in the interface instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the driver determines the connection is lost,
send a deauth frame to the AP anyway just in case
it still considers the connection alive. The frame
might not go through, but at least we've tried.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When sending authentication/association frames they
might take a bit of time to go out because we may
have to synchronise with the AP, in particular in
the case where it's really a P2P GO. In this case
the 200ms fixed timeout could potentially be too
short if the beacon interval is relatively large.
For drivers that report TX status we can do better.
Instead of starting the timeout directly, start it
only when the frame status arrives. Since then the
frame was out on the air, we can wait shorter (the
typical response time is supposed to be 30ms, wait
100ms.) Also, if the frame failed to be transmitted
try again right away instead of waiting.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, when the driver requires the DTIM period,
mac80211 will wait to hear a beacon before association.
This behavior is suboptimal since some drivers may be
able to deal with knowing the DTIM period after the
association, if they get it at all.
To address this, notify the drivers with bss_info_changed
with the new BSS_CHANGED_DTIM_PERIOD flag when the DTIM
becomes known. This might be when changing to associated,
or later when the entire association was done with only
probe response information.
Rename the hardware flag for the current behaviour to
IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC to more accurately
reflect its behaviour. IEEE80211_HW_NEED_DTIM_PERIOD is
no longer accurate as all drivers get the DTIM period
now, just not before association.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's no need to have two checks for "associated"
in ieee80211_sta_restart(), make the first one locked
to not race (unlikely at this point during resume)
and remove the second check.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For drivers that don't actually flush their queues when
aggregation stop with the IEEE80211_AMPDU_TX_STOP_FLUSH
or IEEE80211_AMPDU_TX_STOP_FLUSH_CONT reasons is done,
like iwlwifi or iwlegacy, mac80211 can then transmit on
a TID that the driver still considers busy. This happens
in the following way:
- IEEE80211_AMPDU_TX_STOP_FLUSH requested
- driver marks TID as emptying
- mac80211 removes tid_tx data, this can copy packets
to the TX pending queues and also let new packets
through to the driver
- driver gets unexpected TX as it wasn't completely
converted to the new API
In iwlwifi, this lead to the following warning:
WARNING: at drivers/net/wireless/iwlwifi/dvm/tx.c:442 iwlagn_tx_skb+0xc47/0xce0
Tx while agg.state = 4
Modules linked in: [...]
Pid: 0, comm: kworker/0:0 Tainted: G W 3.1.0 #1
Call Trace:
[<c1046e42>] warn_slowpath_common+0x72/0xa0
[<c1046f13>] warn_slowpath_fmt+0x33/0x40
[<fddffa17>] iwlagn_tx_skb+0xc47/0xce0 [iwldvm]
[<fddfcaa3>] iwlagn_mac_tx+0x23/0x40 [iwldvm]
[<fd8c98b6>] __ieee80211_tx+0xf6/0x3c0 [mac80211]
[<fd8cbe00>] ieee80211_tx+0xd0/0x100 [mac80211]
[<fd8cc176>] ieee80211_xmit+0x96/0xe0 [mac80211]
[<fd8cc578>] ieee80211_subif_start_xmit+0x348/0xc80 [mac80211]
[<c1445207>] dev_hard_start_xmit+0x337/0x6d0
[<c145eee9>] sch_direct_xmit+0xa9/0x210
[<c14462c0>] dev_queue_xmit+0x1b0/0x8e0
Fortunately, solving this problem is easy as the station
is being destroyed, so such transmit packets can only
happen due to races. Instead of trying to close the race
just let the race not reach the drivers by making two
changes:
1) remove the explicit aggregation session teardown in
the managed mode code, the same thing will be done
when the station is removed, in __sta_info_destroy.
2) When aggregation stop with AGG_STOP_DESTROY_STA is
requested, leave the tid_tx data around as stopped.
It will be cleared and freed in cleanup_single_sta
later, but until then any racy packets will be put
onto the tid_tx pending queue instead of transmitted
which is fine since the station is being removed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since drivers can support several BSS / P2P Client
interfaces, the rssi callback needs to inform the driver
about the interface teh rssi event relates to.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Depending on the driver, having ARP filtering for
some addresses may be possible. Remove the logic
that tracks whether ARP filter is enabled or not
and give the driver the total number of addresses
instead of the length of the list so it can make
its own decision.
Reviewed-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The initiator/tx doesn't really identify why an
aggregation session is stopped, give a reason
for stopping that more clearly identifies what's
going on. This will help tell the driver clearly
what is expected of it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In interoperability testing some APs showed bad behaviour
if some of the VHT capabilities of the station are better
than their own. Restrict the assoc request parameters
- beamformee capabable,
- RX STBC and
- RX MCS set
to the subset that the AP can support.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The probe response/beacon management frame RX code passes a
bool parameter to differentiate beacons and probe responses.
This is useless since we have the frame and can thus use its
frame control field. Moreover it is buggy since there is one
call to ieee80211_rx_bss_info with a beacon frame that is
indicated as a probe response, which is also fixed by using
the frame control field, so do that.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The last fixes re-added the RCU synchronize penalty
on roaming to fix the races. Split up sta_info_flush()
now to get rid of that again, and let managed mode
(and only it) delay the actual destruction.
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When all interfaces have been removed, there can't
be any stations left over, so there's no need to
flush again. Remove this, and all code associated
with it, which also simplifies the function.
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When AP's SSID is hidden the BSS can appear several times in
cfg80211's BSS list: once with a zero-length SSID that comes
from the beacon, and once for each SSID from probe reponses.
Since the mac80211 stores its data in ieee80211_bss which
is embedded into cfg80211_bss, mac80211's data will be
duplicated too.
This becomes a problem when a driver needs the dtim_period
since this data exists only in the beacon's instance in
cfg80211 bss table which isn't the instance that is used
when associating.
Remove the DTIM period from the BSS table and track it
explicitly to avoid this problem.
Cc: stable@vger.kernel.org
Tested-by: Efi Tubul <efi.tubul@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If channel contexts are enabled, the CSA should not be processed
further. A return is missing here.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When a BSS struct is updated, the IEs are currently
overwritten or freed. This can lead to races if some
other CPU is accessing the BSS struct and using the
IEs concurrently.
Fix this by always allocating the IEs in a new struct
that holds the data and length and protecting access
to this new struct with RCU.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Determine the VHT channel from the AP's VHT operation IE
(if present) and configure the hardware to that channel
if it is supported. If channel contexts cause a channel
to not be usable, try a smaller bandwidth.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Convert mac80211 (and where necessary, some drivers a
little bit) to the new channel definition struct.
This will allow extending mac80211 for VHT, which is
currently restricted to channel contexts since there
are no drivers using that which makes it easier. As
I also don't care about VHT for drivers not using the
channel context API, I won't convert the previous API
to VHT support.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If ieee80211_prep_channel() decides that HT should be
disabled (because the HT IEs from the AP were invalid)
it will set the IEEE80211_STA_DISABLE_HT to not send
HT capabilities to the AP when associating. If this
happens during authentication, the flag will be lost
and we send HT frames, even if the channel config was
set up for non-HT. This can lead to issues.
Fix this by always resetting the ifmgd flags to zero
when the channel context is released so that the flag
resetting in ieee80211_mgd_assoc() isn't necessary.
To make the code a bit easier move the call to release
the channel in ieee80211_set_disassoc() to the end of
the function together with the flag resetting (which
needs to be at the end to avoid timers setting flags.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the AP doesn't support HT, or more importantly if
it does but we have to disable it because its IEs are
broken, don't advertise HT support in our association
request. Otherwise, we configure our channel to be a
20 MHz non-HT channel but the AP might still think we
support HT, or even 40 MHz.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since the 11n spec amendment was rolled into the
2012 version, "11n" no longer makes sense. Use
"HT" instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the driver doesn't support 40 MHz channels, then
mac80211 erroneously sets number of RX chains to one
although the number of chains is independent of the
support for 40 MHz channels.
Fix this by checking the 40 MHz support only for the
code that sets the 40 MHz channel not the complete
HT code block.
This also means the HT20 channel type will always be
set in the changed code block so there's no need to
set it in case we override the AP due to invalid IEs
in the probe response/beacon.
The indentation is a bit quirky, but I'm rewriting
this code for VHT support so this will change again
very soon.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
While connected to a GO, parse the P2P NoA attribute
and pass the CT Window and opportunistic powersave
parameters to the driver.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When userspace asks to deauthenticate and we're just
authenticated (or still authenticating) send a deauth
frame instead of deleting the auth request.
On the other hand, if we've just disassociated and
therefore deleted all our state already, drop the
deauth request because we no longer have a channel
context to send it on.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Even before channel contexts/multi-channel, having a
single global TX power limit was already problematic,
in particular if two managed interfaces connected to
two APs with different power constraints. The channel
context introduction completely broke this though and
in fact I had disabled TX power configuration there
for drivers using channel contexts.
Change everything to track TX power per interface so
that different user settings and different channel
maxima are treated correctly. Also continue tracking
the global TX power though for compatibility with
applications that attempt to configure the wiphy's
TX power globally.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Remove a duplicate check in ieee80211_rx_mgmt_beacon,
there is no need to make again the same check for the
IEEE80211_HW_PS_NULLFUNC_STACK twice; the two ifs can
be consolidated.
Signed-off-by: Rami Rosen <ramirose@gmail.com>
[reword commit message & break long lines and also
clean up variable]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are a number of unused variables that gcc
pointed out (when building with W=1) as well as
some conditions that can never be true due to
the datatypes used: unsigned values can't be
less than zero. Remove this code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some changes to fix issues with HT40 APs in Korea
and follow-up changes to allow using HT40 even if
the local regulatory database disallows it caused
issues with iwlwifi (and could cause issues with
other devices); iwlwifi firmware would assert if
you tried to connect to an AP that has an invalid
configuration (e.g. using HT40- on channel 140.)
Fix this, while avoiding the "Korean AP" issue by
disabling HT40 and advertising HT20 to the AP
when connecting.
Cc: stable@vger.kernel.org [3.6]
Reported-by: Florian Reitmeir <florian@reitmeir.org>
Tested-by: Florian Reitmeir <florian@reitmeir.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Save the AP's VHT capabilities (in managed
mode) and make them available to the driver
in the station information.
Unlike HT capabilities, they aren't restricted
to the common capabilities, so drivers must be
aware of their own capabilities.
Signed-off-by: Mahesh Palivela <maheshp@posedge.com>
[fix endian conversion bug ...]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Rename struct ieee80211_vht_capabilities to ieee80211_vht_cap
and renamed its member vht_capabilities_info to vht_cap_info.
Signed-off-by: Mahesh Palivela <maheshp@posedge.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
SAE uses two rounds of Authentication frames and both rounds require
considerable calculation to be done. This commit extends the existing
station mode authentication request to allow more control for user
space programs to build the SAE fields and to run the authentication
step ones. Only the second round with authentication transaction
sequence 2 will result in moving to authenticated state.
Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is useful when debugging authentication process issues.
Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Non-zero status code may be needed for Authentication frames, e.g.,
when using SAE.
Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
On each channel that the device is operating on, it
may need to listen using one or more chains depending
on the SMPS settings of the interfaces using it. The
previous channel context changes completely removed
this ability (before, it was available as the SMPS
mode).
Add per-context tracking of the required static and
dynamic RX chains and notify the driver on changes.
To achieve this, track the chains and SMPS mode used
on each virtual interface and update the channel
context whenever this changes.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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>
Avoid situation when we are on associate state in mac80211 and
on disassociate state in cfg80211. This can results on crash
during modules unload (like showed on this thread:
http://marc.info/?t=134373976300001&r=1&w=2) and possibly other
problems.
Reported-by: Pedro Francisco <pedrogfrancisco@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When we disassociate, it's not really useful to
send delBA action frames since we're going to send
disassoc/deauth anyway, so change that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, mac80211 uses the power constraint IE, and reduces
the regulatory max TX power by it. This can cause issues if
the AP is advertising a large power constraint value matching
a high TX power in its country IE, for example in this case:
...
Country: US Environment: Indoor/Outdoor
...
Channels [157 - 157] @ 30 dBm
...
Power constraint: 13 dB
...
What happened here is that our local regulatory TX power is
15 dBm, and gets reduced by 13 dB so we end up with only
2 dBm effective TX power, which is way too low.
Instead, handle the country IE/power constraint IE combined
and restrict our TX power to the max of the regulatory power
and the maximum power advertised by the AP, in this case
17 dBm (= 30 dBm - 13 dB).
Also print a message when this happens to let the user know
and help us debug issues with it.
Reported-by: Carl A. Cook <CACook@quantum-equities.com>
Tested-by: Carl A. Cook <CACook@quantum-equities.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Move ieee80211_send_deauth_disassoc() to util.c to make it
available for the rest of the mac80211 code.
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
[reword commit message]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The power constraint IE is always a single byte
so check the size when parsing instead of later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Disconnect from the AP if channel switching in the
driver failed or if the new channel is unavailable.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Pull in mac80211.git to let the next patch apply
without conflicts, also resolving a hwsim conflict.
Conflicts:
drivers/net/wireless/mac80211_hwsim.c
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ifmgd->bssid wasn't cleared properly in some
auth/assoc failure cases, causing mac80211 and
the low-level driver to go out of sync.
Clear ifmgd->bssid on failure, and notify the driver.
Cc: stable@kernel.org # 3.4+
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In multi-channel scenarios, the channel that we will
transmit a probe request on isn't always the current
channel (which will be NULL anyway) but will instead
be the channel that the AP is on. Pass the channel
to the ieee80211_send_probe_req() function so it can
be used in the different scenarios. The scan code
continues to pass the current channel, of course.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's no need to declare the function in the
header file since it's only used in a single
place, so make it static.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The channel switch IE has a fixed size, so we can
discard it in parsing if it's not the right size
and use the right struct pointer.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The time until the channel switch is in TU,
not in milliseconds, so use TU_TO_EXP_TIME()
to correctly program the timer.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Clean up the CSA handling code by moving some
of it out of the if and using a C99 initializer
for the struct passed to the driver method.
While at it, also add a comment that we should
wait for a beacon after switching the channel.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's a corner case that can happen when we
suspend with a timer running, then resume and
disconnect. If we connect again, suspend and
resume we might start timers that shouldn't be
running. Reset the timer flags to avoid this.
This affects both mesh and managed modes.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When associating anew, the old station MLME flags should
be cleared. The only exception is the 40 MHz disable
flag as it might have been set while the channel was set
in a previous authentication attempt so it needs to be
kept intact.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When sending probe requests, e.g. during software scanning,
these will go out on the *current* channel, so their IEs
need to be built from the current channel. At other times,
e.g. for beacons or probe request templates, the IEs will
be used on the *operating* channel and using the current
channel instead might result in errors.
Add the appropriate parameters to respect the difference.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Using hw.conf.channel is wrong as it could be the
temporary channel if any function like the beacon
get function is called while scanning or during
other temporary out-of-channel activities.
Use oper_channel instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's no need to set up the channel during auth
and again during assoc, just do it once. Currently
this doesn't result in any changes since calling
hw_config() with an unchanged channel will return
early, but with the channel context work this has
an impact on channel context assignment.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In ieee80211_prep_connection(), the station (if not NULL)
is the new station (representing the AP) that needs to be
added. Rename the variable to "new_sta" to clarify this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If HT/VHT isn't supported by us we shouldn't print
a message that we disabled it, do that only if the
AP didn't support WMM and we therefore disable it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, ps mode is indicated per device (rather than
per interface), which doesn't make a lot of sense.
Moreover, there are subtle bugs caused by the inability
to indicate ps change along with other changes
(e.g. when the AP deauth us, we'd like to indicate
CHANGED_PS | CHANGED_ASSOC, as changing PS before
notifying about disassociation will result in null-packets
being sent (if IEEE80211_HW_SUPPORTS_DYNAMIC_PS) while
the sta is already disconnected.)
Keep the current per-device notifications, and add
parallel per-vif notifications.
In order to keep it simple, the per-device ps and
the per-vif ps are orthogonal - the per-vif ps
configuration is determined only by the user
configuration (enable/disable) and the connection
state, and is not affected by other vifs state and
(temporary) dynamic_ps/offchannel operations
(unlike per-device ps).
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This doesn't make any sense since we are expected to be on
the medium or at least to Tx only when we are on the right
channel and the AP/GO can hear us.
Move the call to mgd_prepare_tx() for deauth to be only
done in case we're sending a deauth while not associated.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the HW is monitoring connection loss (as advertised
by IEEE80211_HW_CONNECTION_MONITOR) but not filtering
beacons (IEEE80211_VIF_BEACON_FILTER) then mac80211 will
still start the beacon loss timer and if a few beacons
are lost, e.g. due to scanning, drop the connection.
If the hardware doesn't advertise connection monitoring,
then it won't drop the connection right away but probe
the AP, which is intended, but due to the logic in the
timer when connection monitoring is done it assumes the
connection was actually lost.
Fix this problem by not starting the timer when the HW
does connection monitoring.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Insert VHT IEs into association frames to allow
mac80211 to connect as a VHT client.
Signed-off-by: Mahesh Palivela <maheshp@posedge.com>
[clarify commit message]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
on disassoc, ieee80211_set_disassoc() goes out of PS
before indicating BSS_CHANGED_ASSOC (not sure why this
is needed, but some drivers might count on the current
behavior).
However, it does it after sending the disassoc
frame, which results in null-data frame being sent
(in order to go out of ps) after we were already sent
the disassoc, which is invalid.
Fix it by going out of ps before sending the disassoc.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some drivers (iwlegacy, iwlwifi and rt2x00) today use the
bss_conf.last_tsf value. By itself though that value is
completely worthless since it may be ancient. What really
is needed is synchronisation between some device time and
the TSF.
To clarify this, rename bss_conf.last_tsf to sync_tsf and
add sync_device_ts which is obtained from rx_status which
gets a new field device_timestamp for this purpose. This
is intentionally not using the mactime field since that
is used for other things and in IBSS is expected to sync
with the IBSS's TSF which isn't necessarily true for the
device timestamp.
Also, since we have the information and it's useful even
before the connection has been established, give all the
timing details to the driver before authenticating.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If association failed due to internal error (e.g. no
supported rates IE), we call ieee80211_destroy_assoc_data()
with assoc=true, while we actually reject the association.
This results in the BSSID not being zeroed out.
After passing assoc=false, we no longer have to call
sta_info_destroy_addr() explicitly. While on it, move
the "associated" message after the assoc_success check.
Cc: stable@vger.kernel.org [3.4+]
Signed-off-by: Eliad Peller <eliad@wizery.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ieee80211_mlme_notify_scan_completed() iterates all
interfaces and doesn't need to assign anything to
the sdata variable before the loop.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When the AC parameters change, drivers might rely
on getting a bss_info_changed notification with
BSS_CHANGED_QOS in addition to the conf_tx call.
Always call the function when userspace updates
are made (in AP/GO modes) and also set the change
flag when updates were made by the AP (in managed
mode.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some drivers require setup before being able to send
management frames in managed mode, in particular in
multi-channel cases.
Introduce API to allow the drivers to do such setup
while being able to sleep waiting for the setup to
finish in the device. This isn't possible inside the
TX call since that can't sleep.
A future patch may also restructure the TX retry to
wait for the driver to report the frame status, as
suggested by Arik in
http://mid.gmane.org/CA+XVXffKSEL6ZQPQ98x-zO-NL2=TNF1uN==mprRyUmAaRn254g@mail.gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Drivers might need getting the probe request
(e.g. in order to extract the ssid) even during
auth/assoc.
Make ieee80211_ap_probereq_get() support it
by considering auth_data/assoc_data as well.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
beacon_ies is needed only in order to extract the dtim
period. However, even if it's missing we can still enter
ps with dtim=1 (which also happens if the TIM ie is invalid).
Most drivers don't use conf.max_sleep_period/ps_dtim_period
anyway, and this check prevents them from entering ps if
they don't have beacon (but only probe response), even though
the beacon is not needed at all.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
On deauth/disassoc we tear down all BA sessions. These
DELBA packets are sent on the appropriate TID, while
deauth/disassoc is always sent on VO. This sometimes
ends with the DELBA being sent after the deauth was
already sent.
Fix it by flushing all the pending frames before
sending deauth/disassoc.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are a few things that make the logging and
debugging in mac80211 less useful than it should
be right now:
* a lot of messages should be pr_info, not pr_debug
* wholesale use of pr_debug makes it require *both*
Kconfig and dynamic configuration
* there are still a lot of ifdefs
* the style is very inconsistent, sometimes the
sdata->name is printed in front
Clean up everything, introducing new macros and
separating out the station MLME debugging into
a new Kconfig symbol.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ieee80211_set_disassoc() clears ifmgd->bssid before
building DELBA frames, resulting in frames with invalid
bssid ("00:00:00:00:00:00").
Fix it by clearing ifmgd->bssid only after building
all the needed frames.
After this change, we no longer need to save the
bssid (before clearing it), so remove the local array.
Reported-by: Ido Yariv <ido@wizery.com>
Cc: stable@vger.kernel.org
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Save and configure the wmm_acm per sdata, rather than
per hardware.
If wmm_acm is saved per hardware when running two
interfaces simultaneously on the same hardware one
interface's wmm policy will be affected by the other
interface.
Signed-off-by: Yoni Divinsky <yoni.divinsky@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If an AP is beaconing with different capabilities than the one we get
in the associate response, we were still using the capabilities
received in the beacons. One example is when the AP is beaconing with
the short slot bit set to zero and then we try to connect to it with
long slot. In this case, we would keep using long slot until the next
beacon was received.
Fix this by using the correct capability value when calling
ieee80211_handle_bss_capability(). We were using cbss->capability,
but we should use the bss_conf->assoc_capability instead.
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some compilers (eg. gcc 4.4.1 for ARM) report a false positive warning
in mlme.c:
net/mac80211/mlme.c: In function 'ieee80211_prep_connection':
net/mac80211/mlme.c:3035: warning: 'sta' may be used uninitialized in this function
This is a false positive because the place where 'sta' is used is
inside an if with the same condition of where it is set:
[...]
if (!have_sta) {
sta = sta_info_alloc(sdata, cbss->bssid, GFP_KERNEL);
if (!sta)
return -ENOMEM;
}
[...]
if (!have_sta) {
[...]
sta->sta.supp_rates[cbss->channel->band] = rates;
[...]
For some reason the compiler doesn't understand this and warns.
While this is not a problem in the code itself, we can avoid polluting
the build logs with false positives by setting sta to NULL on
declaration and checking for sta instead of !have_sta in the second if.
Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Stop connection monitor poll during disassociation.
This clears the polling flags and if a scan was
deferred it will be run.
Without this fix, if a scan was deferred due to
connection monitoring while disassociation happens,
this scan blocks further scan requests until interface
down/up which causes problems connecting to another AP.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
commit 24398e39c8
Author: Johannes Berg <johannes.berg@intel.com>
Date: Wed Mar 28 10:58:36 2012 +0200
mac80211: set HT channel before association
removed IEEE80211_CONF_CHANGE_CHANNEL argument from ieee80211_hw_config,
which is required by iwl4965 driver, otherwise that driver does not
configure channel properly and is not able to associate.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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>
Make mac80211 print a message when it disables
HT due to the connection using WEP/TKIP or due
to the AP not supporting WMM/QoS.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Instead of passing around the entire HT information
IE, extract only the HT parameters field and disable
HT if the HT information IE isn't present and well-
formed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ieee80211_get_operstate() was used by drivers in order to
know whether the sta link is up, but it's no longer needed
(nor used) as mac80211 notifies the drivers about
authorization changes (via the sta_state callback)
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Standardize the debugging to be able to use dynamic_debug.
Coalesce formats, align arguments.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Send beacon loss events to userspace, so it will be
able to initiate roaming before disconnection
Signed-off-by: Holger Schurig <holgerschurig@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ieee80211_rx_mgmt_auth() doesn't handle denied authentication
properly - it authenticates the station and waits for association
(for 5 seconds) instead of failing the authentication.
Fix it by destroying auth_data and bailing out instead.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Cc: stable@vger.kernel.org #3.4
Signed-off-by: John W. Linville <linville@tuxdriver.com>
commit 133d40f9a2
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Wed Mar 28 16:01:19 2012 +0200
mac80211: do not scan and monitor connection in parallel
add bug, which make possible to start a scan and never finish it, so
make every new scanning request finish with -EBUSY error. This can
happen on code paths where we finish connection monitoring and clear
IEEE80211_STA_*_POLL flags, but do not check if scan was deferred.
This patch fixes those code paths.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 tries to verify the existence of the current AP by
probing or sending a NULL frame in function
ieee80211_mgd_probe_ap_send. It 1st sends a null frame to the AP,
increments probe_send_count and waits for the ACK to the NULL
frame for a finite duration of time. At times, it happens that by
the time mac80211 gets to increment probe_send_count, the ACK for
the NULL frame transmitted has already been processed. This leads
to a race condition where mac80211 times out waiting for the ACK
for the NULL frame causing unnecessary disconnection with the AP.
Signed-off-by: Soumik Das <soumik.das@stericsson.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Standardize the net core ratelimited logging functions.
Coalesce formats, align arguments.
Change a printk then vprintk sequence to use printf extension %pV.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the new bool function ether_addr_equal to add
some clarity and reduce the likelihood for misuse
of compare_ether_addr for sorting.
Done via cocci script:
$ cat compare_ether_addr.cocci
@@
expression a,b;
@@
- !compare_ether_addr(a, b)
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- compare_ether_addr(a, b)
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) == 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) != 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !!ether_addr_equal(a, b)
+ ether_addr_equal(a, b)
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The rate control updation never be called on 2040 BSS change.
The station should update its rate control on receiving beacon
with different HT mode in the HT operation IE. Not doing so,
leads to sending frames with higher(ht40) rates whereas AP is
operating in lower mode (ht20).
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Conflicts:
drivers/net/ethernet/intel/e1000e/param.c
drivers/net/wireless/iwlwifi/iwl-agn-rx.c
drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
drivers/net/wireless/iwlwifi/iwl-trans.h
Resolved the iwlwifi conflict with mainline using 3-way diff posted
by John Linville and Stephen Rothwell. In 'net' we added a bug
fix to make iwlwifi report a more accurate skb->truesize but this
conflicted with RX path changes that happened meanwhile in net-next.
In e1000e a conflict arose in the validation code for settings of
adapter->itr. 'net-next' had more sophisticated logic so that
logic was used.
Signed-off-by: David S. Miller <davem@davemloft.net>
Before we send probes in connection monitoring we check if scan is not
pending. But we do that check without locking. Fix that and also do not
start scan if connection monitoring is in progress.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
While associated we should never have empty SSID, but life can be full
of surprises, and is allways better to print a warning than crash.
Before memcpy() in ieee80211_probereq_get() check ssid_len instead of
ssid pointer, sice pointer it always passed by "ssidie + 2" expression
to send probe functions, so practically never can be NULL.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When comparing hw->queues to determine if the
device is QoS capable, use IEEE80211_NUM_ACS
instead of just 4.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Devices that have internal rate control need to be
notified when the bandwidth or SMPS state changes
just like external rate control algorithms get a
notification now.
Add this notification and clarify the change bits
while at it, the HT_CHANGED bit really meant only
bandwidth changed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We currently stop the queue when changing the rate
control between 20/40 MHz in the BSS. This seems to
have been necessary when we actually changed the
channel, but now that we just update the station it
doesn't seem right any more. Remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The channel type argument to the rate_update()
callback isn't really the correct way to give
the rate control algorithm about the desired
RX bandwidth of the peer.
Remove this argument, and instead update the
STA capabilities with 20/40 appropriately. The
SMPS update done by this callback works in the
same way, so this makes the callback cleaner.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Changing the channel type during operation is
confusing to some drivers and will be hard to
handle in multi-channel scenarios. Instead of
changing the channel, set it to the right HT
channel before authenticating/associating and
don't change it -- just update the 20/40 MHz
restrictions in rate control as needed when
changed by the AP.
This also fixes a problem that Paul missed in
his fix for the "regulatory makes us deaf"
issue -- when we couldn't use 40 MHz we still
associated saying we were using 40 MHz, which
could in similarly broken APs make us never
even connect successfully.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When receiving DTIM we currently disable power save mode in the
hardware unconditionally, i.e. also when the hardware was not sleeping.
This causes trouble with at least one wireless chipset (Ralink RT3572).
When the hardware is not sleeping and we send a wakeup command (e.g.
this happens after a scan) then a significant decrease of the link
quality or a disconnect may occur.
Disabling power save mode only when it was enabled prevents this issue.
Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com>
Reviewed-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since some of the HT code pre-dates 802.11n-2009
some names are wrong. The one that bothers me most
is that "HT operation" is called "HT information"
in our code and that causes confusion.
Rename "HT information" to "HT operation" and also
the control_chan field to primary_chan to match
the name used in the spec.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sometimes the probe frame (nullfunc) is stuck at the hw queue. so that
the mac80211 terminates the connection as it wont see the tx status.
Instead of waiting for long period for ack status, lets call flush
to get nullfunc status immediately. It also helps to send the nullfunc
till max tries reached.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There might be latency at AP side to update TIM IE which could cause the
station to send pspoll frame even after the wakeup. If the powersave is
disabled, the nullfunc notification alone is sufficient to receive
frames from the AP. And if the pspoll frame was already sent, no need to
resend the frame till it was acked by AP.
Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The TU_TO_EXP_TIME() macro already includes the
"jiffies +" piece of the calculation, so don't
add jiffies again.
Reported-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
uapsd_queues and uapsd_max_sp_len are relevant only for managed
interfaces, and can be configured differently for each vif.
Move them from the local struct to sdata->u.mgd, and update
the debugfs functions accordingly.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When regulatory information changes our HT behavior (e.g,
when we get a country code from the AP we have just associated
with), we should use this information to change the power with
which we transmit, and what channels we transmit. Sometimes
the channel parameters we derive from regulatory information
contradicts the parameters we used in association. For example,
we could have associated specifying HT40, but the regulatory
rules we apply may forbid HT40 operation.
In the situation above, we should reconfigure ourselves to
transmit in HT20 only, however it makes no sense for us to
disable receive in HT40, since if we associated with these
parameters, the AP has every reason to expect we can and
will receive packets this way. The code in mac80211 does
not have the capability of sending the appropriate action
frames to signal a change in HT behaviour so the AP has
no clue we can no longer receive frames encoded this way.
In some broken AP implementations, this can leave us
effectively deaf if the AP never retries in lower HT rates.
This change breaks up the channel_type parameter in the
ieee80211_enable_ht function into a separate receive and
transmit part. It honors the channel flags set by regulatory
in order to configure the rate control algorithm, but uses
the capability flags to configure the channel on the radio,
since these were used in association to set the AP's transmit
rate.
Signed-off-by: Paul Stewart <pstew@chromium.org>
Cc: Sam Leffler <sleffler@chromium.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Reviewed-by: Luis R Rodriguez <mcgrof@frijolero.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This value is not really very useful by itself,
yet some drivers (including iwlwifi until I can
figure out what it should do) use it. At least
rename it to "last_tsf" to indicate the meaning
and add a note that it may be really old.
I suspect the value may become useful combined
with the rx_status->mactime, but we don't (yet)
store that value and pass it to the driver.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The authentication and association handshake
already happens in the context of the new BSS,
and the basic rates are needed at least for
the ACK response frame to the authentication
or association response frames. Therefore the
basic rates should already be configured into
the driver when those frames are sent.
Change the logic to set up the basic rates in
the connection preparation that happens for
authentication and association (if needed).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As associating is possible without first authenticating
(for FT over DS) association also has to be able to
switch to the right channel, insert the station entry
etc. Factor out this common code into a new function
called ieee80211_prep_connection().
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The BSSID has been set a lot earlier already and
didn't change again in ieee80211_set_associated().
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Instead of setting assoc_data->wmm_used solely
based on the BSS also take into account our own
capabilities and later check those.
Also rename "wmm_used" and "uapsd_used" to just
"wmm" and "uapsd".
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Always set/use IEEE80211_STA_DISABLE_11N instead
of duplicating the queue, WMM and HT checks in
all places.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Looks like some changes in this area moved
the code but not the comment that belongs
to the code, move it to the right place.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As we've discussed, we want to avoid channel changes
while associated. While the part when we actually
associate needs a bit more work, the bit that happens
on disassociating can be changed quite easily. Move
the channel type change later in the disassociate
process to set the channel only after the driver was
told that it's now disassociated.
As the driver could expect powersave to be enabled
only when associated, this thus results in splitting
the config call, but overall what happens makes more
sense this way.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the station state callback was added, this
was no longer needed in theory. With the iwlwifi
changes to remove use of it landing, we can kill
the entire tx-sync framework again, RIP.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 is lenient with respect to reception of corrupted beacons.
Even if the frame is corrupted as a whole, the available IE elements
are still passed back and accepted, sometimes replacing legitimate
data. It is unknown to what extent this "feature" is made use of,
but it is clear that in some cases, this is detrimental. One such
case is reported in http://crosbug.com/26832 where an AP corrupts
its beacons but not its probe responses.
One approach would be to completely reject frames with invaid data
(for example, if the last tag extends beyond the end of the enclosing
PDU). The enclosed approach is much more conservative: we simply
prevent later IEs from overwriting the state from previous ones.
This approach hopes that there might be some salient data in the
IE stream before the corruption, and seeks to at least prevent that
data from being overwritten. This approach will fix the case above.
Further, we flag element structures that contain data we think might
be corrupted, so that as we fill the mac80211 BSS structure, we try
not to replace data from an un-corrupted probe response with that
of a corrupted beacon, for example.
Short of any statistics gathering in the various forms of AP breakage,
it's not possible to ascertain the side effects of more stringent
discarding of data.
Signed-off-by: Paul Stewart <pstew@chromium.org>
Cc: Sam Leffler <sleffler@chromium.org>
Cc: Eliad Peller <eliad@wizery.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When associating and particularly when disassociating
there's no need to notify the driver about changes
with multiple calls to bss_info_changed, we should
combine the QoS enabling/disabling into the same call
as otherwise the driver could get confused about QoS
suddenly getting disabled while connected.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Because of the constant size and guaranteed 16 bit alignment, the inline
compare_ether_addr function is much cheaper than calling memcmp.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The association sequence looks (roughly) like
this now:
* set BSSID
* set station to EXIST state
* send auth
* set station to AUTH state
* send assoc
* set station to ASSOC state
* set BSS info to associated
In contrast, the deauth/disassoc sequence is
the other way around:
* clear BSSID/BSS info state
* remove station
* send deauth/disassoc
(in some cases the last two steps are reversed.)
This patch encodes the entire sequence in the
ieee80211_set_disassoc() function and changes
it to be like this, for good measure with an
explicit flush:
* send deauth/disassoc
* flush
* remove station
* clear BSSID/BSS info state
At least iwlwifi gets confused with the other
sequence in P2P mode and complains that it
wasn't able to flush the queues.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When ieee80211_set_disassoc() is called with the
tx argument set to true, it will send DelBA out
to the peer. This isn't useful or necessary in a
few cases where we do it today, those being when
we lost the connection or when the supplicant
explicitly asked us to not tell the AP.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Instead of calling cfg80211 in ieee80211_send_deauth_disassoc()
pass out the frame and call it from the caller. That saves the
SKB allocation if we don't actually want to send the frame and
enables us to make the ordering smarter in the future.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In "cfg80211: no cookies in cfg80211_send_XXX()"
Holger Schurig removed the cookies in the calls
from mac80211 to cfg80211, but the ones in the
other direction were left in. Remove them now.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When removing an interface while it is in the
process of authenticating or associating, we
leak the auth_data or assoc_data, and leave
the timer pending. The timer then crashes the
system when it fires as its data is gone.
Fix this by explicitly deleting all the data
when the interface is removed. This uncovered
another bug -- this problem should have been
detected by the sta_info_flush() warning but
that function doesn't ever return non-zero,
I'll fix that in a separate patch.
Reported-by: Hieu Nguyen <hieux.c.nguyen@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Eliad reports that if a scan finishes in the
middle of processing associated (however it
happens), the interface can go idle. This is
because we set assoc_data to NULL before we
set associated. Change the order so any idle
check will find either one of them.
Doing this requires duplicating the TX sync
processing, but I already have a patch to
delete that completely and will submit that
as soon as my driver changes to no longer
require it are submitted.
Reported-by: Eliad Peller <eliad@wizery.com>
Tested-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ieee80211_restart_sta_timer() takes care for enqueueing
monitor_work if needed, so no need to do it again.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Devices that monitor the connection in the hw don't need
the monitor work in the driver.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is the second part of the auth/assoc redesign,
the mac80211 part. This moves the auth/assoc code
out of the work abstraction and into the MLME, so
that we don't flip channels all the time etc.
The only downside is that when we are associated,
we need to drop the association in order to create
a connection to another AP, but for most drivers
this is actually desirable and the ability to do
was never used by any applications. If we want to
implement resource reservation with FT-OTA, we'd
probably best do it with explicit R-O-C in wpa_s.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
To track authenticated state seems to have been
a design mistake in cfg80211. It is possible to
have out of band authentication (FT), tracking
multiple authentications caused more problems
than it ever helped, and the implementation in
mac80211 is too complex.
Remove all this complexity, and let userspace
do whatever it wants to, mac80211 can deal with
that just fine. Association is still tracked of
course, but authentication no longer is. Local
auth state changes are thus no longer of value,
so ignore them completely.
This will also help implement SAE -- asking the
driver to do an authentication is now almost
equivalent to sending an authentication frame,
with the exception of shared key authentication
which is still handled completely.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The dummy STA support was added because I didn't
want to change the driver API at the time. Now
that we have state transitions triggering station
add/remove in the driver, we only call add once a
station reaches ASSOCIATED, so we can remove the
dummy station stuff again.
While at it, tighten the RX check and accept only
port control (EAP) frames from the AP station if
it's not associated yet -- in other cases there's
no race.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move the station state modification right before insert,
this just makes the current code more readable (you can
tell that it's before insertion looking at a single
screenful of code) right now, but some upcoming changes
will require this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In the future, when we start notifying drivers,
state transitions could potentially fail. To make
it easier to distinguish between programming bugs
and driver failures:
* rename sta_info_move_state() to
sta_info_pre_move_state() which can only be
called before the station is inserted (and
check this with a new station flag).
* rename sta_info_move_state_checked() to just
plain sta_info_move_state(), as it will be
the regular function that can fail for more
than just one reason (bad transition or an
error from the driver)
This makes the programming model easier -- one of
the functions can only be called before insertion
and can't fail, the other can fail.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Similar to the previous beacon filtering patch,
make CQM RSSI support depend on the flags that
the driver set for virtual interfaces.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Due to firmware limitations, we may not be able to
support beacon filtering on all virtual interfaces.
To allow this in mac80211, introduce per-interface
driver capability flags that the driver sets when
an interface is added.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The local maximum transmit power for a channel is defined as the maximum
regulatory transmission power minus the local power constraint specified
for the channel in the Power Constraint element. (7.3.2.15 IEEE80211 2007)
Signed-off-by: Hong Wu <hong.wu@dspg.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When deauth is requested while an auth or assoc
work item is in progress, we currently delete it
without regard for any state it might need to
clean up. Fix it by cleaning up for those items.
In the case Pontus found, the problem manifested
itself as such:
authenticate with 00:23:69:aa:dd:7b (try 1)
authenticated
failed to insert Dummy STA entry for the AP (error -17)
deauthenticating from 00:23:69:aa:dd:7b by local choice (reason=2)
It could also happen differently if the driver
uses the tx_sync callback.
We can't just call the ->done() method of the work
items because that will lock up due to the locking
in cfg80211. This fix isn't very clean, but that
seems acceptable since I have patches pending to
remove this code completely.
Cc: stable@vger.kernel.org
Reported-by: Pontus Fuchs <pontus.fuchs@gmail.com>
Tested-by: Pontus Fuchs <pontus.fuchs@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
this is being recently introduced by the commit
a85e1d5597
Cc: Paul Stewart <pstew@google.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If station info contains a beacon loss count, return
it to userspace.
Signed-off-by: Paul Stewart <pstew@chromium.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
we found that power save is not getting enabled when we do
change interface in this order STA->IBSS->STA. this is
because ieee80211_setup_sdata clears type-dependent union
Reported-by: Leela Kella <leela@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Station entries can have various states, the most
important ones being auth, assoc and authorized.
This patch prepares us for telling the driver about
these states, we don't want to confuse drivers with
strange transitions, so with this we enforce that
they move in the right order between them (back and
forth); some transitions might happen before the
driver even knows about the station, but at least
runtime transitions will be ordered correctly.
As a consequence, IBSS and MESH stations will now
have the ASSOC flag set (so they can transition to
AUTHORIZED), and we can get rid of a special case
in TX processing.
When freeing a station, unwind the state so that
other parts of the code (or drivers later) can rely
on the transitions.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This implements ht-cap over-rides for mac80211 drivers.
HT may be disabled, making an /a/b/g/n station act like an
a/b/g station. HT40 may be disabled forcing the station to
be HT20 even if the AP and local hardware support HT40.
MAX-AMSDU may be disabled.
AMPDU-Density may be increased.
AMPDU-Factor may be decreased.
This has been successfully tested with ath9k using patched
wpa_supplicant and iw.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
WLAN_STA_ASSOC_AP indicates that the station entry
is for an AP we're associated to but isn't used so
remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some drivers (e.g. ath9k) assume that it's safe to go into low-power mode
immediately after the idle state changes. To support that, mac80211 even
calls drv_flush() before that happens.
In some instances, mac80211 sent a packet right after recalculating the
idle state, this patch fixes that.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
802.11n-2009 extends the supported rates element with a
magic value which can be used to prevent legacy stations
from joining the BSS.
However, this magic value is not a rate like the others
and the magic can simply be ignored/skipped at this late
stage.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>---
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the connection monitor timer fires right before
suspend, the following will happen:
timer fires -> monitor_work gets queued
suspend calls ieee80211_sta_quiesce
ieee80211_sta_quiesce:
- deletes timer
- cancels monitor_work synchronously, running it
[note wrong order of these steps]
monitor_work runs, re-arming the timer
later, timer fires while system should be quiesced
This causes a warning:
WARNING: at net/mac80211/util.c:540 ieee80211_can_queue_work+0x35/0x40 [mac80211]()
but is otherwise harmless. I'm not completely sure
this is the scenario Thomas stumbled across, but it
is the only way I can right now see the warning in
a scenario like the one he reported.
Reported-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (47 commits)
forcedeth: fix a few sparse warnings (variable shadowing)
forcedeth: Improve stats counters
forcedeth: remove unneeded stats updates
forcedeth: Acknowledge only interrupts that are being processed
forcedeth: fix race when unloading module
MAINTAINERS/rds: update maintainer
wanrouter: Remove kernel_lock annotations
usbnet: fix oops in usbnet_start_xmit
ixgbe: Fix compile for kernel without CONFIG_PCI_IOV defined
etherh: Add MAINTAINERS entry for etherh
bonding: comparing a u8 with -1 is always false
sky2: fix regression on Yukon Optima
netlink: clarify attribute length check documentation
netlink: validate NLA_MSECS length
i825xx:xscale:8390:freescale: Fix Kconfig dependancies
macvlan: receive multicast with local address
tg3: Update version to 3.121
tg3: Eliminate timer race with reset_task
tg3: Schedule at most one tg3_reset_task run
tg3: Obtain PCI function number from device
...
Some buggy APs (and even P2P_GO) don't advertise their
basic rates in the association response.
In such case, use the min supported rate as the
basic rate.
Reported-by: Pontus Fuchs <pontus.fuchs@gmail.com>
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Only AID values 1-2007 are valid, but some APs have been
found to send random bogus values, in the reported case an
AP that was sending the AID field value 0xffff, an AID of
0x3fff (16383).
There isn't much we can do but disable powersave since
there's no way it can work properly in this case.
Cc: stable@vger.kernel.org
Reported-by: Bill C Riemers <briemers@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
These files are non modular, but need to export symbols using
the macros now living in export.h -- call out the include so
that things won't break when we remove the implicit presence
of module.h from everywhere.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
These files were getting access to these two via the implicit
presence of module.h everywhere. They aren't modules, so they
don't need the full module.h inclusion though.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
* 'pm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (63 commits)
PM / Clocks: Remove redundant NULL checks before kfree()
PM / Documentation: Update docs about suspend and CPU hotplug
ACPI / PM: Add Sony VGN-FW21E to nonvs blacklist.
ARM: mach-shmobile: sh7372 A4R support (v4)
ARM: mach-shmobile: sh7372 A3SP support (v4)
PM / Sleep: Mark devices involved in wakeup signaling during suspend
PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image
PM / Hibernate: Do not initialize static and extern variables to 0
PM / Freezer: Make fake_signal_wake_up() wake TASK_KILLABLE tasks too
PM / Hibernate: Add resumedelay kernel param in addition to resumewait
MAINTAINERS: Update linux-pm list address
PM / ACPI: Blacklist Vaio VGN-FW520F machine known to require acpi_sleep=nonvs
PM / ACPI: Blacklist Sony Vaio known to require acpi_sleep=nonvs
PM / Hibernate: Add resumewait param to support MMC-like devices as resume file
PM / Hibernate: Fix typo in a kerneldoc comment
PM / Hibernate: Freeze kernel threads after preallocating memory
PM: Update the policy on default wakeup settings
PM / VT: Cleanup #if defined uglyness and fix compile error
PM / Suspend: Off by one in pm_suspend()
PM / Hibernate: Include storage keys in hibernation image on s390
...
Recently mac80211 was changed to use nullfunc instead of probe
request for connection monitoring for tx ack status reporting
hardwares. Sometimes in congested network, STA got disconnected
quickly after the association. It was observered that the rate
control was not adopted to environment due to minimal transmission.
As the nullfunc are used for monitoring purpose, these frames should
not be sacrificed for rate control updation. So it is better to send
the monitoring null func frames at minimum rate that could help to
retain the connection.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The flaglock in struct sta_info has long been
something that I wanted to get rid of, this
finally does the conversion to atomic bitops.
The conversion itself is straight-forward in
most places, a few things needed to change a
bit since we can no longer use multiple bits
at the same time.
On x86-64, this is a fairly significant code
size reduction:
text data bss dec hex
427861 23648 1008 452517 6e7a5 before
425383 23648 976 450007 6ddd7 after
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When adding a TDLS peer STA, mark it with a new flag in both nl80211 and
mac80211. Before adding a peer, make sure the wiphy supports TDLS and
our operating mode is appropriate (managed).
In addition, make sure all peers are removed on disassociation.
A TDLS peer is first added just before link setup is initiated. In later
setup stages we have more info about peer supported rates, capabilities,
etc. This info is reported via nl80211_set_station().
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Cc: Kalyan C Gaddam <chakkal@iit.edu>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
save and configure tx param per sdata, rather than
per hardware.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Whenever the scan request or tx_mgmt is requesting not to
use CCK rate for managemet frames through
NL80211_ATTR_TX_NO_CCK_RATE attribute, then mac80211 should
select appropriate least non-CCK rate. This could help to
send P2P probes and P2P action frames at non 11b rates
without diabling 11b rates globally.
Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The commit "mac80211: stop tx before doing hw config and
rate update" stops the tx queue and call drv_flush so frequently
whenever a beacon got received with 11n htcap. This leads to
massive "Failed to stop TX DMA" logspam on embedded hw. So the
queue stop and flush should be called if and only if there is a
change in the channel type.
Reported-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The hw.conf.channel value is not updated properly for drivers that
support HW channel switch. Since the switch is done entirely by the
driver and we don't call ieee80211_hw_config(), this value remains
untouched. This patch fixes that by setting the new channel directly in
ieee80211_chswitch_work().
Signed-off-by: Shahar Levi <shahar_levi@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The assumption is that during the hw config, transmission was
already stopped by mac80211. Sometimes the AP can be switching
b/w the ht modes due to intolerant or etc where STA is in
the middle of transmission. In such scenario, buffer overflow
was observed at driver side. And also before updating the rate
control, the frames are continued to xmited with older rates.
This patch ensures that the frames are always xmitted with
updated rates and avoid buffer overflow.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Removing unnecessary messages saves code and text.
Site specific OOM messages are duplications of a generic MM
out of memory message and aren't really useful, so just
delete them.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When associating to an AP, the station might miss the first EAP
packet that the AP sends due to a race condition between the association
success procedure and the rx flow in mac80211.
In such cases, the packet might fall in ieee80211_rx_h_check due to
the fact that the relevant rx->sta wasn't allocated yet.
Allocation of the relevant station info struct before actually
sending the association request and setting it with a new
dummy_sta flag solve this problem.
The station will accept only EAP packets from the AP while it
is in the pre-association/dummy state.
This dummy station entry is not seen by normal sta_info_get()
calls, only by sta_info_get_bss_rx().
The driver is not notified for the first insertion of the
dummy station. The driver is notified only after the association
is complete and the dummy flag is removed from the station entry.
That way, all the rest of the code flow should be untouched by
this change.
Signed-off-by: Guy Eilam <guy@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The PM QoS implementation files are better named
kernel/power/qos.c and include/linux/pm_qos.h.
The PM QoS support is compiled under the CONFIG_PM option.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Acked-by: markgross <markgross@thegnar.org>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
In P2P client mode, the GO (AP) to connect to might
have periods of time where it is not available due
to powersave. To allow the driver to sync with it
and send frames to the GO only when it is available
add a new callback tx_sync (and the corresponding
finish_tx_sync). These callbacks can sleep unlike
the actual TX.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Scanning currently uses the TX rate mask to
restrict the rate set, which is bogus. Make
it use the new set of rates from userspace.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add tx_conf array to save the current tx queues
configuration, and reconfig it on resume (ieee80211_reconfig).
On resume, the driver is being reconfigured. Without
reconfiguring the tx queues as well, the driver might
configure the device to use wrong ac params (e.g. ps-poll
instead of uapsd).
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In WoWLAN, devices may use crypto keys for TX/RX
and could also implement GTK rekeying. If the
driver isn't able to retrieve replay counters and
similar information from the device upon resume,
or if the device isn't responsive due to platform
issues, it isn't safe to keep the connection up
as GTK rekey messages from during the sleep time
could be replayed against it.
The only protection against that is disconnecting
from the AP. Modifying mac80211 to do that while
it is resuming would be very complex and invasive
in the case that the driver requires a reconfig,
so do it after it has resumed completely. In that
case, however, packets might be replayed since it
can then only happen after TX/RX are up again, so
mark keys for interfaces that need to disconnect
as "tainted" and drop all packets that are sent
or received with those keys.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 maintains a running average of the RSSI when a STA
is associated to an AP. Report threshold events to any driver
that has registered callbacks for getting RSSI measurements.
Implement callbacks in mac80211 so that driver can set thresholds.
Add callbacks in mac80211 which is invoked when an RSSI threshold
event occurs.
mac80211: add tracing to rssi_reports api and remove extraneous fn argument
mac80211: scale up rssi thresholds from driver by 16 before storing
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
A panic was observed when the device is failed to resume properly,
and there are no running interfaces. ieee80211_reconfig tries
to restart STA timers on unassociated state.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use the tx_frames_pending() driver callback to determine if Tx frames are
pending for its internal queues. If so postpone the dynamic PS timeout
to avoid interrupting Tx traffic.
The commit e8306f9894 enabled this
behavior for drivers with IEEE80211_HW_PS_NULLFUNC_STACK. We enable this
for all drivers supporting dynamic PS.
This patch helps improve performance in noisy environments.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Do not send DS Channel parameter for directed probe requests
in order to maximize the chance that we get a response. Some
badly-behaved APs don't respond when this parameter is included.
Signed-off-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Trigger connection monitor on resume from suspend. Since we
have been sleeping, there is reason to suspect that we might
not still be associated. The speed of detecting loss of
{connection,authentication} is worth the cost of the small
additional traffic at resume.
Signed-off-by: Paul Stewart <pstew@chromium.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add ieee80211_get_operstate() function to get the operstate
of the netdevice.
This is needed for drivers that need to know when the interface
is IF_OPER_UP (e.g. wl12xx), and block notifiers can't be used
(e.g. because the interface is already IF_OPER_UP, like after
resuming from suspend)
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This reverts commit 1d38c16ce4.
The mac80211 maintainer raised complaints about abuse of the CSA stop
reason, and about whether this patch actually serves its intended
purpose at all.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
local->ps_data wasn't cleared on disassociation, which
(in some corner cases) caused reconnections to enter
psm before association completed.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Stop tx queues before updating rate control to ensure
proper rate selection. Otherwise packets can be transmitted
in 40 Mhz whereas hw is configured in HT20.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Whenever the driver's queue depth reaches the max, the queues are
stopped by the driver till the driver can accept the frames.
At the mean time dynamic_ps_timer can be expired due to not
receiving packet from upper layer which could restart the transmission
at the end of ps work. Due to the mismatch with driver state,
mac80211 is unneccesarity buffering all the frames till the driver
wakes up the queue.
Check whether there is no transmit or the tx queues were stopped by some
reasons. If any of the queue was stopped, the postpond ps timer and
do not restart netif_tx.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
netif_tx_start_all_queues is used to allow the upper layer
to transmit frames but it does not restart transmission.
To restart the trasmission use netif_tx_wake_all_queues.
Not doing so, sometimes stalls the transmission and the
application has to be restarted to proceed further.
This issue was originally found while sending udp traffic
in higer bandwidth in open environment without bgscan.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In a highly noisy environment, the tx rate of the driver drops and
the application slows down since it has not yet received ACKs for
the frames already queued in the hardware. Since this ACK may take
more than 100ms, stopping the dev queues for entering PS at this
stage breaks applications, WMM test cases in my testing.
If there are frames already pending in the tx queue, postponing the
PS logic helps to avoid redundant queue stops. When power save is
enabled by default and in a noisy environment, this API certainly
helps in improving the average throughput.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If dynamic_ps is disabled, enabling power save before the 4-way
handshake completes may delay the station from being authorized to
send/receive traffic, i.e. increase roaming times. It also may result in
a failed 4-way handshake depending on the AP's timing requirements and
beacon interval, and the station's listen interval.
To fix this, prevent power save from being enabled while the station
isn't authorized and recalculate power save whenever the station's
authorized state changes.
Signed-off-by: Jason Young <a.young.jason@gmail.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Is still possible to schedule conn_mon_timer after disassociate from
ieee80211_sta_tx_notify() and ieee80211_offchannel_ps_disable().
Move disassociate check to ieee80211_sta_reset_conn_monitor() to cover
all these cases, and add unlikely since in most the time we call
ieee80211_sta_reset_conn_monitor() when associated.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There is a race on sending a data frame before the tx completion
of nullfunc frame for enabling power save. As the data quickly
follows the nullfunc frame, the AP thinks that the station is out
of power save and continues to send the frames. Whereas in the
station, the nullfunc ack will be processed after the tx completion
of data frame and mac80211 goes to powersave. Thus the power
save state mismatch between the station and the AP causes some
data loss and some applications fail because of that. This patch
fixes this issue.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some were indirectly set to NO_HT (zero), but I think
it's better to explicitly set it in case the enum ever
changes. In cfg.c, it seems the channel-type was just
ignored (and thus always set to NO_HT).
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This allows users to tune the connection-loss algorithms
to be more or less lenient. In particular, larger
null-func retries helps when using lots of virtual
stations on a loaded network.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
I have a netgear WNDR3700 that appears to have an off-by-four
bug in how it fills out the hti->control_chan (I configure the
AP to channel 11, it reports 15 as control_chan).
Poke a message into the kernel logs to give users a
clue as to why they are not getting the expected
channel-type or rate.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
PS should not be enabled if an infra AP vif exists in
the interface list. So while recalculating PS,
AP vif type should be taken into account.
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to
IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping
channel numbers in the 2GHz and 5GHz band we can't map from channel to
frequency without knowing the band. This is no problem as in most contexts we
know the band. In places where we don't know the band (and WEXT compatibility)
we assume the 2GHz band for channels below 14.
This patch does not implement all channel to frequency mappings defined in
802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz
channels as well as 802.11y channels have been omitted.
The following drivers have been updated to reflect the API changes:
iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx.
The drivers have been compile-tested only.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: Brian Prodoehl <bprodoehl@gmail.com>
Acked-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
net/mac80211/mlme.c: In function 'ieee80211_sta_work':
net/mac80211/mlme.c:1981: warning: too many arguments for format
Introduced by commit 04ac3c0ee2
("mac80211: speed up AP probing using nullfunc frames").
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 uses pm_qos (/dev/network_latency) in order to determine the
dynamic ps timeout (or disable the dynamic-ps at all in some cases).
commit ff616381 added a comparison for the current network_latency
against one high value (1900ms), and against the default value
(2000sec, rather than the commented 2sec).
however, the representation of 1900ms was incorrect:
1900ms = 1900000us ( != 1900000000 )
fix it by using USEC_TO_MSEC/SEC consts.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If the nullfunc frame used to probe the AP was not acked, there is no point
in waiting for the probe timeout, so advance to the next try (or disconnect)
immediately.
If we do reach the probe timeout without having received a tx status, the
connection is probably really bad and worth disconnecting.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ieee80211_is_nullfunc() implies ieee80211_is_data()
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since nullfunc frames are transmitted as unicast frames, they're more
reliable than the broadcast probe requests, so we need fewer retries
to figure out whether the AP is really gone.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
nullfunc frames are better for connection monitoring, because probe requests
are answered even if the AP has already dropped the connection, whereas
nullfunc frames from an unassociated station will trigger a disassoc/deauth
frame from the AP (WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA), which allows
the station to reconnect immediately instead of waiting until it attempts to
transmit the next unicast frame.
This only works on hardware with reliable tx ACK reporting, any other hardware
needs to fall back to the probe request method.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Check the connection by probing the AP (either using nullfunc or a
probe request). If nullfunc probing is supported and the assoc is no
longer valid, the AP will send a disassoc/deauth immediately.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
