- Jan 22, 2010
-
-
Johannes Berg authored
If a device has multiple MAC addresses, userspace will need to know about that. Similarly, if it allows the MAC addresses to vary by a bitmask. If a driver exports multiple addresses, it is assumed that it will be able to deal with that many different addresses, which need not necessarily match the ones programmed into the device; if a mask is set then the device should deal addresses within that mask based on an arbitrary "base address". To test it all and show how it is used, add support to hwsim even though it can't actually deal with addresses different from the default. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- Jan 19, 2010
-
-
Johannes Berg authored
Future code will need to look up rdev and wdev within atomic sections, but currently we need to lock a mutex for such lookups. Change the list handling for both to be RCU-safe so that we can look them up in rcu sections instead in the future. Signed-off-by:
-
- Jan 12, 2010
-
-
Lukáš Turek authored
The new attribute NL80211_ATTR_WIPHY_COVERAGE_CLASS sets IEEE 802.11 Coverage Class, which depends on maximum distance of nodes in a wireless network. It's required for long distance links (more than a few hundred meters). The attribute is now ignored by two non-mac80211 drivers, rndis and iwmc3200wifi, together with WIPHY_PARAM_RETRY_SHORT and WIPHY_PARAM_RETRY_LONG. If it turns out to be a problem, we could split set_wiphy_params callback or add new capability bits. Signed-off-by:
Lukas Turek <8an@praha12.net> Signed-off-by:
-
Johannes Berg authored
When CONFIG_CFG80211_WEXT is not set, there is a refcount imbalance with rdev->opencount, fix that by moving it out of the ifdef. Reported-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
- Nov 28, 2009
-
-
Alban Browaeys authored
This patch moves the works cleanup, scan and events to a cfg80211 dedicated workqueue. Platform driver like eeepc-laptop ought to use works to rfkill (as new rfkill does lock in rfkill_unregister and the platform driver is called from rfkill_switch_all which also lock the same mutex). This raise a new issue in itself that the work scheduled by the platform driver to the global worqueue calls wiphy_unregister which flush_work scan and event works (which thus flush works on the global workqueue inside a work on the global workqueue) and also put on hold the wdev_cleanup_work (which prevents the dev_put on netdev thus indefinite Usage count error on wifi device). Signed-off-by:
Alban Browaeys <prahal@yahoo.com> Signed-off-by:
-
- Nov 19, 2009
-
-
Johannes Berg authored
A number of people have tried to add a wireless interface (in managed mode) to a bridge and then complained that it doesn't work. It cannot work, however, because in 802.11 networks all packets need to be acknowledged and as such need to be sent to the right address. Promiscuous doesn't help here. The wireless address format used for these links has only space for three addresses, the * transmitter, which must be equal to the sender (origin) * receiver (on the wireless medium), which is the AP in the case of managed mode * the recipient (destination), which is on the APs local network segment In an IBSS, it is similar, but the receiver and recipient must match and the third address is used as the BSSID. To avoid such mistakes in the future, disallow adding a wireless interface to a bridge. Felix has recently added a four-address mode to the AP and client side that can be used (after negotiating that it is possible, which must happen out-of-band by setting up both sides) for bridging, so allow that case. Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
Johannes Berg authored
We've accumulated a number of options for wiphys which make more sense as flags as we keep adding more. Convert the existing ones. Signed-off-by:
-
- Oct 30, 2009
-
-
Johannes Berg authored
We can save a lot of code and pointers in the structs by using debugfs_remove_recursive(). First, change cfg80211 to use debugfs_remove_recursive() so that drivers do not need to clean up any files they added to the per-wiphy debugfs (if and only if they are ok to be accessed until after wiphy_unregister!). Then also make mac80211 use debugfs_remove_recursive() where necessary -- it need not remove per-wiphy files as cfg80211 now removes those, but netdev etc. files still need to be handled but can now be removed without needing struct dentry pointers to all of them. Signed-off-by:
-
- Oct 11, 2009
-
-
Alexey Dobriyan authored
After m68k's task_thread_info() doesn't refer to current, it's possible to remove sched.h from interrupt.h and not break m68k! Many thanks to Heiko Carstens for allowing this. Signed-off-by:Alexey Dobriyan <adobriyan@gmail.com>
-
- Oct 07, 2009
-
-
John W. Linville authored
Signed-off-by: -
Johannes Berg authored
Refactor wext to * split out iwpriv handling * split out iwspy handling * split out procfs support * allow cfg80211 to have wireless extensions compat code w/o CONFIG_WIRELESS_EXT After this, drivers need to - select WIRELESS_EXT - for wext support - select WEXT_PRIV - for iwpriv support - select WEXT_SPY - for iwspy support except cfg80211 -- which gets new hooks in wext-core.c and can then get wext handlers without CONFIG_WIRELESS_EXT. Wireless extensions procfs support is auto-selected based on PROC_FS and anything that requires the wext core (i.e. WIRELESS_EXT or CFG80211_WEXT). Signed-off-by:
-
- Oct 05, 2009
-
-
Marcel Holtmann authored
Instead of having to modify every non-mac80211 for device type assignment, do this inside the netdev notifier callback of cfg80211. So all drivers that integrate with cfg80211 will export a proper device type. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Aug 28, 2009
-
-
Johannes Berg authored
When the interface type changes while connected, and the driver does not require the interface to be down for a type change, it is currently possible to get very strange results unless the driver takes special care, which it shouldn't have to. To fix this, take care to disconnect/leave IBSS when changing the interface type -- even if the driver may fail the call. Also process all events that may be pending to avoid running into a situation where an event is reported but only processed after the type has already changed, which would lead to missing events and warnings. A side effect of this is that you will have disconnected or left the IBSS even if the mode change ultimately fails, but since the intention was to change it and thus leave or disconnect, this is not a problem. Signed-off-by:
-
Johannes Berg authored
When we lose a scan, cfg80211 tries to clean up after the driver. However, it currently does this too early, it does this in GOING_DOWN already instead of DOWN, so it may happen with mac80211. Besides fixing this, also make it more robust by leaking the scan request so if the driver later actually finishes the scan, it won't crash. Also check in ___cfg80211_scan_done whether a scan request is still pending and exit if not. Reported-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
- Aug 20, 2009
-
-
Zhu Yi authored
In case of connection failure, the bssid info is not a must have. Signed-off-by:
Zhu Yi <yi.zhu@intel.com> Acked-by:
-
Johannes Berg authored
My patch "cfg80211: fix deadlock" broke the code it was supposed to fix, the scan request checking. But it's not trivial to put it back the way it was, since the original patch had a deadlock. Now do it in a completely new way: queue the check off to a work struct, where we can freely lock. But that has some more complications, like needing to wait for it to be done before the wiphy/rdev can be destroyed, so some code is required to handle that. Signed-off-by:
-
Johannes Berg authored
When removing an interface with nl80211, cfg80211 will deadlock in the netdev notifier because we're already holding rdev->mtx and try to acquire it again to verify the scan has been done. This bug was introduced by my patch "cfg80211: check for and abort dangling scan requests". To fix this, move the dangling scan request check into wiphy_unregister(). This will not be able to catch all cases right away, but if the scan problem happens with a manual ifdown or so it will be possible to remedy it by removing the module/device. Additionally, add comments about the deadlock scenario. Reported-by:
Christian Lamparter <chunkeey@web.de> Signed-off-by:
Kalle Valo <kalle.valo@iki.fi> Signed-off-by:
-
- Aug 14, 2009
-
-
Johannes Berg authored
Sometimes drivers might have a good reason to override the PS default, like iwlwifi right now where it affects RX performance significantly at this point. This will allow them to override the default, if desired, in a way that users can still change it according to their trade-off choices, not the driver's, like would happen if the driver just disabled PS completely then. Signed-off-by:
-
Johannes Berg authored
If you trigger a scan request on an interface and then take it down, or rmmod the module or unplug the device the driver might "forget" to cancel the scan request. That is a bug in the driver, but the current behaviour is that we just hang endlessly waiting for the netdev refcount to become 0 which it never will. To improve robustness, check for this situation in cfg80211, warn about it and clean up behind the driver. I don't just clean up silently because it's likely that the driver also has some internal state it has now leaked. Additionally, this fixes a locking bug, clearing the scan_req pointer should be done under the rdev lock. Finally, we also need to _wait_ for the scan work and not just abort it since it might be pending and wanting to do a cleanup. Signed-off-by:
-
Johannes Berg authored
When calling into the wext code from the NETDEV_UP notifier, we need to hold the devlist_mtx mutex as the wext code ends up calling into channel checks. Reported-by:
-
Johannes Berg authored
In order for userspace to be able to figure out whether it obtained a consistent snapshot of data or not when using netlink dumps, we need to have a generation number in each dump message that indicates whether the list has changed or not -- its value is arbitrary. This patch adds such a number to all dumps, this needs some mac80211 involvement to keep track of a generation number to start with when adding/removing mesh paths or stations. The wiphy and netdev lists can be fully handled within cfg80211, of course, but generation numbers need to be stored there as well. Signed-off-by:
-
- Aug 04, 2009
-
-
Johannes Berg authored
The default of 500ms is pretty high, and leads to the device being awake at least 50% of the time under such light traffic conditions as a simple 1 second interval ping. Reduce to just 100ms -- it should have a similar effect while providing a better sleep time. Signed-off-by:
-
Luis R. Rodriguez authored
We change regulatory code to be protected by its own regulatory mutex and alleviate cfg80211_mutex to only be used to protect cfg80211_rdev_list, the registered device list. By doing this we will be able to work on regulatory core components without having to have hog up the cfg80211_mutex. An example here is we no longer need to use the cfg80211_mutex during driver specific wiphy_apply_custom_regulatory(). We also no longer need it for the the country IE regulatory hint; by doing so we end up curing this new lockdep warning: ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.31-rc4-wl #12 ------------------------------------------------------- phy1/1709 is trying to acquire lock: (cfg80211_mutex){+.+.+.}, at: [<ffffffffa00af852>] regulatory_hint_11d+0x32/0x3f0 [cfg80211] but task is already holding lock: (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0144228>] ieee80211_sta_work+0x108/0x10f0 [mac80211] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (&ifmgd->mtx){+.+.+.}: [<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0 [<ffffffff81085dd3>] lock_acquire+0xe3/0x120 [<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350 [<ffffffffa0141bb8>] ieee80211_mgd_auth+0x108/0x1f0 [mac80211] [<ffffffffa0148563>] ieee80211_auth+0x13/0x20 [mac80211] [<ffffffffa00bc3a1>] __cfg80211_mlme_auth+0x1b1/0x2a0 [cfg80211] [<ffffffffa00bc516>] cfg80211_mlme_auth+0x86/0xc0 [cfg80211] [<ffffffffa00b368d>] nl80211_authenticate+0x21d/0x230 [cfg80211] [<ffffffff81416ba6>] genl_rcv_msg+0x1b6/0x1f0 [<ffffffff81415c39>] netlink_rcv_skb+0x89/0xb0 [<ffffffff814169d9>] genl_rcv+0x29/0x40 [<ffffffff8141591d>] netlink_unicast+0x29d/0x2b0 [<ffffffff81416514>] netlink_sendmsg+0x214/0x300 [<ffffffff813e4407>] sock_sendmsg+0x107/0x130 [<ffffffff813e45b9>] sys_sendmsg+0x189/0x320 [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff -> #2 (&wdev->mtx){+.+.+.}: [<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0 [<ffffffff81085dd3>] lock_acquire+0xe3/0x120 [<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350 [<ffffffffa00ab304>] cfg80211_netdev_notifier_call+0x1a4/0x390 [cfg80211] [<ffffffff814f3dff>] notifier_call_chain+0x3f/0x80 [<ffffffff81075a91>] raw_notifier_call_chain+0x11/0x20 [<ffffffff813f665a>] dev_open+0x10a/0x120 [<ffffffff813f59bd>] dev_change_flags+0x9d/0x1e0 [<ffffffff8144eb6e>] devinet_ioctl+0x6fe/0x760 [<ffffffff81450204>] inet_ioctl+0x94/0xc0 [<ffffffff813e25fa>] sock_ioctl+0x6a/0x290 [<ffffffff8111e911>] vfs_ioctl+0x31/0xa0 [<ffffffff8111ea9a>] do_vfs_ioctl+0x8a/0x5c0 [<ffffffff8111f069>] sys_ioctl+0x99/0xa0 [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff -> #1 (&rdev->mtx){+.+.+.}: [<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0 [<ffffffff81085dd3>] lock_acquire+0xe3/0x120 [<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350 [<ffffffffa00ac4d0>] cfg80211_get_dev_from_ifindex+0x60/0x90 [cfg80211] [<ffffffffa00b21ff>] get_rdev_dev_by_info_ifindex+0x6f/0xa0 [cfg80211] [<ffffffffa00b51eb>] nl80211_set_interface+0x3b/0x260 [cfg80211] [<ffffffff81416ba6>] genl_rcv_msg+0x1b6/0x1f0 [<ffffffff81415c39>] netlink_rcv_skb+0x89/0xb0 [<ffffffff814169d9>] genl_rcv+0x29/0x40 [<ffffffff8141591d>] netlink_unicast+0x29d/0x2b0 [<ffffffff81416514>] netlink_sendmsg+0x214/0x300 [<ffffffff813e4407>] sock_sendmsg+0x107/0x130 [<ffffffff813e45b9>] sys_sendmsg+0x189/0x320 [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff other info that might help us debug this: 3 locks held by phy1/1709: #0: ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<ffffffff8106b45d>] worker_thread+0x19d/0x340 #1: (&ifmgd->work){+.+.+.}, at: [<ffffffff8106b45d>] worker_thread+0x19d/0x340 #2: (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0144228>] ieee80211_sta_work+0x108/0x10f0 [mac80211] Reported-by:Reinette Chatre <reinette.chatre@intel.com> Acked-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
Johannes Berg authored
It's possible to get the NETDEV_UNREGISTER callback multiple times (see net/core/dev.c:netdev_wait_allrefs) and this will completely mess up our cleanup code. To avoid that, clean up only when the interface is still on the wiphy interface list from which it's removed on the first NETDEV_UNREGISTER call. Signed-off-by:
-
Johannes Berg authored
When a userspace SME is active, we're currently not keeping track of the BSS properly for reporting the current link and for internal use. Additionally, it looks like there is a possible BSS leak in that the BSS never gets removed from auth_bsses[]. To fix it, pass the BSS struct to __cfg80211_connect_result in this case. Signed-off-by:
-
- Jul 29, 2009
-
-
Johannes Berg authored
Finally! This is what you've all been waiting for! This patch makes cfg80211 take care of wext emulation _completely_ by itself, drivers that don't need things cfg80211 doesn't do yet don't even need to be aware of wireless extensions. This means we can also clean up mac80211's and iwm's Kconfig and make it possible to build them w/o wext now! RIP wext. Signed-off-by:
-
- Jul 27, 2009
-
-
Johannes Berg authored
In order to make cfg80211/nl80211 aware of network namespaces, we have to do the following things: * del_virtual_intf method takes an interface index rather than a netdev pointer - simply change this * nl80211 uses init_net a lot, it changes to use the sender's network namespace * scan requests use the interface index, hold a netdev pointer and reference instead * we want a wiphy and its associated virtual interfaces to be in one netns together, so - we need to be able to change ns for a given interface, so export dev_change_net_namespace() - for each virtual interface set the NETIF_F_NETNS_LOCAL flag, and clear that flag only when the wiphy changes ns, to disallow breaking this invariant * when a network namespace goes away, we need to reparent the wiphy to init_net * cfg80211 users that support creating virtual interfaces must create them in the wiphy's namespace, currently this affects only mac80211 The end result is that you can now switch an entire wiphy into a different network namespace with the new command iw phy#<idx> set netns <pid> and all virtual interfaces will follow (or the operation fails). Signed-off-by:
-
- Jul 24, 2009
-
-
Johannes Berg authored
The work that we cancel there requires the cfg80211_mutex, so we can't cancel it under the mutex, which is fine, we can just move it to after the locked section. Signed-off-by:
-
Johannes Berg authored
This reworks the key operation in cfg80211, and now only allows, from userspace, configuring keys (via nl80211) after the connection has been established (in managed mode), the IBSS been joined (in IBSS mode), at any time (in AP[_VLAN] modes) or never for all the other modes. In order to do shared key authentication correctly, it is now possible to give a WEP key to the AUTH command. To configure static WEP keys, these are given to the CONNECT or IBSS_JOIN command directly, for a userspace SME it is assumed it will configure it properly after the connection has been established. Since mac80211 used to check the default key in IBSS mode to see whether or not the network is protected, it needs an update in that area, as well as an update to make use of the WEP key passed to auth() for shared key authentication. Signed-off-by:
-
- Jul 10, 2009
-
-
Johannes Berg authored
In order to force drivers to advertise their interface types, don't just disallow creating new interfaces with unadvertised types but also disallow setting them UP. Additionally, add some validation on the operations the drivers support. Signed-off-by:
-
Johannes Berg authored
We've named the registered devices 'drv' sometimes, thinking of "driver", which is not what it is, it's the internal representation of a wiphy, i.e. a device. Let's clean up the naming once and and use 'rdev' aka 'registered device' everywhere. Signed-off-by:
-
Johannes Berg authored
Over time, a lot of locking issues have crept into the smarts of cfg80211, so e.g. scan completion can race against a new scan, IBSS join can race against leaving an IBSS, etc. Introduce a new per-interface lock that protects most of the per-interface data that we need to keep track of, and sprinkle assertions about that lock everywhere. Some things now need to be offloaded to work structs so that we don't require being able to sleep in functions the drivers call. The exception to that are the MLME callbacks (rx_auth etc.) that currently only mac80211 calls because it was easier to do that there instead of in cfg80211, and future drivers implementing those calls will, if they ever exist, probably need to use a similar scheme like mac80211 anyway... In order to be able to handle _deauth and _disassoc properly, introduce a cookie passed to it that will determine locking requirements. Signed-off-by:
-
Johannes Berg authored
Currently we call that cfg80211_put_dev(), but that is misleading. With the new convention of using 'rdev' for registered_device variables, also call that function cfg80211_unlock_rdev(). Signed-off-by:
-
Johannes Berg authored
We shouldn't be looking at the ssid_len for non-IBSS, and for IBSS we should also return an error on trying to leave an IBSS while not in or joining an IBSS. This fixes an issue where we wouldn't disconnect() on an interface being taken down since there's no SSID configured this way. Signed-off-by:
-
Johannes Berg authored
In order to avoid problems with BSS structs going away while they're in use, I've long wanted to make cfg80211 keep track of them. Without the SME, that wasn't doable but now that we have the SME we can do this too. It can keep track of up to four separate authentications and one association, regardless of whether it's controlled by the cfg80211 SME or the userspace SME. Signed-off-by:
-
Johannes Berg authored
When the interface is brought down, we need to reset the auth algorithm because wpa_supplicant doesn't reset it, and then we fail to use shared key auth when required later. Signed-off-by:
-
Johannes Berg authored
Just on/off and timeout, and with a hacky cfg80211 method until we figure out what we want, though this is probably sufficient as we want to use pm_qos for wifi everywhere. Signed-off-by:
-
Johannes Berg authored
This adds code to make it possible to use the cfg80211 connect() API with wireless extensions, and because the previous patch added emulation of that API with auth() and assoc(), by extension also supports wext on that. At the same time, removes code from mac80211 for wext, but doesn't yet clean up mac80211's mlme code more. Signed-off-by:
Samuel Ortiz <samuel.ortiz@intel.com> Signed-off-by:
-
Johannes Berg authored
This adds code to cfg80211 so that drivers (mac80211 right now) that don't implement connect but rather auth/assoc can still be used with the nl80211 connect command. This will also be necessary for the wext compat code. Signed-off-by:
-
Samuel Ortiz authored
This patch introduces the cfg80211 connect/disconnect API. The goal here is to run the AUTH and ASSOC steps in one call. This is needed for some fullmac cards that run both steps directly from the target, after the host driver sends a connect command. Additionally, all the new crypto parameters for connect() are now also valid for associate() -- although associate requires the IEs to be used, the information can be useful for drivers and should be given. Signed-off-by:
-
