<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/net/mac80211/mesh.c, branch linux-4.4.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.4.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.4.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-07-21T07:07:06+00:00</updated>
<entry>
<title>mac80211: mesh: fix RCU warning</title>
<updated>2019-07-21T07:07:06+00:00</updated>
<author>
<name>Thomas Pedersen</name>
<email>thomas@eero.com</email>
</author>
<published>2019-05-25T04:16:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4546109c30a7a93b8c198e011e2e545c377e363b'/>
<id>urn:sha1:4546109c30a7a93b8c198e011e2e545c377e363b</id>
<content type='text'>
[ Upstream commit 551842446ed695641a00782cd118cbb064a416a1 ]

ifmsh-&gt;csa is an RCU-protected pointer. The writer context
in ieee80211_mesh_finish_csa() is already mutually
exclusive with wdev-&gt;sdata.mtx, but the RCU checker did
not know this. Use rcu_dereference_protected() to avoid a
warning.

fixes the following warning:

[   12.519089] =============================
[   12.520042] WARNING: suspicious RCU usage
[   12.520652] 5.1.0-rc7-wt+ #16 Tainted: G        W
[   12.521409] -----------------------------
[   12.521972] net/mac80211/mesh.c:1223 suspicious rcu_dereference_check() usage!
[   12.522928] other info that might help us debug this:
[   12.523984] rcu_scheduler_active = 2, debug_locks = 1
[   12.524855] 5 locks held by kworker/u8:2/152:
[   12.525438]  #0: 00000000057be08c ((wq_completion)phy0){+.+.}, at: process_one_work+0x1a2/0x620
[   12.526607]  #1: 0000000059c6b07a ((work_completion)(&amp;sdata-&gt;csa_finalize_work)){+.+.}, at: process_one_work+0x1a2/0x620
[   12.528001]  #2: 00000000f184ba7d (&amp;wdev-&gt;mtx){+.+.}, at: ieee80211_csa_finalize_work+0x2f/0x90
[   12.529116]  #3: 00000000831a1f54 (&amp;local-&gt;mtx){+.+.}, at: ieee80211_csa_finalize_work+0x47/0x90
[   12.530233]  #4: 00000000fd06f988 (&amp;local-&gt;chanctx_mtx){+.+.}, at: ieee80211_csa_finalize_work+0x51/0x90

Signed-off-by: Thomas Pedersen &lt;thomas@eero.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mac80211: Fix addition of mesh configuration element</title>
<updated>2017-12-20T09:04:52+00:00</updated>
<author>
<name>Ilan peer</name>
<email>ilan.peer@intel.com</email>
</author>
<published>2016-12-26T16:17:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=75252bfe9e493a314d62e820aea07a6c48dea833'/>
<id>urn:sha1:75252bfe9e493a314d62e820aea07a6c48dea833</id>
<content type='text'>
commit 57629915d568c522ac1422df7bba4bee5b5c7a7c upstream.

The code was setting the capabilities byte to zero,
after it was already properly set previously. Fix it.

The bug was found while debugging hwsim mesh tests failures
that happened since the commit mentioned below.

Fixes: 76f43b4c0a93 ("mac80211: Remove invalid flag operations in mesh TSF synchronization")
Signed-off-by: Ilan Peer &lt;ilan.peer@intel.com&gt;
Reviewed-by: Masashi Honma &lt;masashi.honma@gmail.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Cc: Richard Schütz &lt;rschuetz@uni-koblenz.de&gt;
Cc: Mathias Kretschmer &lt;mathias.kretschmer@fit.fraunhofer.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mac80211: Remove invalid flag operations in mesh TSF synchronization</title>
<updated>2017-11-30T08:37:27+00:00</updated>
<author>
<name>Masashi Honma</name>
<email>masashi.honma@gmail.com</email>
</author>
<published>2016-12-08T01:15:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9825826ed7bd7ab22e835b88508f00057b2848c0'/>
<id>urn:sha1:9825826ed7bd7ab22e835b88508f00057b2848c0</id>
<content type='text'>
[ Upstream commit 76f43b4c0a9337af22827d78de4f2b8fd5328489 ]

mesh_sync_offset_adjust_tbtt() implements Extensible synchronization
framework ([1] 13.13.2 Extensible synchronization framework). It shall
not operate the flag "TBTT Adjusting subfield" ([1] 8.4.2.100.8 Mesh
Capability), since it is used only for MBCA ([1] 13.13.4 Mesh beacon
collision avoidance, see 13.13.4.4.3 TBTT scanning and adjustment
procedures for detail). So this patch remove the flag operations.

[1] IEEE Std 802.11 2012

Signed-off-by: Masashi Honma &lt;masashi.honma@gmail.com&gt;
[remove adjusting_tbtt entirely, since it's now unused]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;

Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mac80211: Fix adding of mesh vendor IEs</title>
<updated>2017-02-14T23:22:51+00:00</updated>
<author>
<name>Thorsten Horstmann</name>
<email>thorsten@defutech.de</email>
</author>
<published>2017-02-03T13:38:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b9c29d45f980260b387749c7029453b9ee16b07f'/>
<id>urn:sha1:b9c29d45f980260b387749c7029453b9ee16b07f</id>
<content type='text'>
commit da7061c82e4a1bc6a5e134ef362c86261906c860 upstream.

The function ieee80211_ie_split_vendor doesn't return 0 on errors. Instead
it returns any offset &lt; ielen when WLAN_EID_VENDOR_SPECIFIC is found. The
return value in mesh_add_vendor_ies must therefore be checked against
ifmsh-&gt;ie_len and not 0. Otherwise all ifmsh-&gt;ie starting with
WLAN_EID_VENDOR_SPECIFIC will be rejected.

Fixes: 082ebb0c258d ("mac80211: fix mesh beacon format")
Signed-off-by: Thorsten Horstmann &lt;thorsten@defutech.de&gt;
Signed-off-by: Mathias Kretschmer &lt;mathias.kretschmer@fit.fraunhofer.de&gt;
Signed-off-by: Simon Wunderlich &lt;sw@simonwunderlich.de&gt;
[sven@narfation.org: Add commit message]
Signed-off-by: Sven Eckelmann &lt;sven@narfation.org&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mac80211: Fix mesh estab_plinks counting in STA removal case</title>
<updated>2016-07-27T16:47:27+00:00</updated>
<author>
<name>Jouni Malinen</name>
<email>j@w1.fi</email>
</author>
<published>2016-06-19T20:51:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=96d50acbd447f536b39cc3c2964a6231aeb6bb6f'/>
<id>urn:sha1:96d50acbd447f536b39cc3c2964a6231aeb6bb6f</id>
<content type='text'>
commit 126e7557328a1cd576be4fca95b133a2695283ff upstream.

If a user space program (e.g., wpa_supplicant) deletes a STA entry that
is currently in NL80211_PLINK_ESTAB state, the number of established
plinks counter was not decremented and this could result in rejecting
new plink establishment before really hitting the real maximum plink
limit. For !user_mpm case, this decrementation is handled by
mesh_plink_deactive().

Fix this by decrementing estab_plinks on STA deletion
(mesh_sta_cleanup() gets called from there) so that the counter has a
correct value and the Beacon frame advertisement in Mesh Configuration
element shows the proper value for capability to accept additional
peers.

Signed-off-by: Jouni Malinen &lt;j@w1.fi&gt;
Signed-off-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mac80211: mesh: flush mesh paths unconditionally</title>
<updated>2016-07-27T16:47:27+00:00</updated>
<author>
<name>Bob Copeland</name>
<email>me@bobcopeland.com</email>
</author>
<published>2016-05-15T17:19:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7b90e041d140f785fb2fb06e467ff152c9210082'/>
<id>urn:sha1:7b90e041d140f785fb2fb06e467ff152c9210082</id>
<content type='text'>
commit fe7a7c57629e8dcbc0e297363a9b2366d67a6dc5 upstream.

Currently, the mesh paths associated with a nexthop station are cleaned
up in the following code path:

    __sta_info_destroy_part1
    synchronize_net()
    __sta_info_destroy_part2
     -&gt; cleanup_single_sta
       -&gt; mesh_sta_cleanup
         -&gt; mesh_plink_deactivate
           -&gt; mesh_path_flush_by_nexthop

However, there are a couple of problems here:

1) the paths aren't flushed at all if the MPM is running in userspace
   (e.g. when using wpa_supplicant or authsae)

2) there is no synchronize_rcu between removing the path and readers
   accessing the nexthop, which means the following race is possible:

CPU0                            CPU1
~~~~                            ~~~~
                                sta_info_destroy_part1()
                                synchronize_net()
rcu_read_lock()
mesh_nexthop_resolve()
  mpath = mesh_path_lookup()
                                [...] -&gt; mesh_path_flush_by_nexthop()
  sta = rcu_dereference(
    mpath-&gt;next_hop)
                                kfree(sta)
  access sta &lt;-- CRASH

Fix both of these by unconditionally flushing paths before destroying
the sta, and by adding a synchronize_net() after path flush to ensure
no active readers can still dereference the sta.

Fixes this crash:

[  348.529295] BUG: unable to handle kernel paging request at 00020040
[  348.530014] IP: [&lt;f929245d&gt;] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211]
[  348.530014] *pde = 00000000
[  348.530014] Oops: 0000 [#1] PREEMPT
[  348.530014] Modules linked in: drbg ansi_cprng ctr ccm ppp_generic slhc ipt_MASQUERADE nf_nat_masquerade_ipv4 8021q ]
[  348.530014] CPU: 0 PID: 20597 Comm: wget Tainted: G           O 4.6.0-rc5-wt=V1 #1
[  348.530014] Hardware name: To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080016  11/07/2014
[  348.530014] task: f64fa280 ti: f4f9c000 task.ti: f4f9c000
[  348.530014] EIP: 0060:[&lt;f929245d&gt;] EFLAGS: 00010246 CPU: 0
[  348.530014] EIP is at ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211]
[  348.530014] EAX: f4ce63e0 EBX: 00000088 ECX: f3788416 EDX: 00020008
[  348.530014] ESI: 00000000 EDI: 00000088 EBP: f6409a4c ESP: f6409a40
[  348.530014]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[  348.530014] CR0: 80050033 CR2: 00020040 CR3: 33190000 CR4: 00000690
[  348.530014] Stack:
[  348.530014]  00000000 f4ce63e0 f5f9bd80 f6409a64 f9291d80 0000ce67 f5d51e00 f4ce63e0
[  348.530014]  f3788416 f6409a80 f9291dc1 f4ce8320 f4ce63e0 f5d51e00 f4ce63e0 f4ce8320
[  348.530014]  f6409a98 f9277f6f 00000000 00000000 0000007c 00000000 f6409b2c f9278dd1
[  348.530014] Call Trace:
[  348.530014]  [&lt;f9291d80&gt;] mesh_nexthop_lookup+0xbb/0xc8 [mac80211]
[  348.530014]  [&lt;f9291dc1&gt;] mesh_nexthop_resolve+0x34/0xd8 [mac80211]
[  348.530014]  [&lt;f9277f6f&gt;] ieee80211_xmit+0x92/0xc1 [mac80211]
[  348.530014]  [&lt;f9278dd1&gt;] __ieee80211_subif_start_xmit+0x807/0x83c [mac80211]
[  348.530014]  [&lt;c04df012&gt;] ? sch_direct_xmit+0xd7/0x1b3
[  348.530014]  [&lt;c022a8c6&gt;] ? __local_bh_enable_ip+0x5d/0x7b
[  348.530014]  [&lt;f956870c&gt;] ? nf_nat_ipv4_out+0x4c/0xd0 [nf_nat_ipv4]
[  348.530014]  [&lt;f957e036&gt;] ? iptable_nat_ipv4_fn+0xf/0xf [iptable_nat]
[  348.530014]  [&lt;c04c6f45&gt;] ? netif_skb_features+0x14d/0x30a
[  348.530014]  [&lt;f9278e10&gt;] ieee80211_subif_start_xmit+0xa/0xe [mac80211]
[  348.530014]  [&lt;c04c769c&gt;] dev_hard_start_xmit+0x1f8/0x267
[  348.530014]  [&lt;c04c7261&gt;] ?  validate_xmit_skb.isra.120.part.121+0x10/0x253
[  348.530014]  [&lt;c04defc6&gt;] sch_direct_xmit+0x8b/0x1b3
[  348.530014]  [&lt;c04c7a9c&gt;] __dev_queue_xmit+0x2c8/0x513
[  348.530014]  [&lt;c04c7cfb&gt;] dev_queue_xmit+0xa/0xc
[  348.530014]  [&lt;f91bfc7a&gt;] batadv_send_skb_packet+0xd6/0xec [batman_adv]
[  348.530014]  [&lt;f91bfdc4&gt;] batadv_send_unicast_skb+0x15/0x4a [batman_adv]
[  348.530014]  [&lt;f91b5938&gt;] batadv_dat_send_data+0x27e/0x310 [batman_adv]
[  348.530014]  [&lt;f91c30b5&gt;] ? batadv_tt_global_hash_find.isra.11+0x8/0xa [batman_adv]
[  348.530014]  [&lt;f91b63f3&gt;] batadv_dat_snoop_outgoing_arp_request+0x208/0x23d [batman_adv]
[  348.530014]  [&lt;f91c0cd9&gt;] batadv_interface_tx+0x206/0x385 [batman_adv]
[  348.530014]  [&lt;c04c769c&gt;] dev_hard_start_xmit+0x1f8/0x267
[  348.530014]  [&lt;c04c7261&gt;] ?  validate_xmit_skb.isra.120.part.121+0x10/0x253
[  348.530014]  [&lt;c04defc6&gt;] sch_direct_xmit+0x8b/0x1b3
[  348.530014]  [&lt;c04c7a9c&gt;] __dev_queue_xmit+0x2c8/0x513
[  348.530014]  [&lt;f80cbd2a&gt;] ? igb_xmit_frame+0x57/0x72 [igb]
[  348.530014]  [&lt;c04c7cfb&gt;] dev_queue_xmit+0xa/0xc
[  348.530014]  [&lt;f843a326&gt;] br_dev_queue_push_xmit+0xeb/0xfb [bridge]
[  348.530014]  [&lt;f843a35f&gt;] br_forward_finish+0x29/0x74 [bridge]
[  348.530014]  [&lt;f843a23b&gt;] ? deliver_clone+0x3b/0x3b [bridge]
[  348.530014]  [&lt;f843a714&gt;] __br_forward+0x89/0xe7 [bridge]
[  348.530014]  [&lt;f843a336&gt;] ? br_dev_queue_push_xmit+0xfb/0xfb [bridge]
[  348.530014]  [&lt;f843a234&gt;] deliver_clone+0x34/0x3b [bridge]
[  348.530014]  [&lt;f843a68b&gt;] ? br_flood+0x95/0x95 [bridge]
[  348.530014]  [&lt;f843a66d&gt;] br_flood+0x77/0x95 [bridge]
[  348.530014]  [&lt;f843a809&gt;] br_flood_forward+0x13/0x1a [bridge]
[  348.530014]  [&lt;f843a68b&gt;] ? br_flood+0x95/0x95 [bridge]
[  348.530014]  [&lt;f843b877&gt;] br_handle_frame_finish+0x392/0x3db [bridge]
[  348.530014]  [&lt;c04e9b2b&gt;] ? nf_iterate+0x2b/0x6b
[  348.530014]  [&lt;f843baa6&gt;] br_handle_frame+0x1e6/0x240 [bridge]
[  348.530014]  [&lt;f843b4e5&gt;] ? br_handle_local_finish+0x6a/0x6a [bridge]
[  348.530014]  [&lt;c04c4ba0&gt;] __netif_receive_skb_core+0x43a/0x66b
[  348.530014]  [&lt;f843b8c0&gt;] ? br_handle_frame_finish+0x3db/0x3db [bridge]
[  348.530014]  [&lt;c023cea4&gt;] ? resched_curr+0x19/0x37
[  348.530014]  [&lt;c0240707&gt;] ? check_preempt_wakeup+0xbf/0xfe
[  348.530014]  [&lt;c0255dec&gt;] ? ktime_get_with_offset+0x5c/0xfc
[  348.530014]  [&lt;c04c4fc1&gt;] __netif_receive_skb+0x47/0x55
[  348.530014]  [&lt;c04c57ba&gt;] netif_receive_skb_internal+0x40/0x5a
[  348.530014]  [&lt;c04c61ef&gt;] napi_gro_receive+0x3a/0x94
[  348.530014]  [&lt;f80ce8d5&gt;] igb_poll+0x6fd/0x9ad [igb]
[  348.530014]  [&lt;c0242bd8&gt;] ? swake_up_locked+0x14/0x26
[  348.530014]  [&lt;c04c5d29&gt;] net_rx_action+0xde/0x250
[  348.530014]  [&lt;c022a743&gt;] __do_softirq+0x8a/0x163
[  348.530014]  [&lt;c022a6b9&gt;] ? __hrtimer_tasklet_trampoline+0x19/0x19
[  348.530014]  [&lt;c021100f&gt;] do_softirq_own_stack+0x26/0x2c
[  348.530014]  &lt;IRQ&gt;
[  348.530014]  [&lt;c022a957&gt;] irq_exit+0x31/0x6f
[  348.530014]  [&lt;c0210eb2&gt;] do_IRQ+0x8d/0xa0
[  348.530014]  [&lt;c058152c&gt;] common_interrupt+0x2c/0x40
[  348.530014] Code: e7 8c 00 66 81 ff 88 00 75 12 85 d2 75 0e b2 c3 b8 83 e9 29 f9 e8 a7 5f f9 c6 eb 74 66 81 e3 8c 005
[  348.530014] EIP: [&lt;f929245d&gt;] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] SS:ESP 0068:f6409a40
[  348.530014] CR2: 0000000000020040
[  348.530014] ---[ end trace 48556ac26779732e ]---
[  348.530014] Kernel panic - not syncing: Fatal exception in interrupt
[  348.530014] Kernel Offset: disabled

Reported-by: Fred Veldini &lt;fred.veldini@gmail.com&gt;
Tested-by: Fred Veldini &lt;fred.veldini@gmail.com&gt;
Signed-off-by: Bob Copeland &lt;me@bobcopeland.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mac80211: Requeue work after scan complete for all VIF types.</title>
<updated>2016-03-03T23:07:26+00:00</updated>
<author>
<name>Sachin Kulkarni</name>
<email>Sachin.Kulkarni@imgtec.com</email>
</author>
<published>2016-01-12T09:00:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=81bb655358726b0abf888c54d33135dae3a07c12'/>
<id>urn:sha1:81bb655358726b0abf888c54d33135dae3a07c12</id>
<content type='text'>
commit 4fa11ec726a32ea6dd768dbb2e2af3453a98ec0a upstream.

During a sw scan ieee80211_iface_work ignores work items for all vifs.
However after the scan complete work is requeued only for STA, ADHOC
and MESH iftypes.

This occasionally results in event processing getting delayed/not
processed for iftype AP when it coexists with a STA. This can result
in data halt and eventually disconnection on the AP interface.

Signed-off-by: Sachin Kulkarni &lt;Sachin.Kulkarni@imgtec.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mac80211: TDLS: add proper HT-oper IE</title>
<updated>2015-11-03T09:42:47+00:00</updated>
<author>
<name>Arik Nemtsov</name>
<email>arik@wizery.com</email>
</author>
<published>2015-10-25T08:59:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=57f255f58165974c131f048b4302728052d92d29'/>
<id>urn:sha1:57f255f58165974c131f048b4302728052d92d29</id>
<content type='text'>
When 11n peers performs a TDLS connection on a legacy BSS, the HT
operation IE must be specified according to IEEE802.11-2012 section
9.23.3.2. Otherwise HT-protection is compromised and the medium becomes
noisy for both the TDLS and the BSS links.

Signed-off-by: Arik Nemtsov &lt;arikx.nemtsov@intel.com&gt;
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: make ieee80211_new_mesh_header return unsigned</title>
<updated>2015-10-05T15:54:16+00:00</updated>
<author>
<name>Andrzej Hajda</name>
<email>a.hajda@samsung.com</email>
</author>
<published>2015-09-25T06:42:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5edfcee5ed73eb9537987c4ddb6bf062b6943b73'/>
<id>urn:sha1:5edfcee5ed73eb9537987c4ddb6bf062b6943b73</id>
<content type='text'>
The function returns always non-negative values.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2046107

Signed-off-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: implement VHT support for mesh</title>
<updated>2015-09-22T13:21:25+00:00</updated>
<author>
<name>Bob Copeland</name>
<email>me@bobcopeland.com</email>
</author>
<published>2015-08-27T13:00:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c85fb53c4fa6521352028c40ce096a808aabd389'/>
<id>urn:sha1:c85fb53c4fa6521352028c40ce096a808aabd389</id>
<content type='text'>
Implement the basics required for supporting very high throughput
with mesh: include VHT information elements in beacons, probe
responses, and peering action frames, and check for compatible VHT
configurations when peering.

Signed-off-by: Bob Copeland &lt;me@bobcopeland.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
</feed>
