* 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
* 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
* 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
* 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
* 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
* 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
* 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
* 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
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.
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
* 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
* 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
* 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
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
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.
comlock, I'd like to find and analyse these cases to see if they
really are valid.
So, throw in a lock here and wait for the (hopefully!) inevitable
complaints.
* Change the mesh IE size to be IEEE80211_MESH_CONF_SZ rather than the
size of the structure;
* conf_cap is now a uint8_t rather than a uint16_t (uint16_t in D3.0,
uint8_t in the amendment spec);
* Update mesh config capability bits - earlier bits were from draft X,
current is amendment spec;
* Update the following to be an enum rather than #define and added
a VENDOR entry too from the amendment spec;
IEEE80211_MESHCONF_PATH_*
IEEE80211_MESHCONF_METRIC_*
IEEE80211_MESHCONF_CC_*
IEEE80211_MESHCONF_SYNC_*
IEEE80211_MESHCONF_AUTH_*
* Kept IEEE80211_MESHCONF_FORM_* and IEEE80211_MESHCONF_CAP_* as
defines because they are defined in a way that we need to mask in/out
information;
* In IEEE80211_MESHCONF_CAP_* IEEE80211_MESHCONF_CAP_TBTTA is removed
and 0x80 is made reserved as defined in the amendment spec.
Submitted by: monthadar@gmail.com
Reviewed by: rpaulo
compliance testing.
In order to allow for radar pattern matching to occur, the DFS CAC/NOL
handling needs to be made configurable. This commit introduces a new
sysctl, "net.wlan.dfs_debug", which controls which DFS debug mode
net80211 is in.
* 0 = default, CSA/NOL handling as per normal.
* 1 = announce a CSA, but don't add the channel to the non-occupy list
(NOL.)
* 2 = disable both CSA and NOL - only print that a radar event occured.
This code is not compiled/enabled by default as it breaks regulatory
handling. A user must enable IEEE80211_DFS_DEBUG in their kernel
configuration file for this option to become available.
Obtained from: Atheros
This makes it much easier to determine whether an event occurs in the
net80211 taskqueue (which was called "ath0 taskq") or the ath driver
taskqueue (which is also called "ath0 taskq".)
For example, this particular topology didn't work correctly from all
nodes:
[A] - [B] - [C] - [D]
Submitted by: Monthadar Al Jaberi <monthadar@gmail.com>
Reviewed by: bschmidt, adrian
This allows for multiple MAC addresses to be printed on the same
debugging line. ether_sprintf() uses a static char buffer and
thus isn't very useful here.
Submitted by: Monthadar Al Jaberi <monthadar@gmail.com>
is used.
Although the module _builds_, it fails to load because of a missing symbol from
ieee80211_tdma.c.
Specifics:
* Always build ieee80211_tdma.c in the module;
* only compile in the code if IEEE80211_SUPPORT_TDMA is defined.
