16 Dec, 2013
2 commits
-
Keep the sched scan req when starting sched scan, and reschedule
it in case of HW restart during sched scan.
The upper layer don't have to know about the restart.Signed-off-by: David Spinadel
Reviewed-by: Johannes Berg
Signed-off-by: Johannes Berg
06 Dec, 2013
3 commits
-
Conflicts:
drivers/net/wireless/brcm80211/Kconfig
net/mac80211/util.c -
On scan completion we try start any pending roc.
However, if scan was just pending (and not actually started)
there is no point in trying to start the roc, as it might
have started already.This solves the following warning:
WARNING: CPU: 0 PID: 3552 at net/mac80211/offchannel.c:269 ieee80211_start_next_roc+0x164/0x204 [mac80211]()
[] (unwind_backtrace+0x0/0xf0)
[] (show_stack+0x10/0x14)
[] (dump_stack+0x78/0x94)
[] (warn_slowpath_common+0x68/0x8c)
[] (warn_slowpath_null+0x1c/0x24)
[] (ieee80211_start_next_roc+0x164/0x204 [mac80211])
[] (ieee80211_scan_cancel+0xe8/0x190 [mac80211])
[] (ieee80211_do_stop+0x63c/0x79c [mac80211])
[] (ieee80211_stop+0x10/0x18 [mac80211])
[] (__dev_close_many+0x84/0xcc)
[] (__dev_close+0x28/0x3c)
[] (__dev_change_flags+0x78/0x144)
[] (dev_change_flags+0x10/0x48)
[] (devinet_ioctl+0x614/0x6d0)
[] (sock_ioctl+0x5c/0x2a4)
[] (do_vfs_ioctl+0x7c/0x5d8)
[] (SyS_ioctl+0x6c/0x7c)Signed-off-by: Eliad Peller
Signed-off-by: Johannes Berg -
In some cases, determining the completed scan type was
done by testing the SCAN_HW_SCANNING flag.However, this doesn't take care for the case in which
the hw scan was requested, but hasn't started yet (e.g.
due to active remain_on_channel).Replace this test by checking whether ops->hw_scan is
defined.This solves the following warning:
WARNING: CPU: 0 PID: 3552 at net/mac80211/offchannel.c:156 __ieee80211_scan_completed+0x1b4/0x2dc [mac80211]()
[] (unwind_backtrace+0x0/0xf0)
[] (show_stack+0x10/0x14)
[] (dump_stack+0x78/0x94)
[] (warn_slowpath_common+0x68/0x8c)
[] (warn_slowpath_null+0x1c/0x24)
[] (__ieee80211_scan_completed+0x1b4/0x2dc [mac80211])
[] (ieee80211_scan_cancel+0xe8/0x190 [mac80211])
[] (ieee80211_do_stop+0x63c/0x79c [mac80211])
[] (ieee80211_stop+0x10/0x18 [mac80211])
[] (__dev_close_many+0x84/0xcc)
[] (__dev_close+0x28/0x3c)
[] (__dev_change_flags+0x78/0x144)
[] (dev_change_flags+0x10/0x48)
[] (devinet_ioctl+0x614/0x6d0)
[] (sock_ioctl+0x5c/0x2a4)
[] (do_vfs_ioctl+0x7c/0x5d8)
[] (SyS_ioctl+0x6c/0x7c)Signed-off-by: Eliad Peller
Signed-off-by: Johannes Berg
03 Dec, 2013
1 commit
-
The same code appears just a few lines below.
Signed-off-by: Eliad Peller
Signed-off-by: Johannes Berg
26 Nov, 2013
1 commit
-
These two flags are used for the same purpose, just
combine them into a no-ir flag to annotate no initiating
radiation is allowed.Old userspace sending either flag will have it treated as
the no-ir flag. To be considerate to older userspace we
also send both the no-ir flag and the old no-ibss flags.
Newer userspace will have to be aware of older kernels.Update all places in the tree using these flags with the
following semantic patch:@@
@@
-NL80211_RRF_PASSIVE_SCAN
+NL80211_RRF_NO_IR
@@
@@
-NL80211_RRF_NO_IBSS
+NL80211_RRF_NO_IR
@@
@@
-IEEE80211_CHAN_PASSIVE_SCAN
+IEEE80211_CHAN_NO_IR
@@
@@
-IEEE80211_CHAN_NO_IBSS
+IEEE80211_CHAN_NO_IR
@@
@@
-NL80211_RRF_NO_IR | NL80211_RRF_NO_IR
+NL80211_RRF_NO_IR
@@
@@
-IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_NO_IR
+IEEE80211_CHAN_NO_IR
@@
@@
-(NL80211_RRF_NO_IR)
+NL80211_RRF_NO_IR
@@
@@
-(IEEE80211_CHAN_NO_IR)
+IEEE80211_CHAN_NO_IRAlong with some hand-optimisations in documentation, to
remove duplicates and to fix some indentation.Signed-off-by: Luis R. Rodriguez
[do all the driver updates in one go]
Signed-off-by: Johannes Berg
25 Nov, 2013
1 commit
-
When changing cfg80211 to use RTNL locking, this caused a
deadlock in mac80211 as it calls cfg80211_sched_scan_stopped()
from a work item that's on a workqueue that is flushed with
the RTNL held.Fix this by simply using schedule_work(), the work only needs
to finish running before the wiphy is unregistered, no other
synchronisation (e.g. with suspend) is really required since
for suspend userspace is already blocked anyway when we flush
the workqueue so will only pick up the event after resume.Cc: stable@vger.kernel.org
Fixes: 5fe231e87372 ("cfg80211: vastly simplify locking")
Reported-and-tested-by: Eliad Peller
Signed-off-by: Johannes Berg
05 Nov, 2013
1 commit
-
Conflicts:
drivers/net/wireless/iwlwifi/pcie/drv.c
24 Oct, 2013
1 commit
-
Conflicts:
drivers/net/usb/qmi_wwan.c
include/net/dst.hTrivial merge conflicts, both were overlapping changes.
Signed-off-by: David S. Miller
10 Oct, 2013
1 commit
-
__ieee80211_scan_completed is called from a worker. This
means that the following flow is possible.* driver calls ieee80211_scan_completed
* mac80211 cancels the scan (that is already complete)
* __ieee80211_scan_completed runsWhen scan_work will finally run, it will see that the scan
hasn't been aborted and might even trigger another scan on
another band. This leads to a situation where cfg80211's
scan is not done and no further scan can be issued.Fix this by setting a new flag when a HW scan is being
cancelled so that no other scan will be triggered.Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Johannes Berg
26 Sep, 2013
1 commit
-
Since when we detect beacon lost we do active AP probing (using nullfunc
frame or probe request) there is no need to have beacon polling. Flags
IEEE80211_STA_BEACON_POLL seems to be used just for historical reasons.Change also make that after we start connection poll due to beacon loss,
next received beacon will abort the poll.Signed-off-by: Stanislaw Gruszka
Signed-off-by: Johannes Berg
16 Jul, 2013
2 commits
-
Use a chandef instead of just the channel for scanning, and enable
5/10 Mhz scanning for IBSS mode. Also reporting is changed to the new
inform_bss functions.Signed-off-by: Simon Wunderlich
Signed-off-by: Mathias Kretschmer
Signed-off-by: Johannes Berg -
The various components accessing the bitrates table must use consider
the used channel bandwidth to select only available rates or calculate
the bitrate correctly.There are some rates in reduced bandwidth modes which can't be
represented as multiples of 500kbps, like 2.25 MBit/s in 5 MHz mode. The
standard suggests to round up to the next multiple of 500kbps, just do
that in mac80211 as well.Signed-off-by: Simon Wunderlich
Signed-off-by: Mathias Kretschmer
[make rate unsigned in ieee80211_add_tx_radiotap_header(), squash fix]
Signed-off-by: Johannes Berg
13 Jun, 2013
1 commit
-
Track the AP's beacon rate in the scan BSS data and in the
interface configuration to let the drivers know which rate
the AP is using. This information may be used by drivers,
in our case to let the firmware optimise beacon RX.Signed-off-by: Alexander Bondar
Signed-off-by: Johannes Berg
16 Apr, 2013
1 commit
-
VHT introduces multiple IEs that need to be parsed for a
wide bandwidth channel switch. Two are (currently) needed
in mac80211:
* wide bandwidth channel switch element
* channel switch wrapper elementThe former is contained in the latter for beacons and probe
responses, but not for the spectrum management action frames
so the IE parser needs a new argument to differentiate them.Signed-off-by: Johannes Berg
08 Apr, 2013
1 commit
-
It's always just one byte, so check for that and
remove the length field from the parser struct.Signed-off-by: Johannes Berg
26 Mar, 2013
1 commit
-
Drivers that don't use chanctxes cannot perform VHT association because
they still use a "backward compatibility" pair of {ieee80211_channel,
nl80211_channel_type} in ieee80211_conf and ieee80211_local.Signed-off-by: Karl Beldan
[fix kernel-doc]
Signed-off-by: Johannes Berg
19 Mar, 2013
1 commit
-
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
11 Mar, 2013
1 commit
-
Found by compiling with W=1.
Signed-off-by: Johannes Berg
15 Feb, 2013
1 commit
-
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
Signed-off-by: Simon Wunderlich
Signed-off-by: Johannes Berg
12 Feb, 2013
4 commits
-
We've got a couple of races when enabling powersave with an AP for
off-channel operation. The first is fairly simple. If we go off-channel
before the nullfunc frame to enable PS is transmitted then it may not be
received by the AP. Add a flush after enabling off-channel PS to prevent
this from happening.The second race is a bit more subtle. If the driver supports QoS and has
frames queued when the nullfunc frame is queued, those frames may get
transmitted after the nullfunc frame. If PM is not set then the AP is
being told that we've exited PS before we go off-channel and may try to
deliver frames. To prevent this, add a flush after stopping the queues
but before passing the nullfunc frame to the driver.Signed-off-by: Seth Forshee
Signed-off-by: Johannes Berg -
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
Signed-off-by: Johannes Berg -
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
-
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 [mwifiex]
Signed-off-by: Johannes Berg
31 Jan, 2013
4 commits
-
Patch vastly improve latency while scanning. Slight throughput
improvements were observed as well. Is intended for improve performance
of voice and video applications, when scan is periodically requested by
user space (i.e. default NetworkManager behaviour).Patch remove latency requirement based on PM_QOS_NETWORK_LATENCY,
this value is 2000 seconds by default (i.e. approximately 0.5 hour !?!).Also remove listen interval requirement, which based on beaconing and
depending on BSS parameters. It can make we stay off-channel for a
second or more.Instead try to offer the best latency that we could, i.e. be off-channel
no longer than PASSIVE channel scan time: 125 ms. That mean we will
scan two ACTIVE channels and go back to on-channel, and one PASSIVE
channel, and go back to on-channel.Patch also decrease PASSIVE channel scan time to about 110 ms.
As drawback patch increase overall scan time. On my tests, when scanning
both 2GHz and 5GHz bands, scanning time increase from 5 seconds up to 10
seconds. Since that increase happen only when we are associated, I think
it can be acceptable. If eventually better scan time is needed for
situations when we lose signal and quickly need to decide to which AP
roam, additional scan flag or parameter can be introduced.I tested patch by doing:
while true; do iw dev wlan0 scan; sleep 3; done > /dev/null
and
ping -i0.2 -c 1000 HOST
on remote and local machine, results are as below:
* Ping from local periodically scanning machine to AP:
Unpatched: rtt min/avg/max/mdev = 0.928/24.946/182.135/36.873 ms
Patched: rtt min/avg/max/mdev = 0.928/19.678/150.845/33.130 ms* Ping from remote machine to periodically scanning machine:
Unpatched: rtt min/avg/max/mdev = 1.637/120.683/709.139/164.337 ms
Patched: rtt min/avg/max/mdev = 1.807/26.893/201.435/40.284 msThroughput measured by scp show following results.
* Upload to periodically scanning machine:
Unpatched: 3.9MB/s 03:15
Patched: 4.3MB/s 02:58* Download from periodically scanning machine:
Unpatched: 5.5MB/s 02:17
Patched: 6.2MB/s 02:02Signed-off-by: Stanislaw Gruszka
Signed-off-by: Johannes Berg -
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
-
These pointers/values are never used, remove them.
Signed-off-by: Johannes Berg
-
We track this, but never use it, so we can
just remove it.Signed-off-by: Johannes Berg
29 Jan, 2013
1 commit
-
Conflicts:
drivers/net/wireless/ath/ath9k/main.c
drivers/net/wireless/iwlwifi/dvm/tx.c
16 Jan, 2013
1 commit
-
Since:
commit b23b025fe246f3acc2988eb6d400df34c27cb8ae
Author: Ben Greear
Date: Fri Feb 4 11:54:17 2011 -0800mac80211: Optimize scans on current operating channel.
we do not disable PS while going back to operational channel (on
ieee80211_scan_state_suspend) and deffer that until scan finish.
But since we are allowed to send frames, we can send a frame to AP
without PM bit set, so disable PS on AP side. Then when we switch
to off-channel (in ieee80211_scan_state_resume) we do not enable PS.
Hence we are off-channel with PS disabled, frames are not buffered
by AP.To fix remove offchannel_ps_disable argument and always enable PS when
going off-channel and disable it when going on-channel, like it was
before.Cc: stable@vger.kernel.org # 2.6.39+
Signed-off-by: Stanislaw Gruszka
Tested-by: Seth Forshee
Signed-off-by: Johannes Berg
03 Jan, 2013
3 commits
-
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
Signed-off-by: Johannes Berg -
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
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Johannes Berg -
Do not scan on no-IBSS and disabled channels in IBSS mode. Doing this
can trigger Microcode errors on iwlwifi and iwlegacy drivers.Also rename ieee80211_request_internal_scan() function since it is only
used in IBSS mode and simplify calling it from ieee80211_sta_find_ibss().This patch should address:
https://bugzilla.redhat.com/show_bug.cgi?id=883414
https://bugzilla.kernel.org/show_bug.cgi?id=49411Reported-by: Jesse Kahtava
Reported-by: Mikko Rapeli
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka
Signed-off-by: Johannes Berg
12 Dec, 2012
1 commit
11 Dec, 2012
1 commit
-
Signed-off-by: Johannes Berg
07 Dec, 2012
1 commit
-
Conflicts:
drivers/net/wireless/mwifiex/sta_ioctl.c
net/mac80211/scan.c
30 Nov, 2012
1 commit
-
Instead of assuming 200 bytes are always enough for
all the IEs we add, give the length of the buffer
to the function and warn instead of overrunning.Signed-off-by: Johannes Berg
27 Nov, 2012
1 commit
23 Nov, 2012
1 commit
-
Currently, mac80211 checks the DS params IE if present and
uses it for the (primary) BSS channel, instead of the one
that the frame was received on. This is particularly useful
in the 2.4 GHz band since a frame is often received on one
of the adjacent channels due to overlap.Move this code to cfg80211 so other drivers also do this.
Additionally, on 5 GHz, in particular with some (possibly)
upcoming changes in 802.11ai and duplicate transmissions
when wider channels are used, something similar happens.
So if present, also use the (primary) channel information
contained in the HT operation IE.Signed-off-by: Johannes Berg