#
344969 |
|
09-Mar-2019 |
avos |
MFC r343990: net80211: hide casts for 'i_seq' field offset calculation inside ieee80211_getqos() and reuse it in various places.
|
#
330458 |
|
05-Mar-2018 |
eadler |
MFC r306139:
[net80211] don't add IBSS node table entries for neighbors from other SSIDs.
The adhoc probe/beacon input path was creating nodes for all SSIDs. This wasn't a problem when the NICs were configured to only process frames for the current BSSID, but that didn't allow IBSS merges. Once avos and I flipped on "beacons from all BSSIDs" to allow for correct IBSS merging, we found this interesting behaviour.
This adds a check against the current SSID.
* If there's no VAP SSID, allow anything * If there's a VAP SSID, check if the incoming frame has a suitable SSID and if so, allow it.
This prevents nodes being created for other SSIDs in probe and beacon frames - ie, beacons overlapping IBSSes with different SSIDs, and probe requests from arbitrary devices.
Tested:
* AR9380, IBSS mode, both local and other IBSSes.
|
#
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 |
#
302202 |
|
25-Jun-2016 |
adrian |
[net80211] re-revert the ibss "is this local to the bss" patch.
avos@ pointed out to me that this broke IBSS merging because the rest of the input path no longer was called for non-IBSS frames.
I committed a change to not input non-IBSS frames, which stopped nodes being created for BSSes that weren't ours. Unfortunately thta stopped the input path for non-IBSS frames in general, so the management input path didn't work.
So, I'll revert this until I come up with a better solution. (Hopefully before 11.)
Reviewed by: avos Approved by: re (gjb)
|
#
299575 |
|
12-May-2016 |
avos |
net80211: drop some unused variables / local macros
Most of them left after some commits (r178354, r191544, r287197 etc.); some were never used.
Found by: Clang Static Analyzer
|
#
298995 |
|
03-May-2016 |
pfg |
sys/net*: minor spelling fixes.
No functional change.
|
#
298757 |
|
28-Apr-2016 |
adrian |
[net80211] fix indenting.
Sponsored by: Eva Automation, Inc.
|
#
298756 |
|
28-Apr-2016 |
adrian |
[net80211] handle action frames in adhoc mode from the node that created the BSS.
We don't have a separate bss node; instead we dup the first node we saw and turn that into the BSS node. This means that action frames from that node would be rejected.
So, check that the node is the bss node /and/ the MAC doesn't match ni_macaddr. That's the "right" way for now to verify it's an unknown node.
This fixes handling action frames in adhoc mode, which includes negotiating 11n aggregation via ADDBA/DELBA.
This by itself isn't enough to correctly create 11n adhoc networks; but it is required for aggregation to be negotiated.
Tested:
* AR9380, 11n adhoc mode * broadcom 11ac adhoc (vendor platform)
Sponsored by: Eva Automation, Inc.
|
#
298376 |
|
20-Apr-2016 |
avos |
net80211: hide subtype mask & shift in function call.
Hide subtype mask/shift (which is used for index calculation in ieee80211_mgt_subtype_name[] array) in function call.
Tested with RTL8188CUS, STA mode.
Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D5369
|
#
297727 |
|
08-Apr-2016 |
adrian |
[net80211] revert part of r282405 in order to restore IBSS behaviour.
This prevents nodes being created for peers on BSSes that are not our own. (Ie, same channel, IBSS, but different BSS.)
The "IBSS merge" thing was fixed by me enabling "see all beacons" in the ath(4) driver a few months ago. Trouble is, we now need the filtering again.
Tested:
* ath(4), IBSS, on a very busy IBSS channel with lots (> 15) IBSS networks.
PR: kern/208643 Sponsored by: Eva Automation, Inc.
|
#
296254 |
|
01-Mar-2016 |
avos |
net80211: eliminate copy-paste nearby ieee80211_check_rxseq()
Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D4043
|
#
295795 |
|
19-Feb-2016 |
avos |
net80211: add few missing subtype names.
- Add definitions for Timing Advertisement and Control Wrapper frames. - Refresh ieee80211_mgt_subtype_name and ieee80211_ctl_subtype_name arrays. - Count Timing Advertisement frames as discarded management frames in all modes.
Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5331
|
#
283535 |
|
25-May-2015 |
adrian |
Begin plumbing ieee80211_rx_stats through the receive path.
Smart NICs with firmware (eg wpi, iwn, the new atheros parts, the intel 7260 series, etc) support doing a lot of things in firmware. This includes but isn't limited to things like scanning, sending probe requests and receiving probe responses. However, net80211 doesn't know about any of this - it still drives the whole scan/probe infrastructure itself.
In order to move towards suppoting smart NICs, the receive path needs to know about the channel/details for each received packet. In at least the iwn and 7260 firmware (and I believe wpi, but I haven't tried it yet) it will do the scanning, power-save and off-channel buffering for you - all you need to do is handle receiving beacons and probe responses on channels that aren't what you're currently on. However the whole receive path is peppered with ic->ic_curchan and manual scan/powersave handling. The beacon parsing code also checks ic->ic_curchan to determine if the received beacon is on the correct channel or not.[1]
So:
* add freq/ieee values to ieee80211_rx_stats; * change ieee80211_parse_beacon() to accept the 'current' channel as an argument; * modify the iv_input() and iv_recv_mgmt() methods to include the rx_stats; * add a new method - ieee80211_lookup_channel_rxstats() - that looks up a channel based on the contents of ieee80211_rx_stats; * if it exists, use it in the mgmt path to switch the current channel (which still defaults to ic->ic_curchan) over to something determined by rx_stats.
This is enough to kick-start scan offload support in the Intel 7260 driver that Rui/I are working on. It also is a good start for scan offload support for a handful of existing NICs (wpi, iwn, some USB parts) and it'll very likely dramatically improve stability/performance there. It's not the whole thing - notably, we don't need to do powersave, we should not scan all channels, and we should leave probe request sending to the firmware and not do it ourselves. But, this allows for continued development on the above features whilst actually having a somewhat working NIC.
TODO:
* Finish tidying up how the net80211 input path works. Right now ieee80211_input / ieee80211_input_all act as the top-level that everything feeds into; it should change so the MIMO input routines are those and the legacy routines are phased out.
* The band selection should be done by the driver, not by the net80211 layer.
* ieee80211_lookup_channel_rxstats() only determines 11b or 11g channels for now - this is enough for scanning, but not 100% true in all cases. If we ever need to handle off-channel scan support for things like static-40MHz or static-80MHz, or turbo-G, or half/quarter rates, then we should extend this.
[1] This is a side effect of frequency-hopping and CCK modes - you can receive beacons when you think you're on a different channel. In particular, CCK (which is used by the low 11b rates, eg beacons!) is decodable from adjacent channels - just at a low SNR. FH is a side effect of having the hardware/firmware do the frequency hopping - it may pick up beacons transmitted from other FH networks that are in a different phase of hopping frequencies.
|
#
282820 |
|
12-May-2015 |
adrian |
Do not check sequence number for QoS Null frames; set it for generated QoS Null frames to 0
From IEEE Std. 802.11-2012, 8.3.2.1 "Data frame format", p. 415 (513): "The Sequence Control field for QoS (+)Null frames is ignored by the receiver upon reception."
At this moment, any <mode>_input() function interprets them as regular QoS data frames with TID = 0. As a result, stations, that use another TX sequence for QoS Null frames (e.g. wpi(4), where (QoS) Null frames are generated by the firmware), may experience significant packet loss with any other NIC in hostap mode.
Tested:
* wpi(4) (author) * iwn(4) - Intel 5100, STA mode (me)
PR: kern/200128 Submitted by: Andriy Voskoboinyk <s3erios@gmail.com>
|
#
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.
|
#
282735 |
|
10-May-2015 |
adrian |
Fix typo introduced in previous commit.
PR: kern/199632 Submitted by: Andriy Voskoboinyk <s3erios@gmail.com>
|
#
282405 |
|
03-May-2015 |
adrian |
Use bssid validation for data frames only + add RUN -> RUN state transition
However, IBSS merge will be performed only if a driver calls ieee80211_ibss_merge(); so, this applicable to the ath(4) only. Also, this should fix bug 167870.
PR: kern/199632 Submitted by: Andriy Voskoboinyk <s3erios@gmail.com>
|
#
271861 |
|
19-Sep-2014 |
glebius |
Mechanically convert to if_inc_counter().
|
#
260444 |
|
08-Jan-2014 |
kevlo |
Rename definition of IEEE80211_FC1_WEP to IEEE80211_FC1_PROTECTED.
The origin of WEP comes from IEEE Std 802.11-1997 where it defines whether the frame body of MAC frame has been encrypted using WEP algorithm or not. IEEE Std. 802.11-2007 changes WEP to Protected Frame, indicates whether the frame is protected by a cryptographic encapsulation algorithm.
Reviewed by: adrian, rpaulo
|
#
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.
|
#
246930 |
|
17-Feb-2013 |
adrian |
Disable this variable; the code using it is also disabled.
|
#
246927 |
|
17-Feb-2013 |
adrian |
Disable this code and add a note as to why.
It wasn't currently being called anyway - but being explicit about it can't hurt.
|
#
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.
|
#
244078 |
|
10-Dec-2012 |
adrian |
Adjust the channel to correctly setup the HT flags when transitioning an IBSS VAP to RUN.
An 11n IBSS was beaconing HTINFO/HTCAP IE's that didn't have any HT information setup (like the HT TX/RX MCS bitmask.)
Tested:
* AR9280, IBSS - both a statically setup channel and a scanned channel
PR: kern/172955
|
#
244061 |
|
09-Dec-2012 |
adrian |
Undo the previous adhoc commit - doing the WME IE handling here is totally wrong.
If we parse the WME IE here, we'll be constantly updating the WME configuration from each WME enabled IBSS node we see.
There's a separate issue where the WME configuration is blanked out when the interface is brought up; the WME parameters aren't "sticky."
Also, ieee80211_init_neighbor() parses the ath IE, so doing it here isn't required.
Sorry about the noise.
PR: kern/165969
|
#
244060 |
|
09-Dec-2012 |
adrian |
Handle ath-specific and WME IE's in adhoc mode.
The Adhoc support wasn't parsing and handling the ath specific and WME IEs, thus the atheros vendor support and WME TXOP parameters aren't being copied from the peer.
It copies the WME parameters from whichever adhoc node it decides to associate to, rather than just having them be statically configured per adhoc node. This may or may not be exactly "right", but it's certainly going to be more convienent for people - they just have to ensure their adhoc nodes are setup with correct WME parameters.
Since WME parameters aren't per-node but are configured on hardware TX queues, if some nodes support WME and some don't - or perhaps, have different WME parameters - things will get quite quirky.
So ensure that you configure your adhoc nodes with the same WME parameters.
Secondly - the Atheros Vendor IE is parsed and operated on per-node, so this should work out ok between nodes that do and don't do Atheros extensions. Once you see a becaon from that node and you setup the association state, it _should_ parse things correctly.
TODO:
* I do need to ensure that both adhoc setup paths are correctly updating the IE stuff. Ie, if the adhoc node is created by a data frame instead of a beacon frame, it'll come up with no WME/ath IE config. The next beacon frame that it receives from that node will update the state. I just need to sit down and better understand how that's suppose to work in IBSS mode.
Tested:
* AR5416 <-> AR9280 - fast frames and the WME configuration both popped up. (This is with a local HAL patch that enables the fast frames capability on the AR5416 chipsets.)
PR: kern/165969
|
#
241138 |
|
02-Oct-2012 |
adrian |
Migrate the power-save functions to be overridable VAP methods.
This turns ieee80211_node_pwrsave(), ieee80211_sta_pwrsave() and ieee80211_recv_pspoll() into methods.
The intent is to let drivers override these and tie into the power save management pathway.
For ath(4), this is the beginning of forcing a node software queue to stop and start as needed, as well as supporting "leaking" single frames from the software queue to the hardware.
Right now, ieee80211_recv_pspoll() will attempt to transmit a single frame to the hardware (whether it be a data frame on the power-save queue or a NULL data frame) but the driver may have hardware/software queued frames queued up. This initial work is an attempt at providing the hooks required to implement correct behaviour.
Allowing ieee80211_node_pwrsave() to be overridden allows the ath(4) driver to pause and unpause the entire software queue for a given node. It doesn't make sense to transmit anything whilst the node is asleep.
Please note that there are other corner cases to correctly handle - specifically, setting the MORE data bit correctly on frames to a station, as well as keeping the TIM updated. Those particular issues can be addressed later.
|
#
221418 |
|
04-May-2011 |
adrian |
Fix some corner cases in the net80211 sequence number retransmission handling.
The current sequence number code does a few things incorrectly:
* It didn't try eliminating duplications from HT nodes. I guess it's assumed that out of order / retransmission handling would be handled by the AMPDU RX routines. If a HT node isn't doing AMPDU RX, then retransmissions need to be eliminated. Since most of my debugging is based on this (as AMPDU TX software packet aggregation isn't yet handled), handle this corner case.
* When a sequence number of 4095 was received, any subsequent sequence number is going to be (by definition) less than 4095. So if the following sequence number (0) doesn't initially occur and the retransmit is received, it's incorrectly eliminated by the IEEE80211_FC1_RETRY && SEQ_LEQ() check. Try to handle this better.
This almost completely eliminates out of order TCP statistics showing up during iperf testing for the 11a, 11g and non-aggregate 11n AMPDU RX case. The only other packet loss conditions leading to this are due to baseband resets or heavy interference.
|
#
218958 |
|
22-Feb-2011 |
bschmidt |
Make sure to only accept and handle action frames which are for us. In promiscuous mode we might receive stuff which otherwise gets filtered by hardware.
|
#
218927 |
|
21-Feb-2011 |
bschmidt |
Add a new mgmt subtype "ACTION NO ACK" defined in 802.11n-2009, while here clean up parts of the *_recv_mgmt() functions. - make sure appropriate counters are bumped and debug messages are printed - order the unhandled subtypes by value and add a few missing ones - fix some whitespace nits - remove duplicate code in adhoc_recv_mgmt() - remove a useless comment, probably left in while c&p
|
#
205277 |
|
18-Mar-2010 |
rpaulo |
Fix a couple of bugs with 802.11n: o Process the BAR frame on the adhoc, mesh and sta modes o Fix the format of the ADDBA reply frame o Fix references to the spec section numbers
Also, print the all the MCS rates in bootverbose.
Sponsored by: iXsystems, Inc. Obtained from: //depot/user/rpaulo/80211n/...
|
#
203422 |
|
03-Feb-2010 |
rpaulo |
When taking the AMPDU reorder fastpath, need_tap wasn't being initialized. Initialize on declaration to avoid this.
Found with: clang static analyzer
|
#
195377 |
|
05-Jul-2009 |
sam |
Revamp 802.11 action frame handling: o add a new facility for components to register send+recv handlers o ieee80211_send_action and ieee80211_recv_action now use the registered handlers to dispatch operations o rev ieee80211_send_action api to enable passing arbitrary data o rev ieee80211_recv_action api to pass the 802.11 frame header as it may be difficult to locate o update existing IEEE80211_ACTION_CAT_BA and IEEE80211_ACTION_CAT_HT handling o update mwl for api rev
Reviewed by: rpaulo Approved by: re (kensmith)
|
#
192765 |
|
25-May-2009 |
sam |
Fix handling of devices w/o radiotap support: o do not attach DLT_IEEE802_11_RADIO unless both tx and rx headers are present; this is assumed in the capture code paths o verify the above with asserts in ieee80211_radiotap_{rx,tx} o add missing checks for active taps before calling ieee80211_radiotap_rx
|
#
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
|
#
191754 |
|
02-May-2009 |
sam |
whitespace
|
#
191547 |
|
26-Apr-2009 |
sam |
print both fc bytes when hitting a protocol version mismatch
|
#
191546 |
|
26-Apr-2009 |
sam |
add iv_recv_ctl method to allow hooking rx ctl frame handling
|
#
191534 |
|
26-Apr-2009 |
sam |
o use shared code to handle bpf tap and mbuf cleanup o swap conditional order to put the cheapest first
|
#
190391 |
|
24-Mar-2009 |
sam |
split Atheros SuperG support out into it's own file that's included only with a new IEEE80211_SUPPORT_SUPERG option
|
#
188466 |
|
10-Feb-2009 |
sam |
clean neighbor entries on beacon miss
|
#
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
|
#
184480 |
|
30-Oct-2008 |
sam |
Fix checks for fast frames negotiation. ni_ath_flags holds the capabilities reported by the ap. These need to be cross-checked against the local configuration in the vap. Previously we were only checking the ap capabilities which meant that if an ap reported it was ff-capable but we were not setup to use them we'd try to do ff aggregation and drop the frame.
There are a number of problems to be fixed here but applying this fix immediately as the problem causes all traffic to stop (and has not workaround).
Reported by: Ashish Shukla
|
#
184345 |
|
27-Oct-2008 |
sam |
o use the new association callback to notify the driver when joining a bss in sta and adhoc modes; this should've been done forever ago as most all drivers use this hook to set per-station transmit parameters such as for tx rate control o adjust drivers to remove explicit calls to the driver newassoc method
|
#
184276 |
|
25-Oct-2008 |
sam |
use a private mgt frame recv handler for ahdemo mode instead of an inline test in the adhoc mode rx path so classes derived from ahdemo mode can override the default behaviour
|
#
184268 |
|
25-Oct-2008 |
sam |
add/improve debug msgs
|
#
183247 |
|
21-Sep-2008 |
sam |
Cleanup AMPDU handling:
For receive: o explicitly tag rx frames w/ M_AMPDU instead of passing frames through the reorder processing according to the node having HT and the frame being QoS data o relax ieee80211_ampdu_reorder asserts to allow any frame to be passed in, unsuitable frames are returned to the caller for normal processing; this permits drivers that cannot inspect the PLCP to mark all data frames as potential ampdu candidates with only a small penalty o add M_AMPDU_MPDU to identify frames resubmitted from the reorder q
For transmit: o tag aggregation candidates with M_AMPDU_MPDU o fix the QoS ack policy set in ampdu subframes; we only support immediate BA streams which should be marked for "normal ack" to get implicit block ack behaviour; interestingly certain vendor parts BA'd frames with the 11e BA ack policy set o do not assign a sequence # to aggregation candidates; this must be done when frames are submitted for transmit (NB: this can/will be handled better when aggregation is pulled up to net80211)
|
#
179216 |
|
22-May-2008 |
sam |
no need to stop the sw beacon miss timer; it's not used with adhoc or wds
|
#
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)
|