Commit Graph

890 Commits

Author SHA1 Message Date
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