<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/net/mac80211/main.c, branch v5.7</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>mac80211: populate debugfs only after cfg80211 init</title>
<updated>2020-04-24T09:30:13+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2020-04-23T09:13:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6cb5f3ea4654faf8c28b901266e960b1a4787b26'/>
<id>6cb5f3ea4654faf8c28b901266e960b1a4787b26</id>
<content type='text'>
When fixing the initialization race, we neglected to account for
the fact that debugfs is initialized in wiphy_register(), and
some debugfs things went missing (or rather were rerooted to the
global debugfs root).

Fix this by adding debugfs entries only after wiphy_register().
This requires some changes in the rate control code since it
currently adds debugfs at alloc time, which can no longer be
done after the reordering.

Reported-by: Jouni Malinen &lt;j@w1.fi&gt;
Reported-by: kernel test robot &lt;rong.a.chen@intel.com&gt;
Reported-by: Hauke Mehrtens &lt;hauke@hauke-m.de&gt;
Reported-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Cc: stable@vger.kernel.org
Fixes: 52e04b4ce5d0 ("mac80211: fix race in ieee80211_register_hw()")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Acked-by: Sumit Garg &lt;sumit.garg@linaro.org&gt;
Link: https://lore.kernel.org/r/20200423111344.0e00d3346f12.Iadc76a03a55093d94391fc672e996a458702875d@changeid
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 fixing the initialization race, we neglected to account for
the fact that debugfs is initialized in wiphy_register(), and
some debugfs things went missing (or rather were rerooted to the
global debugfs root).

Fix this by adding debugfs entries only after wiphy_register().
This requires some changes in the rate control code since it
currently adds debugfs at alloc time, which can no longer be
done after the reordering.

Reported-by: Jouni Malinen &lt;j@w1.fi&gt;
Reported-by: kernel test robot &lt;rong.a.chen@intel.com&gt;
Reported-by: Hauke Mehrtens &lt;hauke@hauke-m.de&gt;
Reported-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Cc: stable@vger.kernel.org
Fixes: 52e04b4ce5d0 ("mac80211: fix race in ieee80211_register_hw()")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Acked-by: Sumit Garg &lt;sumit.garg@linaro.org&gt;
Link: https://lore.kernel.org/r/20200423111344.0e00d3346f12.Iadc76a03a55093d94391fc672e996a458702875d@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: fix race in ieee80211_register_hw()</title>
<updated>2020-04-15T07:31:58+00:00</updated>
<author>
<name>Sumit Garg</name>
<email>sumit.garg@linaro.org</email>
</author>
<published>2020-04-07T10:10:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=52e04b4ce5d03775b6a78f3ed1097480faacc9fd'/>
<id>52e04b4ce5d03775b6a78f3ed1097480faacc9fd</id>
<content type='text'>
A race condition leading to a kernel crash is observed during invocation
of ieee80211_register_hw() on a dragonboard410c device having wcn36xx
driver built as a loadable module along with a wifi manager in user-space
waiting for a wifi device (wlanX) to be active.

Sequence diagram for a particular kernel crash scenario:

    user-space  ieee80211_register_hw()  ieee80211_tasklet_handler()
    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
       |                    |                 |
       |&lt;---phy0----wiphy_register()          |
       |-----iwd if_add----&gt;|                 |
       |                    |&lt;---IRQ----(RX packet)
       |              Kernel crash            |
       |              due to unallocated      |
       |              workqueue.              |
       |                    |                 |
       |       alloc_ordered_workqueue()      |
       |                    |                 |
       |              Misc wiphy init.        |
       |                    |                 |
       |            ieee80211_if_add()        |
       |                    |                 |

As evident from above sequence diagram, this race condition isn't specific
to a particular wifi driver but rather the initialization sequence in
ieee80211_register_hw() needs to be fixed. So re-order the initialization
sequence and the updated sequence diagram would look like:

    user-space  ieee80211_register_hw()  ieee80211_tasklet_handler()
    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
       |                    |                 |
       |       alloc_ordered_workqueue()      |
       |                    |                 |
       |              Misc wiphy init.        |
       |                    |                 |
       |&lt;---phy0----wiphy_register()          |
       |-----iwd if_add----&gt;|                 |
       |                    |&lt;---IRQ----(RX packet)
       |                    |                 |
       |            ieee80211_if_add()        |
       |                    |                 |

Cc: stable@vger.kernel.org
Signed-off-by: Sumit Garg &lt;sumit.garg@linaro.org&gt;
Link: https://lore.kernel.org/r/1586254255-28713-1-git-send-email-sumit.garg@linaro.org
[Johannes: fix rtnl imbalances]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A race condition leading to a kernel crash is observed during invocation
of ieee80211_register_hw() on a dragonboard410c device having wcn36xx
driver built as a loadable module along with a wifi manager in user-space
waiting for a wifi device (wlanX) to be active.

Sequence diagram for a particular kernel crash scenario:

    user-space  ieee80211_register_hw()  ieee80211_tasklet_handler()
    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
       |                    |                 |
       |&lt;---phy0----wiphy_register()          |
       |-----iwd if_add----&gt;|                 |
       |                    |&lt;---IRQ----(RX packet)
       |              Kernel crash            |
       |              due to unallocated      |
       |              workqueue.              |
       |                    |                 |
       |       alloc_ordered_workqueue()      |
       |                    |                 |
       |              Misc wiphy init.        |
       |                    |                 |
       |            ieee80211_if_add()        |
       |                    |                 |

As evident from above sequence diagram, this race condition isn't specific
to a particular wifi driver but rather the initialization sequence in
ieee80211_register_hw() needs to be fixed. So re-order the initialization
sequence and the updated sequence diagram would look like:

    user-space  ieee80211_register_hw()  ieee80211_tasklet_handler()
    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
       |                    |                 |
       |       alloc_ordered_workqueue()      |
       |                    |                 |
       |              Misc wiphy init.        |
       |                    |                 |
       |&lt;---phy0----wiphy_register()          |
       |-----iwd if_add----&gt;|                 |
       |                    |&lt;---IRQ----(RX packet)
       |                    |                 |
       |            ieee80211_if_add()        |
       |                    |                 |

Cc: stable@vger.kernel.org
Signed-off-by: Sumit Garg &lt;sumit.garg@linaro.org&gt;
Link: https://lore.kernel.org/r/1586254255-28713-1-git-send-email-sumit.garg@linaro.org
[Johannes: fix rtnl imbalances]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: driver can remain on channel if not using chan_ctx</title>
<updated>2020-03-20T13:42:21+00:00</updated>
<author>
<name>Yan-Hsuan Chuang</name>
<email>yhchuang@realtek.com</email>
</author>
<published>2020-03-12T07:43:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8fa180bb4aceaa25233ea61032eab5b025fb522f'/>
<id>8fa180bb4aceaa25233ea61032eab5b025fb522f</id>
<content type='text'>
Some of the drivers are not using channel context, but let the
stack to control/switch channels instead. For such cases, driver
can still remain on channel because the mac80211 stack actually
supports it.

The stack will check if the driver is using chan_ctx and has
ops-&gt;remain_on_channel been hooked. Otherwise it will start its
ROC work to remain on channel. So, even if the driver is not
using chan_ctx, the driver is still capable of doing remain on
channel.

Signed-off-by: Yan-Hsuan Chuang &lt;yhchuang@realtek.com&gt;
Link: https://lore.kernel.org/r/20200312074337.16198-1-yhchuang@realtek.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some of the drivers are not using channel context, but let the
stack to control/switch channels instead. For such cases, driver
can still remain on channel because the mac80211 stack actually
supports it.

The stack will check if the driver is using chan_ctx and has
ops-&gt;remain_on_channel been hooked. Otherwise it will start its
ROC work to remain on channel. So, even if the driver is not
using chan_ctx, the driver is still capable of doing remain on
channel.

Signed-off-by: Yan-Hsuan Chuang &lt;yhchuang@realtek.com&gt;
Link: https://lore.kernel.org/r/20200312074337.16198-1-yhchuang@realtek.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: Allow deleting stations in ibss mode to reset their state</title>
<updated>2020-03-20T13:42:20+00:00</updated>
<author>
<name>Nicolas Cavallari</name>
<email>nicolas.cavallari@green-communications.fr</email>
</author>
<published>2020-03-05T13:57:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a916062a09d94cbeff87b7d57840b8747ab4a833'/>
<id>a916062a09d94cbeff87b7d57840b8747ab4a833</id>
<content type='text'>
Set the NL80211_EXT_FEATURE_DEL_IBSS_STA if the interface support IBSS
mode, so that stations can be reset from user space.

mac80211 already deletes stations by itself, so mac80211 drivers must
already support this.

This has been successfully tested with ath9k.

Signed-off-by: Nicolas Cavallari &lt;nicolas.cavallari@green-communications.fr&gt;
Link: https://lore.kernel.org/r/20200305135754.12094-2-cavallar@lri.fr
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Set the NL80211_EXT_FEATURE_DEL_IBSS_STA if the interface support IBSS
mode, so that stations can be reset from user space.

mac80211 already deletes stations by itself, so mac80211 drivers must
already support this.

This has been successfully tested with ath9k.

Signed-off-by: Nicolas Cavallari &lt;nicolas.cavallari@green-communications.fr&gt;
Link: https://lore.kernel.org/r/20200305135754.12094-2-cavallar@lri.fr
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: handle no-preauth flag for control port</title>
<updated>2020-03-20T13:42:19+00:00</updated>
<author>
<name>Markus Theil</name>
<email>markus.theil@tu-ilmenau.de</email>
</author>
<published>2020-03-12T09:10:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7f3f96cedd79e36b199a8eb4015a077468c37f3a'/>
<id>7f3f96cedd79e36b199a8eb4015a077468c37f3a</id>
<content type='text'>
This patch adds support for disabling pre-auth rx over the nl80211 control
port for mac80211.

Signed-off-by: Markus Theil &lt;markus.theil@tu-ilmenau.de&gt;
Link: https://lore.kernel.org/r/20200312091055.54257-3-markus.theil@tu-ilmenau.de
[fix indentation slightly, squash feature enablement]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds support for disabling pre-auth rx over the nl80211 control
port for mac80211.

Signed-off-by: Markus Theil &lt;markus.theil@tu-ilmenau.de&gt;
Link: https://lore.kernel.org/r/20200312091055.54257-3-markus.theil@tu-ilmenau.de
[fix indentation slightly, squash feature enablement]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "mac80211: support NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211_MAC_ADDRS"</title>
<updated>2020-02-24T09:21:52+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2020-02-24T09:19:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8079e4fee5639cc01374cc2d2ea3f952598896b4'/>
<id>8079e4fee5639cc01374cc2d2ea3f952598896b4</id>
<content type='text'>
This reverts commit 9b125c27998719288e4dcf2faf54511039526692.

As Jouni points out, there's really no need for this, since the
RSN pre-authentication frames are normal data frames, not port
control frames (locally).

Fixes: 9b125c279987 ("mac80211: support NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211_MAC_ADDRS")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Link: https://lore.kernel.org/r/20200224101910.b87da63a3cd6.Ic94bc51a370c4aa7d19fbca9b96d90ab703257dc@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 9b125c27998719288e4dcf2faf54511039526692.

As Jouni points out, there's really no need for this, since the
RSN pre-authentication frames are normal data frames, not port
control frames (locally).

Fixes: 9b125c279987 ("mac80211: support NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211_MAC_ADDRS")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Link: https://lore.kernel.org/r/20200224101910.b87da63a3cd6.Ic94bc51a370c4aa7d19fbca9b96d90ab703257dc@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: Fix setting txpower to zero</title>
<updated>2020-02-14T08:57:00+00:00</updated>
<author>
<name>Ben Greear</name>
<email>greearb@candelatech.com</email>
</author>
<published>2019-12-17T18:30:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=db6d9e9e8b48b7ab68c61553eb5fa68534dd0fde'/>
<id>db6d9e9e8b48b7ab68c61553eb5fa68534dd0fde</id>
<content type='text'>
With multiple VIFS ath10k, and probably others, tries to find the
minimum txpower for all vifs and uses that when setting txpower in
the firmware.

If a second vif is added and starts to scan, it's txpower is not
initialized yet and it set to zero.

ath10k had a patch to ignore zero values, but then it is impossible
to actually set txpower to zero.

So, instead initialize the txpower to INT_MIN in mac80211, and let
drivers know that means the power has not been set and so should
be ignored.

This should fix regression in:

commit 88407beb1b1462f706a1950a355fd086e1c450b6
Author: Ryan Hsu &lt;ryanhsu@qca.qualcomm.com&gt;
Date:   Tue Dec 13 14:55:19 2016 -0800

    ath10k: fix incorrect txpower set by P2P_DEVICE interface

Tested on ath10k 9984 with ath10k-ct firmware.

Signed-off-by: Ben Greear &lt;greearb@candelatech.com&gt;
Link: https://lore.kernel.org/r/20191217183057.24586-1-greearb@candelatech.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With multiple VIFS ath10k, and probably others, tries to find the
minimum txpower for all vifs and uses that when setting txpower in
the firmware.

If a second vif is added and starts to scan, it's txpower is not
initialized yet and it set to zero.

ath10k had a patch to ignore zero values, but then it is impossible
to actually set txpower to zero.

So, instead initialize the txpower to INT_MIN in mac80211, and let
drivers know that means the power has not been set and so should
be ignored.

This should fix regression in:

commit 88407beb1b1462f706a1950a355fd086e1c450b6
Author: Ryan Hsu &lt;ryanhsu@qca.qualcomm.com&gt;
Date:   Tue Dec 13 14:55:19 2016 -0800

    ath10k: fix incorrect txpower set by P2P_DEVICE interface

Tested on ath10k 9984 with ath10k-ct firmware.

Signed-off-by: Ben Greear &lt;greearb@candelatech.com&gt;
Link: https://lore.kernel.org/r/20191217183057.24586-1-greearb@candelatech.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: support NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211_MAC_ADDRS</title>
<updated>2020-02-07T11:59:40+00:00</updated>
<author>
<name>Markus Theil</name>
<email>markus.theil@tu-ilmenau.de</email>
</author>
<published>2020-02-07T11:58:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9b125c27998719288e4dcf2faf54511039526692'/>
<id>9b125c27998719288e4dcf2faf54511039526692</id>
<content type='text'>
This is now a trivial patch, but for seeing the actual changes
I (Johannes) split it out from the original.

Signed-off-by: Markus Theil &lt;markus.theil@tu-ilmenau.de&gt;
Link: https://lore.kernel.org/r/20200115125522.3755-1-markus.theil@tu-ilmenau.de
[split into separate cfg80211/mac80211 patches]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is now a trivial patch, but for seeing the actual changes
I (Johannes) split it out from the original.

Signed-off-by: Markus Theil &lt;markus.theil@tu-ilmenau.de&gt;
Link: https://lore.kernel.org/r/20200115125522.3755-1-markus.theil@tu-ilmenau.de
[split into separate cfg80211/mac80211 patches]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211/mac80211: Allow user space to register for station Rx authentication</title>
<updated>2020-02-07T11:54:09+00:00</updated>
<author>
<name>Ilan Peer</name>
<email>ilan.peer@intel.com</email>
</author>
<published>2020-01-31T11:45:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ff74c51e8f4c543ed2bd3bf1c2f3287b098660df'/>
<id>ff74c51e8f4c543ed2bd3bf1c2f3287b098660df</id>
<content type='text'>
To support Pre Association Security Negotiation (PASN) while already
associated to one AP, allow user space to register to Rx
authentication frames, so that the user space logic would be able to
receive/handle authentication frames from a different AP as part of
PASN.

Note that it is expected that user space would intelligently register
for Rx authentication frames, i.e., only when PASN is used and
configure a match filter only for PASN authentication algorithm, as
otherwise the MLME functionality of mac80211 would be broken.

Additionally, since some versions of the user space daemons wrongly
register to all types of authentication frames (which might result in
unexpected behavior) allow such registration if the request is for a
specific authentication algorithm number.

Signed-off-by: Ilan Peer &lt;ilan.peer@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Link: https://lore.kernel.org/r/20200131114529.894206-1-luca@coelho.fi
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
To support Pre Association Security Negotiation (PASN) while already
associated to one AP, allow user space to register to Rx
authentication frames, so that the user space logic would be able to
receive/handle authentication frames from a different AP as part of
PASN.

Note that it is expected that user space would intelligently register
for Rx authentication frames, i.e., only when PASN is used and
configure a match filter only for PASN authentication algorithm, as
otherwise the MLME functionality of mac80211 would be broken.

Additionally, since some versions of the user space daemons wrongly
register to all types of authentication frames (which might result in
unexpected behavior) allow such registration if the request is for a
specific authentication algorithm number.

Signed-off-by: Ilan Peer &lt;ilan.peer@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Link: https://lore.kernel.org/r/20200131114529.894206-1-luca@coelho.fi
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: make ieee80211_wep_init() return void</title>
<updated>2020-02-07T11:40:34+00:00</updated>
<author>
<name>Luca Coelho</name>
<email>luciano.coelho@intel.com</email>
</author>
<published>2020-01-31T11:12:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4a65cc2437ce4a643c24b357d849e3ff773efed1'/>
<id>4a65cc2437ce4a643c24b357d849e3ff773efed1</id>
<content type='text'>
This function always returns 0, so there's no point in returning int.
Make it void and remove the impossible error-path when calling it.

Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Link: https://lore.kernel.org/r/20200131111300.891737-11-luca@coelho.fi
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This function always returns 0, so there's no point in returning int.
Make it void and remove the impossible error-path when calling it.

Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Link: https://lore.kernel.org/r/20200131111300.891737-11-luca@coelho.fi
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
