Our legal structure changed at some point (see wikipedia), but
we forgot to immediately switch over to the new copyright
notice.
For files that we have modified in the time since the change,
add the proper copyright notice now.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When using the cfg80211_inform_bss[_width]() functions drivers
cannot currently indicate whether the data was received in a
beacon or probe response. Fix that by passing a new enum that
indicates such (or unknown).
For good measure, use it in ath6kl.
Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> [ath6kl]
Acked-by: Arend van Spriel <arend@broadcom.com> [brcmfmac]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are a few possible cases of where BSS data came from:
1) only a beacon has been received
2) only a probe response has been received
3) the driver didn't report what it received (this happens when
using cfg80211_inform_bss[_width]())
4) both probe response and beacon data has been received
Unfortunately, in the userspace API, a few things weren't there:
a) there was no way to differentiate cases 1) and 4) above
without comparing the data of the IEs
b) the TSF was always from the last frame, instead of being
exposed for beacon/probe response separately like IEs
Fix this by
i) exporting a new flag attribute that indicates whether or
not probe response data has been received - this addresses (a)
ii) exporting a BEACON_TSF attribute that holds the beacon's TSF
if a beacon has been received
iii) not exporting the beacon attributes in case (3) above as that
would just lead userspace into thinking the data actually came
from a beacon when that isn't clear
To implement this, track inside the IEs struct whether or not it
(definitely) came from a beacon.
Reported-by: William Seto
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Channels in 2.4GHz band overlap, this means that if we
send a probe request on channel 1 and then move to channel
2, we will hear the probe response on channel 2. In this
case, the RSSI will be lower than if we had heard it on
the channel on which it was sent (1 in this case).
The firmware / low level driver can parse the channel in
the DS IE or HT IE and compensate the RSSI so that it will
still have a valid value even if we heard the frame on an
adjacent channel. This can be done up to a certain offset.
Add this offset as a configuration for the low level driver.
A low level driver that can compensate the low RSSI in this
case should assign the maximal offset for which the RSSI
value is still valid.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add locked-version for cfg80211_sched_scan_stopped.
This is used for some users that might want to
call it when rtnl is already locked.
Fixes: d43c6b6 ("mac80211: reschedule sched scan after HW restart")
Cc: stable@vger.kernel.org (3.14+)
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Name wiphy_to_rdev is more accurate to describe what the function
does, i.e., return a pointer pointing to struct
cfg80211_registered_device.
Signed-off-by: Zhao, Gang <gamerh2o@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Name "dev" is too common and ambiguous, let all the pointer name
pointing to struct cfg80211_registered_device be "rdev". This can
improve code readability and consistency(since other places have
already called it rdev).
Signed-off-by: Zhao, Gang <gamerh2o@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When looking for a BSS matching given parameters, ignore invalid
BSSIDs. This avoids, for example, trying to join an IBSS that has
a multicast BSSID, which isn't supported by all drivers nor is it
a valid configuration of the IBSS so better create a new one with
a correctly chosen random BSSID.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
cfg80211_wext_freq() is declared in wext-compat.h, but its
parameter struct wiphy's declaration is not included there.
As the parameter isn't used, just remove it.
Signed-off-by: Zhao, Gang <gamerh2o@gmail.com>
[remove parameter instead of changing to netdev]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
RCU pointer bss->pub.beacon_ies is checked before in previous
statement:
if (rcu_access_pointer(bss->pub.beacon_ies))
continue;
There is no need to check it twice(and in the wrong way :) ).
Signed-off-by: Zhao, Gang <gamerh2o@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
On 2.4Ghz band, the channels overlap since the delta
between different channels is 5Mhz while the width of the
receiver is 20Mhz (at least).
This means that we can hear beacons or probe responses from
adjacent channels. These frames will have a significant
lower RSSI which will feed all kinds of logic with inaccurate
data. An obvious example is the roaming algorithm that will
think our AP is getting weak and will try to move to another
AP.
In order to avoid this, update the signal only if the frame
has been heard on the same channel as the one advertised by
the AP in its DS / HT IEs.
We refrain from updating the values only if the AP is
already in the BSS list so that we will still have a valid
(but inaccurate) value if the AP was heard on an adjacent
channel only.
To achieve this, stop taking the channel from DS / HT IEs
in mac80211. The DS / HT IEs is taken into account to
discard the frame if it was received on a disabled channel.
This can happen due to the same phenomenon: the frame is
sent on channel 12, but heard on channel 11 while channel
12 can be disabled on certain devices. Since this check
is done in cfg80211, stop even checking this in mac80211.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
[remove unused rx_freq variable]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Due to the previous commit, when a scan finishes, it is in theory
possible to hit the following sequence:
1. interface starts being removed
2. scan is cancelled by driver and cfg80211 is notified
3. scan done work is scheduled
4. interface is removed completely, rdev->scan_req is freed,
event sent to userspace but scan done work remains pending
5. new scan is requested on another virtual interface
6. scan done work runs, freeing the still-running scan
To fix this situation, hang on to the scan done message and block
new scans while that is the case, and only send the message from
the work function, regardless of whether the scan_req is already
freed from interface removal. This makes step 5 above impossible
and changes step 6 to be
5. scan done work runs, sending the scan done message
As this can't work for wext, so we send the message immediately,
but this shouldn't be an issue since we still return -EBUSY.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add a utility function to get the number of channels supported by
the device, and update the places in the code that need this data.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
[replace another occurrence in libertas, fix kernel-doc, fix bugs]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
___cfg80211_scan_done() can be called in some cases
(e.g. on NETDEV_DOWN) before the low level driver
notified scan completion (which is indicated by
passing leak=true).
Clearing rdev->scan_req in this case is buggy, as
scan_done_wk might have already being queued/running
(and can't be flushed as it takes rtnl()).
If a new scan will be requested at this stage, the
scan_done_wk will try freeing it (instead of the
previous scan), and this will later result in
a use after free.
Simply remove the "leak" option, and replace it with
a standard WARN_ON.
An example backtrace after such crash:
Unable to handle kernel paging request at virtual address fffffee5
pgd = c0004000
[fffffee5] *pgd=9fdf6821, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] SMP ARM
PC is at cfg80211_scan_done+0x28/0xc4 [cfg80211]
LR is at __ieee80211_scan_completed+0xe4/0x2dc [mac80211]
[<bf0077b0>] (cfg80211_scan_done+0x28/0xc4 [cfg80211])
[<bf0973d4>] (__ieee80211_scan_completed+0xe4/0x2dc [mac80211])
[<bf0982cc>] (ieee80211_scan_work+0x94/0x4f0 [mac80211])
[<c005fd10>] (process_one_work+0x1b0/0x4a8)
[<c0060404>] (worker_thread+0x138/0x37c)
[<c0066d70>] (kthread+0xa4/0xb0)
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since rdev->sched_scan_req is dereferenced outside the
lock protecting it, this might be done at the wrong
time, causing crashes. Move the dereference to where
it should be - inside the RTNL locked section.
Cc: stable@vger.kernel.org [3.8+]
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This function is being removed, so remove the reference to it.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
To allow scanning and working with 5 MHz and 10 MHz BSS, extend the
inform bss commands and add wrappers to take 5 and 10 MHz bss into
account.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Should help the next person that tries to understand
the bss refcounting logic.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Virtually all code paths in cfg80211 already (need to) hold
the RTNL. As such, there's little point in having another
four mutexes for various parts of the code, they just cause
lock ordering issues (and much of the time, the RTNL and a
few of the others need thus be held.)
Simplify all this by getting rid of the extra four mutexes
and just use the RTNL throughout. Only a few code changes
were needed to do this and we can get rid of a work struct
for bonus points.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If a P2P device wdev is removed while it has a scan, then the
scan completion might crash later as it is already freed by
that time. To avoid the crash always check the scan completion
when the P2P device is being removed for some reason. If the
driver already canceled it, don't want and free it, otherwise
warn and leak it to avoid later crashes.
In order to do this, locking needs to be changed away from the
rdev mutex (which can't always be guaranteed). For now, use
the sched_scan_mtx instead, I'll rename it to just scan_mtx in
a later patch.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In the odd case that while updating information from a beacon,
a BSS was found that is part of a hidden group, we drop the
new information. In this case, however, we leak the IE buffer
from the update, and erroneously update the entry's timestamp
so it will never time out. Fix both these issues.
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add new NL80211_CMD_RADAR_DETECT, which starts the Channel
Availability Check (CAC). This command will also notify the
usermode about events (CAC finished, CAC aborted, radar
detected, NOP finished).
Once radar detection has started it should continuously
monitor for radars as long as the channel is active.
This patch enables DFS for AP mode in nl80211/cfg80211.
Based on original patch by Victor Goldenshtein <victorg@ti.com>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
[remove WIPHY_FLAG_HAS_RADAR_DETECT again -- my mistake]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
cfg80211_find_vendor_ie() was checking only that the vendor IE would
fit in the remaining IEs buffer. If a corrupt includes a vendor IE
that is too small, we could potentially overrun the IEs buffer.
Fix this by checking that the vendor IE fits in the reported IE length
field and skip it otherwise.
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Luciano Coelho <coelho@ti.com>
[change BUILD_BUG_ON to != 1 (from >= 2)]
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>
There's no way scan BSS IEs can be NULL as even
if the allocation fails the frame is discarded.
Remove some code checking for this and document
that it is always non-NULL.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, cfg80211 will copy beacon IEs from a previously
received hidden SSID beacon to a probe response entry, if
that entry is created after the beacon entry. However, if
it is the other way around, or if the beacon is updated,
such changes aren't propagated.
Fix this by tracking the relation between the probe
response and beacon BSS structs in this case.
In case drivers have private data stored in a BSS struct
and need access to such data from a beacon entry, cfg80211
now provides the hidden_beacon_bss pointer from the probe
response entry to the beacon entry.
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>
Instead of annotating with a comment, add a lockdep
annotation which also serves as documentation.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The comment about allocating the IEs together with
the BSS struct is no longer true, remove it. Also
fix a typo in the same area.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As Thomas pointed out, cfg80211_get_mesh() is
unused and can be removed.
Cc: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of first checking if a BSS is an MBSS
and then doing the comparisons, inline it all
into the BSS comparison function. This avoids
doing the IE searches twice and is also a lot
less code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When trying to find a hidden SSID, the lookup function
is done wrong; the code is trying to combine the two
lookups into one, and as a consequence doesn't always
find the entry at all. To understand this, consider a
case where multiple BSS entries with the same channel
and BSSID exist but have different SSID length. Then
comparing against the probe response SSID length is
bound to cause problems since the hidden one might be
either zeroed out or zero-length.
To fix this we need to do two lookups for the two ways
to hide SSIDs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of duplicating the rbtree functions, pass
an argument to the compare function. This removes
the code duplication for the two searches.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Now that mac80211 no longer uses this API, remove
it completely. If anyone needs it again, we can
revert this patch of course, but mac80211 was the
only user right now.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We do a:
sprintf(buf, " Last beacon: %ums ago",
elapsed_jiffies_msecs(bss->ts));
elapsed_jiffies_msecs() can return a 10 digit number so "buf" needs to
be 31 characters long.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
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>
The cmp_bss() comparator function uses memcmp() to
compare the SSID. This means that cmp_hidden_bss()
needs to similarly return a number bigger than zero
(use 1) instead of -1 when ie1 is bigger than ie2,
which is the case if an ie2 byte is non-zero.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's no need to stop the machine, just leak
the BSS entry if there's an issue with its hold
counter when freeing.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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 <johannes.berg@intel.com>
Also add tracing to the API functions that drivers
(and mac80211) can call in cfg80211.
Signed-off-by: Beni Lev <beni.lev@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This will allow adding central tracing like in mac80211.
Signed-off-by: Hila Gonen <hila.gonen@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add an NL80211_SCAN_FLAG_FLUSH flag that causes old bss cache
entries to be flushed on scan completion. This is useful for
collecting guaranteed fresh scan/survey result (e.g. on resume).
For normal scan, flushing only happens on successful completion
of a scan; i.e. it does not happen if the scan is aborted.
For scheduled scan, previous scan results are flushed everytime
when we get new scan results.
This feature is enabled by default. Drivers can disable it by
unsetting the NL80211_FEATURE_SCAN_FLUSH flag.
Signed-off-by: Sam Leffler <sleffler@chromium.org>
Tested-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
[invert polarity of feature flag to account for old kernels]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
