Commit Graph

26 Commits

Author SHA1 Message Date
Adrian Chadd
1a006f7d56 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
2012-12-10 07:00:46 +00:00
Adrian Chadd
dac9484010 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
2012-12-09 23:56:29 +00:00
Adrian Chadd
24effd1107 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
2012-12-09 22:56:29 +00:00
Adrian Chadd
e7f0d7cf47 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.
2012-10-02 17:45:19 +00:00
Adrian Chadd
cd0b8f2d4a 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.
2011-05-04 02:23:59 +00:00
Bernhard Schmidt
893c4d6ef1 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.
2011-02-22 19:05:42 +00:00
Bernhard Schmidt
96283082bb 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
2011-02-21 19:59:43 +00:00
Rui Paulo
0917631f16 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/...
2010-03-18 11:06:38 +00:00
Rui Paulo
2b80a3409e When taking the AMPDU reorder fastpath, need_tap wasn't being
initialized. Initialize on declaration to avoid this.

Found with:	clang static analyzer
2010-02-03 10:07:43 +00:00
Sam Leffler
7634012302 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)
2009-07-05 17:59:19 +00:00
Sam Leffler
a6c3cf3eca 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
2009-05-25 16:38:47 +00:00
Sam Leffler
5463c4a485 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
2009-05-20 20:00:40 +00:00
Sam Leffler
24a599dd50 whitespace 2009-05-02 20:18:18 +00:00
Sam Leffler
dc7bf546c8 print both fc bytes when hitting a protocol version mismatch 2009-04-26 21:50:21 +00:00
Sam Leffler
49eae5f79e add iv_recv_ctl method to allow hooking rx ctl frame handling 2009-04-26 21:46:04 +00:00
Sam Leffler
8bbd3e4119 o use shared code to handle bpf tap and mbuf cleanup
o swap conditional order to put the cheapest first
2009-04-26 21:03:29 +00:00
Sam Leffler
616190d079 split Atheros SuperG support out into it's own file that's included only
with a new IEEE80211_SUPPORT_SUPERG option
2009-03-24 20:39:08 +00:00
Sam Leffler
f09cf33f40 clean neighbor entries on beacon miss 2009-02-10 23:51:18 +00:00
Sam Leffler
10ad9a77f3 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
2009-01-08 17:12:47 +00:00
Sam Leffler
d6f57961a8 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
2008-10-30 16:22:04 +00:00
Sam Leffler
e66b0905fc 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
2008-10-27 16:46:50 +00:00
Sam Leffler
52ef06dcfe 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
2008-10-25 23:40:29 +00:00
Sam Leffler
07760642a6 add/improve debug msgs 2008-10-25 23:23:41 +00:00
Sam Leffler
45f856e3ac 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)
2008-09-21 23:00:19 +00:00
Sam Leffler
5f5cf81567 no need to stop the sw beacon miss timer; it's not used with adhoc or wds 2008-05-22 22:14:58 +00:00
Sam Leffler
b032f27c36 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)
2008-04-20 20:35:46 +00:00