Allow management frame injection on DFS channels if the channel has been CAC
checked and is available
Signed-off-by: Lorenzo Bianconi <[email protected]>
---
net/mac80211/tx.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 3456c04..edb1d3e 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1694,8 +1694,10 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
* radar detection by itself. We can do that later by adding a
* monitor flag interfaces used for AP support.
*/
- if ((chan->flags & (IEEE80211_CHAN_NO_IBSS | IEEE80211_CHAN_RADAR |
- IEEE80211_CHAN_PASSIVE_SCAN)))
+ if (((chan->flags & (IEEE80211_CHAN_PASSIVE_SCAN |
+ IEEE80211_CHAN_NO_IBSS))) ||
+ ((chan->flags & IEEE80211_CHAN_RADAR) &&
+ chan->dfs_state != NL80211_DFS_AVAILABLE))
goto fail_rcu;
ieee80211_xmit(sdata, skb, chan->band);
--
1.8.1.2
I am testing some personal hostapd changes in order to add CAC/NOP
management using methods added by Simon
2013/10/2 Johannes Berg <[email protected]>:
> On Wed, 2013-10-02 at 14:52 +0200, Lorenzo Bianconi wrote:
>> I am not using latest mac80211/hostapd (in particular
>> compat-wireless-2013-04-16/hostapd-20130807) because I have to port
>> some personal stuff. In this scenario I was not able to establish an
>> AP/STA connection on DFS channel. Anyway I will update these packages.
>
> But that old hostapd doesn't support DFS to start with, does it? I'm
> confused.
>
> johannes
>
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep
On Wed, 2013-10-02 at 14:52 +0200, Lorenzo Bianconi wrote:
> I am not using latest mac80211/hostapd (in particular
> compat-wireless-2013-04-16/hostapd-20130807) because I have to port
> some personal stuff. In this scenario I was not able to establish an
> AP/STA connection on DFS channel. Anyway I will update these packages.
But that old hostapd doesn't support DFS to start with, does it? I'm
confused.
johannes
On Wed, 2013-10-02 at 12:07 +0200, Lorenzo Bianconi wrote:
> Before start beaconing cfg80211_reg_can_beacon() verifies the channel
> is CAC checked and available calling cfg80211_secondary_chans_ok().
> Although the channel is marked NL80211_DFS_AVAILABLE after a CAC
> period, ieee80211_monitor_start_xmit() does not allow to inject mgmt
> frames on DFS channels causing association failures.
I don't see how this can cause association failures? Please explain.
DFS-capable hostapd doesn't use monitor interfaces with mac80211 any
more.
johannes
On Mon, 2013-09-30 at 14:52 +0200, Lorenzo Bianconi wrote:
> Allow management frame injection on DFS channels if the channel has been CAC
> checked and is available
> +++ b/net/mac80211/tx.c
> @@ -1694,8 +1694,10 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
> * radar detection by itself. We can do that later by adding a
> * monitor flag interfaces used for AP support.
> */
> - if ((chan->flags & (IEEE80211_CHAN_NO_IBSS | IEEE80211_CHAN_RADAR |
> - IEEE80211_CHAN_PASSIVE_SCAN)))
> + if (((chan->flags & (IEEE80211_CHAN_PASSIVE_SCAN |
> + IEEE80211_CHAN_NO_IBSS))) ||
> + ((chan->flags & IEEE80211_CHAN_RADAR) &&
> + chan->dfs_state != NL80211_DFS_AVAILABLE))
This would be the only place where mac80211 is accessing
chan->dfs_state, does that make sense? Why is it not needed elsewhere?
johannes
Before start beaconing cfg80211_reg_can_beacon() verifies the channel
is CAC checked and available calling cfg80211_secondary_chans_ok().
Although the channel is marked NL80211_DFS_AVAILABLE after a CAC
period, ieee80211_monitor_start_xmit() does not allow to inject mgmt
frames on DFS channels causing association failures.
Lorenzo
2013/10/2 Johannes Berg <[email protected]>:
> On Mon, 2013-09-30 at 14:52 +0200, Lorenzo Bianconi wrote:
>> Allow management frame injection on DFS channels if the channel has been CAC
>> checked and is available
>
>> +++ b/net/mac80211/tx.c
>> @@ -1694,8 +1694,10 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
>> * radar detection by itself. We can do that later by adding a
>> * monitor flag interfaces used for AP support.
>> */
>> - if ((chan->flags & (IEEE80211_CHAN_NO_IBSS | IEEE80211_CHAN_RADAR |
>> - IEEE80211_CHAN_PASSIVE_SCAN)))
>> + if (((chan->flags & (IEEE80211_CHAN_PASSIVE_SCAN |
>> + IEEE80211_CHAN_NO_IBSS))) ||
>> + ((chan->flags & IEEE80211_CHAN_RADAR) &&
>> + chan->dfs_state != NL80211_DFS_AVAILABLE))
>
> This would be the only place where mac80211 is accessing
> chan->dfs_state, does that make sense? Why is it not needed elsewhere?
>
> johannes
>
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep
I am not using latest mac80211/hostapd (in particular
compat-wireless-2013-04-16/hostapd-20130807) because I have to port
some personal stuff. In this scenario I was not able to establish an
AP/STA connection on DFS channel. Anyway I will update these packages.
Lorenzo
2013/10/2 Johannes Berg <[email protected]>:
> On Wed, 2013-10-02 at 12:07 +0200, Lorenzo Bianconi wrote:
>> Before start beaconing cfg80211_reg_can_beacon() verifies the channel
>> is CAC checked and available calling cfg80211_secondary_chans_ok().
>> Although the channel is marked NL80211_DFS_AVAILABLE after a CAC
>> period, ieee80211_monitor_start_xmit() does not allow to inject mgmt
>> frames on DFS channels causing association failures.
>
> I don't see how this can cause association failures? Please explain.
> DFS-capable hostapd doesn't use monitor interfaces with mac80211 any
> more.
>
> johannes
>
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep