157 Commits

Author SHA1 Message Date
Adrian Chadd
d957a93abe net80211: move ieee80211_free_node() call on error from ic_raw_xmit() to ieee80211_raw_output().
This doesn't free the mbuf upon error; the driver ic_raw_xmit method is still
doing that.

Submitted by:	<s3erios@gmail.com>
Differential Revision:	https://reviews.freebsd.org/D3774
2015-10-12 04:55:20 +00:00
Adrian Chadd
d3a4ade3b8 net80211: free node reference in the ieee80211_parent_xmitpkt() when error happened.
Move error handling into ieee80211_parent_xmitpkt() instead of spreading it
between functions.

Submitted by:	<s3erios@gmail.com>
Differential Revision:	https://reviews.freebsd.org/D3772
2015-10-12 04:30:38 +00:00
Adrian Chadd
d07be335a0 net80211: separate mbuf cleanup from ieee80211_fragment()
* Create ieee80211_free_mbuf() which frees a list of mbufs.
* Use it in the fragment transmit path and ath / uath transmit paths.
* Call it in xmit_pkt() if the transmission fails; otherwise fragments
  may be leaked.

This should be a big no-op.

Submitted by:	<s3erios@gmail.com>
Differential Revision:	https://reviews.freebsd.org/D3769
2015-10-12 03:27:08 +00:00
Adrian Chadd
210ab3c258 net80211: drop ieee80211_beacon_offsets parameter from ieee80211_beacon_alloc() and ieee80211_beacon_update()
Submitted by:	<s3erios@gmail.com>
Differential Revision:	https://reviews.freebsd.org/D3659
2015-10-03 22:12:25 +00:00
Adrian Chadd
f9128a1be3 Comments, mostly to remind myself of what's going on and why. 2015-09-28 00:51:24 +00:00
Adrian Chadd
4eadefc260 Expose the wme_info IE method. 2015-09-18 04:01:26 +00:00
Gleb Smirnoff
7a79cebfba 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.
2015-08-27 08:56:39 +00:00
Adrian Chadd
ba2c1fbc03 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.
2015-08-08 01:10:17 +00:00
Gleb Smirnoff
79d2c5e857 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
2015-08-07 11:43:14 +00:00
Adrian Chadd
3a1da00bd9 Some hostap setups may result in raw frames being transmitted with
no parameters set.  So, don't unconditionally call things.

Thanks to jkim@ for pointing this out!

MFC after:	2 weeks
Sponsored by:	Norse Corp, Inc.
2015-06-04 23:07:21 +00:00
Adrian Chadd
ff09e23f53 Tag outbound raw 802.11 frames with both the node and an mbuf tag
with the transmit params.

This allows raw 802.11 frames to be queued in the driver if necessary,
rather than requiring it to be direct-dispatched into the hardware.

Tested:

* ath(4), STA mode
* iwn(4), STA mode

MFC after:	2 weeks
Sponsored by:	Norse Corp, Inc.
2015-06-04 17:54:41 +00:00
Gleb Smirnoff
e14a2a4cf4 Cleanup compat shims for FreeBSD versions that predate 10.0-RELEASE.
There are no plans to merge anything save a trivial bugfix to stable/9.

Discussed with:	adrian
2015-05-25 20:06:49 +00:00
Adrian Chadd
b9b533891f 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.
2015-05-25 19:18:16 +00:00
Andrey V. Elsukov
79077edc1a Properly update TX statistics for wlan(4).
ieee80211_pwrsave() can fail due to queue overflow, check its return code
and increment oerrors counter when it fails. Also handle more error cases
and update oerrors counter when we don't send mbuf due to some errors.
Return ENETDOWN when parent interface isn't ready. Update obytes and omcasts
counters in corresponding places.

PR:		184626
Differential Revision:	https://reviews.freebsd.org/D2621
Reviewed by:	adrian
MFC after:	1 week
2015-05-23 09:49:40 +00:00
Adrian Chadd
c3ebe01919 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>
2015-05-12 16:55:50 +00:00
Adrian Chadd
b83391bf44 Fix kern/196290 - don't announce 11n HTINFO rates if the channel is
configured as 11b.

This came up when debugging other issues surrounding scanning and
channel modes.

What's going on:

* The VAP comes up as an 11b VAP, but on an 11n capable NIC;
* .. it announces HTINFO and MCS rates;
* The AP thinks it's an 11n capable device and transmits 11n frames
  to the STA;
* But the STA is in 11b mode, and thus doesn't receive/ACK the frames.

It didn't happen for the ath(4) devices as the AR5416/AR9300 HALs
unconditionally enable MCS frame reception, even if the channel
mode is not 11n.  But the Intel NICs are configured in 11b/11a/11g
modes when doing those, even if 11n is enabled and available.

So, don't announce 11n capabilities if the VAP isn't on an 11n
channel when sending management assocation request / reassociation
request frames.

TODO:

* Lots more testing - 11n should be "upgraded" after association,
  and I just want to make sure I haven't broken 11n upgrade.
  I shouldn't have - this is only happening for /sending/ association
  requests, which APs aren't doing.

Tested:

* ath(4) APs (AR9331, AR7161+AR9280, AR934x)
* AR5416, STA mode
* Intel 5100, STA mode

PR:		kern/196290
2015-02-27 04:45:47 +00:00
Adrian Chadd
de981aecde Make ieee80211_add_ssid() public.
Some drivers use private copies of this.

PR:		kern/196116
Submitted by:	Andriy Voskoboinyk <s3erios@gmail.com>
2014-12-19 01:39:58 +00:00
Gleb Smirnoff
dea4512157 Mechanically convert to if_inc_counter(). 2014-09-19 09:20:55 +00:00
Adrian Chadd
ddd9ebbcec Allow frames to be transmitted in either RUN or SLEEP state
Frames transmitted during SLEEP state should be queued in the
power save queue before waking the unit up.  Otherwise DHCP
requests and such will be dropped if the NIC is asleep - the
NIC will wake up but not transmit the frame.
2014-04-23 22:44:49 +00:00
Kevin Lo
5945b5f5ab 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
2014-01-08 08:06:56 +00:00
Adrian Chadd
c6d5b60008 Don't return ENOBUFS if the transmit path handles the frame but queues it (eg in power save.)
This is definitely an MFC candidate for 10.0-REL.

MFC after:	1 week
2013-11-06 17:20:49 +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
e94527beaf Fix a use-after-free node reference issue when waiting for a return
from a management frame transmission.

This bug is a bit loopy, so here goes.

The underlying cause is pretty easy to understand - the node isn't
referenced before passing into the callout, so if the node is deleted
before the callout fires, it'll dereference free'd memory.

The code path however is slightly more convoluted.

The functions _say_ mgt_tx - ie management transmit - which is partially
true.  Yes, that callback is attached to the mbuf for some management
frames.  However, it's only for frames relating to scanning and
authentication attempts.  It helpfully drives the VAP state back to
"SCAN" if the transmission fails _OR_ (as I subsequently found out!)
if the transmission succeeds but the state machine doesn't make progress
towards being authenticated and active.

Now, the code itself isn't terribly clear about this.

It _looks_ like it's just handling the transmit failure case.

However, when you look at what goes on in the transmit success case, it's
moving the VAP state back to SCAN if it hasn't changed state since
the time the callback was scheduled.  Ie, if it's in ASSOC or AUTH still,
it'll go back to SCAN.  But if it has transitioned to the RUN state,
the comparison will fail and it'll not transition things back to the
SCAN state.

So, to fix this, I decided to leave everything the way it is and merely
fix the locking and remove the node reference.

The _better_ fix would be to turn this callout into a "assoc/auth request"
timeout callback and make the callout locked, thus eliminating all races.
However, until all the drivers have been fixed so that transmit completions
occur outside of any locking that's going on, it's going to be impossible
to do this without introducing LORs.  So, I leave some of the evilness
in there.

Tested:

* AR5212, ath(4), STA mode
* 5100 and 4965 wifi, iwn(4), STA mode
2013-10-24 17:04:16 +00:00
Adrian Chadd
36ee7775f4 Create a new function to complete 802.11 mbuf transmission.
The aim of this function is to eventually be the completion entry point
for all 802.11 encapsulated mbufs.  All the wifi drivers end up doing
what is in this function so it's an easy win to turn it into a net80211
method and abstract out this code.

Ideally the drivers will all eventually be modified to queue up completed
mbufs and call this function with all the driver locks not held.
This will allow for some much more interesting software queue handling
in the future (like net80211 based A-MSDU, fast-frames, A-MPDU aggregation
and retransmission.)

Tested:

* ath(4), iwn(4)
2013-08-27 14:37:13 +00:00
Adrian Chadd
74b4c76e4e Migrate the ff_encap1() routine out into the normal output code.
This will eventually be used by the A-MSDU encapsulation code that
I'm writing - the sub-frame encapsulation requirement is the same.
2013-08-26 09:52:05 +00:00
Adrian Chadd
11e0ddb146 Return the correct status if ieee80211_ff_check() consumes the mbuf.
I broke this when converting the net80211 TX path to use if_transmit.
2013-08-18 20:40:13 +00:00
Adrian Chadd
1df885c863 Add in missing m_free()'s during error conditions. 2013-08-10 21:46:58 +00:00
Adrian Chadd
e7495198d5 Convert net80211 over to using if_transmit for the dispatch from the
upper layer(s).

This eliminates the if_snd queue from net80211. Yay!

This unfortunately has a few side effects:

* It breaks ALTQ to net80211 for now - sorry everyone, but fixing
  parallelism and eliminating the if_snd queue is more important
  than supporting this broken traffic scheduling model. :-)

* There's no VAP and IC flush methods just yet - I think I'll add
  some NULL methods for now just as placeholders.

* It reduces throughput a little because now net80211 will drop packets
  rather than buffer them if the driver doesn't do its own buffering.
  This will be addressed in the future as I implement per-node software
  queues.

Tested:

* ath(4) and iwn(4) in STA operation
2013-08-08 05:09:35 +00:00
Adrian Chadd
cc80eae5cf Allow net80211 to compile on stable/9 and stable/8. 2013-08-07 22:01:43 +00:00
Adrian Chadd
363a2c3c13 Refactor the VAP transmit path code into a utility function that both
the normal and the mesh transmit paths can use.

The API is a bit horrible because it both consumes the mbuf and frees
the node reference regardless of whether it succeeds or not.
It's a hold-over from how the code behaves; it'd be nice to have it
not free the node reference / mbuf if TX fails and let the caller
decide what to do.
2013-07-28 04:53:00 +00:00
Rui Paulo
d8df5f3d71 Add ieee80211_add_{qos,wpa,rsn}() functions since they are needed by an
OpenBSD driver that is being ported to FreeBSD.

Reviewed by:	adrian
2013-07-25 06:23:26 +00:00
Alfred Perlstein
d7b5c50b92 Make kassert_printf use __printflike.
Fix associated errors/warnings while I'm here.

Requested by: avg
2013-07-07 21:39:37 +00:00
Adrian Chadd
8d46c25d23 Fix net80211 fragment creation.
When creating fragment frames, the header length should honour the
DATAPAD flag.

This fixes the fragments that are queued to the ath(4) driver but it
doesn't yet fix fragment transmission.  That requires further changes
to the ath(4) transmit path.  Well, strictly speaking, it requires
further changes to _all_ wifi driver transmit paths, but this is at least
a start.

Tested:

* AR5416, STA mode, w/ fragthreshold set to 256.
2013-05-25 06:28:30 +00:00
Gleb Smirnoff
47e8d432d5 Add const qualifier to the dst parameter of the ifnet if_output method. 2013-04-26 12:50:32 +00:00
Adrian Chadd
6ce4aeb88f Fix another compiler warning issue when invariants are disabled. 2013-03-09 15:35:31 +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
Monthadar Al Jaberi
4efafd66eb Mesh bug: debug infomartion showing swapped SA and DA address.
* Fix bug for "forward frame from SA(%6D), DA(%6D)" where addresses where
  swapped between SA and DA;

Approved by:	adrian (mentor)
2013-02-07 21:30:29 +00:00
Monthadar Al Jaberi
227da7d10b Add mesh debug for interarction between DS & MBSS.
* Add mesh debug information when frames enter or leave the MBSS;
* Set IEEE80211_MSG_OUTPUT bit to enable output;

Approved by:	adrian (mentor)
2013-02-07 21:18:22 +00:00
Gleb Smirnoff
eb1b1807af Mechanically substitute flags from historic mbuf allocator with
malloc(9) flags within sys.

Exceptions:

- sys/contrib not touched
- sys/mbuf.h edited manually
2012-12-05 08:04:20 +00:00
Monthadar Al Jaberi
d566999aa5 Mesh mode, potential garbage in QoS subfield.
* qos[1] subfield is never assigned a value before this statement.
qos[1] can potentially be OR:ed with garbage. Make it an assignment instead;
* Remove brackets around if statement;

Approved by: adrian
2012-06-25 11:52:26 +00:00
Monthadar Al Jaberi
3c314f6dc3 Mesh forwarding with proxy support.
* Modified HWMP PREP/PREQ to contain a proxy entry and also changed PREP
frame processing according to amendment as following:
        o Fixed PREP to always update/create if acceptance criteria is meet;
        o PREQ processing to reply if request is for a proxy entry that is
          proxied by us;
        o Removed hwmp_discover call from PREQ, because sending a PREP will
          build the forward path, and by receving and accepting a PREQ we
          have already built the reverse path (non-proactive code);
* Disabled code for pro-active in PREP for now (will make a separate patch for
pro-active HWMP routing later)
* Added proxy information for a Mesh route, mesh gate to use and proxy seqno;
* Modified ieee80211_encap according to amendment;
* Introduced Mesh control address extension enum and removed unused struct,
also rename some structure element names.
* Modified mesh_input and added mesh_recv_* that should verify and process mesh
data frames according to 9.32 Mesh forwarding framework in amendment;
* Modified mesh_decap accordingly to changes done in mesh control AE struct;

Approved by: adrian
2012-05-01 15:56:26 +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
91216c714c * Introduce new flag for QoS control field;
* Change in mesh_input to validate that QoS is set and Mesh Control field
  is present, also both bytes of the QoS are read;
* Moved defragmentation in mesh_input before we try to forward packet as
  inferred from amendment spec, because Mesh Control field only present in first
  fragment;
* Changed in ieee80211_encap to set QoS subtype and Mesh Control field present,
  only first fragment have Mesh Control field present bit equal to 1;

Submitted by:	monthadar@gmail.com
2012-03-04 05:52:26 +00:00
Adrian Chadd
70e0b5ac20 Hold IF_LOCK when manipulating the interface flags.
It doesn't _really_ help all that much, I'll commit something to
sys/net/if.c at some point explaining why, but the lock should be held
when checking/manipulating/branching because of said lock.
2012-02-24 05:40:36 +00:00
Bjoern A. Zeeb
6ffd0ca91b Correct comment for the IPv6 case to say "traffic class" not "TOS"
as pointed out back in 2009.

MFC after:	3 days
2012-01-07 23:41:38 +00:00
Adrian Chadd
32b0e64b56 Add 802.11h quiet time element support into net80211.
This supports both station and hostap modes:

* Station mode quiet time element support listens to quiet time
  IE's and modifies the local quiet time configuration as appropriate;
* Hostap mode both obeys the locally configured quiet time period
  and includes it in beacon frames so stations also can obey as needed.

Submitted by:	Himali Patel <himali.patel@sibridgetech.com>
Sponsored by:	Sibridge Technologies
2011-11-08 04:00:24 +00:00
Adrian Chadd
fa3324c985 This patch fixes beacon frame sequence number generation. The code
didn't set a sequence number; it didn't show up earlier because the
hardware most people use for hostap (ie, AR5212 series stuff) sets the
sequence numbers up in hardware. Later hardware (AR5416, etc) which
can do 11n and aggregation require sequence numbers to be generated in
software.

Submitted by:	paradyse@gmail.com
Approved by:	re (kib)
2011-08-24 08:53:33 +00:00
Bernhard Schmidt
50cfec0eb3 Data frames sent over the mgmt path might be part of a TX aggr session
too. In that case don't fiddle with the seqno as drivers are supposed
to handle that.

Currently only the powersave feature does sent QoS-null-data frames
before and after a background scan which must be handled correctly. Due
to this being quite rare we don't fiddle around with starting of aggr
sessions.
2011-06-04 14:28:09 +00:00
Bjoern A. Zeeb
8355d59d91 We need in.h for both INET and INET6, as according to RFC 3493 it
defines struct in6_addr, which is needed by ip6_hdr used in here.

Reviewed by:	gnn
Sponsored by:	The FreeBSD Foundation
Sponsored by:	iXsystems
MFC after:	5 days
2011-04-25 16:37:47 +00:00
Bernhard Schmidt
0d9aed8ad6 When injecting frames a temporary node is faked, during this several
uses of ic_curchan occur. Due to the nature of a scan, switching
channels constantly and all this happening without any kind of locks
held, it might happen that ic_curchan points to nowhere leading to
panics. Fix this by not allowing frame injections while in SCAN state.

Tested by:	Paul B. Mahol <onemda at gmail.com>
2011-03-13 12:56:46 +00:00