summaryrefslogtreecommitdiff
path: root/net/mac80211/mesh_hwmp.c
AgeCommit message (Collapse)Author
2014-07-15mac80211: remove unnecessary break after returnFabian Frederick
Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-22mac80211: mesh: always use the latest target_snBob Copeland
When a path target responds to a path request, its response always contains the most up-to-date information; accordingly, it should use the latest target_sn, regardless of net_traversal_jiffies(). Otherwise, only the first path response is considered when constructing a path, as it will have the highest target_sn of all replies during that period. Signed-off-by: Bob Copeland <bob@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-04-22mac80211: mesh: use u16 return type for u16 getterBob Copeland
u16_field_get() is a simple wrapper around get_unaligned_le16(), and it is being assigned to a u16, so there's no need to promote to u32 in the middle. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-11-25mac80211: use put_unaligned_le in mesh when necessaryChun-Yeow Yeoh
Use put_unaligned_le16 and put_unaligned_le32 for mesh_path_error_tx and mesh_path_sel_frame_tx. Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-11-25mac80211: add generic cipher scheme supportMax Stepanov
This adds generic cipher scheme support to mac80211, such schemes are fully under control by the driver. On hw registration drivers may specify additional HW ciphers with a scheme how these ciphers have to be handled by mac80211 TX/RR. A cipher scheme specifies a cipher suite value, a size of the security header to be added to or stripped from frames and how the PN is to be verified on RX. Signed-off-by: Max Stepanov <Max.Stepanov@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-04-16mac80211: parse VHT channel switch IEsJohannes Berg
VHT introduces multiple IEs that need to be parsed for a wide bandwidth channel switch. Two are (currently) needed in mac80211: * wide bandwidth channel switch element * channel switch wrapper element The former is contained in the latter for beacons and probe responses, but not for the spectrum management action frames so the IE parser needs a new argument to differentiate them. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-04-08mac80211: return new mpath from mesh_path_add()Bob Copeland
Most times that mesh_path_add() is called, it is followed by a lookup to get the just-added mpath. We can instead just return the new mpath in the case that we allocated one (or the existing one if already there), so do that. Also, reorder the code in mesh_path_add a bit so that we don't need to allocate in the pre-existing case. Signed-off-by: Bob Copeland <bob@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-04-08mac80211: fix the PREP mesh hwmp debug messageChun-Yeow Yeoh
The mesh hwmp debug message is a bit confusing. The "sending PREP to %p" should be the MAC address of mesh STA that has originated the PREQ message and the "received PREP from %pM" should be the MAC address of the mesh STA that has originated the PREP message. Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: clean up mesh codeJohannes Berg
There's various code with strange indentation, questionable loop and locking constructs, etc. The bigger change is moving the "sdata" argument to the first argument of all functions, like all other mac80211 functions that have one. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: constify IE parsingJohannes Berg
Make all the parsed IE pointers const, and propagate the change to all the users etc. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-04mac80211: mesh power save basicsMarco Porsch
Add routines to - maintain a PS mode for each peer and a non-peer PS mode - indicate own PS mode in transmitted frames - track neighbor STAs power modes - buffer frames when neighbors are in PS mode - add TIM and Awake Window IE to beacons - release frames in Mesh Peer Service Periods Add local_pm to sta_info to represent the link-specific power mode at this station towards the remote station. When a peer link is established, use the default power mode stored in mesh config. Update the PS status if the peering status of a neighbor changes. Maintain a mesh power mode for non-peer mesh STAs. Set the non-peer power mode to active mode during peering. Authenticated mesh peering is currently not working when either node is configured to be in power save mode. Indicate the current power mode in transmitted frames. Use QoS Nulls to indicate mesh power mode transitions. For performance reasons, calls to the function setting the frame flags are placed in HWMP routing routines, as there the STA pointer is already available. Add peer_pm to sta_info to represent the peer's link-specific power mode towards the local station. Add nonpeer_pm to represent the peer's power mode towards all non-peer stations. Track power modes based on received frames. Add the ps_data structure to ieee80211_if_mesh (for TIM map, PS neighbor counter and group-addressed frame buffer). Set WLAN_STA_PS flag for STA in PS mode to use the unicast frame buffering routines in the tx path. Update num_sta_ps to buffer and release group-addressed frames after DTIM beacons. Announce the awake window duration in beacons if in light or deep sleep mode towards any peer or non-peer. Create a TIM IE similarly to AP mode and add it to mesh beacons. Parse received Awake Window IEs and check TIM IEs for buffered frames. Release frames towards peers in mesh Peer Service Periods. Use the corresponding trigger frames and monitor the MPSP status. Append a QoS Null as trigger frame if neccessary to properly end the MPSP. Currently, in HT channels MPSPs behave imperfectly and show large delay spikes and frame losses. Signed-off-by: Marco Porsch <marco@cozybit.com> Signed-off-by: Ivan Bezyazychnyy <ivan.bezyazychnyy@gmail.com> Signed-off-by: Mike Krinkin <krinkin.m.u@gmail.com> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-28Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless Conflicts: drivers/net/wireless/ath/ath9k/main.c drivers/net/wireless/iwlwifi/dvm/tx.c
2013-01-16mac80211: add encrypt headroom to PERR framesBob Copeland
Mesh PERR action frames are robust and thus may be encrypted, so add proper head/tailroom to allow this. Fixes this warning when operating a Mesh STA on ath5k: WARNING: at net/mac80211/wpa.c:427 ccmp_encrypt_skb.isra.5+0x7b/0x1a0 [mac80211]() Call Trace: [<c011c5e7>] warn_slowpath_common+0x63/0x78 [<c011c60b>] warn_slowpath_null+0xf/0x13 [<e090621d>] ccmp_encrypt_skb.isra.5+0x7b/0x1a0 [mac80211] [<e090685c>] ieee80211_crypto_ccmp_encrypt+0x1f/0x37 [mac80211] [<e0917113>] invoke_tx_handlers+0xcad/0x10bd [mac80211] [<e0917665>] ieee80211_tx+0x87/0xb3 [mac80211] [<e0918932>] ieee80211_tx_pending+0xcc/0x170 [mac80211] [<c0121c43>] tasklet_action+0x3e/0x65 Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-16mac80211: set NEED_TXPROCESSING for PERR framesBob Copeland
A user reported warnings in ath5k due to transmitting frames with no rates set up. The frames were Mesh PERR frames, and some debugging showed an empty control block with just the vif pointer: > [ 562.522682] XXX txinfo: 00000000: 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 ................ > [ 562.522688] XXX txinfo: 00000010: 00 00 00 00 00 00 00 00 54 b8 f2 > db 00 00 00 00 ........T....... > [ 562.522693] XXX txinfo: 00000020: 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 ................ Set the IEEE80211_TX_INTFL_NEED_TXPROCESSING flag to ensure that rate control gets run before the frame is sent. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-01-04mac80211: fix mesh_hwmp kerneldocBob Copeland
One of the function names was wrong and some parameters were missing. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-08-20mac80211: clean up mpath_move_to_queue()Thomas Pedersen
Use skb_queue_walk_safe instead, and fix a few issues: - didn't free old skbs on moving - didn't react to failed skb alloc - needlessly held a local pointer to the destination frame queue - didn't check destination queue length before adding skb Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-10net: Fix (nearly-)kernel-doc comments for various functionsBen Hutchings
Fix incorrect start markers, wrapped summary lines, missing section breaks, incorrect separators, and some name mismatches. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-06-24mac80211: clean up debuggingJohannes Berg
There are a few things that make the logging and debugging in mac80211 less useful than it should be right now: * a lot of messages should be pr_info, not pr_debug * wholesale use of pr_debug makes it require *both* Kconfig and dynamic configuration * there are still a lot of ifdefs * the style is very inconsistent, sometimes the sdata->name is printed in front Clean up everything, introducing new macros and separating out the station MLME debugging into a new Kconfig symbol. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-18mac80211: fix and improve mesh RANN processingChun-Yeow Yeoh
This patch fixes the problem of dropping RANN element if the TTL is 1. If the received RANN element TTL is 1 or greater than 1, the RANN is processed. However, forwarding of received RANN element with TTL 1 or less is prohibited according to the standard. This is previously reported by Monthadar Al Jaberi. Besides, this patch also avoid the processing of unicast PREQ generation if the RANN element does not meet the acceptance criteria mentioned in Sec. 13.10.12.4.2 of IEEE Std. 802.11-2012. Reported-by: Monthadar Al Jaberi <monthadar@gmail.com> Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-18{nl,cfg,mac}80211: implement dot11MeshHWMPconfirmationIntervalChun-Yeow Yeoh
As defined in section 13.10.9.3 Case D (802.11-2012), this control variable is used to limit the mesh STA to send only one PREQ to a root mesh STA within this interval of time (in TUs). The default value for this variable is set to 2000 TUs. However, for current implementation, the maximum configurable of dot11MeshHWMPconfirmationInterval is restricted by dot11MeshHWMPactivePathTimeout. Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> [line-break commit log] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-18mac80211: implement the proactive PREP generationChun-Yeow Yeoh
Generate the proactive PREP element in Proactive PREQ mode as defined in Sec. 13.10.10.3 (Case D) of IEEE Std. 802.11-2012. Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-14mac80211: implement the proactive PREQ generationChun-Yeow Yeoh
Generate the proactive PREQ element as defined in Sec. 13.10.9.3 (Case C) of IEEE Std. 802.11-2012 based on the selection of dot11MeshHWMPRootMode as follow: dot11MeshHWMPRootMode (2) is proactivePREQnoPREP dot11MeshHWMPRootMode (3) is proactivePREQwithPREP The proactive PREQ is generated based on the interval defined by dot11MeshHWMProotInterval. With this change, proactive RANN element is now generated if the dot11MeshHWMPRootMode is set to (4) instead of (1). Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> [line-break commit log] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-09mac80211: Rename stainfo variable for the more common staJavier Cardona
Signed-off-by: Javier Cardona <javier@cozybit.com> Reviewed-by: Jason Abele <jason@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-09mac80211: Remove unused variableJavier Cardona
Signed-off-by: Javier Cardona <javier@cozybit.com> Reviewed-by: Jason Abele <jason@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-06-05net: mac80211: Convert printk(KERN_DEBUG to pr_debugJoe Perches
Standardize the debugging to be able to use dynamic_debug. Coalesce formats, align arguments. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-05-22Merge git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-nextJohn W. Linville
2012-05-15mac80211: fix the increment of unicast/multicast counters for forwarded PREQChun-Yeow Yeoh
Forwarded PREQ is either unicast or multicast. The appropriate counters should be incremented accordingly. Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-05-09mac80211: Convert compare_ether_addr to ether_addr_equalJoe Perches
Use the new bool function ether_addr_equal to add some clarity and reduce the likelihood for misuse of compare_ether_addr for sorting. Done via cocci script: $ cat compare_ether_addr.cocci @@ expression a,b; @@ - !compare_ether_addr(a, b) + ether_addr_equal(a, b) @@ expression a,b; @@ - compare_ether_addr(a, b) + !ether_addr_equal(a, b) @@ expression a,b; @@ - !ether_addr_equal(a, b) == 0 + ether_addr_equal(a, b) @@ expression a,b; @@ - !ether_addr_equal(a, b) != 0 + !ether_addr_equal(a, b) @@ expression a,b; @@ - ether_addr_equal(a, b) == 0 + !ether_addr_equal(a, b) @@ expression a,b; @@ - ether_addr_equal(a, b) != 0 + ether_addr_equal(a, b) @@ expression a,b; @@ - !!ether_addr_equal(a, b) + ether_addr_equal(a, b) Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-12mac80211: fix the assignment of PREQ's MAC address for Proactive RANNChun-Yeow Yeoh
Record the RANN sender's address only for RANNs that meet the acceptance criteria (per sections 13.10.12.4.2). Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Reviewed-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-04-09mac80211: fix the RANN propagation issuesChun-Yeow Yeoh
This patch is intended to solve the follwing issues in RANN propagation: [1] The interval in propagated RANN should be based on the interval of received RANN. [2] The aggregated path metric for propagated RANN is as received plus own link metric towards the transmitting mesh STA (not root mesh STA). [3] The comparison of path metric for RANN with same sequence number should be done before deciding whether to propagate or not. Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-04-09mac80211: fix the sparse warnings on endian handling in RANN propagationChun-Yeow Yeoh
The HWMP sequence number of received RANN element is compared to decide whether to be propagated. The sequence number is required to covert from 32bit little endian data into CPUs endianness for comparison. The same applies to the RANN metric. Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-03-06mac80211: fix mesh airtime link metric estimatingThomas Pedersen
Airtime link metric estimation was broken in HT mesh, use cfg80211_calculate_bitrate to get the right rate value. Also factor out tx rate copying from sta_set_sinfo(). Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-03-05mac80211: fix the support of setting non-forwarding entity in MeshChun-Yeow Yeoh
RANN, PREP and PERR propagation should happen only if the dot11MeshForwarding is true. Besides, data frame should not be forwarded if dot11MeshForwarding is false. This redundant checking is necessary to avoid the broadcasted ARP breaking the non-forwarding rule. Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-03-05mac80211: use compare_ether_addr on MAC addresses instead of memcmpFelix Fietkau
Because of the constant size and guaranteed 16 bit alignment, the inline compare_ether_addr function is much cheaper than calling memcmp. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-03-05mac80211: Fix the generation of PREQs in proactive RANN mechanism of HWMPChun-Yeow Yeoh
According to Section Y.7.4 Actions on receipt of proactive RANN, an individually addressed PREQ should be generated towards the neighbor peer mesh STA indicated in the RANN Sender Address field in the forwarding information. Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-27mac80211: clean up asm/unaligned.h inclusionJohannes Berg
Some files implicitly get this via mesh.h which itself doesn't need it, so move the inclusion into the right files. Some other files don't need it at all but include it, so remove it from there. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-01Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
2012-01-27{nl,cfg,mac}80211: Add support of setting non-forwarding entity in MeshChun-Yeow Yeoh
A mesh node that joins the mesh network is by default a forwarding entity. This patch allows the mesh node to set as non-forwarding entity. Whenever dot11MeshForwarding is set to 0, the mesh node can prevent itself from forwarding the traffic which is not destined to him. Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-01-18mac80211: Use the right headroom size for mesh mgmt framesJavier Cardona
Use local->tx_headroom instad of local->hw.extra_tx_headroom. local->tx_headroom is the max of hw.extra_tx_headroom required by the driver and the headroom required by mac80211 for status reporting. On drivers where hw.extra_tx_headroom is smaller than what mac80211 requires (e.g. ath5k), we would not reserve sufficient buffer space to report tx status. Also, don't reserve local->tx_headroom + local->hw.extra_tx_headroom. Reported-by: Simon Morgenthaler <s.morgenthaler@students.unibe.ch> Reported-by: Kai Scharwies <kai@scharwies.de> Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-11-28mac80211: don't initiate path discovery when forwarding frame with unknown DAThomas Pedersen
We used to initiate a path discovery when receiving a frame for which there is no forwarding information. To cut down on PREQ spam, just send a (gated) PERR in response. Also separate path discovery logic from nexthop querying. This patch means we no longer queue frames when forwarding, so kill the PERR TX stuff in discard_frame(). Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-11-28{nl,cfg,mac}80211: implement dot11MeshHWMPperrMinIntervalThomas Pedersen
As per 802.11mb 13.9.11.3 Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-11-28mac80211: fix switched HWMP frame addressesThomas Pedersen
HWMP originator and target addresses were switched on the air but also on reception, which is why path selection still worked. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-11-28mac80211: failed forwarded mesh frame addressingThomas Pedersen
Don't write the TA until next hop is actually known, since we might need the original TA for sending a PERR. Previously we would send a PERR to ourself if path resolution for a forwarded frame failed. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-11-21mac80211: minor cleanup to mesh state lockingJohannes Berg
First time I tried smatch, and it says: mesh_hwmp.c +870 mesh_queue_preq(21) error: double lock 'bottom_half:' mesh_hwmp.c +873 mesh_queue_preq(24) error: double unlock 'bottom_half:' mesh_hwmp.c +886 mesh_queue_preq(37) error: double unlock 'bottom_half:' Which is indeed true -- there's no point in disabling BHs again if we just did that a few lines earlier, so remove. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-11-17mac80211: memory leak in mesh_queue_preq()Dan Carpenter
We recently introduced a return here, but we need to call kfree first. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-11-09mac80211: simplify mesh frame queue mapping and QoSJavier Cardona
We only need to set the skb queue twice: 1. by the netdev, on local TX. 2. when forwarding a mesh frame. We only need to set the qos header twice: 1. by mac80211, on local TX. 2. when putting a frame on the mpath->frame_queue We also don't need the RA in order to set the proper queue mapping since all mesh STAs are QoS, indicate this and do it once when the frame is received. Also fixes an issue where the QoS header and queue mapping was not set for unicast forwarded frames. Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-11-09mac80211: Avoid filling up mesh preq queue with redundant requestsJavier Cardona
Don't accept redundant PREQs for a given destination. This fixes a problem under high load: kernel: [20386.250913] mesh_queue_preq: 235 callbacks suppressed kernel: [20386.253335] Mesh HWMP (mesh0): PREQ node queue full kernel: [20386.253352] Mesh HWMP (mesh0): PREQ node queue full (...) The 802.11s protocol has a provision to limit the rate of path requests (PREQs) are transmitted (dot11MeshHWMPpreqMinInterval) but there was no limit on the rate at which PREQs were being queued up. There is a valid reason for queuing PREQs: this way we can even out PREQ bursts. But queueing multiple PREQs for the same destination is useless. Reported-by: Pedro Larbig <pedro.larbig@carhs.de> Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-11-08mac80211: comment allocation of mesh framesThomas Pedersen
Remove most references to magic numbers, save a few bytes and hopefully improve readability. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-10-11mac80211: Fix regression that allowed mpaths between non-peers.Javier Cardona
Mesh paths should only exist over established peer links. Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-09-14mac80211: Mesh data frames must have the QoS headerJavier Cardona
Per sec 7.1.3.5 of draft 12.0 of 802.11s, mesh frames indicate the presence of the mesh control header in their QoS header. Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit (git 2.34.1) at 2024-05-28 13:10:18 +0000