The IEEE 802.11p amendment specifies usage of 5 and 10 MHz wide
channels in 5.9GHz band for vehicular environment. This patch-set
adds new channel attributes holding the information about the
prohibited bandwidths. This is meant to be used mainly with
channels in 5.9GHz band in future implementation of 802.11p.
Changes since v2:
* Rebased to jberg/mac80211-next
* Squashed patches 1+2
Rostislav Lisovy (2):
cfg80211: Add attributes describing prohibited channel bandwidth
cfg80211: Use 5MHz bandwidth by default when checking usable channels
include/net/cfg80211.h | 6 ++++++
include/uapi/linux/nl80211.h | 6 ++++++
net/wireless/chan.c | 2 ++
net/wireless/nl80211.c | 13 +++++++++++++
net/wireless/reg.c | 22 +++++++++++++++-------
5 files changed, 42 insertions(+), 7 deletions(-)
--
1.9.2
Current code checks if the 20MHz bandwidth is allowed for
particular channel -- if it is not, the channel is disabled.
Since we need to use 5/10 MHz channels, this code is modified in
the way that the default bandwidth to check is 5MHz. If the
maximum bandwidth allowed by the channel is smaller than 5MHz,
the channel is disabled. Otherwise the channel is used and the
flags are set according to the bandwidth allowed by the channel.
Signed-off-by: Rostislav Lisovy <[email protected]>
---
net/wireless/reg.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 9d32633..3f3bc2e 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -927,7 +927,7 @@ freq_reg_info_regd(struct wiphy *wiphy, u32 center_freq,
if (!band_rule_found)
band_rule_found = freq_in_rule_band(fr, center_freq);
- bw_fits = reg_does_bw_fit(fr, center_freq, MHZ_TO_KHZ(20));
+ bw_fits = reg_does_bw_fit(fr, center_freq, MHZ_TO_KHZ(5));
if (band_rule_found && bw_fits)
return rr;
@@ -1011,10 +1011,10 @@ static void chan_reg_rule_print_dbg(const struct ieee80211_regdomain *regd,
}
#endif
-/*
- * Note that right now we assume the desired channel bandwidth
- * is always 20 MHz for each individual channel (HT40 uses 20 MHz
- * per channel, the primary and the extension channel).
+/* Find an ieee80211_reg_rule such that a 5MHz channel with frequency
+ * @chan->center_freq fits there.
+ * If there is no such reg_rule, disable the channel, otherwise set the
+ * flags corresponding to the bandwidths allowed in the particular reg_rule
*/
static void handle_channel(struct wiphy *wiphy,
enum nl80211_reg_initiator initiator,
@@ -1075,8 +1075,12 @@ static void handle_channel(struct wiphy *wiphy,
if (reg_rule->flags & NL80211_RRF_AUTO_BW)
max_bandwidth_khz = reg_get_max_bandwidth(regd, reg_rule);
+ if (max_bandwidth_khz < MHZ_TO_KHZ(10))
+ bw_flags = IEEE80211_CHAN_NO_10MHZ;
+ if (max_bandwidth_khz < MHZ_TO_KHZ(20))
+ bw_flags |= IEEE80211_CHAN_NO_20MHZ;
if (max_bandwidth_khz < MHZ_TO_KHZ(40))
- bw_flags = IEEE80211_CHAN_NO_HT40;
+ bw_flags |= IEEE80211_CHAN_NO_HT40;
if (max_bandwidth_khz < MHZ_TO_KHZ(80))
bw_flags |= IEEE80211_CHAN_NO_80MHZ;
if (max_bandwidth_khz < MHZ_TO_KHZ(160))
@@ -1510,8 +1514,12 @@ static void handle_channel_custom(struct wiphy *wiphy,
if (reg_rule->flags & NL80211_RRF_AUTO_BW)
max_bandwidth_khz = reg_get_max_bandwidth(regd, reg_rule);
+ if (max_bandwidth_khz < MHZ_TO_KHZ(10))
+ bw_flags = IEEE80211_CHAN_NO_10MHZ;
+ if (max_bandwidth_khz < MHZ_TO_KHZ(20))
+ bw_flags |= IEEE80211_CHAN_NO_20MHZ;
if (max_bandwidth_khz < MHZ_TO_KHZ(40))
- bw_flags = IEEE80211_CHAN_NO_HT40;
+ bw_flags |= IEEE80211_CHAN_NO_HT40;
if (max_bandwidth_khz < MHZ_TO_KHZ(80))
bw_flags |= IEEE80211_CHAN_NO_80MHZ;
if (max_bandwidth_khz < MHZ_TO_KHZ(160))
--
1.9.2
Since there are frequency bands (e.g. 5.9GHz) allowing channels
with only 10 or 5 MHz bandwidth, this patch adds attributes that
allow keeping track about this information.
When channel attributes are reported to user-space, make sure to
not break old tools, i.e. if the 'split wiphy dump' is enabled,
report the extra attributes (if present) describing the bandwidth
restrictions. If the 'split wiphy dump' is not enabled,
completely omit those channels that have flags set to either
IEEE80211_CHAN_NO_10MHZ or IEEE80211_CHAN_NO_20MHZ.
Add the check for new bandwidth restriction flags in
cfg80211_chandef_usable() to comply with the restrictions.
Signed-off-by: Rostislav Lisovy <[email protected]>
---
include/net/cfg80211.h | 6 ++++++
include/uapi/linux/nl80211.h | 6 ++++++
net/wireless/chan.c | 2 ++
net/wireless/nl80211.c | 13 +++++++++++++
4 files changed, 27 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9496fe5..4e9016d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -111,6 +111,10 @@ enum ieee80211_band {
* restrictions.
* @IEEE80211_CHAN_INDOOR_ONLY: see %NL80211_FREQUENCY_ATTR_INDOOR_ONLY
* @IEEE80211_CHAN_GO_CONCURRENT: see %NL80211_FREQUENCY_ATTR_GO_CONCURRENT
+ * @IEEE80211_CHAN_NO_20MHZ: 20 MHz bandwidth is not permitted
+ * on this channel.
+ * @IEEE80211_CHAN_NO_10MHZ: 10 MHz bandwidth is not permitted
+ * on this channel.
*
*/
enum ieee80211_channel_flags {
@@ -125,6 +129,8 @@ enum ieee80211_channel_flags {
IEEE80211_CHAN_NO_160MHZ = 1<<8,
IEEE80211_CHAN_INDOOR_ONLY = 1<<9,
IEEE80211_CHAN_GO_CONCURRENT = 1<<10,
+ IEEE80211_CHAN_NO_20MHZ = 1<<11,
+ IEEE80211_CHAN_NO_10MHZ = 1<<12,
};
#define IEEE80211_CHAN_NO_HT40 \
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 513bfd7..0592032 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2358,6 +2358,10 @@ enum nl80211_band_attr {
* connected to an AP with DFS and radar detection on the UNII band (it is
* up to user-space, i.e., wpa_supplicant to perform the required
* verifications)
+ * @NL80211_FREQUENCY_ATTR_NO_20MHZ: 20 MHz operation is not allowed
+ * on this channel in current regulatory domain.
+ * @NL80211_FREQUENCY_ATTR_NO_10MHZ: 10 MHz operation is not allowed
+ * on this channel in current regulatory domain.
* @NL80211_FREQUENCY_ATTR_MAX: highest frequency attribute number
* currently defined
* @__NL80211_FREQUENCY_ATTR_AFTER_LAST: internal use
@@ -2384,6 +2388,8 @@ enum nl80211_frequency_attr {
NL80211_FREQUENCY_ATTR_DFS_CAC_TIME,
NL80211_FREQUENCY_ATTR_INDOOR_ONLY,
NL80211_FREQUENCY_ATTR_GO_CONCURRENT,
+ NL80211_FREQUENCY_ATTR_NO_20MHZ,
+ NL80211_FREQUENCY_ATTR_NO_10MHZ,
/* keep last */
__NL80211_FREQUENCY_ATTR_AFTER_LAST,
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index c61bcdd..aee2dc2 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -616,12 +616,14 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
width = 5;
break;
case NL80211_CHAN_WIDTH_10:
+ prohibited_flags |= IEEE80211_CHAN_NO_10MHZ;
width = 10;
break;
case NL80211_CHAN_WIDTH_20:
if (!ht_cap->ht_supported)
return false;
case NL80211_CHAN_WIDTH_20_NOHT:
+ prohibited_flags |= IEEE80211_CHAN_NO_20MHZ;
width = 20;
break;
case NL80211_CHAN_WIDTH_40:
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 232d15c..2f0a1b1 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -567,6 +567,13 @@ static int nl80211_msg_put_channel(struct sk_buff *msg,
struct ieee80211_channel *chan,
bool large)
{
+ /* Some channels must be completely excluded from the
+ * list to protect old user-space tools from breaking
+ */
+ if (!large && chan->flags &
+ (IEEE80211_CHAN_NO_10MHZ | IEEE80211_CHAN_NO_20MHZ))
+ return 0;
+
if (nla_put_u32(msg, NL80211_FREQUENCY_ATTR_FREQ,
chan->center_freq))
goto nla_put_failure;
@@ -620,6 +627,12 @@ static int nl80211_msg_put_channel(struct sk_buff *msg,
if ((chan->flags & IEEE80211_CHAN_GO_CONCURRENT) &&
nla_put_flag(msg, NL80211_FREQUENCY_ATTR_GO_CONCURRENT))
goto nla_put_failure;
+ if ((chan->flags & IEEE80211_CHAN_NO_20MHZ) &&
+ nla_put_flag(msg, NL80211_FREQUENCY_ATTR_NO_20MHZ))
+ goto nla_put_failure;
+ if ((chan->flags & IEEE80211_CHAN_NO_10MHZ) &&
+ nla_put_flag(msg, NL80211_FREQUENCY_ATTR_NO_10MHZ))
+ goto nla_put_failure;
}
if (nla_put_u32(msg, NL80211_FREQUENCY_ATTR_MAX_TX_POWER,
--
1.9.2
On Tue, 2014-04-15 at 14:37 +0200, Rostislav Lisovy wrote:
> The IEEE 802.11p amendment specifies usage of 5 and 10 MHz wide
> channels in 5.9GHz band for vehicular environment. This patch-set
> adds new channel attributes holding the information about the
> prohibited bandwidths. This is meant to be used mainly with
> channels in 5.9GHz band in future implementation of 802.11p.
Both applied.
johannes
On 2014-04-15 14:37, Rostislav Lisovy wrote:
> Current code checks if the 20MHz bandwidth is allowed for
> particular channel -- if it is not, the channel is disabled.
> Since we need to use 5/10 MHz channels, this code is modified in
> the way that the default bandwidth to check is 5MHz. If the
> maximum bandwidth allowed by the channel is smaller than 5MHz,
> the channel is disabled. Otherwise the channel is used and the
> flags are set according to the bandwidth allowed by the channel.
>
> Signed-off-by: Rostislav Lisovy <[email protected]>
This change causes a regression and needs to be reverted or fixed.
It leaves Channel 12 enabled for US regdomain and does not prevent
bringing up AP mode on it (IEEE80211_CHAN_NO_20MHZ does not get set).
I think the main problem with this change is that max_bandwidth_khz
(which is used to derive the no-10mhz and no-20mhz flags) does not
consider the frequency when calculating the max bandwidth.
- Felix
On Sun, 2014-06-22 at 13:41 +0200, Felix Fietkau wrote:
> On 2014-04-15 14:37, Rostislav Lisovy wrote:
> > Current code checks if the 20MHz bandwidth is allowed for
> > particular channel -- if it is not, the channel is disabled.
> > Since we need to use 5/10 MHz channels, this code is modified in
> > the way that the default bandwidth to check is 5MHz. If the
> > maximum bandwidth allowed by the channel is smaller than 5MHz,
> > the channel is disabled. Otherwise the channel is used and the
> > flags are set according to the bandwidth allowed by the channel.
> >
> > Signed-off-by: Rostislav Lisovy <[email protected]>
> This change causes a regression and needs to be reverted or fixed.
Noted, I've reverted it in mac80211.git.
> It leaves Channel 12 enabled for US regdomain and does not prevent
> bringing up AP mode on it (IEEE80211_CHAN_NO_20MHZ does not get set).
I'm not sure this makes sense - CHAN_NO_20MHZ shouldn't get set on that
channel? It should be disabled for other reasons for AP mode - e.g.
NO_IR.
johannes
On 2014-06-23 11:08, Johannes Berg wrote:
> On Sun, 2014-06-22 at 13:41 +0200, Felix Fietkau wrote:
>> On 2014-04-15 14:37, Rostislav Lisovy wrote:
>> > Current code checks if the 20MHz bandwidth is allowed for
>> > particular channel -- if it is not, the channel is disabled.
>> > Since we need to use 5/10 MHz channels, this code is modified in
>> > the way that the default bandwidth to check is 5MHz. If the
>> > maximum bandwidth allowed by the channel is smaller than 5MHz,
>> > the channel is disabled. Otherwise the channel is used and the
>> > flags are set according to the bandwidth allowed by the channel.
>> >
>> > Signed-off-by: Rostislav Lisovy <[email protected]>
>
>> This change causes a regression and needs to be reverted or fixed.
>
> Noted, I've reverted it in mac80211.git.
>
>> It leaves Channel 12 enabled for US regdomain and does not prevent
>> bringing up AP mode on it (IEEE80211_CHAN_NO_20MHZ does not get set).
>
> I'm not sure this makes sense - CHAN_NO_20MHZ shouldn't get set on that
> channel? It should be disabled for other reasons for AP mode - e.g.
> NO_IR.
I was thinking it could be valid in AP mode for 5 MHz operation.
- Felix
On Mon, 2014-06-23 at 12:04 +0200, Felix Fietkau wrote:
> On 2014-06-23 11:08, Johannes Berg wrote:
> > On Sun, 2014-06-22 at 13:41 +0200, Felix Fietkau wrote:
> >> On 2014-04-15 14:37, Rostislav Lisovy wrote:
> >> > Current code checks if the 20MHz bandwidth is allowed for
> >> > particular channel -- if it is not, the channel is disabled.
> >> > Since we need to use 5/10 MHz channels, this code is modified in
> >> > the way that the default bandwidth to check is 5MHz. If the
> >> > maximum bandwidth allowed by the channel is smaller than 5MHz,
> >> > the channel is disabled. Otherwise the channel is used and the
> >> > flags are set according to the bandwidth allowed by the channel.
> >> >
> >> > Signed-off-by: Rostislav Lisovy <[email protected]>
> >
> >> This change causes a regression and needs to be reverted or fixed.
> >
> > Noted, I've reverted it in mac80211.git.
> >
> >> It leaves Channel 12 enabled for US regdomain and does not prevent
> >> bringing up AP mode on it (IEEE80211_CHAN_NO_20MHZ does not get set).
> >
> > I'm not sure this makes sense - CHAN_NO_20MHZ shouldn't get set on that
> > channel? It should be disabled for other reasons for AP mode - e.g.
> > NO_IR.
> I was thinking it could be valid in AP mode for 5 MHz operation.
Huh, ok, maybe. I guess Rostislav can look into the details :)
johannes
On Mon, 2014-06-23 at 12:05 +0200, Johannes Berg wrote:
> On Mon, 2014-06-23 at 12:04 +0200, Felix Fietkau wrote:
> > On 2014-06-23 11:08, Johannes Berg wrote:
> > > On Sun, 2014-06-22 at 13:41 +0200, Felix Fietkau wrote:
> > >> On 2014-04-15 14:37, Rostislav Lisovy wrote:
> > >> > Current code checks if the 20MHz bandwidth is allowed for
> > >> > particular channel -- if it is not, the channel is disabled.
> > >> > Since we need to use 5/10 MHz channels, this code is modified in
> > >> > the way that the default bandwidth to check is 5MHz. If the
> > >> > maximum bandwidth allowed by the channel is smaller than 5MHz,
> > >> > the channel is disabled. Otherwise the channel is used and the
> > >> > flags are set according to the bandwidth allowed by the channel.
> > >> >
> > >> > Signed-off-by: Rostislav Lisovy <[email protected]>
> > >
> > >> This change causes a regression and needs to be reverted or fixed.
> > >
> > > Noted, I've reverted it in mac80211.git.
> > >
> > >> It leaves Channel 12 enabled for US regdomain and does not prevent
> > >> bringing up AP mode on it (IEEE80211_CHAN_NO_20MHZ does not get set).
> > >
> > > I'm not sure this makes sense - CHAN_NO_20MHZ shouldn't get set on that
> > > channel? It should be disabled for other reasons for AP mode - e.g.
> > > NO_IR.
> > I was thinking it could be valid in AP mode for 5 MHz operation.
>
> Huh, ok, maybe. I guess Rostislav can look into the details :)
>
I am a bit confused right now. The regression is that the channel used
to be completely disabled and now it is not? The regulatory restrictions
prohibit the 20MHz BW for this channel but 5MHz BW is alright?
(I am out of office for the next few days, thus I am unfortunately
unable to write/test any code.)
Rostislav;
On 2014-06-23 16:38, Rostislav Lisovy wrote:
> On Mon, 2014-06-23 at 12:05 +0200, Johannes Berg wrote:
>> On Mon, 2014-06-23 at 12:04 +0200, Felix Fietkau wrote:
>> > On 2014-06-23 11:08, Johannes Berg wrote:
>> > > On Sun, 2014-06-22 at 13:41 +0200, Felix Fietkau wrote:
>> > >> On 2014-04-15 14:37, Rostislav Lisovy wrote:
>> > >> > Current code checks if the 20MHz bandwidth is allowed for
>> > >> > particular channel -- if it is not, the channel is disabled.
>> > >> > Since we need to use 5/10 MHz channels, this code is modified in
>> > >> > the way that the default bandwidth to check is 5MHz. If the
>> > >> > maximum bandwidth allowed by the channel is smaller than 5MHz,
>> > >> > the channel is disabled. Otherwise the channel is used and the
>> > >> > flags are set according to the bandwidth allowed by the channel.
>> > >> >
>> > >> > Signed-off-by: Rostislav Lisovy <[email protected]>
>> > >
>> > >> This change causes a regression and needs to be reverted or fixed.
>> > >
>> > > Noted, I've reverted it in mac80211.git.
>> > >
>> > >> It leaves Channel 12 enabled for US regdomain and does not prevent
>> > >> bringing up AP mode on it (IEEE80211_CHAN_NO_20MHZ does not get set).
>> > >
>> > > I'm not sure this makes sense - CHAN_NO_20MHZ shouldn't get set on that
>> > > channel? It should be disabled for other reasons for AP mode - e.g.
>> > > NO_IR.
>> > I was thinking it could be valid in AP mode for 5 MHz operation.
>>
>> Huh, ok, maybe. I guess Rostislav can look into the details :)
>>
>
> I am a bit confused right now. The regression is that the channel used
> to be completely disabled and now it is not? The regulatory restrictions
> prohibit the 20MHz BW for this channel but 5MHz BW is alright?
Correct. The matching rule is this:
(2402 - 2472 @ 40), (N/A, 30), (N/A)
Channel 11 (2462 MHz) is allowed, because 2472 MHz is below the limit.
Channel 12 (2467 MHz) is not allowed, because 2477 MHz is too high.
With your change, Channel 12 was enabled and usable for AP mode.
- Felix
On Mon, 2014-06-23 at 16:46 +0200, Felix Fietkau wrote:
> On 2014-06-23 16:38, Rostislav Lisovy wrote:
> > On Mon, 2014-06-23 at 12:05 +0200, Johannes Berg wrote:
> >> On Mon, 2014-06-23 at 12:04 +0200, Felix Fietkau wrote:
> >> > On 2014-06-23 11:08, Johannes Berg wrote:
> >> > > On Sun, 2014-06-22 at 13:41 +0200, Felix Fietkau wrote:
> >> > >> On 2014-04-15 14:37, Rostislav Lisovy wrote:
> >> > >> > Current code checks if the 20MHz bandwidth is allowed for
> >> > >> > particular channel -- if it is not, the channel is disabled.
> >> > >> > Since we need to use 5/10 MHz channels, this code is modified in
> >> > >> > the way that the default bandwidth to check is 5MHz. If the
> >> > >> > maximum bandwidth allowed by the channel is smaller than 5MHz,
> >> > >> > the channel is disabled. Otherwise the channel is used and the
> >> > >> > flags are set according to the bandwidth allowed by the channel.
> >> > >> >
> >> > >> > Signed-off-by: Rostislav Lisovy <[email protected]>
> >> > >
> >> > >> This change causes a regression and needs to be reverted or fixed.
> >> > >
> >> > > Noted, I've reverted it in mac80211.git.
> >> > >
> >> > >> It leaves Channel 12 enabled for US regdomain and does not prevent
> >> > >> bringing up AP mode on it (IEEE80211_CHAN_NO_20MHZ does not get set).
> >> > >
> >> > > I'm not sure this makes sense - CHAN_NO_20MHZ shouldn't get set on that
> >> > > channel? It should be disabled for other reasons for AP mode - e.g.
> >> > > NO_IR.
> >> > I was thinking it could be valid in AP mode for 5 MHz operation.
> >>
> >> Huh, ok, maybe. I guess Rostislav can look into the details :)
> >>
> >
> > I am a bit confused right now. The regression is that the channel used
> > to be completely disabled and now it is not? The regulatory restrictions
> > prohibit the 20MHz BW for this channel but 5MHz BW is alright?
> Correct. The matching rule is this:
> (2402 - 2472 @ 40), (N/A, 30), (N/A)
>
> Channel 11 (2462 MHz) is allowed, because 2472 MHz is below the limit.
> Channel 12 (2467 MHz) is not allowed, because 2477 MHz is too high.
>
> With your change, Channel 12 was enabled and usable for AP mode.
Thank you Felix, this makes sense.
I think the issue is the call
bw_fits = reg_does_bw_fit(fr, center_freq, MHZ_TO_KHZ(5));
which checks if "2467 + 5" is equal or less than 2472 (which indeed is),
when the result is true, the maximum allowed BW (max_bandwidth_khz) is
wrongly used on that particular channel.
I hope I will send a fix on Friday.
Rostislav;