#
344223 |
|
17-Feb-2019 |
avos |
MFC r343696: net80211: do not setup roaming parameters for unsupported modes.
ifconfig(8) prints per-mode parameters if they are non-zero; since we have 13 possible modes with 3...5 typically supported this change should greatly reduce amount of information for 'ifconfig <wlan> list roam' command.
While here ensure that sta_roam_check() will not use roaming parameters for unsupported modes (it should not).
This change effectively reverts r188776.
|
#
343818 |
|
06-Feb-2019 |
avos |
MFC r343697: net80211(4): fix rate check when 'roaming' ifconfig(8) option is set to 'auto'
Do not try to clear 'basic rate' bit from roamRate; it cannot be here and, actually, this operation clears 'MCS rate' bit instead, breaking comparison for 11n / 11ac modes.
|
#
343510 |
|
28-Jan-2019 |
avos |
MFC r343342: net80211: turn channel mode check into assertion.
There is may be only 11b channel (since chanflags[] table maps MODE_AUTO to the corresponding 11b channel flags).
|
#
343509 |
|
28-Jan-2019 |
avos |
MFC r343340: net80211: fix channel list construction for non-auto operating mode.
Change the way how channel list mode <-> desired mode match is done: - Match channel list mode for next non-auto desired modes: * 11b: 11g, 11ng; * 11a: 11na - Add pre-defined channels only when one of the next conditions met: * the desired channel mode is 'auto' or * the desired channel and selected channel list modes are exactly the same or * the previous rule (11g / 11n promotion) applies.
Before r275875 construction work properly for all except 11ng / 11na modes - these were broken at all (i.e., the scan list was empty); after r275875 all checks were removed, so scan table was populated by all device-compatible channels (desired mode was ignored).
For example, if I will set 'ifconfig wlan0 mode 11ng' for RTL8821AU: - pre-r275875: nothing, scan will not work; - after r275875: both 11ng and 11na bands were scanned; also, since 11b channel list was used, 14th channel was scanned too. - after this change: only 11ng - 1-13 channels - are used for scanning.
Note: since 11-stable does not have VHT mode definitions they were removed from this merge.
|
#
330446 |
|
05-Mar-2018 |
eadler |
MFC r327231,r327232:
kernel: Fix several typos and minor errors lib: Fix several typos and minor errors
- duplicate words - typos - references to old versions of FreeBSD
|
#
302408 |
|
07-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
300232 |
|
19-May-2016 |
avos |
net80211: fix more compiler warnings.
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.
|
#
298359 |
|
20-Apr-2016 |
avos |
net80211: replace internal LE_READ_*/LE_WRITE_* macro with system 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
|
#
297405 |
|
29-Mar-2016 |
adrian |
[net80211] migrate the time_* macros to ieee80211_* namespace.
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.
|
#
296239 |
|
29-Feb-2016 |
avos |
net80211: do not enforce promiscuous mode for AP scan
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
|
#
295126 |
|
01-Feb-2016 |
glebius |
These files were getting sys/malloc.h and vm/uma.h with header pollution via sys/mbuf.h
|
#
288086 |
|
22-Sep-2015 |
adrian |
Remove duplicate use of RV(), LE_* and other macros.
Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3705
|
#
287197 |
|
27-Aug-2015 |
glebius |
Replay r286410. Change KPI of how device drivers that provide wireless 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.
|
#
286437 |
|
07-Aug-2015 |
adrian |
Revert the wifi ifnet changes until things are more baked and tested.
* 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.
|
#
286410 |
|
07-Aug-2015 |
glebius |
Change KPI of how device drivers that provide wireless 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 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
|
#
283556 |
|
26-May-2015 |
adrian |
Migrate the scan iterator lock typedefs out into ieee80211_freebsd.h.
This removes the final piece of freebsd-specific locking that snuck into the tree - it's now all inside ieee80211_freebsd.h.
|
#
283538 |
|
25-May-2015 |
adrian |
Convert malloc/free back to #define's, as part of OS portability work.
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.
|
#
282742 |
|
10-May-2015 |
adrian |
Prepare for supporting driver-overridden curchan when submitting scan 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.
|
#
275875 |
|
18-Dec-2014 |
adrian |
Fix the scan handling for 11b->11g upgrades in a world where, well, 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.
|
#
258736 |
|
29-Nov-2013 |
rpaulo |
Fix typo in comment.
|
#
257176 |
|
26-Oct-2013 |
glebius |
The r48589 promised to remove implicit inclusion of if_var.h soon. Prepare 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.
|
#
254315 |
|
14-Aug-2013 |
rpaulo |
Replace the homegrown implementation of nitems() with calls to nitems() (param.h).
Operating systems that don't have nitems() can easily define it on their own net80211 OS-specific header file.
Discussed with: adrian
|
#
245928 |
|
25-Jan-2013 |
adrian |
Initial cut at making IBSS support 802.11n aware.
* 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.
|
#
224717 |
|
08-Aug-2011 |
bschmidt |
When setting a fixed channel on adapters with 11n support the scan 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)
|
#
219601 |
|
13-Mar-2011 |
bschmidt |
Fix rmax calculation during BSS selection.
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.
|
#
215699 |
|
22-Nov-2010 |
bschmidt |
The meshid element is memcpy()'ed into se_meshid if included in either 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
|
#
213321 |
|
01-Oct-2010 |
adrian |
Fix background roaming to actually work in AUTO roaming mode.
IEEE80211_F_BGSCAN is a vap flag, not a channel flag. So although bgscan occured, sta_roam_check() would never be called.
|
#
208697 |
|
01-Jun-2010 |
rpaulo |
Compare the address of the array, not the array.
Found with: Coverity Prevent(tm) CID: 3690 MFC after: 3 days
|
#
206617 |
|
14-Apr-2010 |
rpaulo |
Make this code a little more portable by wrapping the mtx calls into macros.
MFC after: 1 week
|
#
196005 |
|
31-Jul-2009 |
sam |
fix misplaced #endif that caused tdma handling to be merged with ESS handling (causing tdma scanning to break)
Approved by: re (kib)
|
#
195618 |
|
11-Jul-2009 |
rpaulo |
Implementation of the upcoming Wireless Mesh standard, 802.11s, on the 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
|
#
193655 |
|
07-Jun-2009 |
sam |
iv_flags_ext is full, make room by moving HT-related flags to a new iv_flags_ht word
|
#
192468 |
|
20-May-2009 |
sam |
Overhaul monitor mode handling: 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
|
#
191746 |
|
02-May-2009 |
thompsa |
Create a taskqueue for each wireless interface which provides a serialised 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
|
#
189980 |
|
18-Mar-2009 |
sam |
Minor cleanups of tdma protocol handling: 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
|
#
189377 |
|
04-Mar-2009 |
sam |
add the desired channel to the scan list if not already present and compatible with other scan controls
|
#
188782 |
|
19-Feb-2009 |
sam |
Add modes for 1/2 and 1/4-width channels so we have separate roaming 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.
|
#
188777 |
|
19-Feb-2009 |
sam |
use c99 initializer
|
#
187991 |
|
01-Feb-2009 |
sam |
when promoting an 11b channel to 11g do not accept a ``pure G'' (OFDM only) 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
|
#
186904 |
|
08-Jan-2009 |
sam |
TDMA support for long distance point-to-point links using ath devices: 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
|
#
186302 |
|
18-Dec-2008 |
sam |
convert MALLOC/FREE to malloc/free
|
#
186107 |
|
14-Dec-2008 |
sam |
Fix definition of IEEE80211_CHAN_MAX; it was defined as 255 but 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
|
#
184302 |
|
26-Oct-2008 |
sam |
Fix joining an 11b BSS: scanning is normally done using 11g channels (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
|
#
184275 |
|
25-Oct-2008 |
sam |
expand captured ie's before calling match_bss so they can potentially be used in the process
|
#
184274 |
|
25-Oct-2008 |
sam |
change ieee80211_sta_join to take an explicit channel instead of using the value in the scan parameters; this will be used to fix issues with 11b operation
|
#
184210 |
|
23-Oct-2008 |
des |
Revert the removal of the MALLOC and FREE macros from the net80211 code.
Requested by: sam
|
#
184205 |
|
23-Oct-2008 |
des |
Retire the MALLOC and FREE macros. They are an abomination unto style(9).
MFC after: 3 months
|
#
183421 |
|
27-Sep-2008 |
sam |
guard against adhoc_pick_channel returning a NULL channel; this can happen after a scan cache flush (e.g. in response to ifconfig wlan bssid -)
|
#
178354 |
|
20-Apr-2008 |
sam |
Multi-bss (aka vap) support for 802.11 devices.
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)
|
#
176653 |
|
29-Feb-2008 |
sam |
Fix adhoc mode to scan all available channels for a bss to join 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
|
#
173956 |
|
26-Nov-2007 |
sam |
Be more careful handling off-channel frames: if the driver (wrongly) 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
|
#
173862 |
|
23-Nov-2007 |
sam |
use the DSPARMS ie to find the home channel for off-channel frames
Reviewed by: thompsa MFC after: 1 week
|
#
173368 |
|
05-Nov-2007 |
sam |
Correct handling of off-channel frames: 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
|
#
173273 |
|
02-Nov-2007 |
sam |
sync 11n support with vap code base; many changes based on interop testing with all major vendors
MFC after: 1 week
|
#
171519 |
|
20-Jul-2007 |
sephe |
In add_channel(), search 11g channels if mode is AUTO and corresponding 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)
|
#
171409 |
|
12-Jul-2007 |
sam |
revert handling of ssid and bssid to be manadatory instead of advisory
Prodded by: Kevin Gerry Reviewed by: thompsa, sephe Approved by: re (kensmith)
|
#
171124 |
|
30-Jun-2007 |
thompsa |
Change the channel number in the scan results struct to be a pointer to the operating channel and use this in the scan cache rather than directly using ic_curchan. Some firmware cards can only do a full scan and so ic_curchan does not have the correct value.
Also add IEEE80211_CHAN2IEEE to directly dereference ic_ieee from the channel to be used in the fast path.
Reviewed by: sam, sephe Approved by: re (kensmith)
|
#
170530 |
|
11-Jun-2007 |
sam |
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing
Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested
This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
|