<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/wireless/util.c, branch v4.4.271</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>cfg80211: mitigate A-MSDU aggregation attacks</title>
<updated>2021-06-03T06:22:05+00:00</updated>
<author>
<name>Mathy Vanhoef</name>
<email>Mathy.Vanhoef@kuleuven.be</email>
</author>
<published>2021-05-31T20:28:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=daea7ff51861cec93ff7f561095d9048b673b51f'/>
<id>daea7ff51861cec93ff7f561095d9048b673b51f</id>
<content type='text'>
commit 2b8a1fee3488c602aca8bea004a087e60806a5cf upstream.

Mitigate A-MSDU injection attacks (CVE-2020-24588) by detecting if the
destination address of a subframe equals an RFC1042 (i.e., LLC/SNAP)
header, and if so dropping the complete A-MSDU frame. This mitigates
known attacks, although new (unknown) aggregation-based attacks may
remain possible.

This defense works because in A-MSDU aggregation injection attacks, a
normal encrypted Wi-Fi frame is turned into an A-MSDU frame. This means
the first 6 bytes of the first A-MSDU subframe correspond to an RFC1042
header. In other words, the destination MAC address of the first A-MSDU
subframe contains the start of an RFC1042 header during an aggregation
attack. We can detect this and thereby prevent this specific attack.
For details, see Section 7.2 of "Fragment and Forge: Breaking Wi-Fi
Through Frame Aggregation and Fragmentation".

Note that for kernel 4.9 and above this patch depends on "mac80211:
properly handle A-MSDUs that start with a rfc1042 header". Otherwise
this patch has no impact and attacks will remain possible.

Cc: stable@vger.kernel.org
Signed-off-by: Mathy Vanhoef &lt;Mathy.Vanhoef@kuleuven.be&gt;
Link: https://lore.kernel.org/r/20210511200110.25d93176ddaf.I9e265b597f2cd23eb44573f35b625947b386a9de@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2b8a1fee3488c602aca8bea004a087e60806a5cf upstream.

Mitigate A-MSDU injection attacks (CVE-2020-24588) by detecting if the
destination address of a subframe equals an RFC1042 (i.e., LLC/SNAP)
header, and if so dropping the complete A-MSDU frame. This mitigates
known attacks, although new (unknown) aggregation-based attacks may
remain possible.

This defense works because in A-MSDU aggregation injection attacks, a
normal encrypted Wi-Fi frame is turned into an A-MSDU frame. This means
the first 6 bytes of the first A-MSDU subframe correspond to an RFC1042
header. In other words, the destination MAC address of the first A-MSDU
subframe contains the start of an RFC1042 header during an aggregation
attack. We can detect this and thereby prevent this specific attack.
For details, see Section 7.2 of "Fragment and Forge: Breaking Wi-Fi
Through Frame Aggregation and Fragmentation".

Note that for kernel 4.9 and above this patch depends on "mac80211:
properly handle A-MSDUs that start with a rfc1042 header". Otherwise
this patch has no impact and attacks will remain possible.

Cc: stable@vger.kernel.org
Signed-off-by: Mathy Vanhoef &lt;Mathy.Vanhoef@kuleuven.be&gt;
Link: https://lore.kernel.org/r/20210511200110.25d93176ddaf.I9e265b597f2cd23eb44573f35b625947b386a9de@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: properly handle A-MSDUs that start with an RFC 1042 header</title>
<updated>2021-06-03T06:22:05+00:00</updated>
<author>
<name>Mathy Vanhoef</name>
<email>Mathy.Vanhoef@kuleuven.be</email>
</author>
<published>2021-05-31T20:28:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e76511a6fbb5e568a2db4da8da5a120481c914fe'/>
<id>e76511a6fbb5e568a2db4da8da5a120481c914fe</id>
<content type='text'>
commit a1d5ff5651ea592c67054233b14b30bf4452999c upstream.

Properly parse A-MSDUs whose first 6 bytes happen to equal a rfc1042
header. This can occur in practice when the destination MAC address
equals AA:AA:03:00:00:00. More importantly, this simplifies the next
patch to mitigate A-MSDU injection attacks.

Cc: stable@vger.kernel.org
Signed-off-by: Mathy Vanhoef &lt;Mathy.Vanhoef@kuleuven.be&gt;
Link: https://lore.kernel.org/r/20210511200110.0b2b886492f0.I23dd5d685fe16d3b0ec8106e8f01b59f499dffed@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a1d5ff5651ea592c67054233b14b30bf4452999c upstream.

Properly parse A-MSDUs whose first 6 bytes happen to equal a rfc1042
header. This can occur in practice when the destination MAC address
equals AA:AA:03:00:00:00. More importantly, this simplifies the next
patch to mitigate A-MSDU injection attacks.

Cc: stable@vger.kernel.org
Signed-off-by: Mathy Vanhoef &lt;Mathy.Vanhoef@kuleuven.be&gt;
Link: https://lore.kernel.org/r/20210511200110.0b2b886492f0.I23dd5d685fe16d3b0ec8106e8f01b59f499dffed@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211/mac80211: make ieee80211_send_layer2_update a public function</title>
<updated>2020-01-23T07:18:35+00:00</updated>
<author>
<name>Dedy Lansky</name>
<email>dlansky@codeaurora.org</email>
</author>
<published>2018-07-29T11:59:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9d9805179c7c195a9468a31d93974d1cf1800ae9'/>
<id>9d9805179c7c195a9468a31d93974d1cf1800ae9</id>
<content type='text'>
commit 30ca1aa536211f5ac3de0173513a7a99a98a97f3 upstream.

Make ieee80211_send_layer2_update() a common function so other drivers
can re-use it.

Signed-off-by: Dedy Lansky &lt;dlansky@codeaurora.org&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
[bwh: Backported to 4.4 as dependency of commit 3e493173b784
 "mac80211: Do not send Layer 2 Update frame before authorization":
 - Retain type-casting of skb_put() return value
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 30ca1aa536211f5ac3de0173513a7a99a98a97f3 upstream.

Make ieee80211_send_layer2_update() a common function so other drivers
can re-use it.

Signed-off-by: Dedy Lansky &lt;dlansky@codeaurora.org&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
[bwh: Backported to 4.4 as dependency of commit 3e493173b784
 "mac80211: Do not send Layer 2 Update frame before authorization":
 - Retain type-casting of skb_put() return value
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: Purge frame registrations on iftype change</title>
<updated>2019-10-05T10:27:54+00:00</updated>
<author>
<name>Denis Kenzior</name>
<email>denkenz@gmail.com</email>
</author>
<published>2019-08-28T21:11:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b85938f66b6ef4680a06e3229c10f5d6353f53d9'/>
<id>b85938f66b6ef4680a06e3229c10f5d6353f53d9</id>
<content type='text'>
commit c1d3ad84eae35414b6b334790048406bd6301b12 upstream.

Currently frame registrations are not purged, even when changing the
interface type.  This can lead to potentially weird situations where
frames possibly not allowed on a given interface type remain registered
due to the type switching happening after registration.

The kernel currently relies on userspace apps to actually purge the
registrations themselves, this is not something that the kernel should
rely on.

Add a call to cfg80211_mlme_purge_registrations() to forcefully remove
any registrations left over prior to switching the iftype.

Cc: stable@vger.kernel.org
Signed-off-by: Denis Kenzior &lt;denkenz@gmail.com&gt;
Link: https://lore.kernel.org/r/20190828211110.15005-1-denkenz@gmail.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c1d3ad84eae35414b6b334790048406bd6301b12 upstream.

Currently frame registrations are not purged, even when changing the
interface type.  This can lead to potentially weird situations where
frames possibly not allowed on a given interface type remain registered
due to the type switching happening after registration.

The kernel currently relies on userspace apps to actually purge the
registrations themselves, this is not something that the kernel should
rely on.

Add a call to cfg80211_mlme_purge_registrations() to forcefully remove
any registrations left over prior to switching the iftype.

Cc: stable@vger.kernel.org
Signed-off-by: Denis Kenzior &lt;denkenz@gmail.com&gt;
Link: https://lore.kernel.org/r/20190828211110.15005-1-denkenz@gmail.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: fix a type issue in ieee80211_chandef_to_operating_class()</title>
<updated>2018-10-10T06:52:11+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2018-08-31T08:10:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2c81860b8ebd47ab1a4b3f719874937acf1a2e24'/>
<id>2c81860b8ebd47ab1a4b3f719874937acf1a2e24</id>
<content type='text'>
[ Upstream commit 8442938c3a2177ba16043b3a935f2c78266ad399 ]

The "chandef-&gt;center_freq1" variable is a u32 but "freq" is a u16 so we
are truncating away the high bits.  I noticed this bug because in commit
9cf0a0b4b64a ("cfg80211: Add support for 60GHz band channels 5 and 6")
we made "freq &lt;= 56160 + 2160 * 6" a valid requency when before it was
only "freq &lt;= 56160 + 2160 * 4" that was valid.  It introduces a static
checker warning:

    net/wireless/util.c:1571 ieee80211_chandef_to_operating_class()
    warn: always true condition '(freq &lt;= 56160 + 2160 * 6) =&gt; (0-u16max &lt;= 69120)'

But really we probably shouldn't have been truncating the high bits
away to begin with.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 8442938c3a2177ba16043b3a935f2c78266ad399 ]

The "chandef-&gt;center_freq1" variable is a u32 but "freq" is a u16 so we
are truncating away the high bits.  I noticed this bug because in commit
9cf0a0b4b64a ("cfg80211: Add support for 60GHz band channels 5 and 6")
we made "freq &lt;= 56160 + 2160 * 6" a valid requency when before it was
only "freq &lt;= 56160 + 2160 * 4" that was valid.  It introduces a static
checker warning:

    net/wireless/util.c:1571 ieee80211_chandef_to_operating_class()
    warn: always true condition '(freq &lt;= 56160 + 2160 * 6) =&gt; (0-u16max &lt;= 69120)'

But really we probably shouldn't have been truncating the high bits
away to begin with.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: ignore netif running state when changing iftype</title>
<updated>2015-05-29T11:05:40+00:00</updated>
<author>
<name>Michal Kazior</name>
<email>michal.kazior@tieto.com</email>
</author>
<published>2015-05-22T08:57:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6cbfb1bb66e4e85da5db78e8ff429a85bd84ce64'/>
<id>6cbfb1bb66e4e85da5db78e8ff429a85bd84ce64</id>
<content type='text'>
It was possible for mac80211 to be coerced into an
unexpected flow causing sdata union to become
corrupted. Station pointer was put into
sdata-&gt;u.vlan.sta memory location while it was
really master AP's sdata-&gt;u.ap.next_beacon. This
led to station entry being later freed as
next_beacon before __sta_info_flush() in
ieee80211_stop_ap() and a subsequent invalid
pointer dereference crash.

The problem was that ieee80211_ptr-&gt;use_4addr
wasn't cleared on interface type changes.

This could be reproduced with the following steps:

 # host A and host B have just booted; no
 # wpa_s/hostapd running; all vifs are down
 host A&gt; iw wlan0 set type station
 host A&gt; iw wlan0 set 4addr on
 host A&gt; printf 'interface=wlan0\nssid=4addrcrash\nchannel=1\nwds_sta=1' &gt; /tmp/hconf
 host A&gt; hostapd -B /tmp/conf
 host B&gt; iw wlan0 set 4addr on
 host B&gt; ifconfig wlan0 up
 host B&gt; iw wlan0 connect -w hostAssid
 host A&gt; pkill hostapd
 # host A crashed:

 [  127.928192] BUG: unable to handle kernel NULL pointer dereference at 00000000000006c8
 [  127.929014] IP: [&lt;ffffffff816f4f32&gt;] __sta_info_flush+0xac/0x158
 ...
 [  127.934578]  [&lt;ffffffff8170789e&gt;] ieee80211_stop_ap+0x139/0x26c
 [  127.934578]  [&lt;ffffffff8100498f&gt;] ? dump_trace+0x279/0x28a
 [  127.934578]  [&lt;ffffffff816dc661&gt;] __cfg80211_stop_ap+0x84/0x191
 [  127.934578]  [&lt;ffffffff816dc7ad&gt;] cfg80211_stop_ap+0x3f/0x58
 [  127.934578]  [&lt;ffffffff816c5ad6&gt;] nl80211_stop_ap+0x1b/0x1d
 [  127.934578]  [&lt;ffffffff815e53f8&gt;] genl_family_rcv_msg+0x259/0x2b5

Note: This isn't a revert of f8cdddb8d61d
("cfg80211: check iface combinations only when
iface is running") as far as functionality is
considered because b6a550156bc ("cfg80211/mac80211:
move more combination checks to mac80211") moved
the logic somewhere else already.

Fixes: f8cdddb8d61d ("cfg80211: check iface combinations only when iface is running")
Signed-off-by: Michal Kazior &lt;michal.kazior@tieto.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It was possible for mac80211 to be coerced into an
unexpected flow causing sdata union to become
corrupted. Station pointer was put into
sdata-&gt;u.vlan.sta memory location while it was
really master AP's sdata-&gt;u.ap.next_beacon. This
led to station entry being later freed as
next_beacon before __sta_info_flush() in
ieee80211_stop_ap() and a subsequent invalid
pointer dereference crash.

The problem was that ieee80211_ptr-&gt;use_4addr
wasn't cleared on interface type changes.

This could be reproduced with the following steps:

 # host A and host B have just booted; no
 # wpa_s/hostapd running; all vifs are down
 host A&gt; iw wlan0 set type station
 host A&gt; iw wlan0 set 4addr on
 host A&gt; printf 'interface=wlan0\nssid=4addrcrash\nchannel=1\nwds_sta=1' &gt; /tmp/hconf
 host A&gt; hostapd -B /tmp/conf
 host B&gt; iw wlan0 set 4addr on
 host B&gt; ifconfig wlan0 up
 host B&gt; iw wlan0 connect -w hostAssid
 host A&gt; pkill hostapd
 # host A crashed:

 [  127.928192] BUG: unable to handle kernel NULL pointer dereference at 00000000000006c8
 [  127.929014] IP: [&lt;ffffffff816f4f32&gt;] __sta_info_flush+0xac/0x158
 ...
 [  127.934578]  [&lt;ffffffff8170789e&gt;] ieee80211_stop_ap+0x139/0x26c
 [  127.934578]  [&lt;ffffffff8100498f&gt;] ? dump_trace+0x279/0x28a
 [  127.934578]  [&lt;ffffffff816dc661&gt;] __cfg80211_stop_ap+0x84/0x191
 [  127.934578]  [&lt;ffffffff816dc7ad&gt;] cfg80211_stop_ap+0x3f/0x58
 [  127.934578]  [&lt;ffffffff816c5ad6&gt;] nl80211_stop_ap+0x1b/0x1d
 [  127.934578]  [&lt;ffffffff815e53f8&gt;] genl_family_rcv_msg+0x259/0x2b5

Note: This isn't a revert of f8cdddb8d61d
("cfg80211: check iface combinations only when
iface is running") as far as functionality is
considered because b6a550156bc ("cfg80211/mac80211:
move more combination checks to mac80211") moved
the logic somewhere else already.

Fixes: f8cdddb8d61d ("cfg80211: check iface combinations only when iface is running")
Signed-off-by: Michal Kazior &lt;michal.kazior@tieto.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: properly send NL80211_ATTR_DISCONNECTED_BY_AP in disconnect</title>
<updated>2015-05-26T13:21:27+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-05-22T14:22:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=80279fb7ba5b71981a60988b0307afa43f78f6b1'/>
<id>80279fb7ba5b71981a60988b0307afa43f78f6b1</id>
<content type='text'>
When we disconnect from the AP, drivers call cfg80211_disconnect().
This doesn't know whether the disconnection was initiated locally
or by the AP though, which can cause problems with the supplicant,
for example with WPS. This issue obviously doesn't show up with any
mac80211 based driver since mac80211 doesn't call this function.

Fix this by requiring drivers to indicate whether the disconnect is
locally generated or not. I've tried to update the drivers, but may
not have gotten the values correct, and some drivers may currently
not be able to report correct values. In case of doubt I left it at
false, which is the current behaviour.

For libertas, make adjustments as indicated by Dan Williams.

Reported-by: Matthieu Mauger &lt;matthieux.mauger@intel.com&gt;
Tested-by: Matthieu Mauger &lt;matthieux.mauger@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When we disconnect from the AP, drivers call cfg80211_disconnect().
This doesn't know whether the disconnection was initiated locally
or by the AP though, which can cause problems with the supplicant,
for example with WPS. This issue obviously doesn't show up with any
mac80211 based driver since mac80211 doesn't call this function.

Fix this by requiring drivers to indicate whether the disconnect is
locally generated or not. I've tried to update the drivers, but may
not have gotten the values correct, and some drivers may currently
not be able to report correct values. In case of doubt I left it at
false, which is the current behaviour.

For libertas, make adjustments as indicated by Dan Williams.

Reported-by: Matthieu Mauger &lt;matthieux.mauger@intel.com&gt;
Tested-by: Matthieu Mauger &lt;matthieux.mauger@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: move IE split utilities here from mac80211</title>
<updated>2015-04-07T11:56:41+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-03-31T13:36:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=29464ccc78f1e8f77b8c37ddbe95af46d13c2ec2'/>
<id>29464ccc78f1e8f77b8c37ddbe95af46d13c2ec2</id>
<content type='text'>
As the next patch will require the IE splitting utility functions
in cfg80211, move them there from mac80211.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As the next patch will require the IE splitting utility functions
in cfg80211, move them there from mac80211.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg/mac80211: add regulatory classes IE during TDLS setup</title>
<updated>2015-03-30T08:26:36+00:00</updated>
<author>
<name>Arik Nemtsov</name>
<email>arik@wizery.com</email>
</author>
<published>2015-03-18T06:46:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a38700dd486f3def34cef47d00e2d360a04a7bc8'/>
<id>a38700dd486f3def34cef47d00e2d360a04a7bc8</id>
<content type='text'>
Seems Broadcom TDLS peers (Nexus 5, Xperia Z3) refuse to allow TDLS
connection when channel-switching is supported but the regulatory
classes IE is missing from the setup request.
Add a chandef to reg-class translation function to cfg80211 and use it
to add the required IE during setup. For now add only the current
regulatory class as supported - it is enough to resolve the
compatibility issue.

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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Seems Broadcom TDLS peers (Nexus 5, Xperia Z3) refuse to allow TDLS
connection when channel-switching is supported but the regulatory
classes IE is missing from the setup request.
Add a chandef to reg-class translation function to cfg80211 and use it
to add the required IE during setup. For now add only the current
regulatory class as supported - it is enough to resolve the
compatibility issue.

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;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: add operating classes 128-130</title>
<updated>2015-03-03T14:56:07+00:00</updated>
<author>
<name>Eliad Peller</name>
<email>eliad@wizery.com</email>
</author>
<published>2015-03-01T07:10:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=954a86ef45ffa2db4e361d5344ed61464fb2a204'/>
<id>954a86ef45ffa2db4e361d5344ed61464fb2a204</id>
<content type='text'>
Operating classes 128-130 are defined in the 11ac
spec for the 5GHz band.

Update ieee80211_operating_class_to_band() to support them.

Signed-off-by: Eliad Peller &lt;eliadx.peller@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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Operating classes 128-130 are defined in the 11ac
spec for the 5GHz band.

Update ieee80211_operating_class_to_band() to support them.

Signed-off-by: Eliad Peller &lt;eliadx.peller@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;
</pre>
</div>
</content>
</entry>
</feed>
