- 24 Jun, 2013 3 commits
-
-
Ben Greear authored
If it *is* still set when the netdev is being deleted, then we are about to leak a pointer. Warn and clean up in that case. Signed-off-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Ben Greear authored
Should help the next person that tries to understand the bss refcounting logic. Signed-off-by:
-
Ben Greear authored
Otherwise, we can leak a bss reference. Signed-off-by:
-
- 19 Jun, 2013 5 commits
-
-
Johannes Berg authored
This fixes the potential issue that the BSS struct that we use and later assign to wdev->current_bss is removed from the scan list while associating. Also warn when we don't have a BSS struct in connect_result unless it's from a driver that only has the connect() API. Signed-off-by: -
Johannes Berg authored
Doing so will allow us to hold the BSS (not just ref it) over the association process, thus ensuring that it doesn't time out and gets invisible to the user (e.g. in 'iw wlan0 link'.) This also fixes a leak in mac80211 where it doesn't always release the BSS struct properly in all cases where calling this function. This leak was reported by Ben Greear. Signed-off-by: -
Johannes Berg authored
Avoid parsing the original dump message again and again by allocating a small state struct that is used by the functions involved in the dump, storing this struct in cb->args[0]. This reduces the memory allocation size as well. Signed-off-by: -
Johannes Berg authored
Merge mac80211 to avoid conflicts with the nl80211 attrbuf changes. Conflicts: net/mac80211/iface.c net/wireless/nl80211.c Signed-off-by: -
Johannes Berg authored
Since my commit 3713b4e3 ("nl80211: allow splitting wiphy information in dumps"), nl80211_dump_wiphy() uses the global nl80211_fam.attrbuf for parsing the incoming data. This wouldn't be a problem if it only did so on the first dump iteration which is locked against other commands in generic netlink, but due to space constraints in cb->args (the needed state doesn't fit) I decided to always parse the original message. That's racy though since nl80211_fam.attrbuf could be used by some other parsing in generic netlink concurrently. For now, fix this by allocating a separate parse buffer (it's a bit too big for the stack, currently 1448 bytes on 64-bit). For -next, I'll change the code to parse into the global buffer in the first round only and then allocate a smaller buffer to keep the data in cb->args. Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Acked-by:
David S. Miller <davem@davemloft.net> Acked-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
- 18 Jun, 2013 7 commits
-
-
Antonio Quartulli authored
This reverts commit 6d810f10 In this way an IBSS station will not use the AUTH messages to trigger a state reinitialisation anymore. The behaviour was racy and was not working properly. It has been introduced to help wpa_supplicant to support IBSS/RSN, however all the logic is now getting moved into wpa_s itself which will also be in charge of handling the AUTH messages thanks to the mgmt frame registration. If userspace does not register for receiving AUTH frames then mac80211 will still reply by itself. At the same time, the auth frame registration counter can be removed since it is not needed anymore. Signed-off-by:
Antonio Quartulli <antonio@open-mesh.com> [remove unused variable] Signed-off-by:
-
Simon Wunderlich authored
This should make some parts cleaner and is also required for handling 5/10 MHz properly. Signed-off-by:
Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by:
Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by:
-
Simon Wunderlich authored
This is a collection of minor fixes: * don't allow HT IEs in IBSS for 5/10 MHz * don't allow HT IEs in Mesh for 5/10 MHz * don't downgrade from/to 5 and 10 MHz channels * don't try HT rates for 5 and 10 MHz channels when selecting rates Signed-off-by:
-
Simon Wunderlich authored
Signed-off-by:
-
Simon Wunderlich authored
Add defines for 5 and 10 MHz channel width and fix channel handling functions accordingly. Also check for and report the WIPHY_FLAG_SUPPORTS_5_10_MHZ capability. Signed-off-by:
-
Thomas Pedersen authored
Instead of updating the mesh beacon immediately when requested (which would require the sdata_lock()), defer it to the mac80211 workqueue. Fixes yet another deadlock on calling sta_info_flush() with the sdata_lock() held from ieee80211_stop_mesh(). We could just drop the sdata_lock() around the mesh_sta_cleanup() call, but this path is also taken from several non-locked error paths. Signed-off-by:
Thomas Pedersen <thomas@cozybit.com> [fix comment position] Signed-off-by:
-
Simon Wunderlich authored
only the attributes are required and not the whole netlink info, as the function accesses the attributes only anyway. This makes it easier to parse nested beacon IEs later. Signed-off-by:
-
- 13 Jun, 2013 3 commits
-
-
Ilan Peer authored
Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Alexander Bondar authored
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 <alexander.bondar@intel.com> Signed-off-by:
-
Ben Greear authored
All accesses of the tid_start_tx lock should be protected by sta->lock if there is any chance that another thread could still be accessing the sta object. Signed-off-by:
-
- 12 Jun, 2013 4 commits
-
-
Johannes Berg authored
Ben reports that kmemleak is saying TX aggregation TID structs are leaked. Given his workload, I suspect that they're leaked because stations are destroyed before their aggregation sessions get a chance to start. Fix this by simply freeing structs that are not used yet. Reported-by:
-
Simon Wunderlich authored
The order of parameters was mixed up, introduced in commit "mac80211: improve the rate control API" Cc: Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Simon Wunderlich authored
When a CAC is running and stop_ap is called (e.g. when hostapd is killed while performing CAC), the CAC must be aborted immediately. Otherwise ieee80211_stop_ap() will try to stop it when it's too late - wdev->channel is already NULL and the abort event can not be generated. Signed-off-by:
-
Johannes Berg authored
There are some APs, notably 2G/3G/4G Wifi routers, specifically the "Onda PN51T", "Vodafone PocketWiFi 2", "ZTE MF60" and a similar T-Mobile branded device [1] that erroneously don't include all the needed information in (re)association response frames. Work around this by assuming the information is the same as it was in the beacon or probe response and using the data from there instead. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=58881. [1] https://bbs.archlinux.org/viewtopic.php?pid=1277305 Note that this requires marking the first ieee802_11_parse_elems() argument const, otherwise we'd get a compiler warning. Cc: stable@vger.kernel.org Reported-and-tested-by:
Michal Zajac <manwe@manwe.pl> Signed-off-by:
-
- 11 Jun, 2013 11 commits
-
-
Johannes Berg authored
In two wiphy dump error cases, most often when the dump allocation must be increased, the RTNL is leaked. This quickly results in a complete system lockup. Release the RTNL correctly. Reported-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Antonio Quartulli authored
Users may want to send a frame on the current channel without specifying it. This is particularly useful for the correct implementation of the IBSS/RSN support in wpa_supplicant which requires to receive and send AUTH frames. Make mgmt_tx pass a NULL channel to the driver if none has been specified by the user. Signed-off-by:
-
Antonio Quartulli authored
cfg80211 passes a NULL channel to mgmt_tx if the frame has to be sent on the one currently in use by the device. Make the implementation of mgmt_tx correctly handle this case Cc: Nicolas Cavallari <Nicolas.Cavallari@lri.fr> Acked-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Antonio Quartulli authored
cfg80211 passes a NULL channel to mgmt_tx if the frame has to be sent on the one currently in use by the device. Make the implementation of mgmt_tx correctly handle this case Cc: brcm80211-dev-list@broadcom.com Acked-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
-
Antonio Quartulli authored
cfg80211 passes a NULL channel to mgmt_tx if the frame has to be sent on the one currently in use by the device. Make the implementation of mgmt_tx correctly handle this case. Fail if offchan is required. Signed-off-by:
-
Jouni Malinen authored
I (Johannes) accidentally applied the first version of the patch ("Allow TDLS peer AID to be configured for VHT"). Now apply just the changes between v1 and v2 to get the AID verification and prefer the new attribute over the old one. Signed-off-by:Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by:
-
Ashok Nagarajan authored
Currently mesh uses mandatory rates as the default basic rates. Allow basic rates to be configured during mesh join. Basic rates are applied only if channel is also provided with mesh join command. Signed-off-by:
Ashok Nagarajan <ashok@cozybit.com> [some whitespace fixes, refuse basic rates w/o channel] Signed-off-by:
-
Colleen Twitty authored
The time it takes to see the peer link expire may differ by a minute since sta_expire() is run once a minute as a mesh housekeeping task. Signed-off-by:
Colleen Twitty <colleen@cozybit.com> Signed-off-by:
-
Colleen Twitty authored
If a STA has a peer that it hasn't seen any tx activity from for a certain length of time, the peer link is expired. This means the inactive STA is removed from the list of peers and that STA is not considered a peer again unless it re-peers. Previously, this inactivity time was always 30 minutes. Now, add it to the mesh configuration and allow it to be configured. Retain 30 minutes as a default value. Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Thomas Pedersen authored
The patch "cfg80211/mac80211: use cfg80211 wdev mutex in mac80211" introduced several deadlocks by converting the ifmsh->mtx to wdev->mtx. Solve these by: 1. drop the cancel_work_sync() in ieee80211_stop_mesh(). Instead make the mesh work conditional on whether the mesh is running or not. 2. lock the mesh work with sdata_lock() to protect beacon updates and prevent races with wdev->mesh_id_len or cfg80211. Signed-off-by:
-
- 05 Jun, 2013 3 commits
-
-
Johannes Berg authored
Some kernel-doc fixes for forgotten fields and renamed things. Signed-off-by: -
Alexander Bondar authored
Currently beacon availability upon association is marked by have_beacon flag of assoc_data structure that becomes unavailable when association completes. However beacon availability indication is required also after association to inform a driver. Currently dtim_period parameter is used for this purpose. Move have_beacon flag to another structure, persistant throughout a interface's life cycle. Use suitable sematics for beacon availability indication. Signed-off-by:
-
Alexander Bondar authored
ieee80211_rx_bss_info() deals with dtim_period setting and PS update when associated. Move all these to another locations cleaning this function. Also, the current implementation is buggy because when it calls ieee80211_recalc_ps() bss_conf->dtim_period is notset properly yet and thus nothing will happen. Signed-off-by:
-
- 04 Jun, 2013 4 commits
-
-
Johannes Berg authored
The change to use atomic_inc_return() for assigning the wiphy index made the first wiphy index 1 instead of 0. This is fine, but we all habitually type "phy0" when we're testing, so make it go back to 0 instead of 1 by subtracting 1 from the index. Signed-off-by: -
Johannes Berg authored
My big locking cleanups caused a problem by registering the rfkill instance with the RTNL held, while the callback also acquires the RTNL. This potentially causes a deadlock since the two locks used (rfkill mutex and RTNL) can be acquired in two different orders. Fix this by (un)registering rfkill without holding the RTNL. This needs to be done after the device struct is registered, but that can also be done w/o holding the RTNL. Signed-off-by: -
Johannes Berg authored
get_reg_request_treatment() returns 0 in one case but is defined to return an enum, use the proper value REG_REQ_OK. Signed-off-by: -
Johannes Berg authored
The current internal SME implementation in cfg80211 is very mixed up with the MLME handling, which has been causing issues for a long time. There are three things that the implementation has to provide: * a basic SME implementation for nl80211's connect() call (for drivers implementing auth/assoc, which is really just mac80211) and wireless extensions * MLME events for the userspace SME * SME events (connected, disconnected etc.) for all different SME implementation possibilities (driver, cfg80211 and userspace) To achieve these goals it isn't necessary to track the software SME's connection status outside of it's state (which is the part that caused many issues.) Instead, track it only in the SME data (wdev->conn) and in the general case only track whether the wdev is connected or not (via wdev->current_bss.) Also separate the internal implementation to not have callbacks from the SME events, but rather call it from the API functions that the driver (or rather mac80211) calls. This separates the code better. Signed-off-by:
-
