Commit Graph

1054 Commits

Author SHA1 Message Date
Adrian Chadd
7f0660a04b Don't treat the node as an 11n node if 11n rates are disabled.
For now, the AMRR code only knows about _either_ MCS or non-MCS rates.
It doesn't know how to downgrade (ie, doing 11b CCK rates if MCS0 isn't
reliable.)

PR:		kern/183428
2013-10-31 02:04:53 +00:00
Gleb Smirnoff
104dc21415 - Provide necessary includes, that before came via if.h pollution.
- Remove unnecessary ones.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2013-10-28 22:26:03 +00:00
Gleb Smirnoff
c3322cb91c Include necessary headers that now are available due to pollution
via if_var.h.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2013-10-28 07:29:16 +00:00
Gleb Smirnoff
eedc7fd9e8 Provide includes that are needed in these files, and before were read
in implicitly via if.h -> if_var.h pollution.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2013-10-26 18:18:50 +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
fce9c39777 Fix the "am I a net80211 vap" check for bpf listeners.
I changed it to use if_transmit a while ago but apparently with monitor
mode the if_transmit method is overridden.

This is (mostly) a workaround until a more permanent solution can be
found.

Submitted by:	Patrick Kelsey <kelsey@ieee.org>
Approved by:	re@ (gjb)
2013-10-10 19:56:31 +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
b105165323 Add in some backwards compatability hacks to make -HEAD net80211 compile
on -9.
2013-08-22 05:53:47 +00:00
Andre Oppermann
5fc98a7895 Reorder the mbuf defines to make more sense and group related flags
together.

Add M_FLAG_PRINTF for use with printf(9) %b indentifier.

Use the generic mbuf flags print names in the net80211 code and adjust
the protocol specific bits for their new positions.

Change SCTP M_PROTO mapping from 5 to 1 to fit within the 16bit field
they use internally to store some additional information.

Discussed with:	trociny, glebius
2013-08-19 14:25:11 +00:00
Andre Oppermann
7100b4d04a Migrate the net80211 protocol specific use of M_FRAG, M_FIRSTFRAG and
M_LASTFRAG flags to protocol specific flags.

Remove the now unused M_FRAG, M_FIRSTFRAG and M_LASTFRAG mbuf flags.

Discussed with:	trociny, glebius, adrian
2013-08-19 14:07:31 +00:00
Andre Oppermann
86bd049144 Add m_clrprotoflags() to clear protocol specific mbuf flags at up and
downwards layer crossings.

Consistently use it within IP, IPv6 and ethernet protocols.

Discussed with:	trociny, glebius
2013-08-19 13:27:32 +00:00
Adrian Chadd
bfd3bbdb11 Don't return ENOTSUPP here - the net80211 pluggable ioctl API will treat
this as the final item in the linker set and not try others.

This stopped the fast frames IOCTLs from being called.
2013-08-18 23:40:30 +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
Rui Paulo
a3e08d6f4c Replace the homegrown implementation of nitems() with calls to nitems()
(param.h).

Operating systems that don't have nitems() can easily define it on their own
net80211 OS-specific header file.

Discussed with:		adrian
2013-08-14 04:24:25 +00:00
Adrian Chadd
57b5fc5f3d Blank m_nextpkt before passing it up. 2013-08-12 22:27:53 +00:00
Adrian Chadd
4bd57e1078 When flushing packets from the powersave queue, make sure that
m_nextpkt is NULL before passing it up to the parent transmit
method.
2013-08-12 02:21:44 +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
1cc7c4c370 Fix compilation when debugging is disabled. 2013-07-28 17:35:19 +00:00
Adrian Chadd
0e20ac3863 Commit the missing header change. 2013-07-28 16:50:45 +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
0933e74b10 Add a missing unlock. 2013-07-05 22:10:50 +00:00
Adrian Chadd
f8d390be65 Document the current 11n rate selection shortcoming in the AMRR code. 2013-07-05 00:03:53 +00:00
Adrian Chadd
f8bf74f232 Implement basic 802.11n awareness in the PHY and AMRR rate control code.
* Add 802.11n 2ghz and 5ghz tables, including legacy rates and up to
  MCS23 rates (3x3.)

* Populate the rate code -> rate index lookup table with MCS _and_
  normal rates, but _not_ the basic rate flag.  Since the basic rate flag
  is the same as the MCS flag, we can only use one.

* Introduce some accessor inlines that do PLCP and rate table lookup/access
  and enforce that it doesn't set the basic rate bit.  They're not
  designed for MCS rates, so it will panic.

* Start converting drivers that use the rate table stuff to use the
  accessor inlines and strip the basic flag.

* Teach AMRR about basic 11n - it's still as crap for MCS as it is
  being used by iwn, so it's not a step _backwardS_.

* Convert iwn over to accept 11n MCS rates rather than 'translate' legacy
  to MCS rates.  It doesn't use a lookup table any longer; instead it's a
  function which takes the current node (for HT parameters) and the
  rate code, and returns the hardware PLCP code to use.

Tested:

* ath - it's a no-op, and it works that way
* iwn - both 11n and non-11n
2013-07-04 21:16:49 +00:00
Rui Paulo
edd39a8e2d Don't panic the kernel if we run wpa_supplicant on a hostap VAP.
Reviewed by:	adrian
2013-06-29 06:36:42 +00:00
Eitan Adler
eadc444a0f Fix typo (dbM -> dBm)
Submitted by:	Daan@vitsch.nl
Reviewed by:	adrian
2013-06-14 23:04:31 +00:00
Adrian Chadd
9984c9baf3 Don't hold the node lock over the iterator.
The "find node" function call will increase the node reference anyway;
so there's no reason to hold the node table lock during the MLME change.

The only reason I could think of is to stop overlapping mlme ioctls
from causing issues, but this should be fixed a different way.

This fixes a whole class of LORs that creep up when nodes are being
timed out or removed by hostapd.

Tested:

* AR5416, hostap, with nodes coming and going.  No LORs or stability
  issues were observed.
2013-06-07 09:03:56 +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
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
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
ebe15a7b25 Implement a utility function to return the current TX power cap for
the given node.

This takes into account the per-node cap, the ic cap and the
per-channel regulatory caps.

This is designed to replace references to ni_txpower in various net80211
drivers - ni_txpower doesn't necessarily reflect the actual cap for
the given node (eg if the node has the default value of 50dBm (100) and
the administrator has manually configured a lower TX power.)
2013-04-16 20:36:32 +00:00
Adrian Chadd
bd8cbcc32c Add VNET wrappers around the rest of the ieee80211 rtsock messages.
I triggered the cac/radar messages when doing testing in DFS channels.
2013-03-20 02:42:52 +00:00
Adrian Chadd
b451a99ecc Kill this, it's not needed at this point and (hopefully) the parent
has correctly locked the ic/vap.
2013-03-10 04:38:06 +00:00
Adrian Chadd
6ce4aeb88f Fix another compiler warning issue when invariants are disabled. 2013-03-09 15:35:31 +00:00
Adrian Chadd
3eed804d03 Fix non-invariant compilation. 2013-03-09 05:20:33 +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
341177e1d8 Disable this variable; the code using it is also disabled. 2013-02-18 01:37:55 +00:00
Adrian Chadd
32d384a45c 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.
2013-02-18 01:08:59 +00:00
Adrian Chadd
8c67042b72 Fix an incorrect sizeof()
Spotted by:	clang

Submitted by:	dim
2013-02-16 00:12:21 +00:00
Monthadar Al Jaberi
0cc7a79be6 Mesh: QoS Control field bit flags fix.
* The following bit flags where incroccetly defined:
    o Mesh Control Present
    o Mesh Power Save Level
    o RSPI
  This is now corrected according to Table 8.4 as per IEEE 802.11 2012;

Approved by:	adrian (mentor)
2013-02-14 20:00:38 +00:00
Gleb Smirnoff
23f4fd6da4 Substitute '#ifdef ALIGNED_POINTER' with '#ifndef __NO_STRICT_ALIGNMENT',
since the former is defined everywhere. This cuts off some code not
necessary on non strict aligment arches.

Reviewed by:	adrian
Sponsored by:	Nginx, Inc.
2013-02-12 11:24:37 +00:00
Adrian Chadd
d6aee93f98 Fix ieee80211_mesh.c compilation.
* Add the superg.h header to allow ieee80211_check_ff() to work
* Since the assert stuff creates assertions based on line numbers and there
  was a conflict, just nudge things down a bit.
2013-02-08 09:11:55 +00:00
Monthadar Al Jaberi
6db8a9b0f4 Mesh: recevied GANN frames where not parsed correctly.
* Added mesh_parse_meshgate_action that parse all values to host endian;
* Add more detailed debug output;

Approved by:	adrian (mentor)
2013-02-07 21:32:09 +00:00
Monthadar Al Jaberi
d68e1a3749 Mesh HWMP forwarding information: updating FI for transmitter.
* Added hwmp_update_transmitter function that checks if the metric
  to the transmitter have improved. If old FI is invalid or metric
  is larger the FI to the transmitter is updated occurdingly.
  This is a recommendation from the 802.11 2012 standard, table 13-9;

Approved by:	adrian (mentor)
2013-02-07 21:31:37 +00:00
Monthadar Al Jaberi
80e25642f2 Mesh HWMP PERR bug fixes.
* When calling ieee80211_mesh_rt_flush_peer, the rt->rt_dest argument
  should not be passed because it can get freed before invalidating
  the other routes that depends on it to compare with next_hop.
  Use PERR_DADDR(i) instead;

Approved by:	adrian (mentor)
2013-02-07 21:30:58 +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
62f0748505 Update ddb to print mesh routing table.
* Modified _db_show_vap and _db_show_com to print mesh routing table
  if the 'm' modifier is specified;

Approved by:	adrian (mentor)
2013-02-07 21:29:48 +00:00
Monthadar Al Jaberi
026e280fbf Mesh HWMP PREQ: fixed conditions for discarding elements.
Approved by:	adrian (mentor)
2013-02-07 21:29:14 +00:00
Monthadar Al Jaberi
230394c08b Mesh HWMP: don't send an intermediate PREP for proxy entries.
* The standard is unclear about what should happen in case a mesh STA (not
  marked as a mesh gate) recevies a PREQ for a destination that is marked
  as proxy. Solution for now is not to do intermediate reply at all, and
  let the PREQ reach the mesh gate;

Approved by:	adrian (mentor)
2013-02-07 21:28:25 +00:00
Monthadar Al Jaberi
6e83902004 Mesh HWMP PREQ update: proxy reply only if mesh STA is a meshgate.
* Original PREP frame is transmitted only by the target mesh STA or the
  mesh STA that is the proxy target;
* Fixed so that metric value is not over written incorrectly in
  hwmp_recv_preq for when replying back with a PREP;

Approved by:	adrian (mentor)
2013-02-07 21:27:40 +00:00
Monthadar Al Jaberi
4c4f4aa0f3 HWMP: ic->raw_xmit didn't always point to correct ni.
This is a code re-write. ic->raw_xmit need a pointer to ieee80211_node
for the destination node (da). I have reorganized the code so that
a pointer to the da node is searched for in the end & in one place.

* Make mesh_find_txnode public to be used by HWMP, renamed to
  ieee80211_mesh_finx_txnode;
* changed the argument from ieee80211_node to ieee80211vap for all
  hwmp_send_* functions;
* removed the 'sa' argument from hwmp_send_* functions as all HWMP frames
  have the source address equal to vap->iv_myaddr;
* Modified hwmp_send_action so that if da is MULTCAST ni=vap->iv_bss
  otherwise we called ieee80211_mesh_find_txnode. Also no need to hold
  a reference in this functions if da is not MULTICAST as by finding the
  node it became referenced in ieee80211_find_txnode;

Approved by:	adrian (mentor)
2013-02-07 21:26:40 +00:00
Monthadar Al Jaberi
15254d455e Mesh gate code to transmit to all mesh gates.
* Modified mesh_find_txnode to be able to handle proxy marked entries by
  recursively calling itself to find the txnode towards the active mesh gate;
* Mesh Gate: Added a new function that transmits data frames
  similar to ieee80211_start;
* Modified ieee80211_mesh_forward_to_gates so that:
     + Frames are duplicated and sent to each valid Mesh Gate;
     + Route is marked invalid before return of function, this is
       because we dont know yet which Mesh Gate is we will use;

Approved by:	adrian (mentor)
2013-02-07 21:26:06 +00:00
Monthadar Al Jaberi
b79858dac6 Send frames to mesh gate if 11s discovery fails.
* Send frames that have no path to a known valid Mesh Gate;
* Added the function ieee80211_mesh_forward_to_gates that sends the frame
  to the first found Mesh Gate in the forwarding information;
* If we try to discover again while we are discovering queue frame,
  the discovery callout will send the frames either to mesh gates
  or discards them silently;
* Queue frame also if we try to discover to frequently;

Approved by:	adrian (mentor)
2013-02-07 21:25:32 +00:00
Monthadar Al Jaberi
a21c6123ed Mark root mesh as gate when mesh gate flag set.
* Add function ieee80211_mesh_mark_gate in ieee80211_mesh.h;
* When received a proactive PREQ or RANN with corresponding mesh gate
  flag set, create a new entry in the known mesh gate list;

Approved by:	adrian (mentor)
2013-02-07 21:24:52 +00:00
Monthadar Al Jaberi
4cc361aa03 Propagate GANN frames, and store know gate info.
* Modified mesh_recv_action_meshgate to do following:
    + if mesh STA already knows the mesh gate of the recevied GANN frame
    + if mesh gate is know, check seq number according to 802.11 standard
    + if mesh gate is not know, add it to the list of known mesh gates
    + if forwarding is enabled and ttl >= 1 then propagate the GANN frame;
* Declare a new malloc type M_80211_MESH_GT_RT;
* Declare a struct to store GANN information, ieee80211_mesh_gate_route. And
  add it as a TAILQ list to ieee80211_mesh_state;

Approved by:	adrian (mentor)
2013-02-07 21:24:20 +00:00
Monthadar Al Jaberi
ed0b544066 Mesh update: add base Mesh Gate functionality.
A Mesh Gate should transmit a Mesh Action frame containing
ieee80211_meshgann_ie as its only information element periodically
every ieee80211_mesh_gateint ms. Unless the mesh gate is also configure
as a ROOT, then these frames should not be send.
This is according to 802.11 2012 standard;

* Introduce new SYSCTL net.wlan.mesh.gateint, with 10s default;
* Add two new functions mesh_gatemode_setup and mesh_gatemode_cb. This
  is similar to how HWMP setups up a callout;
* Add two new action handlers mesh_recv_action_meshgate and
  mesh_send_action_meshgate;
* Added ieee80211_add_meshgate to ieee80211_mesh.h;
* Modified mesh_send_action to look similar to hwmp_send_action. This is
  because we need to send out broadcast management frames.
* Introduced a new flag for mesh state IEEE80211_MESHFLAGS_ROOT. This flag
  is now set by HWMP code when a mesh STA is configured as a ROOT. This
  is then checked by mesh_gatemode_cb before scheduling a new callout;
* Added to new field to ieee80211_mesh_state:
    + struct callout                  ms_gatetimer
    + ieee80211_mesh_seq              ms_gateseq;

Approved by:	adrian (mentor)
2013-02-07 21:23:43 +00:00
Monthadar Al Jaberi
c81ceff7c7 Start accepting IEEE80211_ACTION_MESH_GANN frames;
* Add IEEE80211_ACTION_MESH_GANN Action frame verification in
  ieee80211_parse_action;

Approved by:	adrian (mentor)
2013-02-07 21:22:14 +00:00
Monthadar Al Jaberi
cd47d75c70 Mesh: management mesh action frames are to be discarded
when not peered.

* Modified ieee80211_recv_action to check if neighbour is peered for
  IEEE80211_ACTION_CAT_MESH frames, if not frame is discarded. This is
  according to IEEE802.11 2012 standard;
* Removed duplicate checks in each hwmp_recv_* handlers because HWMP
  is a subtype of mesh action;

Approved by:	adrian (mentor)
2013-02-07 21:21:40 +00:00
Monthadar Al Jaberi
71766338b2 Update in ieee80211_action.c for mesh code handlers.
* Removed meshlm_send_action and hwmp_send_action. Introduced one common
  for all Mesh Action frames meshaction_send_action. According to 802.11
  standard Link Metric and HWMP are all under Mesh Action category;
* Did similar changes to recv_action part;
* The size of meshaction_*_action is set to 12. This is to make room for
  the rest of Mesh Action category subtypes;

Approved by:	adrian (mentor)
2013-02-07 21:21:05 +00:00
Monthadar Al Jaberi
e1373e86c4 Update net80211 mesh struct ieee80211_meshgann_ie.
* Change all field prefix from pann_ to gann_;
* Added IEEE80211_MESHGANN_BASE_SZ macro to be used in the length field
  of a GANN frame according to 802.11 standard;
* Changed gann_seq field type to uint32_t;
* Added a Gate Announcement interval field according to
  IEEE802.11 2012 standard;
* Added IEEE80211_MESHRT_FLAGS_GATE as flag bit to ieee80211_mesh_route;
* Added IEEE80211_MESHRT_FLAGS_GATE as flag bit to ieee80211req_mesh_route;

Approved by:	adrian (mentor)
2013-02-07 21:20:28 +00:00
Monthadar Al Jaberi
40c44a6bb5 HWMP: Accept a PERR even if path is valid.
* An HWMP PERR should be accepted even if path is valid. Because
  we check if we recevied it from a neighbour that we use as a next hop;

Approved by:	adrian (mentor)
2013-02-07 21:19:44 +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
Monthadar Al Jaberi
8c751dd528 Fix mesh path flag.
* A bug occurs while in discovery mode which leaves a path marked with
  both Discover and Valid flag. This happens when receiving/sending
  PREQ and PREP in a particular order. Solution is to assign the Valid bit
  instead of oring it;

Approved by:	adrian (mentor)
2013-02-07 21:17:35 +00:00
Monthadar Al Jaberi
ff17492f7c Stop a mesh STA from flooding with peer frames.
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)
2013-02-07 21:12:55 +00:00
Adrian Chadd
9da01550a9 Wrap this in an #ifdef so IEEE80211_SUPPORT_SUPERG will work correctly
in a wlan.ko module.
2013-02-02 02:00:10 +00:00
Adrian Chadd
d71a1f7ae4 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.
2013-01-26 00:37:54 +00:00
Adrian Chadd
3484d5ad30 Remove the use of the ifnet send queue and if_start() in the power
save queue code.

Instead, use if_transmit() directly - and handle the cases where frame
transmission fails.

I don't necessarily like this and I think at this point the M_ENCAP check,
node freeing upon fail and the actual if_transmit() call should be done
in methods in ieee80211_freebsd.c, but I digress slightly..

This removes one of the last few uses of if_start() and the ifnet
if_snd queue.  The last major offender is ieee80211_output.c, where
ieee80211_start() implements if_start() and uses the ifnet queue
directly.

(There's a couple of gotchas here, where the if_start pointer is
compared to ieee80211_start(), but that's a later problem.)
2013-01-15 17:50:07 +00:00
Adrian Chadd
b8f699e9a8 Add in the missing radiotap definitions from the sipsolutions.net
radiotap "upstream" source.
2013-01-08 06:59:21 +00:00
Adrian Chadd
7ea3aada55 Handle ps-poll data frame if_transmit() failure.
If the data frame transmission failures, it may have a node reference
that needs cleaning up.

If the frame is marked as M_ENCAP then it should treat recvif as a node
reference and clear it.

Now - since the mbuf has been freed by calling if_transmit() (even on
failure), the mbuf has to be treated as invalid.  Hence why the ifp is
used.
2013-01-06 04:40:07 +00:00
Adrian Chadd
17b08c4368 Handle HWMP if_transmit() failure gracefully.
If if_transmit() fails, the node ref may need freeing.

This is based on the same logic used by the ageq, which the mesh code
(re) uses for frames which need to be staged before transmitting.
It also does the same thing - if M_ENCAP is set on the mbuf, it treats
the recvif pointer as a node reference and derefs it.
2013-01-06 04:38:31 +00:00
Adrian Chadd
a7f31a3636 if_start() is being used here as a way of kick-starting the new queue
processing.  For if_transmit() style hardware drivers (which none publicly
exist yet, for wireless) they will need to still implement if_start()
but only to re-start the TX queue.
2012-12-22 01:17:49 +00:00
Adrian Chadd
88954eb02e Remove a use of if_start() - instead, use if_transmit() to dispatch the
frame.
2012-12-22 01:16:28 +00:00
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
a48a8ad7a5 Update the aggressive mode logic to also enable aggressive mode
parameters in IBSSes.

IBSS was just being plainly ignored here even though aggressive mode
was 'on'.

This still doesn't fix the "why are the WME parameters reset upon
interface down/up" issue.

PR:		kern/165969
2012-12-10 00:16:38 +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
b3c69eef25 Atheros SuperG bug fixes, as part of hunting down kern/174283.
The stageqdepth (global, over all staging queues) was being kept
incorrectly.  It was being incremented whenever things were added,
but only decremented during a flush.  During active fast frames activity
it wasn't being decremented, resulting in it always having a non-zero
value during normal fast-frames operation.

It was only used when checking if the aging queue should be checked;
we may as well just defer to each of those staging queue counters (which
look correct, thankfully.)

Whilst I'm here, add locking assertions in the staging queue add/remove
functions.  The current crash shows that the staging queue has one frame,
but only has a tail pointer set (the head pointer being set to NULL.)
I'd like to grab a few more crashes where these locking assertions are
in place so I can narrow down the issue between "somehow locking is
messed up and things are racy" and "the stage queue head/tail pointer
manipulation logic is subtly wrong."

Tested:

* AR5416 STA, AR5413 AP; with FastFrames enabled in the AR5416 HAL.

PR:		kern/174283
2012-12-09 19:20:28 +00:00
Adrian Chadd
25b5bb4c1b Don't panic if the stageq here is empty; just fall through with NULL
pointers and leave the stage queue flush routine to just do nothing
(since both head and tail here will be NULL.)

This should quieten the "stageq empty" panic where the stageq itself
is empty, but it won't fix the second KASSERT() here "staging queue empty"
as that's likely a different underlying problem.

PR:		kern/174283
2012-12-09 01:08:44 +00:00
Adrian Chadd
132581aa5d Fix a use-after-free bug in the Atheros fast-frames support.
Tested:

* AR5212 AP, AR5413 STA, iperf TCP STA->AP, destroyed and/or shutdown
  the STA vap during active iperf TCP traffic.

PR:		kern/174273
MFC after:	1 week
2012-12-08 09:48:03 +00:00
Adrian Chadd
2f760a0455 Add a new 900MHz GSM regulatory SKU for the Xagyl Communications XC900M.
The XC900M acts as a Ubiquiti XR9 (and I _think_ SR9) by default;
it uses the same 900MHz<->2.4GHz downconverter mapping.

However it has an alternative frequency mapping which squeezes in a couple
more half/quarter rate channels.  Since the default HAL doesn't support
fractional tuning (sub-1MHz) in 2.4GHz mode on the AR5413/AR5414, they
implement it using a jumper.

Datasheet: http://www.xagyl.com/download/XC900M_Datasheet.pdf

Thankyou to Xagyl Communications for the XC900M NICs and Edgar Martinez
for organising the donation.

Tested:

* XC900M <-> XC900M
* Ubiquiti XR9 <-> XC900M

TODO:

* Test against SR9 and GZ901 if possible (the IEEE channel<->frequency
  mapping may not match up, thanks to the slightly different channels
  involved)
2012-12-07 06:34:46 +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
Adrian Chadd
3845e36744 Add a primitive to check if a lock is not owned. 2012-11-26 00:06: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
fdf3d9543a Oops, missed in my last commit. 2012-10-26 19:46:55 +00:00
Adrian Chadd
f397643e36 Allow net80211 to be built on -9 and -8.
There are some people who use the -HEAD net80211 and wireless drivers
on earlier FreeBSD versions in order to get the updated 802.11n support.
The previous if_clone API changes broke this.
2012-10-26 19:06:24 +00:00
Adrian Chadd
30e4856a81 Fix up some initial issues with creation and deletion of hotplugged
net80211 devices and vaps.

* vnet sets vnet0 during kldload and device probe/attach, but not for
  the hotplug event.  Thus, plugging in a NIC causes things to panic.
  So, add a CURVNET_SET(vnet0) for now during the attach phase, until
  the hotplug code is taught to set CURVNET_SET(vnet0).

* there's also no implied detach vnet context - so teach the detach
  path about ifp->if_vnet.

* When creating/deleting vaps, also set the vnet context appropriately.
  These can be done at any time.

Now, the problems!

* ieee80211.c is supposed to be OS-portable code, with no OS-specific stuff
  like vnet. That should be fixed.

* When the device hotplug code gets taught about CURVNET_SET(vnet0), the
  device vnet set can go away; but the VAP vnet set still needs to be there.

* .. and there still is the question about potentially adding an implied
  CURVNET_SET(ifp->if_vnet) on if_free(), since any/all devices may end up
  being detached by a hotplug event in today's world.  That's going to be
  a topic of a subsequent commit.
2012-10-26 16:56:55 +00:00
Gleb Smirnoff
42a58907c3 Make the "struct if_clone" opaque to users of the cloning API. Users
now use function calls:

  if_clone_simple()
  if_clone_advanced()

to initialize a cloner, instead of macros that initialize if_clone
structure.

Discussed with:		brooks, bz, 1 year ago
2012-10-16 13:37:54 +00:00
Kevin Lo
9823d52705 Revert previous commit...
Pointyhat to:	kevlo (myself)
2012-10-10 08:36:38 +00:00
Kevin Lo
a10cee30c9 Prefer NULL over 0 for pointers 2012-10-09 08:27:40 +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
7b5a343596 Fix a crash bug introduced in the iterate node work recently done.
When resuming, the first VAP is checked for max_aid; however if there
is no VAP, this results in a NULL pointer dereference and kernel
panic.
2012-09-16 22:45:00 +00:00
Eitan Adler
0af1b47258 s/ is is / is /g
s/ a a / a /g

Approved by:	cperciva
MFC after:	3 days
2012-09-14 22:00:03 +00:00
Adrian Chadd
b6afbb7943 Fix an incorrect comparison.
PR:		kern/170098
2012-08-16 00:53:23 +00:00
Adrian Chadd
7d684b4b18 Don't call the node iteration function inside the node table / node
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
2012-08-15 20:01:28 +00:00
Adrian Chadd
2a72e4b222 Fix an incorrect comment. 2012-08-08 17:16:06 +00:00
Monthadar Al Jaberi
33a2506f6b Fixed some debug output in hwmp_recv_prep. 2012-07-31 08:05:40 +00:00
Monthadar Al Jaberi
cfe1569450 Fix a PREQ comparison error in 11s HWMP.
* Earlier we compared two not equal metrics, one was what we recevied
in the 'new PREQ' while the other was what we already have saved which
was 'old PREQ' + link metric for the last hop;
* Fixed by adding 'new PREQ' + link metric for the last hop in a
temporary variable;
2012-07-31 07:36:27 +00:00
Monthadar Al Jaberi
b06953a432 Fix bugs in net80211s found with wtap simulator.
For description of the test scripts refer to projects/net80211_testsuite/wtap.

* Test 007 showed a bug in intermediate PREP for a proxy entry. Resolved;
* Test 002 showed a bug in the Addressing Mode flag for a PREQ. Resolved;
2012-07-31 07:31:47 +00:00
Adrian Chadd
64f3cab069 Add a check for dynamic OFDM/CCK channel types. 2012-07-01 04:25:49 +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
Adrian Chadd
8a3860d5b4 Extend the radiotap code to be aware of the size of any extra vendor
bitmaps that may occur.

The way this works is:

* the beginning of the radiotap frame has a 32 bit "radiotap" namespace
  bitmap;
* if the vendor bitmap bit is set, then the next bitmap will be interpreted
  as a vendor bitmap;
* this can keep going on and on (ie, more vendor and radiotap namespace
  bitmaps can be added) until the last bitmap with no "more bitmaps" set.

Now, the radiotap code gets its grubby fingers into the supplied
radiotap rx/tx buffer and replaces the channel configuration
for each frame.  I don't know why it's not up to the drivers themselves
to do this, but I digress.  So, if a vendor bitmap (or two, etc) exists,
the offset calculations will be all completely wrong.

This particular patch introduces ieee80211_radiotap_attachv(), which
includes the number of vendor bitmaps (well, any other bitmaps, vendor
or otherwise) between the end of the bitmap/header and the start of the
actual radiotap field entries.  This makes the radiotap calculations
"right", so it correctly calculates where to overwrite the channel
configuration.

The long term fix is to go through and make each driver update the channel
configuration, as some of the fields are already being updated.

That, however, is a longer term fix that will need each driver fixed.

I leave that as an exercise to someone in the future.
2012-06-18 02:08:04 +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
Monthadar Al Jaberi
46684c91ec Update HWMP Proactive code and mesh route flags.
* Modified hwmp_recv_preq:
    o cleaned up code, removed rootmac variable because preq->origaddr
      is the root when we recevie a Proactive PREQ;
    o Modified so that a PREP in response of a Proactive PREQ is unicast,
      a PREP is ALWAYS unicast;
* Modified hwmp_recv_prep:
    o Before we mark a route to be valid we should remove the discovery
      flag and then mark it valid in such a way we wont lose the isgate flag;

Approved by: adrian
2012-05-01 16:18:38 +00:00
Monthadar Al Jaberi
47451c661b PREQ discovery update.
* Added a new discovery flag IEEE80211_MESHRT_FLAGS_DISCOVER;
* Modified ieee80211_ioctl.h to include IEEE80211_MESHRT_FLAGS_DISCOVER;
* Added hwmp_rediscover_cb, which will be called by a timeout to do
rediscovery if we have not reach max number of preq discovery;
* Modified hwmp_discover to setup a callout for path rediscovery;
* Added to ieee80211req_mesh_route to have a back pointer to ieee80211vap
for the discovery callout context;
* Modified mesh_rt_add_locked arguemnt from ieee80211_mesh_state to
ieee80211vap, this because we have to initialize the above back pointer;

Approved by: adrian
2012-05-01 16:16:20 +00:00
Monthadar Al Jaberi
9fc85253aa Net80211s update: Mesh Gate Announcement and removal of Portal Announcement.
* Renamed IEEE80211_ELEMID_MESHPANN to IEEE80211_ELEMID_MESHGANN according to
 amendment;
 * Added IEEE80211_IOC_MESH_GATE that controls whether Mesh Gate Announcement
 is activated or not;
 * Renamed all flags from Portal to Gate in HWMP frames;
 * Removed IEEE80211_ACTION_MESHPANN enum cause its part of the Mesh Action
 category now as per amendment;
 * Renamed IEEE80211_MESHFLAGS_PORTAL to IEEE80211_MESHFLAGS_GATE in
 ieee80211_mesh_state flags;
 * Modified ieee80211_hwmp.c/ieee80211_mesh.c to use new GATE flags;

Approved by: adrian
2012-05-01 16:14:18 +00:00
Monthadar Al Jaberi
f02ce81b16 RANN update
* Introduced a new HWMP sysctl, Root Confirmation Interval;
* Added hr_lastrootconf to hwmp_route, is for ratecheck for a specific ROOT;
* We missed reading RANN.interval subfield from a RANN frame before;
* Updated hwmp_recv_rann according to amendment, see comments;

Approved by: adrian
2012-05-01 16:13:22 +00:00
Monthadar Al Jaberi
3db825165a PERR update to be called from mesh code.
* Added mpp_senderror for Mesh Path Selection protocol;
* Added hwmp_senderror that will send an HWMP PERR according to the
supplied reason code;
* Call mpp_senderror when deleting a route with correct reason code
for whether the route is marked proxy or not;
* Call mpp_senderror when trying to forward an individually addressed
frame and there is no forwarding information;

Approved by: adrian
2012-05-01 16:12:39 +00:00
Monthadar Al Jaberi
d421a252f6 * Modified PERR acceptance criteria according to amendment;
* Modified how PERR is handled and propagated according to amendment;

Approved by: adrian
2012-05-01 16:11:47 +00:00
Monthadar Al Jaberi
c0985dbc7a Updated PREQ propagation code;
* When receiving a Proactive PREQ dont return after processing it but propagate;
* When we propagate we should not enforce ratechecking;
* Added checking for multiple pred ID detection;
* Storing proxy orig address when PREQ is not for us;

Approved by: adrian
2012-05-01 16:10:32 +00:00
Monthadar Al Jaberi
52e45fc074 * PREQ acceptance criteria updated to check for proxy condition as in amendment;
Approved by: adrian
2012-05-01 16:09:44 +00:00
Monthadar Al Jaberi
53c35d21d5 * Proactive PREQ (original transmission) must also set
IEEE80211_MESHPREQ_TFLAGS_USN flag in target_flag field;

Approved by: adrian
2012-05-01 16:08:46 +00:00
Monthadar Al Jaberi
7b977be4d0 * Fixed hwmp_discover code to populate a PREQ packet correctly;
* Removed IEEE80211_MESHPREQ_TFLAGS_RF which is no longer part of the
amendment spec;

Approved by: adrian
2012-05-01 16:07:35 +00:00
Monthadar Al Jaberi
3d7486ce50 * Fixed PREQ flag field Adressing mode subfiled according to amendment specs;
Approved by: adria
2012-05-01 16:06:20 +00:00
Monthadar Al Jaberi
79b9f8c6b4 * Added a mesh max PREQ retires sysctl that governous how many times
we try to discover an address;
* Added a mesh net travelse time across an MBSS, which is used to enforce
discovery rate check;

Approved by: adrian
2012-05-01 16:05:09 +00:00
Monthadar Al Jaberi
8ccfff66c1 Change how we enforce PREQ minimum interval.
* Moved hs_lastpreq to be hr_lastpreq cause this rate check should be per
target mesh STA according to amendment (NB: not applicable for PERR);
* Modified hwmp_send_preq to use two extra arguments for last sent PREQ and
minimum PREQ interval;
* hwmp_send_preq is called with last two arguments equal to NULL when sending
Proactive PREQs cause the call back task enforces the rate check;

Approved by: adrian
2012-05-01 16:03:27 +00:00
Monthadar Al Jaberi
644ccee405 PREP update
* Added assertion in mesh_rt_update;
* Fixed some prep propagation that where multicast, ALL PREPS ARE UNICAST;
* Fixed PREP acceptance criteria;
* Fixed some PREP debug messages;
* HWMP intermediate reply (PREP) should only be sent if we have newer
forwarding infomration (FI) about target;
* Fixed PREP propagation condition and PREP w/ AE handling;
* Ignore PREPs that have unknown originator.
* Removed old code inside PREP that was for proactive path building
to root mesh;

Other errors include:
* use seq number of target and not orig mesh STA;
* Metric is what we have stored in our FI;
* Error in amendment, Hop count is not 0 but equals FI hopcount for target;

Approved by: adrian
2012-05-01 16:02:31 +00:00
Monthadar Al Jaberi
737a965ec9 * MeshForwarding update mesh_recv_indiv_data_to_fwrd to silently discard
unknown meshDA instead of panic, which is allowed per amendment spec;

Approved by: adrian
2012-05-01 16:00:31 +00:00
Monthadar Al Jaberi
4f3a27ae65 Added route lifetime update for destination and source mesh along a mesh path;
* In mesh_recv_indiv_data_to_fwd update route entry for both meshDA and meshSA;
 * In mesh_recv_indiv_data_to_me update route entry for meshSA;
 * in ieee80211_mesh_rt_update put code so that a proxy entry that is gated
 by us (number of hops == 0) is never invalidated;
 * Fixed so that we always call ieee80211_mesh_rt_update with lifetime in ms;

Approved by: adrian
2012-05-01 15:58:10 +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
Monthadar Al Jaberi
b5df85a6fd Implemented so that Mesh forwarding information lifetime is dynamic.
* Introduced ieee80211_mesh_rt_update that updates a route with the
 maximum(lifetime left, new lifetime);
 * Modified ieee80211_mesh_route struct by adding a lock that will be used
 by both ieee80211_mesh_rt_update and precursor code (added in future commit);
 * Modified in ieee80211_hwmp.c HWMP code to use new ieee80211_mesh_rt_update;
 * Modified mesh_rt_flush_invalid to use new ieee80211_mesh_rt_update;
 * mesh_rt_flush also checks that lifetime == 0, this gives route discovery
 a change to complete;
 * Modified mesh_recv_mgmt case IEEE80211_FC0_SUBTYPE_BEACON:
 when ever we received a beacon from a neighbor we update route lifetime;

Approved by: adrian
2012-05-01 15:47:30 +00:00
Monthadar Al Jaberi
6eb9b443f4 Fixed some MPM reason codes and max number of neighbors check
* Added IEEE80211_MESH_MAX_NEIGHBORS and it is set to 15, same as before;
 * Modified mesh_parse_meshpeering_action to verify MPM frame and send
 correct reason code for when a frame is rejected according to standard spec;
 * Modified mesh_recv_action_meshpeering_* according to the standard spec;
 * Modified mesh_peer_timeout_cb to always send CLOSE frame when in CONFIRMRCV
 state according to the standard spec;

Approved by: adrian
2012-05-01 15:42:41 +00:00
Monthadar Al Jaberi
c2042c359f Modified structure and code that handles Mesh peering management.
* Old struct ieee80211_meshpeer_ie had wrong peer_proto field size;
 * Added IEEE80211_MPM_* size macros;
 * Created an enum for the Mesh Peering Protocol Identifier field according
 to the standard spec and removed old defines;
 * Abbreviated Handshake Protocol is not used by the standard anymore;
 * Modified mesh_verify_meshpeer to use IEEE80211_MPM_* macros for verification;
 * Modified mesh_parse_meshpeering_action to parse complete frame, also to parse
 it according to the standard spec;
 * Modified ieee80211_add_meshpeer to construct correct MPM frames according to
 the standard spec;

Approved by: adrian
2012-05-01 15:39:16 +00:00
Monthadar Al Jaberi
ebeaa1ade5 Added Self-protected action category (including MPM).
* Added new action category IEEE80211_ACTION_CAT_SELF_PROT which is used by 11s
for Mesh Peering Management;
* Updated Self protected enum Action codes to start from 1 instead of 0
according to the standard spec;
* Removed old and wrong action categories IEEE80211_ACTION_CAT_MESHPEERING;
* Modified ieee80211_mesh.c and ieee80211_action.c to use the new action
category code;
* Added earlier verification code in ieee80211_input;

Approved by: adrian
2012-05-01 15:35:10 +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
Bernhard Schmidt
a2a4a2aa53 Add basic HT channel setup to ieee80211_init_channels(), this will be
used by at least ral(4).

Reviewed by:	ray
2012-04-03 17:48:42 +00:00
Adrian Chadd
e789273713 Correct the ordering of tid/crypto ic_name.
Because the code lacks all the GNU extensions to printf() format stuff,
the compiler doesn't helpfully tell us that I messed up in a previous
commit.

Pointy hat to: adrian, who likely only cares about this because he's the
  only one who bothers flipping on net80211 debugging.
2012-03-27 04:15:38 +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
Adrian Chadd
dc1f12bf69 Re-commit this - store the alq payload in network order. 2012-03-21 03:19:50 +00:00
Adrian Chadd
bca1cc1fd2 .. revert out a local change that I hadn't yet completely finished fleshing
out and testing.

sorry!
2012-03-18 21:54:59 +00:00
Adrian Chadd
ee56d93281 Add a missing endian conversion. 2012-03-18 19:35:30 +00:00
Adrian Chadd
a284b01037 Pull in a dependency on ALQ if it's compiled with IEEE80211_ALQ. 2012-03-16 23:08:13 +00:00
Adrian Chadd
561bc9b3e4 Add missing \n's.
This showed up when testing the wtap module, as it attaches with
no radiotap tx/rx configuration.
2012-03-08 23:46:42 +00:00
Adrian Chadd
1f88a92ba9 Modify HWMP to be able to allocate memory for PREQ/PREP/PERR for all scenarios.
* Added verify_mesh_*_len functions that verify the length
  according to the amendment spec and return number of destination addresses
  for allocation of appropriate struct size in memory;
* Modified hwmp_recv_action_meshpath to allocate HWMP ie instead of
  storing them on the stack and store all available field according the flags;
* Modify hwmp_add_mesh* to work with all cases of HWMP according to amendment.
* Modify hwmp_send_* to calculate correct len of bytes for the HWMP ie.
* Added new M_80211_MESH_* malloc defines.
* Added macros with magic numbers for HWMP ie sizes according to amendment.
* Added the external address to all HWMP ie structs.

Submitted by:	monthadar@gmail.com
2012-03-06 21:20:16 +00:00
Adrian Chadd
05f91fa06a Oops - used the wrong field.
Noticed by:	nwhitehorn
2012-03-05 02:36:15 +00:00
Adrian Chadd
cf42b1cce7 Add the thread id to the net80211 alq records.
This will (hopefully) aid in debugging concurrency related issues.
2012-03-04 23:13:52 +00:00
Adrian Chadd
22eeb8c617 Fix style(9) issues. 2012-03-04 23:04:16 +00:00
Gleb Smirnoff
dbab732d75 Fix build w/o 'options IEEE80211_SUPPORT_MESH'. 2012-03-04 09:45:43 +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
bdd2a07668 * Added IEEE80211_ACTION_CAT_MESH in ieee80211.h as specified amendment spec;
* Moved old categories as specified by D4.0 to be action fields of MESH category
  as specified in amendment spec;
* Modified functions to use MESH category and its action fields:
  + ieee80211_send_action_register
  + ieee80211_send_action
  + ieee80211_recv_action_register
  +ieee80211_recv_action;
* Modified ieee80211_hwmp_init and hwmp_send_action so they uses correct
  action fields as specified in amendment spec;
* Modified ieee80211_parse_action so that it verifies MESH frames.
* Change Mesh Link Metric to use one information element as amendment spec.
  Draft 4.0 defined two different information elements for request and response.

Submitted by:	monthadar@gmail.com
2012-03-04 05:49:39 +00:00
Adrian Chadd
66b74386c7 Attempt to catch scan cancellations at exactly the wrong time from occuring.
The scan code unlocks the comlock and calls into the driver.  It then
assumes the state hasn't changed from underneath it.

Although I haven't seen this particular condition trigger, I'd like to
be informed if I or anyone else sees it.

What I'm thinking may occur:

* A cancellation comes in during the scan_end call;
* the cancel flag is set;
* but it's never checked, so scandone isn't updated;
* .. and the interface stays in the STA power save mode.

It's a subtle race, if it even exists.

PR:		kern/163318
2012-03-02 02:53:43 +00:00
Adrian Chadd
e168e5f947 Only increment is_beacon_bad if we're not scanning.
Otherwise things such as off-channel probe responses and beacons are also
silently discarded and logged against this error counter.
2012-02-28 21:43:29 +00:00
Adrian Chadd
de6818224d Print out the bogus beacon interval. 2012-02-28 21:41:47 +00:00
Adrian Chadd
fd9a6137da Track the number of bad beacons received.
PR:		kern/165517
2012-02-28 04:05:35 +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