From: Jan Kaisrlik <[email protected]>
The patch adds support for Intelligent Transportation System (ITS-G5)
band to the ath9k driver.
Signed-off-by: Jan Kaisrlik <[email protected]>
Cc: Michal Sojka <[email protected]>
---
Hi all,
in this second version of the patch we removed dependency on
CFG80211_CERTIFICATION_ONUS as suggested by Johannes. We are, however,
not sure whether this is the right thing to do.
The problem is that ath9k uses (REGULATORY_STRICT_REG |
REGULATORY_CUSTOM_REG), which means that in order to use the 5.9 GHz
band, ath9k's private regdomain has to be extended. This in turn means
that the 5.9 GHz band is enabled by default in many configurations. It
can be disabled if one sends a regulatory hint and has valid regdb in
user space, but this cannot be relied upon.
As I already wrote, I don't think that regulatory documents allow such
behavior:
In EU, regulatory (ECC Decision (08)01) reads:
... decides ... that CEPT administrations shall designate the
frequency sub-band 5875-5905 MHz on a non-exclusive basis for ITS
traffic safety applications;
I understand this that the band can be used only by "traffic safety
applications" and not by random laptops running Linux.
In US, regulatory (FCC 03-324) says among others:
ยง 95.603 (h) Each Dedicated Short-Range Communications Service
On-Board Unit (DSRCS-OBU) that operates or is intended to operate
in the DSRCS (5.850-5.925 GHz) must be certified in accordance
with subpart L of this part and subpart J of part 2 of this
chapter.
Especially the US regulatory suggests that using
CFG80211_CERTIFICATION_ONUS might have sense (see the previous version
http://www.mail-archive.com/[email protected]/msg15228.html).
What do you think?
Thanks.
-Michal & Jan
drivers/net/wireless/ath/ath9k/common-init.c | 19 +++++++++++++++++++
drivers/net/wireless/ath/ath9k/hw.h | 2 +-
drivers/net/wireless/ath/regd.c | 17 ++++++++++++-----
3 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common-init.c b/drivers/net/wireless/ath/ath9k/common-init.c
index a006c14..0b61c63 100644
--- a/drivers/net/wireless/ath/ath9k/common-init.c
+++ b/drivers/net/wireless/ath/ath9k/common-init.c
@@ -86,6 +86,25 @@ static const struct ieee80211_channel ath9k_5ghz_chantable[] = {
CHAN5G(5785, 35), /* Channel 157 */
CHAN5G(5805, 36), /* Channel 161 */
CHAN5G(5825, 37), /* Channel 165 */
+
+ /* ITS-G5B */
+ CHAN5G(5855, 38), /* Channel 171 */
+ CHAN5G(5860, 39), /* Channel 172 */
+ CHAN5G(5865, 40), /* Channel 173 */
+ CHAN5G(5870, 41), /* Channel 174 */
+ /* ITS-G5A */
+ CHAN5G(5875, 42), /* Channel 175 */
+ CHAN5G(5880, 43), /* Channel 176 */
+ CHAN5G(5885, 44), /* Channel 177 */
+ CHAN5G(5890, 45), /* Channel 178 */
+ CHAN5G(5895, 46), /* Channel 179 */
+ CHAN5G(5900, 47), /* Channel 180 */
+ CHAN5G(5905, 48), /* Channel 181 */
+ /* ITS-G5D */
+ CHAN5G(5910, 49), /* Channel 182 */
+ CHAN5G(5915, 50), /* Channel 183 */
+ CHAN5G(5920, 51), /* Channel 184 */
+ CHAN5G(5925, 52), /* Channel 185 */
};
/* Atheros hardware rate code addition for short premble */
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index e8454db..debf609 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -73,7 +73,7 @@
#define ATH9K_RSSI_BAD -128
-#define ATH9K_NUM_CHANNELS 38
+#define ATH9K_NUM_CHANNELS 53
/* Register read/write primitives */
#define REG_WRITE(_ah, _reg, _val) \
diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index 444bd28..1f8b209 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -50,6 +50,8 @@ static int __ath_regd_init(struct ath_regulatory *reg);
#define ATH9K_5GHZ_5725_5850 REG_RULE(5725-10, 5850+10, 80, 0, 30,\
NL80211_RRF_NO_IR)
+#define ATH9K_5GHZ_ITSG5 REG_RULE(5855-5, 5925+5, 10, 0, 33, 0)
+
#define ATH9K_2GHZ_ALL ATH9K_2GHZ_CH01_11, \
ATH9K_2GHZ_CH12_13, \
ATH9K_2GHZ_CH14
@@ -64,53 +66,58 @@ static int __ath_regd_init(struct ath_regulatory *reg);
/* Can be used for:
* 0x60, 0x61, 0x62 */
static const struct ieee80211_regdomain ath_world_regdom_60_61_62 = {
- .n_reg_rules = 5,
+ .n_reg_rules = 6,
.alpha2 = "99",
.reg_rules = {
ATH9K_2GHZ_ALL,
ATH9K_5GHZ_ALL,
+ ATH9K_5GHZ_ITSG5,
}
};
/* Can be used by 0x63 and 0x65 */
static const struct ieee80211_regdomain ath_world_regdom_63_65 = {
- .n_reg_rules = 4,
+ .n_reg_rules = 5,
.alpha2 = "99",
.reg_rules = {
ATH9K_2GHZ_CH01_11,
ATH9K_2GHZ_CH12_13,
ATH9K_5GHZ_NO_MIDBAND,
+ ATH9K_5GHZ_ITSG5,
}
};
/* Can be used by 0x64 only */
static const struct ieee80211_regdomain ath_world_regdom_64 = {
- .n_reg_rules = 3,
+ .n_reg_rules = 4,
.alpha2 = "99",
.reg_rules = {
ATH9K_2GHZ_CH01_11,
ATH9K_5GHZ_NO_MIDBAND,
+ ATH9K_5GHZ_ITSG5,
}
};
/* Can be used by 0x66 and 0x69 */
static const struct ieee80211_regdomain ath_world_regdom_66_69 = {
- .n_reg_rules = 3,
+ .n_reg_rules = 4,
.alpha2 = "99",
.reg_rules = {
ATH9K_2GHZ_CH01_11,
ATH9K_5GHZ_ALL,
+ ATH9K_5GHZ_ITSG5,
}
};
/* Can be used by 0x67, 0x68, 0x6A and 0x6C */
static const struct ieee80211_regdomain ath_world_regdom_67_68_6A_6C = {
- .n_reg_rules = 4,
+ .n_reg_rules = 5,
.alpha2 = "99",
.reg_rules = {
ATH9K_2GHZ_CH01_11,
ATH9K_2GHZ_CH12_13,
ATH9K_5GHZ_ALL,
+ ATH9K_5GHZ_ITSG5,
}
};
--
2.5.3
On Mon, Nov 02, 2015 at 11:22:57AM +0100, Michal Sojka wrote:
> The patch adds support for Intelligent Transportation System (ITS-G5)
> band to the ath9k driver.
NAK. This would enable use of licensed 5.9 GHz band on large number of
deployed "world roaming" cards. This would allow one to set up an AP on
such a channel and would also make station mode scan those channels with
active scan (i.e., sending Probe Request frames) on them by default for
every single full scan. That's not appropriate regardless of whether
CFG80211_CERTIFICATION_ONUS is set.
This would be bad from both regulatory enforcement view point (5.9 GHz
band is not allowed for this type of use) and normal use case
performance (adding more channels for scanning makes scans take longer
without there being any point in scanning a band that is not supposed to
have APs for normal station mode connection).
> in this second version of the patch we removed dependency on
> CFG80211_CERTIFICATION_ONUS as suggested by Johannes. We are, however,
> not sure whether this is the right thing to do.
>
> The problem is that ath9k uses (REGULATORY_STRICT_REG |
> REGULATORY_CUSTOM_REG), which means that in order to use the 5.9 GHz
> band, ath9k's private regdomain has to be extended. This in turn means
> that the 5.9 GHz band is enabled by default in many configurations. It
> can be disabled if one sends a regulatory hint and has valid regdb in
> user space, but this cannot be relied upon.
This sounds like a special use case and I don't see why upstream Linux
kernel should enable those channels regardless of kernel build
configuration. Proper regulatory rule enforcement is needed to prevent
the channels from being used in unlicensed use cases.
> Especially the US regulatory suggests that using
> CFG80211_CERTIFICATION_ONUS might have sense (see the previous version
> http://www.mail-archive.com/[email protected]/msg15228.html).
> What do you think?
I don't think it is sufficient to enable these channels based on any
kernel build configuration parameter. We must prevent accidental use of
these channels regardless of what config options a user might pick.
--
Jouni Malinen PGP id EFC895FA
On Mon, Nov 02, 2015 at 06:33:45PM +0100, Michal Sojka wrote:
> Can this be solved by having proper/new regulatory flags on these
> channels that would prohibit running AP or scanning on these channels?
I'm not sure that alone is sufficient, but yes, I think this should be
done as part of the solution. On the 5.9 GHz band, cfg80211 should allow
only the operations modes that are appropriate for that band.
> I expect that there will be quite a lot applications/devices that will
> need to communicate in this band. From technical point of view, it might
> be beneficial if there is one solid implementation available in the
> upstream Linux. I'm not sure about the legal point of view.
I agree that it would be convenient and maybe even beneficial in the end
as long as it is done in a way that meets the requirements for enforcing
rules on the licensed band.
> Can you image this "proper regulatory rule enforcement" as a part of
> upstream Linux? Do you have an idea how it would look like?
I'm not sure what would be sufficient. In general, I'm hesitant on
enabling any licensed bands for Wi-Fi operations by default regardless
of what the kernel configuration is.
> Would kernel config option + custom regdb be sufficient?
That would certainly be much closer to what I'd like to see from the
regulatory enforcement view point; not sure how convenient this is to
use with ath9k. I think the custom regdb route (i.e., require someone to
knowingly generate the explicit rules to enable the licensed bands and
only distribute the regdb with these changes to properly licensed users)
was one of the approaches discussed in the past for this type of use
cases.
--
Jouni Malinen PGP id EFC895FA
Hi Jouni,
thanks for quick reply.
On Mon, Nov 02 2015, Jouni Malinen wrote:
> On Mon, Nov 02, 2015 at 11:22:57AM +0100, Michal Sojka wrote:
>> The patch adds support for Intelligent Transportation System (ITS-G5)
>> band to the ath9k driver.
>
> NAK. This would enable use of licensed 5.9 GHz band on large number of
> deployed "world roaming" cards.
I agree that this is not good.
> This would allow one to set up an AP on such a channel and would also
> make station mode scan those channels with active scan (i.e., sending
> Probe Request frames) on them by default for every single full scan.
> That's not appropriate regardless of whether
> CFG80211_CERTIFICATION_ONUS is set.
Can this be solved by having proper/new regulatory flags on these
channels that would prohibit running AP or scanning on these channels?
> This would be bad from both regulatory enforcement view point (5.9 GHz
> band is not allowed for this type of use) and normal use case
> performance (adding more channels for scanning makes scans take longer
> without there being any point in scanning a band that is not supposed to
> have APs for normal station mode connection).
>
>> in this second version of the patch we removed dependency on
>> CFG80211_CERTIFICATION_ONUS as suggested by Johannes. We are, however,
>> not sure whether this is the right thing to do.
>>
>> The problem is that ath9k uses (REGULATORY_STRICT_REG |
>> REGULATORY_CUSTOM_REG), which means that in order to use the 5.9 GHz
>> band, ath9k's private regdomain has to be extended. This in turn means
>> that the 5.9 GHz band is enabled by default in many configurations. It
>> can be disabled if one sends a regulatory hint and has valid regdb in
>> user space, but this cannot be relied upon.
>
> This sounds like a special use case and I don't see why upstream Linux
> kernel should enable those channels regardless of kernel build
> configuration.
I expect that there will be quite a lot applications/devices that will
need to communicate in this band. From technical point of view, it might
be beneficial if there is one solid implementation available in the
upstream Linux. I'm not sure about the legal point of view.
> Proper regulatory rule enforcement is needed to prevent the channels
> from being used in unlicensed use cases.
Can you image this "proper regulatory rule enforcement" as a part of
upstream Linux? Do you have an idea how it would look like?
>> Especially the US regulatory suggests that using
>> CFG80211_CERTIFICATION_ONUS might have sense (see the previous version
>> http://www.mail-archive.com/[email protected]/msg15228.html).
>> What do you think?
>
> I don't think it is sufficient to enable these channels based on any
> kernel build configuration parameter. We must prevent accidental use of
> these channels regardless of what config options a user might pick.
Would kernel config option + custom regdb be sufficient?
Cheers.
-Michal
On Mon, Nov 02, 2015 at 07:38:57PM +0100, Michal Sojka wrote:
> We discussed that about a year ago [1]. The thing is that regulatory
> documents do not talk about modes (at least in Europe). They only talk
> about channel widths, EIRP etc. and say that the band is designated for
> Intelligent Transportation System (ITS) applications. Only the ITS
> standards (e.g. ETSI EN 302 663) talk about OCB mode. From the last
> year's discussion I took away that we should not restrict these bands to
> OCB only, because regulatory documents do not require it. But I might
> get it wrong.
>
> [1] http://www.mail-archive.com/[email protected]/msg656581.html
In some sense, I agree with that, but taken into account that I'm much
more concerned about accidentally using this band, I think there is
justification for adding that extra constraint of allowing only the OCB
mode to be used even if the regulatory requirements may not explicitly
say so. Especially the behavior of including these channels with active
scanning allowed in all full scans is something that really must not be
enabled.
> Hmm, ath9k is the hardware that we can currently play with. Can you
> suggest another hardware that supports 5.9 GHz and a driver that would
> be more convenient to develop with?
I don't think there is any hardware alternative that would be more
convenient for this type of efforts than chips supported by ath9k. It is
just that the needs of this project are somewhat in conflict with the
needs of regulatory rule enforcement for most other use cases.. :)
--
Jouni Malinen PGP id EFC895FA
On Mon, Nov 02 2015, Jouni Malinen wrote:
> On Mon, Nov 02, 2015 at 06:33:45PM +0100, Michal Sojka wrote:
>> Can this be solved by having proper/new regulatory flags on these
>> channels that would prohibit running AP or scanning on these channels?
>
> I'm not sure that alone is sufficient, but yes, I think this should be
> done as part of the solution. On the 5.9 GHz band, cfg80211 should allow
> only the operations modes that are appropriate for that band.
We discussed that about a year ago [1]. The thing is that regulatory
documents do not talk about modes (at least in Europe). They only talk
about channel widths, EIRP etc. and say that the band is designated for
Intelligent Transportation System (ITS) applications. Only the ITS
standards (e.g. ETSI EN 302 663) talk about OCB mode. From the last
year's discussion I took away that we should not restrict these bands to
OCB only, because regulatory documents do not require it. But I might
get it wrong.
[1] http://www.mail-archive.com/[email protected]/msg656581.html
>
>> I expect that there will be quite a lot applications/devices that will
>> need to communicate in this band. From technical point of view, it might
>> be beneficial if there is one solid implementation available in the
>> upstream Linux. I'm not sure about the legal point of view.
>
> I agree that it would be convenient and maybe even beneficial in the end
> as long as it is done in a way that meets the requirements for enforcing
> rules on the licensed band.
>
>> Can you image this "proper regulatory rule enforcement" as a part of
>> upstream Linux? Do you have an idea how it would look like?
>
> I'm not sure what would be sufficient. In general, I'm hesitant on
> enabling any licensed bands for Wi-Fi operations by default regardless
> of what the kernel configuration is.
>
>> Would kernel config option + custom regdb be sufficient?
>
> That would certainly be much closer to what I'd like to see from the
> regulatory enforcement view point; not sure how convenient this is to
> use with ath9k.
Hmm, ath9k is the hardware that we can currently play with. Can you
suggest another hardware that supports 5.9 GHz and a driver that would
be more convenient to develop with?
> I think the custom regdb route (i.e., require someone to knowingly
> generate the explicit rules to enable the licensed bands and only
> distribute the regdb with these changes to properly licensed users)
> was one of the approaches discussed in the past for this type of use
> cases.
Thanks for all the input. We will try to come up with another solution.
Regards.
-Michal