summaryrefslogtreecommitdiffstats
path: root/sys/net80211/ieee80211_scan_sta.c
Commit message (Collapse)AuthorAgeFilesLines
* net80211: fix more compiler warnings.avos2016-05-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ieee80211.c: add_chanlist(): 'error' variable will be uninitialized if no channels were passed; return '0' instead. ieee80211_action.c: ieee80211_send_action_register(): drop 'break' after 'return'. ieee80211_crypto_none.c: none_encap(): 'keyid' is not used in non-debug builds; hide it behind IEEE80211_DEBUG ifdef. ieee80211_freebsd.c: Staticize global 'ieee80211_debug' variable (used only in this file). ieee80211_hostap.c: Fix a comment (associatio -> association). ieee80211_ht.c: ieee80211_setup_htrates(): initialize 'maxunequalmcs' to 0 to mute compiler warning. ieee80211_hwmp.c: hwmp_recv_preq(): copy 'prep' between conditional blocks to fix -Wshadow warning. ieee80211_mesh.c: mesh_newstate(): remove duplicate 'ni' definition. mesh_recv_group_data(): fix -Wempty-body warning in non-debug builds. ieee80211_phy.c: ieee80211_compute_duration(): remove 'break' after panic() call. ieee80211_scan_sta.c: Hide some TDMA-specific macros under IEEE80211_SUPPORT_TDMA ifdef adhoc_pick_bss(): remove 'ic' pointer redefinition. ieee80211_sta.c: sta_beacon_miss(): remove 'ic' pointer redefinition. ieee80211_superg.c: superg_ioctl_set80211(): drop unreachable return. Tested with clang 3.8.0, gcc 4.6.4 and gcc 5.3.0.
* net80211: replace internal LE_READ_*/LE_WRITE_* macro with systemavos2016-04-201-1/+2
| | | | | | | | | | | | | | | | | le*dec / le*enc functions. Replace net80211 specific macros with system-wide bytestream encoding/decoding functions: - LE_READ_2 -> le16dec - LE_READ_4 -> le32dec - LE_WRITE_2 -> le16enc - LE_WRITE_4 -> le32enc + drop ieee80211_input.h include, where it was included for these operations only. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D6030
* [net80211] migrate the time_* macros to ieee80211_* namespace.adrian2016-03-301-2/+2
| | | | | | | It turns out that these will clash very annoyingly with the linux macros in the linuxkpi layer, so let the wookie^Wlinux win. The only user that I can find is ath(4), so fix it there too.
* net80211: do not enforce promiscuous mode for AP scanavos2016-02-291-3/+0
| | | | | | | | | | | | | Drivers should set their own filters via ic_scan_start()/ic_scan_end() callbacks; and we don't need frames other than beacons or probe responses. (Note: this was a noop since r287197 due to promiscuous mode with bridge workaround) Tested with Intel 3945BG, RTL8188EU and WUSB54GC in HOSTAP mode. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5474
* These files were getting sys/malloc.h and vm/uma.h with header pollutionglebius2016-02-011-0/+1
| | | | via sys/mbuf.h
* Remove duplicate use of RV(), LE_* and other macros.adrian2015-09-221-11/+3
| | | | | Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3705
* Replay r286410. Change KPI of how device drivers that provide wirelessglebius2015-08-271-23/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
* Revert the wifi ifnet changes until things are more baked and tested.adrian2015-08-081-3/+23
| | | | | | | | | * 286410 * 286413 * 286416 The initial commit broke a variety of debug and features that aren't in the GENERIC kernels but are enabled in other platforms.
* Change KPI of how device drivers that provide wireless connectivity interactglebius2015-08-071-23/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Details here: https://wiki.freebsd.org/projects/ifnet/net80211 Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances of problems are low. The wtap wasn't compilable even before this change. But the ndis driver is complex, and it is likely to be broken with this commit. Help with testing and debugging it is appreciated. Differential Revision: D2655, D2740 Sponsored by: Nginx, Inc. Sponsored by: Netflix
* Migrate the scan iterator lock typedefs out into ieee80211_freebsd.h.adrian2015-05-261-5/+5
| | | | | This removes the final piece of freebsd-specific locking that snuck into the tree - it's now all inside ieee80211_freebsd.h.
* Convert malloc/free back to #define's, as part of OS portability work.adrian2015-05-251-7/+8
| | | | | | | | | | | | | | | | | | | | | | | DragonflyBSD uses the FreeBSD wireless stack and drivers. Their malloc() API is named differently, so they don't have userland/kernel symbol clashes like we do (think libuinet.) So, to make it easier for them and to port to other BSDs/other operating systems, start hiding the malloc specific bits behind defines in ieee80211_freebsd.h. DragonflyBSD can now put these portability defines in their local ieee80211_dragonflybsd.h. This should be a great big no-op for everyone running wifi. TODO: * kill M_WAITOK - some platforms just don't want you to use it * .. and/or handle it returning NULL rather than waiting forever. * MALLOC_DEFINE() ? * Migrate the well-known malloc names (eg M_TEMP) to net80211 namespace defines.
* Prepare for supporting driver-overridden curchan when submitting scanadrian2015-05-101-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | results. Right now the scan infrastructure assumes the channel is under net80211 control, and that when receiving beacon frames for scanning, the current channel is indeed what ic_curchan is set to. But firmware NICs with firmware scan support need more than this - they can do background scans whilst hiding the off-channel behaviour from net80211. Ie, net80211 still thinks everything is associated and on the main channel, but it's getting scan results from all the background traffic. However sta_add() pays attention to ic_curchan and discards scan results that aren't on the right channel. CCK beacon frames can be decoded from adjacent channels so the receive path and sta_add discard these as appropriate. This is fine for software scanning like for ath(4), but not for firmware NICs. So with those, the whole concept of background firmware scanning won't work without major hacks (eg, overriding ic_curchan before calling the beacon input / scan add.) As part of my scan overhaul, modify sta_add() and the scan_add() APIs to take an explicit current channel. The normal RX path will set it to ic_curchan so it's a no-op. However, drivers may decide to (eventually!) override the scan method to set the "right" current channel based on what the firmware reports the scan state is. So for example, iwn, rsu and other NICs will eventually do this: * driver issues scan start firmware command; * firmware sends a "scan start on channel X" notify; * firmware sends a bunch of beacon RX's as part of the scan results; * .. and the driver will replace scan_add() curchan with channel X, so scan results are correct. * firmware sends a "scan start on channel Y" notify; * firmware sends more beacons... * .. the driver replaces scan_add() curchan with channel Y. Note: * Eventually, net80211 should eventually grow the idea of a per-packet current channel. It's possible in various modes (eg WAVE, P2P, etc) that individual frames can come in from different channels and that is under firmware control rather than driver/net80211 control, so we should support that.
* Fix the scan handling for 11b->11g upgrades in a world where, well,adrian2014-12-181-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | it's not just 11b/11g. The following was happening, and it's quite .. annoyingly grr-y. * create vap, setup wpa_supplicant with no bgscanning, etc - there's no call to ieee80211_media_change, so vap->iv_des_mode is IEEE80211_MODE_AUTO; * do ifconfig wlan0 scan - same thing, media_change doesn't get called, iv_des_mode stays as auto. * But then, run wpa_cli and do 'scan' - it'll do a media change. * if you're on 11ng, vap->iv_des_mode gets changed to IEEE80211_MODE_11NG * Then makescanlist() is called. There's a block of code that gets called if iv_des_mode != IEEE80211_MODE_AUTO, and it does this: if (vap->iv_des_mode != IEEE80211_MODE_11G || mode != IEEE80211_MODE_11B) continue; mode = IEEE80211_MODE_11G; /* upgrade */ * .. now, iv_des_mode is not IEEE80211_MODE_11G, so it always runs 'continue' * .. and thus the scan list stays empty and no further channel scans occur. Ever.(1) If you then disassociate and try associating to something, your scan table has likely been purged / aged out and you'll never see anything in the scan list. (1) You need to do 'ifconfig wlan0 mode auto' or just destroy/re-create the VAP to get working wireless again. Tested: * iwn(4) - intel 5300 wifi; STA mode; using wpa_supplicant; bgscan enabled -and- wpa_supplicant scanning. Thanks to: * Everyone who kept poking me about this and wondering why the hell their wifi would eventually stop seeing scan lists. Grr. I eventually snapped this evening and dug back into this code.
* Fix typo in comment.rpaulo2013-11-291-1/+1
|
* The r48589 promised to remove implicit inclusion of if_var.h soon. Prepareglebius2013-10-261-0/+1
| | | | | | | | to this event, adding if_var.h to files that do need it. Also, include all includes that now are included due to implicit pollution via if_var.h Sponsored by: Netflix Sponsored by: Nginx, Inc.
* Replace the homegrown implementation of nitems() with calls to nitems()rpaulo2013-08-141-3/+1
| | | | | | | | | (param.h). Operating systems that don't have nitems() can easily define it on their own net80211 OS-specific header file. Discussed with: adrian
* Initial cut at making IBSS support 802.11n aware.adrian2013-01-261-5/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add HTINFO field decoding to ieee80211_ies_expand() - it's likely not 100% correct as it's not looking at the draft 11n HTINFO location, but I don't think anyone will care. * When doing an IBSS join make sure the 11n channel configuration is used - otherwise the 11a/11bg channel will be used and there won't be any chance for an upgrade to 11n. * When creating an IBSS network, ensure the channel is updated to an 11n channel so other 11n nodes can see it and speak to it with MCS rates. * Add a bit of code that's disabled for now which handles the HT field updating. This won't work out very well with lots of adhoc nodes as we'd end up ping-ponging between the HT configuration for each node. Instead, we should likely only pay attention to the "master" node we initially associated against and then ensure we propagate that information forward in our subsequent beacons. However, due to the nature of IBSS (ie, there's no specific "master" node in the specification) it's unclear which node we should lift the HT parameters from. So for now this assumes the HT parameters are squirreled away in the initial beacon/probe response. So there's some trickiness here. With ap/sta pairing, the probe response just populates a legacy node and the association request/response is what is used for negotiation 11n-ness (and upgrading things as needed.) With ibss networks, the pairing is done with probe request/response, with discovery being done by creating nodes when new beacons in the IBSS / BSSID are heard. There's no assoc request/response frames going on. So the trick here has been to figure out where to upgrade things. I don't like how I just taught ieee80211_sta_join() to "speak" HT - I'd rather there be an upgrade path when an IBSS node joins and there are HT parameters present. Once I've done that, I'll kill this HT special casing that's going on in ieee80211_sta_join(). Tested: * AR9280, AR5416, AR5212 - basic iperf and ping interoperability tests whilst in a non-encrypted adhoc network. TODO: * Fix up the HT upgrade path for IBSS nodes rather than adding code in ieee80211_sta_join(), then remove my code from there. * When associating, there's a concept of a "master" node in the IBSS which is the node you first joined the network through. It's possible the correct thing to do is to listen to HT updates and configure WME parameters from that node. However, once that node goes away, which node(s) should be listened to for configuration changes? For things like HT channel width, it's likely going to be ok to just associate as HT40 and then use the per-neighbor rate control and HTINFO/HTCAP fields to figure out which rates and configuration to speak. Ie, for a 20MHz 11n node, just speak 20MHz rates to it. It shouldn't "change", like what goes on in AP/STA configurations.
* When setting a fixed channel on adapters with 11n support the scanbschmidt2011-08-081-1/+9
| | | | | | | | | | | | | | | | | channel list ends up with 2 entries, the HT and the legacy channel. The scan itself is currently always done at legacy rates so we end up receiving scan results for legacy networks on the HT channel and erroneously assigning the BSS to the 11n channel. As the channel's capabilities are used to setup the adapter we might end up with non-working settings and/or firmware crashes. Fix this by ensuring that scan results received on a HT channel are only assigned to that channel if the htcap IE is available, else use the legacy channel equivalent. Tested by: Pawel Worach, Raoul Megelas, Maciej Milewski, Andrei <az at azsupport dot com> Approved by: re (kib)
* Fix rmax calculation during BSS selection.bschmidt2011-03-131-9/+21
| | | | | | | | | | | | | | | | | | If multiple networks are available the max bandwidth is one condition used for selecting the "best" BSS. To achieve that we should consider all parameters which affect the max RX rate. This includes 20/40MHz, SGI and the of course the MCS set. If the TX MCS parameters are available we should use those, because an AP announcing support for receiving frames at 450Mbps might only be able to transmit at 150Mbps (1T3R). I haven't seen devices with support for transmitting at higher rates then receiving, so prefering TX over RX information should be safe. While here, remove the hardcoded assumption that MCS15 is the max possible MCS rate, use MCS31 instead which really is the highest rate (according to the 802.11n std). Also, fix a mismatch of an 40MHz/SGI check.
* The meshid element is memcpy()'ed into se_meshid if included in eitherbschmidt2010-11-221-1/+1
| | | | | | | | beacon or probe-response frames. Fix the condition by checking for the the array's content instead of the always existing array itself. Reviewed by: rpaulo, stefanf MFC after: 3 days
* Fix background roaming to actually work in AUTO roaming mode.adrian2010-10-011-1/+1
| | | | | IEEE80211_F_BGSCAN is a vap flag, not a channel flag. So although bgscan occured, sta_roam_check() would never be called.
* Compare the address of the array, not the array.rpaulo2010-06-011-1/+1
| | | | | | Found with: Coverity Prevent(tm) CID: 3690 MFC after: 3 days
* Make this code a little more portable by wrapping the mtx calls intorpaulo2010-04-141-23/+23
| | | | | | macros. MFC after: 1 week
* fix misplaced #endif that caused tdma handling to be merged with ESS handlingsam2009-07-311-1/+1
| | | | | | (causing tdma scanning to break) Approved by: re (kib)
* Implementation of the upcoming Wireless Mesh standard, 802.11s, on therpaulo2009-07-111-25/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | net80211 wireless stack. This work is based on the March 2009 D3.0 draft standard. This standard is expected to become final next year. This includes two main net80211 modules, ieee80211_mesh.c which deals with peer link management, link metric calculation, routing table control and mesh configuration and ieee80211_hwmp.c which deals with the actually routing process on the mesh network. HWMP is the mandatory routing protocol on by the mesh standard, but others, such as RA-OLSR, can be implemented. Authentication and encryption are not implemented. There are several scripts under tools/tools/net80211/scripts that can be used to test different mesh network topologies and they also teach you how to setup a mesh vap (for the impatient: ifconfig wlan0 create wlandev ... wlanmode mesh). A new build option is available: IEEE80211_SUPPORT_MESH and it's enabled by default on GENERIC kernels for i386, amd64, sparc64 and pc98. Drivers that support mesh networks right now are: ath, ral and mwl. More information at: http://wiki.freebsd.org/WifiMesh Please note that this work is experimental. Also, please note that bridging a mesh vap with another network interface is not yet supported. Many thanks to the FreeBSD Foundation for sponsoring this project and to Sam Leffler for his support. Also, I would like to thank Gateworks Corporation for sending me a Cambria board which was used during the development of this project. Reviewed by: sam Approved by: re (kensmith) Obtained from: projects/mesh11s
* iv_flags_ext is full, make room by moving HT-related flags to a newsam2009-06-071-2/+2
| | | | iv_flags_ht word
* Overhaul monitor mode handling:sam2009-05-201-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | o replace DLT_IEEE802_11 support in net80211 with DLT_IEEE802_11_RADIO and remove explicit bpf support from wireless drivers; drivers now use ieee80211_radiotap_attach to setup shared data structures that hold the radiotap header for each packet tx/rx o remove rx timestamp from the rx path; it was used only by the tdma support for debugging and was mostly useless due to it being 32-bits and mostly unavailable o track DLT_IEEE80211_RADIO bpf attachments and maintain per-vap and per-com state when there are active taps o track the number of monitor mode vaps o use bpf tap and monitor mode vap state to decide when to collect radiotap state and dispatch frames; drivers no longer explicitly directly check bpf state or use bpf calls to tap frames o handle radiotap state updates on channel change in net80211; drivers should not do this (unless they bypass net80211 which is almost always a mistake) o update various drivers to be more consistent/correct in handling radiotap o update ral to include TSF in radiotap'd frames o add promisc mode callback to wi Reviewed by: cbzimmer, rpaulo, thompsa
* Create a taskqueue for each wireless interface which provides a serialisedthompsa2009-05-021-3/+3
| | | | | | | | | | | | | | | | | | | | | | | sleepable context for net80211 driver callbacks. This removes the need for USB and firmware based drivers to roll their own code to defer the chip programming for state changes, scan requests, channel changes and mcast/promisc updates. When a driver callback completes the hardware state is now guaranteed to have been updated and is in sync with net80211 layer. This nukes around 1300 lines of code from the wireless device drivers making them more readable and less race prone. The net80211 layer has been updated as follows - all state/channel changes are serialised on the taskqueue. - ieee80211_new_state() always queues and can now be called from any context - scanning runs from a single taskq function and executes to completion. driver callbacks are synchronous so the channel, phy mode and rx filters are guaranteed to be set in hardware before probe request frames are transmitted. Help and contributions from Sam Leffler. Reviewed by: sam
* Minor cleanups of tdma protocol handling:sam2009-03-181-5/+9
| | | | | | | | | | | o break out version-related code to simplify rev'ing the protocol o add parameter validation macros so checks that appear multiple places are consistent (and easy to change) o add protocol version check when looking for a scan candidate o improve scan debug output format o rewrite beacon update handling to calculate a bitmask of changed values and pass that down through the driver callback so drivers can optimize work o do slot bounds check before use when parsing received beacons
* add the desired channel to the scan list if not already present andsam2009-03-041-0/+27
| | | | compatible with other scan controls
* Add modes for 1/2 and 1/4-width channels so we have separate roamingsam2009-02-191-0/+2
| | | | | | | | | | | | | | | | | | and xmit parameters. This makes it possible to use tdma on fractional channels. o add IEEE80211_MODE_HALF and IEEE80211_MODE_QUARTER; note these are band-agnostic (may need revisiting) o setup all default rates in ic_sup_rates instead of doing it only for active modes; we need these to calculate the default tx parameters which are not recalculated after a regulatory update (can't just recalculate after installing a new channel list because we might clobber user settings) o remove special case code in ieee80211_get_suprates; this is now a candidate for an inline or removal o add various entries for new modes (roaming+tx params, wme, rate mapping, scan set setup, country ie construction, tdma, basic rates) Note these modes are intentionally not visible through if_media.
* use c99 initializersam2009-02-191-10/+13
|
* when promoting an 11b channel to 11g do not accept a ``pure G'' (OFDM only)sam2009-02-011-2/+2
| | | | | | channel, only accept a real 11g channel; this fixes a problem where we were wrongly promoting 11b to a Dynamic Turbo G channel which broke scanning on channel 6
* TDMA support for long distance point-to-point links using ath devices:sam2009-01-081-1/+65
| | | | | | | | | | | | | | | o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
* convert MALLOC/FREE to malloc/freesam2008-12-181-5/+5
|
* Fix definition of IEEE80211_CHAN_MAX; it was defined as 255 butsam2008-12-151-1/+6
| | | | | | | really was meant to be 256. Adjust usage accordingly and replace bogus usage of this value in checking IEEE channel #'s. NB: this causes an ABI change; ifconfig must be recompiled
* Fix joining an 11b BSS: scanning is normally done using 11g channelssam2008-10-261-17/+72
| | | | | | | | | | | | | | (unless explicitly locked to mode 11b) so when we join the bss the channel attached to the scan cache entry may need to be demoted. o demote to 11b if the ap is advertising 11b rates o skip the ap if it's 11b but we're locked to 11g (could consider this advisory but for now treat it as mandatory) o handle an odd edge case, if there is a fixed transmit rate for 11g then the rate check against the 11b ap will fail, try to demote to 11b and retry the rate check Reviewed by: sephe, thompsa
* expand captured ie's before calling match_bss so they can potentiallysam2008-10-251-1/+1
| | | | be used in the process
* change ieee80211_sta_join to take an explicit channel instead ofsam2008-10-251-3/+14
| | | | | using the value in the scan parameters; this will be used to fix issues with 11b operation
* Revert the removal of the MALLOC and FREE macros from the net80211 code.des2008-10-231-5/+5
| | | | Requested by: sam
* Retire the MALLOC and FREE macros. They are an abomination unto style(9).des2008-10-231-5/+5
| | | | MFC after: 3 months
* guard against adhoc_pick_channel returning a NULL channel; this cansam2008-09-271-3/+6
| | | | happen after a scan cache flush (e.g. in response to ifconfig wlan bssid -)
* Multi-bss (aka vap) support for 802.11 devices.sam2008-04-201-359/+478
| | | | | | | | | | | Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
* Fix adhoc mode to scan all available channels for a bss to joinsam2008-02-291-42/+63
| | | | | | | | | | while still restricting auto-channel select to only those channels permitted by regulatory constraints (sorta, we're still missing the checks to honor radar and noadhoc status on channels). This somehow got lost in the initial merge of the revised scanning code. Reviewed by: jhay MFC after: 2 weeks
* Be more careful handling off-channel frames: if the driver (wrongly)sam2007-11-261-3/+4
| | | | | | | | | | | sends frames up the stack after changing the current channel then the lookup by ieee channel number may fail leaving a null ptr in se_chan; if this happens fallback to the channel recorded when the frame is processed (curchan). Since the frame doesn't contribute to scan results for the sta this is acceptable. Reviewed by: thompsa MFC after: 3 days
* use the DSPARMS ie to find the home channel for off-channel framessam2007-11-231-11/+12
| | | | | Reviewed by: thompsa MFC after: 1 week
* Correct handling of off-channel frames:sam2007-11-051-12/+37
| | | | | | | | | | | | | | | o do not override the home channel recorded for the sta when the frame is received off-channel; this fixes a problem where we might think the sta was operating on the channel the frame was received on causing association requests to be ignored/rejected (likely cause of kern/99036) o don't include rssi of off-channel frames in the avg rssi used to select a bss; this gives us a better estimate of the signal we will see for the station when on-channel PR: kern/99036 Found by: Yubin Gong Reviewed by: sephe MFC after: 1 week
* sync 11n support with vap code base; many changes based on interopsam2007-11-021-1/+2
| | | | | | testing with all major vendors MFC after: 1 week
* In add_channel(), search 11g channels if mode is AUTO and correspondingsephe2007-07-201-5/+11
| | | | | | | | | | 11b channel is not found, e.g. Atheros 5211. Reported by: matteo Problem outlined by: thompsa Reviewed by: sam, thompsa Approved by: re (kensmith), sam (mentor) Tested by: matteo (an early version)
* revert handling of ssid and bssid to be manadatory instead of advisorysam2007-07-121-33/+40
| | | | | | Prodded by: Kevin Gerry Reviewed by: thompsa, sephe Approved by: re (kensmith)
OpenPOWER on IntegriCloud