The ath(4) driver now sees beacons and management frames for different
BSSIDs in IBSS mode, which is a problem when you're in a very busy
IBSS environment.
So, expose this function so drivers can use it to check if the current
RX node is actually for a BSS we need to pay attention to or not.
PR: kern/208644
Sponsored by: Eva Automation. Inc.
field and into a separate fast-frames staging pointer in ieee80211_node.
The A-MPDU TX path allows txa_private to be used by drivers. So it will
clash with any attempt to use fast-frames. Now, fast-frames is not really
anything special - it's just a custom ethernet frame type that contains
two MSDUs into one MPDU. So all the NIC has to support doing is transmitting
up to a 4KiB frame with an arbitrary ethertype and bam! Fast-frames.
However, using txa_private means we can /either/ do fast-frames or A-MPDU TX,
so fast frames has been turned off in the Atheros HAL for 11n chipsets.
This is a bit silly - it actually means that 802.11 performance to/from
11abg Atheros chips is actually better than between an 11abg atheros device
and an 11n Atheros device.
So:
* create a new mbuf staging queue for fast frames. It only queues a single
frame in the staging queue (and there's a top-level ic staging queue
used for expiry/tracking) so it's just an mbuf pointer per TID.
* Still use the ampdu TX packet counter to determine whether to do
aggregation or not. It'll double count if we start doing both A-MPDU TX
and fast frames, but that's not all that important right now.
* Initialise the pps tracker so ticks isn't zero. This ensures that
fast-frames actually gets used - without it, the ticks math overflows
and the pps math always sets txa_pps=0. This is the same bug that
plagued A-MPDU TX starting logic.
This actually allows fast-frames transmit to occur between the AR9331
(in 11n HT/20 mode) and AR9170 (if_otus) in 11bg mode.
Now, this is a great big no-op on atheros 11n hardware, so don't worry.
It may mean you start seeing more reliable fast-frames transmission on
11abg hardware which may expose some more amusing bugs.
TODO:
* further testing and debugging of all of this before flipping on
fast-frames in if_ath (for 11n) and if_otus.
This problem happens when using ACL policy to filter mesh STA
but two nodes have different policy. Then one of them will try to
peer all the time. This can also help if for any reason one of the
peering mesh STA have problems sending/receiving peer frames.
* Modified struct ieee80211_node to include two new fields:
+ struct callout ni_mlhtimer /* link mesh backoff timer */
+ uint8_t ni_mlhcnt /* link mesh holding counter */
* Added two new sysctl (check sysctl -d for more info):
+ net.wlan.mesh.backofftimeout=5000
+ net.wlan.mesh.maxholding=2;
* When receiving a beacon and we are in IEEE80211_NODE_MESH_IDLE
check if ni_mlhcnt >= ieee80211_mesh_maxholding, if so do not do anything;
* In mesh_peer_timeout_cb when transitioning from IEEE80211_NODE_MESH_HOLDING
to IEEE80211_NODE_MESH_IDLE increment ni_mlhcnt, and eventually start
ieee80211_mesh_backofftimeout;
Approved by: adrian (mentor)
iterate lock.
This causes LORs and deadlocks as some code paths will have the com lock
held when calling ieee80211_iterate_nodes().
Here, the comlock isn't held during the node table and node iteration
locks; and the callback isn't called with any (extra) lock held.
PR: kern/170098
Submitted by: moonlightakkiy@yahoo.ca
MFC after: 4 weeks
Currently, a channel width change updates the 802.11n HT info data in
net80211 but it doesn't trigger any device changes. So the device
driver may decide that HT40 frames can be transmitted but the last
device channel set only had HT20 set.
Now, a task is scheduled so a hardware reset or change isn't done
during any active ongoing RX. It also means that it's serialised
with the other task operations (eg channel change.)
This isn't the final incantation of this work, see below.
For now, any unmodified drivers will simply receive a channel
change log entry. A subsequent patch to ath(4) will introduce
some basic channel change handling (by resetting the NIC.)
Other NICs may need to update their rate control information.
TODO:
* There's still a small window at the present moment where the
channel width has been updated but the task hasn't been fired.
The final version of this should likely pass in a channel width
field to the driver and let the driver atomically do whatever
it needs to before changing the channel.
PR: kern/166286
This introduces struct ieee80211_rx_stats - which stores the various kinds
of RX statistics which a MIMO and non-MIMO 802.11 device can export.
It also fleshes out the mimo export to userland (node_getmimoinfo()).
It assumes that MIMO radios (for now) export both ctl and ext channels.
Non-11n MIMO radios are possible (and I believe Atheros made at least
one), so if that chipset support is added, extra flags to the
struct ieee80211_rx_stats can be added to extend this support.
Two new input functions have been added - ieee80211_input_mimo() and
ieee80211_input_mimo_all() - which MIMO-aware devices can call with
MIMO specific statistics.
802.11 devices calling the non-MIMO input functions will still function.
This framework allows drivers to abstract the rate control algorithm and
just feed the framework with the usable parameters. The rate control
framework will now deal with passing the parameters to the selected
algorithm. Right now we have AMRR (the default) and RSSADAPT but there's
no way to select one with ifconfig, yet.
The objective is to have more rate control algorithms in the net80211
stack so all drivers[0] can use it. Ideally, we'll have the well-known
sample rate control algorithm in the net80211 at some point so all
drivers can use it (not just ath).
[0] all drivers that do rate control in software, that is.
Reviewed by: bschmidt, thompsa, weyongo
MFC after: 1 months
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
long-term work before they can be serviced. Packets are tagged and
assigned an age (in seconds) at the point they are added to the
queue. If a packet is not retrieved before it's age expires it is
reclaimed. Tagging can take two forms: a reference to an ieee80211_node
(as happens in the tx path) or an opaque token in cases where there
is no reference or the node structure is not stable (i.e. it's going
to be destroyed).
o add ic_stageq to replace the per-node wds staging queue used for
dynamic wds
o add ieee80211_mac_hash for building ageq tokens; this computes a
32-bit hash from an 802.11 mac address (copied from the bridge)
o while here fix a stray ';' noticed in IEEE80211_PSQ_INIT
Reviewed by: rpaulo
Approved by: re (kensmith)
we receive the AssocResp, so we can only set ni_txparms properly
at that point. To make this possible make node_setuptxparms public
as ieee80211_node_setuptxparms.
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
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
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
indicates if an association id is required before outbound traffic
is permitted. This cleans up the previous change that broke mcast
traffic "to the stack" in ap mode as a side effect.
Reviewed by: sephe, thompsa, weongyo
don't duplicate this. These are setup according to the role of the
node--the bss node for ap and adhoc modes need to use parameters
that are the least common denomimator of all nodes in the bss;
otherwise we are setting up params for a station joining a bss and
we select those according to the capabilities of the station.
This stuff needs more work as we do extra work due to having setup
in common code paths shared by nodes using both roles.
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)
o add driver callback to handle notification of beacon changes;
this is required for devices that manage beacon frames themselves
(devices must override the default handler which does nothing)
o move beacon update-related flags from ieee80211com to the beacon
offsets storage (or handle however a driver wants)
o expand beacon offsets structure with members needed for 11h/dfs
and appie's
o change calling convention for ieee80211_beacon_alloc and
ieee80211_beacon_update
o add overlapping bss support for 11g; requires driver to pass
beacon frames from overlapping bss up to net80211 which is not
presently done by any driver
o move HT beacon contents update to a routine in the HT code area
Reviewed by: avatar, thompsa, sephe
Approved by: re (blanket wireless)
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.
o plug memory leak in adhoc mode: on rx the sender may be the
current master so simply checking against ic_bss is not enough
to identify if the packet comes from an unknown sender; must
also check the mac address
o split neighbor node creation into two routines and fillin state
of nodes faked up on xmit when a beacon or probe response frame
is later received; this ensures important state like the rate set
and advertised capabilities are correct
Obtained from: netbsd
MFC after: 1 week
o add ic_curchan and use it uniformly for specifying the current
channel instead of overloading ic->ic_bss->ni_chan (or in some
drivers ic_ibss_chan)
o add ieee80211_scanparams structure to encapsulate scanning-related
state captured for rx frames
o move rx beacon+probe response frame handling into separate routines
o change beacon+probe response handling to treat the scan table
more like a scan cache--look for an existing entry before adding
a new one; this combined with ic_curchan use corrects handling of
stations that were previously found at a different channel
o move adhoc neighbor discovery by beacon+probe response frames to
a new ieee80211_add_neighbor routine
Reviewed by: avatar
Tested by: avatar, Michal Mertl
MFC after: 2 weeks
Crypto changes:
o change driver/net80211 key_alloc api to return tx+rx key indices; a
driver can leave the rx key index set to IEEE80211_KEYIX_NONE or set
it to be the same as the tx key index (the former disables use of
the key index in building the keyix->node mapping table and is the
default setup for naive drivers by null_key_alloc)
o add cs_max_keyid to crypto state to specify the max h/w key index a
driver will return; this is used to allocate the key index mapping
table and to bounds check table loookups
o while here introduce ieee80211_keyix (finally) for the type of a h/w
key index
o change crypto notifiers for rx failures to pass the rx key index up
as appropriate (michael failure, replay, etc.)
Node table changes:
o optionally allocate a h/w key index to node mapping table for the
station table using the max key index setting supplied by drivers
(note the scan table does not get a map)
o defer node table allocation to lateattach so the driver has a chance
to set the max key id to size the key index map
o while here also defer the aid bitmap allocation
o add new ieee80211_find_rxnode_withkey api to find a sta/node entry
on frame receive with an optional h/w key index to use in checking
mapping table; also updates the map if it does a hash lookup and the
found node has a rx key index set in the unicast key; note this work
is separated from the old ieee80211_find_rxnode call so drivers do
not need to be aware of the new mechanism
o move some node table manipulation under the node table lock to close
a race on node delete
o add ieee80211_node_delucastkey to do the dirty work of deleting
unicast key state for a node (deletes any key and handles key map
references)
Ath driver:
o nuke private sc_keyixmap mechansim in favor of net80211 support
o update key alloc api
These changes close several race conditions for the ath driver operating
in ap mode. Other drivers should see no change. Station mode operation
for ath no longer uses the key index map but performance tests show no
noticeable change and this will be fixed when the scan table is eliminated
with the new scanning support.
Tested by: Michal Mertl, avatar, others
Reviewed by: avatar, others
MFC after: 2 weeks
when operating in ap mode. Previously we allocated a node from the
station table, sent the frame (using the node), then released the
reference that "held the frame in the table". But while the frame
was in flight the node might be reclaimed which could lead to
problems. The solution is to add an ieee80211_tmp_node routine
that crafts a node that does exist in a table and so isn't ever
reclaimed; it exists only so long as the associated frame is in flight.
MFC after: 5 days
stations in ap mode. Track when a node's first auth frame is
received and use this to decide whether or not to bump the refcnt.
This insures we only ever bump the refcnt once.
Reviewed by: avatar
Approved by: re (scottl)
