Commit Graph

87 Commits

Author SHA1 Message Date
Adrian Chadd
9764ef21c4 [net80211] address seqno allocation for group addressed frames
After some digging and looking at packet traces, it looks like the
sequence number allocation being done by net80211 doesn't meet
802.11-2012.

Specifically, group addressed frames (broadcast, multicast) have
sequence numbers allocated from a separate pool, even if they're
QoS frames.

This patch starts to try and address this, both on transmit and
receive.

* When receiving, don't throw away multicast frames for now.
  It's sub-optimal, but until we correctly track group addressed
  frames via another TID counter, this is the best we can do.

* When doing A-MPDU checks, don't include group addressed frames
  in the sequence number checks.

* When transmitting, don't allocate group frame sequence numbers
  from the TID, instead use the NONQOS TID for allocation.

This may fix iwn(4) 11n because I /think/ this was one of the
handful of places where ni_txseqs[] was being assigned /outside/
of the driver itself.

This however doesn't completely fix things - notably the way that
TID assignment versus WME assignment for driver hardware queues
will mess up multicast ordering. For example, if all multicast
QoS frames come from one sequence number space but they're
expected to obey the QoS value assigned, they'll end up in
different queues in the hardware and go out in different
orders.

I can't fix that right now and indeed fixing it will require some
pretty heavy lifting of both the WME<->TID QoS assignment, as well
as figuring out what the correct way for drivers to behave.

For example, both iwn(4) and ath(4) shouldn't put QoS multicast
traffic into the same output queue as aggregate traffic, because
the sequence numbers are all wrong. So perhaps the correct thing
to do there is ignore the WME/TID for QoS traffic and map it all
to the best effort queue or something, and ensure it doesn't
muck up the TID/blockack window tracking. However, I'm /pretty/
sure that is still going to happen.

.. maybe I should disable multicast QoS frames in general as well,
but I don't know what that'll do for whatever the current state
of 802.11s mesh support is.

Tested:

* STA mode, ath10k NIC
* AP mode, AR9344/AR9580 AP
* iperf tcp/udp tests with concurrent multicast QoS traffic.

Before this, iperfs would fail pretty quickly because the sending
AP would start sending out QoS multicast frames that would be
out of order from the rest of the TID traffic, causing the blockack
window to get way, way out of sync.

This now doesn't occur.

TODO:

* verify which QoS frames SHOULD be tagged as M_AMPDU_MPDU.
  For example, QoS NULL frames shouldn't be tagged!

Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D9357
2017-01-30 01:11:30 +00:00
Andriy Voskoboinyk
c5bba9da5a net80211: allow to configure LDPC support
Tested with RTL8821AU, STA mode (Tx support only)

Reviewed by:	adrian
Differential Revision:	https://reviews.freebsd.org/D9268
2017-01-21 14:19:06 +00:00
Adrian Chadd
51172f62a7 [net80211] Initial VHT node upgrade/downgrade support and initial IE parsing.
This is the bulk of the magic to start enabling VHT channel negotiation.
It is absolutely, positively not yet even a complete VHT wave-1 implementation.

* parse IEs in scan, assoc req/resp, probe req/resp;
* break apart the channel upgrade from the HT IE parsing - do it after the
  VHT IEs are parsed;
* (dirty! sigh) add channel width decision making in ieee80211_ht.c htinfo_update_chw().
  This is the main bit where negotiated channel promotion through IEs occur.
* Shoehorn in VHT node init ,teardown, rate control, etc calls like the HT
  versions;
* Do VHT channel adjustment where appropriate

Tested:

* monitor mode, ath10k port
* STA mode, ath10k port - VHT20, VHT40, VHT80 modes

TODO:

* IBSS;
* hostap;
* (ignore mesh, wds for now);
* finish 11n state engine - channel width change, opmode notifications, SMPS, etc;
* VHT basic rate negotiation and acceptance criteria when scanning, associating, etc;
* VHT control/management frame handling (group managment and operating mode being
  the two big ones);
* Verify TX/RX VHT rate negotiation is actually working correctly.

Whilst here, add some comments about seqno allocation and locking.  To achieve
the full VHT rates I need to push seqno allocation into the drivers and
finally remove the IEEE80211_TX_LOCK() I added years ago to fix issues. :/
2017-01-13 07:02:04 +00:00
Adrian Chadd
3d12d1f14f [net80211] Remove extra \n. 2016-11-22 02:02:13 +00:00
Adrian Chadd
339be86fdb [net80211] implement "first RX defines the BAW" hack.
Unfortunately (sigh) some firmware doesn't provide the RX BA starting point,
so we need to cope and set a "close enough" sequence number so we (hopefully!)
don't discard frames as duplicates.

Tested:

* QCA9880v2, athp driver (under development), STA mode
2016-11-10 18:36:40 +00:00
Adrian Chadd
0cc0288529 [net80211] add a method to also explicitly tear down RX A-MPDU.
The ath10k firmware API doesn't pass up the ADDBA/DELBA frames, only
WMI firmware notifications.

Tested:

* ath10k (QCA9880), doing actual (ha!) 11n!
2016-11-06 19:16:46 +00:00
Adrian Chadd
562b9792f0 [net80211] remove now duplicate copy of the QOSDATA check macro. 2016-10-13 16:45:01 +00:00
Adrian Chadd
f383e58f2e [net80211] add a HT method to populate HTCAP based on IBSS requirements.
IBSS negotiation is a subset of the STA/AP negotiation.  We always have a
current channel, so base the HT capabilities on the current channel.
This is then put into IBSS probe requests to inform peers of our
11n capabilities.
2016-09-17 05:44:57 +00:00
Andriy Voskoboinyk
6dbbec9385 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.
2016-05-19 21:08:33 +00:00
Adrian Chadd
ced0a8950a [net80211] add extra debugging around negotiated A-MPDU parameters. 2016-05-04 16:42:53 +00:00
Pedro F. Giffuni
a4641f4eaa sys/net*: minor spelling fixes.
No functional change.
2016-05-03 18:05:43 +00:00
Adrian Chadd
5706199db6 [net80211] add STBC capability flags to iv_flags_ht.
This is in preparation for exposing configuring STBC flags up to ifconfig
so STBC TX/RX can be configured at runtime.

* Set the FHT_STBC flags for TX/RX if the HT capabilitiex exist
* Clear the RX STBC HT capability flag when creating a HTCAP IE, so
  we only announce it if it's configured in the FHT flags.

Tested:

* AR9331 (carambola2), AP/STA modes
2016-04-26 01:29:03 +00:00
Andriy Voskoboinyk
d72d72d381 net80211: provide descriptions for reason codes
Add text description for deauth/disassoc/etc reason codes
in addition to 'reason: <number>' string.

Reviewed by:	adrian
Obtained from:	IEEE Std 802.11-2012, 8.4.1.7 "Reason Code field"
Differential Revision:	https://reviews.freebsd.org/D5367
2016-04-20 20:30:18 +00:00
Andriy Voskoboinyk
31021a2b4e 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
2016-04-20 18:29:30 +00:00
Adrian Chadd
b4fb3d6e02 [net80211] correctly (i hope, wow) do a ticks comparison to limit A-MPDU attempts
I was seeing the stack constantly attempt to renegotiate A-MPDU TX
even after 3 failures.  My hunch is that the direct ticks comparison
is failing around the ticks wrap-around point.

This failure shouldn't /really/ happen normally, but it turns out being
the IBSS master node on FreeBSD doesn't quite setup 11n right, so
negotiating A-MPDU TX fails.
2016-04-10 04:16:34 +00:00
Adrian Chadd
6548c62c97 [net80211] unconditionally do A-MPDU RX aging.
It's 2016 and vendors (including us!) still have 802.11n TX/RX sequence
handling bugs.  It's suboptimal, but I'd rather see us default to handling
things in a sensible way.

So, just delete the #ifdef'ed code for now.  I'll leave the option in
so it doesn't break existing configurations.

This all started because I've started getting reports about urtwn not
working after I enabled 802.11n support, and it's because the ARM kernel
configs don't include A-MPDU RX aging.
2016-04-10 03:35:17 +00:00
Adrian Chadd
5cf581e264 [net80211] log the node pointer when calling ht node init/cleanup
This makes it easier to track which node is having what done do it
during normal use.

This is likely the eighth time I've done this since I started doing
net80211 development, so I think it's about time I just committed it.
2016-04-09 22:01:32 +00:00
Adrian Chadd
b8e29e065d [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.
2016-03-30 00:44:10 +00:00
Gleb Smirnoff
8ec07310fa These files were getting sys/malloc.h and vm/uma.h with header pollution
via sys/mbuf.h
2016-02-01 17:41:21 +00:00
Adrian Chadd
75426752f5 [net80211] log the A-MPDU setup attempt count as part of debugging.
I've seen some cases where we get stuck in a loop constantly trying to
negotiate A-MPDU TX which is definitely not supposed to happen.
This will let me see if it's something funky with the retry count or
not.
2015-11-25 18:16:42 +00:00
Adrian Chadd
d7621b8c80 Abstract out the ampdu TX pps initialisation code so it can be reused
in the superg fast-frames code.

This harks back to an earlier commit (r280349) where I found that
initialising the pps code with ticks=0 would cause hilariously bad
hz ticks wraparound failures, leading to never actually aggregating
traffic.  This is still true for the superg path and so I have to
do the same thing there.

This is a big no-op; a subsequent commit will flip this on so it
works with the fast-frames transmit path.

Tested:

* AR9170, otus(4) - STA mode, 11bg operation
* AR9331, AP mode
2015-09-28 00:17:51 +00:00
Adrian Chadd
163f8705a4 Add external facing methods to control TX A-MPDU negotiaton.
Some fullmac devices may rely on the stack starting it but not doing it.

Whilst here, remove a duplicate LE_* macro definition, thanks to
Andriy Voskoboinyk <s3erios@gmail.com>.
2015-09-22 02:25:29 +00:00
Adrian Chadd
1f3a8d1129 Add an external facing function to manually set the RX A-MPDU parameters
for re-ordering.

Devices like if_rsu don't pass through action/management frames but do send
firmware commands to inform us of things.  One of those notifications is
the RX A-MPDU negotiated parameters.
2015-09-18 05:01:05 +00:00
Gleb Smirnoff
c8f5794e0a Use name from ieee80211com instead of parent ifnet, in debugging printfs.
Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-05-25 14:30:44 +00:00
Jung-uk Kim
fd90e2ed54 CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than ten
years for head.  However, it is continuously misused as the mpsafe argument
for callout_init(9).  Deprecate the flag and clean up callout_init() calls
to make them more consistent.

Differential Revision:	https://reviews.freebsd.org/D2613
Reviewed by:	jhb
MFC after:	2 weeks
2015-05-22 17:05:21 +00:00
Adrian Chadd
3265af355a Attempt to address Bug #176201 - don't advertise what the AP announced
to us. Instead, advertise what we can do based on what the AP says and what
we're capped at by the VAP settings.

For non-STA modes we still advertise what our VAP settings are.

It may be that I've over-complicated this and instead of capping things
we can just always announce what we're capable of.  But this should at least
stop the blatantly wrong handling of A-MPDU parameters.

(I'll happily simplify things if someone can dig up a replacement, better
compliant behaviour.)

PR:		kern/176201
2015-05-10 06:57:53 +00:00
Adrian Chadd
83249cea34 Initialise the pps / packet tracking timestamp so 11n aggregation works again.
There's a bug in the ticks handling where when initialised at '0', once
the ticks counter wrapped the comparison math would never trigger.
The pps calculation would never happen, and thus aggregation was never
enabled.

It manifests itself as "oh you only get 11n transmit aggregation for the
first 10 minutes of uptime."

I'm sure there are other ticks related issues lurking in net80211.

Tested:

* ath / iwn, both with 'wlandebug +11n' and a little bit of iperf to
  kick off the transmit A-MPDU negotiation once the pps gets high enough.
2015-03-22 17:54:00 +00:00
Hans Petter Selasky
f0188618f2 Fix multiple incorrect SYSCTL arguments in the kernel:
- Wrong integer type was specified.

- Wrong or missing "access" specifier. The "access" specifier
sometimes included the SYSCTL type, which it should not, except for
procedural SYSCTL nodes.

- Logical OR where binary OR was expected.

- Properly assert the "access" argument passed to all SYSCTL macros,
using the CTASSERT macro. This applies to both static- and dynamically
created SYSCTLs.

- Properly assert the the data type for both static and dynamic
SYSCTLs. In the case of static SYSCTLs we only assert that the data
pointed to by the SYSCTL data pointer has the correct size, hence
there is no easy way to assert types in the C language outside a
C-function.

- Rewrote some code which doesn't pass a constant "access" specifier
when creating dynamic SYSCTL nodes, which is now a requirement.

- Updated "EXAMPLES" section in SYSCTL manual page.

MFC after:	3 days
Sponsored by:	Mellanox Technologies
2014-10-21 07:31:21 +00:00
Gleb Smirnoff
76039bc84f 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.
2013-10-26 17:58:36 +00:00
Adrian Chadd
5b58efc6cc Fix a VAP BSS node reference in the HT code to actually take a reference
before using said node.

The "blessed" way here is to take a node reference before referencing
anything inside the node, otherwise the node can be freed between
the time the pointer is copied/dereferenced and the time the node contents
are used.

This mirrors fixes that I've done elsewhere in the net80211/driver
stack.

PR:		kern/178470
2013-05-10 09:37:58 +00:00
Adrian Chadd
5cda6006e4 Bring over my initial work from the net80211 TX locking branch.
This patchset implements a new TX lock, covering both the per-VAP (and
thus per-node) TX locking and the serialisation through to the underlying
physical device.

This implements the hard requirement that frames to the underlying physical
device are scheduled to the underlying device in the same order that they
are processed at the VAP layer.  This includes adding extra encapsulation
state (such as sequence numbers and CCMP IV numbers.)  Any order mismatch
here will result in dropped packets at the receiver.

There are multiple transmit contexts from the upper protocol layers as well
as the "raw" interface via the management and BPF transmit paths.
All of these need to be correctly serialised or bad behaviour will result
under load.

The specifics:

* add a new TX IC lock - it will eventually just be used for serialisation
  to the underlying physical device but for now it's used for both the
  VAP encapsulation/serialisation and the physical device dispatch.

  This lock is specifically non-recursive.

* Methodize the parent transmit, vap transmit and ic_raw_xmit function
  pointers; use lock assertions in the parent/vap transmit routines.

* Add a lock assertion in ieee80211_encap() - the TX lock must be held
  here to guarantee sensible behaviour.

* Refactor out the packet sending code from ieee80211_start() - now
  ieee80211_start() is just a loop over the ifnet queue and it dispatches
  each VAP packet send through ieee80211_start_pkt().

  Yes, I will likely rename ieee80211_start_pkt() to something that
  better reflects its status as a VAP packet transmit path.  More on
  that later.

* Add locking around the management and BAR TX sending - to ensure that
  encapsulation and TX are done hand-in-hand.

* Add locking in the mesh code - again, to ensure that encapsulation
  and mesh transmit are done hand-in-hand.

* Add locking around the power save queue and ageq handling, when
  dispatching to the parent interface.

* Add locking around the WDS handoff.

* Add a note in the mesh dispatch code that the TX path needs to be
  re-thought-out - right now it's doing a direct parent device transmit
  rather than going via the vap layer.  It may "work", but it's likely
  incorrect (as it bypasses any possible per-node power save and
  aggregation handling.)

Why not a per-VAP or per-node lock?

Because in order to ensure per-VAP ordering, we'd have to hold the
VAP lock across parent->if_transmit().  There are a few problems
with this:

* There's some state being setup during each driver transmit - specifically,
  the encryption encap / CCMP IV setup.  That should eventually be dragged
  back into the encapsulation phase but for now it lives in the driver TX path.
  This should be locked.

* Two drivers (ath, iwn) re-use the node->ni_txseqs array in order to
  allocate sequence numbers when doing transmit aggregation.  This should
  also be locked.

* Drivers may have multiple frames queued already - so when one calls
  if_transmit(), it may end up dispatching multiple frames for different
  VAPs/nodes, each needing a different lock when handling that particular
  end destination.

So to be "correct" locking-wise, we'd end up needing to grab a VAP or
node lock inside the driver TX path when setting up crypto / AMPDU sequence
numbers, and we may already _have_ a TX lock held - mostly for the same
destination vap/node, but sometimes it'll be for others.  That could lead
to LORs and thus deadlocks.

So for now, I'm sticking with an IC TX lock.  It has the advantage of
papering over the above and it also has the added advantage that I can
assert that it's being held when doing a parent device transmit.
I'll look at splitting the locks out a bit more later on.

General outstanding net80211 TX path issues / TODO:

* Look into separating out the VAP serialisation and the IC handoff.
  It's going to be tricky as parent->if_transmit() doesn't give me the
  opportunity to split queuing from driver dispatch.  See above.

* Work with monthadar to fix up the mesh transmit path so it doesn't go via
  the parent interface when retransmitting frames.

* Push the encryption handling back into the driver, if it's at all
  architectually sane to do so.  I know it's possible - it's what mac80211
  in Linux does.

* Make ieee80211_raw_xmit() queue a frame into VAP or parent queue rather
  than doing a short-cut direct into the driver.  There are QoS issues
  here - you do want your management frames to be encapsulated and pushed
  onto the stack sooner than the (large, bursty) amount of data frames
  that are queued.  But there has to be a saner way to do this.

* Fragments are still broken - drivers need to be upgraded to an if_transmit()
  implementation and then fragmentation handling needs to be properly fixed.

Tested:

* STA - AR5416, AR9280, Intel 5300 abgn wifi
* Hostap - AR5416, AR9160, AR9280
* Mesh - some testing by monthadar@, more to come.
2013-03-08 20:23:55 +00:00
Adrian Chadd
0ef1bc21bc Add some further BAR TX debugging; it was useful when figuring out
when BAR TX was actually failing.
2012-10-28 04:18:49 +00:00
Adrian Chadd
545c886250 Fix some corner cases in the ieee80211_send_bar() handling.
* If the first call succeeded but failed to transmit, a timer would
  reschedule it via bar_timeout().  Unfortunately bar_timeout() didn't
  check the return value from the ieee80211_send_bar() reattempt and
  if that failed (eg the driver ic_raw_xmit() failed), it would never
  re-arm the timer.

* If BARPEND is cleared (which ieee80211_send_bar() will do if it can't
  TX), then re-arming the timer isn't enough - once bar_timeout() occurs,
  it'll see BARPEND is 0 and not run through the rest of the routine.
  So when rearming the timer, also set that flag.

* If the TX wasn't occuring, bar_tx_complete() wouldn't be called and the
  driver callback wouldn't be called either.  So the driver had no idea
  that the BAR TX attempt had failed.  In the ath(4) case, TX would stay
  paused.

  (There's no callback to indicate that BAR TX had failed or not;
  only a "BAR TX was attempted".  That's a separate, later problem.)

  So call the driver callback (ic_bar_response()) before the ADDBA session
  is torn down, so it has a chance of being notified that things didn't
  quite go to plan.

I've verified that yes, this does suspend traffic for ath(4), retry BAR
TX even if the driver is failing ic_raw_xmit(), and then eventually giving
up and sending a DELBA.  I'll address the "out of ath_buf" issue in ath(4)
in a subsequent commit - this commit just fixes the edge case where any
driver is (way) out of internal buffers/descriptors and fails frame TX.

PR:		kern/168170
Reviewed by:	bschmidt
MFC after:	1 month
2012-05-22 19:37:12 +00:00
Adrian Chadd
2aa563dfeb Migrate the net80211 TX aggregation state to be from per-AC to per-TID.
TODO:

* Test mwl(4) more thoroughly!

Reviewed by:	bschmidt (for iwn)
2012-04-15 20:29:39 +00:00
Adrian Chadd
fcacf9318c Add some statistics to track BAR TX. 2012-04-08 04:51:25 +00:00
Adrian Chadd
b94299c437 Create a new task to handle 802.11n channel width changes.
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
2012-03-25 03:11:57 +00:00
Bernhard Schmidt
65d22fe921 MCS32 equals 32, not 8*ic_txstream. 2012-01-02 16:02:30 +00:00
Bernhard Schmidt
fcd9500f91 Fix some net80211 enum nits:
- ic_vap_create() uses an ieee80211_opmode argument
- ieee80211_rate2media() takes an ieee80211_phymode argument
- ieee80211_plcp2rate() takes an ieee80211_phytype argument
- cast to enum ieee80211_protmode and ieee80211_roamingmode to silence
  compiler warnings

Submitted by:	arundel@
2011-12-17 10:23:17 +00:00
Adrian Chadd
198af96ed7 Correctly handle BAR TX failures.
On a TX failure, ic_raw_xmit will still call ieee80211_node_free().
There's no need to call it here.

Submitted by:	moonlightakkiy@yahoo.ca
Approved by:	re (kib)
2011-08-19 15:21:13 +00:00
Adrian Chadd
6291312c14 Fix BAR frame TX completion - successful transmission is indicated
by a status of 0.

Approved by:	re (kib)
2011-08-16 09:07:59 +00:00
Adrian Chadd
a834836d83 Add a callback for ADDBA response timeouts.
TX for the given TID needs to be paused during ADDBA requests (and unpaused
once the session is established.) Since net80211 currently doesn't implement
software aggregation, if this pause/unpause is done in the driver (as it
is in my development branch) then it will need to be unpaused both on
ADDBA response and on ADDBA timeout.

This callback allows the driver to unpause TX for the relevant TID.

Reviewed by:	bschmidt
2011-06-20 11:46:03 +00:00
Bernhard Schmidt
bf1f922275 Certain adapters have HT40 support on some but not all channels. The
Intel 4965 devices for example have HT40 on 2GHz completely disabled
but it is still supported for 5GHz. To handle that in sta mode we
need to check if we can "upgrade" to a HT40 channel after the
association, if that is not possible but we are still announcing
support to the remote side we are left with a very flabby connection.

Reviewed by:	adrian
2011-06-04 15:05:32 +00:00
Bernhard Schmidt
8dc8c1f7e3 Constantly use MHz instead of Mhz.
Pointed out by:	N.J. Mann <njm at njm.me.uk>
2011-03-13 13:05:50 +00:00
Bernhard Schmidt
597029bf18 Honor device capabilities while initializing ni_htrates.
Instead of hardcoding MCS0-15 generate the table dynamically, also
restrict the MCS rates to our own capabilities while parsing a htcap
element.
2011-03-13 12:16:23 +00:00
Bernhard Schmidt
d8e14b5eac Fill hc_mcsset completely.
Contrary to the rateset information in legacy frames the MCS Set
field also contains TX capability information in cases where the
number of available TX and RX spartial streams differ. Because a
rateset doesn't contain that information we have to pull the
those directly from the hardware capabilities.
2011-03-13 11:56:33 +00:00
Bernhard Schmidt
bffb67e30f Change the way HT capatibilities are announced.
Get rid of the assumption that every device is capable of 40MHz,
SGI and 2 spartial streams. Instead of printing, in the worst case,
8 times 76 MCS rates, print logically connect ranges and the
support RX/TX streams.

A device without 40MHz and SGI support looks like:
ath0: 2T2R
ath0: 11na MCS 20Mhz
ath0: MCS 0-7: 6.5Mbps - 65Mbps
ath0: MCS 8-15: 13Mbps - 130Mbps
ath0: 11ng MCS 20Mhz
ath0: MCS 0-7: 6.5Mbps - 65Mbps
ath0: MCS 8-15: 13Mbps - 130Mbps
2011-03-13 11:45:58 +00:00
Bernhard Schmidt
f136f45f39 Complete the MCS rate table based on the final 802.11n std. While here
adjust the IEEE80211_HTRATE_MAXSIZE constant, only MCS0 - 76 are valid
the other bits in the mcsset IE (77 - 127) are either reserved or used
for TX parameters.
2011-03-10 18:17:24 +00:00
Rui Paulo
e1d36f8395 Add a new field for extended HT capabilities.
Submitted by:	Alexander Egorenkov <egorenar at gmail.com>
MFC after:	2 weeks
Sponsored by:	iXsystems, inc.
2010-03-23 12:03:09 +00:00
Rui Paulo
fec0a521a7 Unbreak build by removing a code bit that is only related to other code
in my branch.
2010-03-18 15:28:17 +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