| Message ID | 1401468984-24575-2-git-send-email-rostislav.lisovy@fel.cvut.cz (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Fri, 2014-05-30 at 18:56 +0200, Rostislav Lisovy wrote: > IEEE 802.11p operates in its own 5.9GHz band. When there will > be a record for the 5.9GHz band in the regulatory daemon, > it must be limited to the OCB mode only -- using the newly > added flags. Is this really a *regulatory* limitation? Rather than a limitation elsewhere, e.g. the spec? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 03, 2014 at 10:01:33PM +0200, Johannes Berg wrote: > On Fri, 2014-05-30 at 18:56 +0200, Rostislav Lisovy wrote: > > IEEE 802.11p operates in its own 5.9GHz band. When there will > > be a record for the 5.9GHz band in the regulatory daemon, > > it must be limited to the OCB mode only -- using the newly > > added flags. > > Is this really a *regulatory* limitation? Rather than a limitation > elsewhere, e.g. the spec? Our engaged and capable *real* regulatory folks in the community are: * Liraz Perelmooter <liraz.perelmooter@intel.com> * Michael Green <green@qti.qualcomm.com> Additionally we have the wireless-regdb mailing list [0] which we should Cc for inquiries and verification on things like this. We hope for their participation as they are our real experts who grind away at the specs. Rostislav, can you provide documentation references which would clarify the stance on 802.11p and restrictions for only allowing OCB mode? Also your patches seem to refer to the 802.11p ammendment work to 802.11, but it is now merged as of IEEE 802.11-2012 as per Jouni's last update to us on the standards work [1]. As per Jouni's slides 802.11p-2010 made it as an ammendment into 802.11-2012 and this work is rerrred to as "Wireless Access for the Vehicular Environent". It would be *useful* if you'd refer to the IEEE 802.11-2012 standard then and document as part of your patches the exact sections and references that about Wireless Access for the Vehicular Environment. For reference to others this comes in as a full patch series by Rostislav to add some form of "802.11p" support using OCB (Outside the Context of BSS) mode. This mode of operation allows devices to send frames not connected to a BSS. The patch in question above is for the regulatory flag that is being proposed to be added, the full series of the other patches can be seen on the mailing list archive [2]. Rostislav clarifies that when OCB mode is used all the STAs communicate with each other without the need for a coordinator. The 5.9 GHz band is being clarified to be used for 802.11p, the patch series also is specifying that when 5.9 GHz is enabled only OCB mode of operation is allowed on that band. No references are made to the specific 802.11 ammendment / IEEE 802.11 sections or more importantly it is not being made clear if the OCB mode is something that differs depending on regulatory bodies at this point. Since 802.11p was designed for cars in mind I suspect regulatory bodies likely do want proper rules followed, but its unclear what countries that follow either IEEE 802.11 or the ISO equivalent want OCB mode of operation and if they also have the same restrictions of only allowing 5.9 GHz operation only for OCB. I can also imagine for example of regulatory bodies that may want to allow 5.9 GHz for non OCB mode, specially if they need the spectrum. One particular use case which provides a compromise could be for example to have APs/P2P GOs look for OCB communication and if its detected to disallow it. Not like I would recommend this given that it would then introduce crazy regulatory compliance silliness such as seen with DFS and that pushed crazy implementation and designs, but -- its certainly possible. So is this an IEEE compliance thing or regulatory thing? If its a generally accepted IEEE compliance thing for 802.11-2012 then I don't see why we don't just hard code this restriction on cfg80211 for the band. That after all would be the much more saner thing to do than all the silly mess of discrepencies betwen regulatory bodies. After all cfg80211 is for 802.11, and if we follow the specs and if its mentioned clearly there I see no resason why not to hard code this. If folks want to override this (I envision university environments doing research on this) the patch can add a Kconfig option that depends on CONFIG_CFG80211_CERTIFICATION_ONUS which will make the check permissive on 5.9 GHz instead of fully enforced. [0] http://lists.infradead.org/mailman/listinfo/wireless-regdb [1] http://wireless.kernel.org/en/developers/Summits/Barcelona-2012?action=AttachFile&do=view&target=ieee80211-barcelona-2012.pdf [2] http://comments.gmane.org/gmane.linux.kernel.wireless.general/121022 Luis
Dear Luis; Thank you for the introduction in the wireless-regdb mailing-list. On Wed, 2014-06-04 at 00:18 +0200, Luis R. Rodriguez wrote: > Rostislav, can you provide documentation references which would > clarify > the stance on 802.11p and restrictions for only allowing OCB mode? If I may cite the 802.11-2012 standard: -- 1st Quote 4.3.11 STA transmission of data frames outside the context of a BSS Communication of data frames when dot11OCBActivated is true might take place in a frequency band that is dedicated for its use, and such a band might require licensing depending on the regulatory domain. A STA for which dot11OCBActivated is true initially transmits and receives on a channel known in advance, either through regulatory designation or some other out-of-band communication. -- End of quote -- 2nd Quote Annex E (normative) Country elements and operating classes E.2.3 5.9 GHz band in the United States (5.850–5.925 GHz) ... STAs shall have dot11OCBActivated set to true. E.2.4 5.9 GHz band in Europe (5.855–5.925 GHz) STAs shall have dot11OCBActivated set to true. -- end of quote Regards; Rostislav -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jun 9, 2014 at 7:21 AM, Rostislav Lisovy <lisovy@gmail.com> wrote: > Dear Luis; > Thank you for the introduction in the wireless-regdb mailing-list. > > On Wed, 2014-06-04 at 00:18 +0200, Luis R. Rodriguez wrote: >> Rostislav, can you provide documentation references which would >> clarify >> the stance on 802.11p and restrictions for only allowing OCB mode? > > If I may cite the 802.11-2012 standard: > -- 1st Quote > 4.3.11 STA transmission of data frames outside the context of a BSS > > Communication of data frames when dot11OCBActivated is true might take > place in a frequency band that is dedicated for its use, and such a band > might require licensing depending on the regulatory domain. A STA for > which dot11OCBActivated is true initially transmits and receives on a > channel known in advance, either through regulatory designation or some > other out-of-band communication. > -- End of quote OK the spec does not rule out communication on that special band for regular operation as such that special band is mentioned in the context of OCB communication, but it does say that the frequency range may be licensed. As it stands the public wireless-regdb only covers unlicensed frequency ranges, but it obviously can support licensed frequency ranges, just that the distribution mechanism and integration of the wireless-regdb files then would have to be done separately through separate distributors -- ie, not upstream. If the OCB bands are unlicensed then we can surely add them to wireless-regdb, however it remains unclear if those bands are unlicensed if we can use them for regular non OCB communication. Follow this logic to move forward then: * Poke folks to see if the US band for OCB is licensed or unlicensed * Poke folks to see if the EU band for OCB is licensed or unlicensed * If the bands are licensed then the wireless-regdb changes that would be needed imply that a wireless-regdb needs to be provided to whatever customer by whomever is licensing that entity for usage of that band, that is, we upstream can be removed from the equation of the distribution. The upstream kernel however would require a flag for frequency ranges for OCB frequency ranges. Although the regulatory classes specify a few for the US and EU, this can likely change. I forget if the regulatory class can be interpreted through IEs, if so and if the specification is going to remain static I can envision the ability to hard code the OCB frequency ranges upstream but you'd then need to parse these things. * If the bands are *not licensed* there is one corner case that I still think should be reviewed by regulatory folks: having an OCB frequency range unlicensed under the current reading of the specification of 802.11-2012 means that 802.11 devices *can* use them for OCB, however if OCB is not enabled on the device it seems to be that OCB bands can be used for non OCB communication. Furthermore 4.3.11 seems to be saying that it is only optional to use a dedicated frequency for OCB, OCB can happen on other frequency ranges. > -- 2nd Quote > Annex E (normative) Country elements and operating classes > E.2.3 5.9 GHz band in the United States (5.850–5.925 GHz) > ... > STAs shall have dot11OCBActivated set to true. So all STAs in the US wil have OCB activated? I fail to understand how Annex E should be read in the context of operating classes. > E.2.4 5.9 GHz band in Europe (5.855–5.925 GHz) > STAs shall have dot11OCBActivated set to true. Ditto. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dear Luis and others, I work with Rostislav on the Linux support of ITS-G5. I did some research on the regulatory staff for 5.9 GHz band. See my findings below and sorry for long delay of my reply. On Tue, Jun 10 2014, Luis R. Rodriguez wrote: > On Mon, Jun 9, 2014 at 7:21 AM, Rostislav Lisovy <lisovy@gmail.com> wrote: >> Dear Luis; >> Thank you for the introduction in the wireless-regdb mailing-list. >> >> On Wed, 2014-06-04 at 00:18 +0200, Luis R. Rodriguez wrote: >>> Rostislav, can you provide documentation references which would >>> clarify >>> the stance on 802.11p and restrictions for only allowing OCB mode? >> >> If I may cite the 802.11-2012 standard: >> -- 1st Quote >> 4.3.11 STA transmission of data frames outside the context of a BSS >> >> Communication of data frames when dot11OCBActivated is true might take >> place in a frequency band that is dedicated for its use, and such a band >> might require licensing depending on the regulatory domain. A STA for >> which dot11OCBActivated is true initially transmits and receives on a >> channel known in advance, either through regulatory designation or some >> other out-of-band communication. >> -- End of quote > > OK the spec does not rule out communication on that special band for > regular operation as such that special band is mentioned in the > context of OCB communication, but it does say that the frequency range > may be licensed. As it stands the public wireless-regdb only covers > unlicensed frequency ranges, but it obviously can support licensed > frequency ranges, just that the distribution mechanism and integration > of the wireless-regdb files then would have to be done separately > through separate distributors -- ie, not upstream. If the OCB bands > are unlicensed then we can surely add them to wireless-regdb, however > it remains unclear if those bands are unlicensed if we can use them > for regular non OCB communication. > > Follow this logic to move forward then: > > * Poke folks to see if the US band for OCB is licensed or unlicensed > * Poke folks to see if the EU band for OCB is licensed or unlicensed I only researched status in the EU. In summary, the band is unlicensed. The relevant document for Europe is 2008/671/EC (see below). This was confirmed to us by Czech Telecommunication Office which is responsible for the administration of radio frequencies in the Czech republic. The document can be found at http://www.erodocdb.dk/docs/doc98/official/pdf/2008671EC.pdf and its full name is "2008/671/EC, Commission Decision of 5 August 2008 on the harmonised use of radio spectrum in the 5 875-5 905 MHz frequency band for safety-related applications of Intelligent Transport Systems (ITS)". Few quotes from the document: Article 3 §1: Member States shall, not later than six months after entry into force of this Decision, designate the frequency band 5 875-5 905 MHz for Intelligent Transport Systems and, as soon as reasonably practicable following such designation, make that frequency band available on a non-exclusive basis. Such designation shall be in compliance with the parameters set out in the Annex. Annex: Maximum spectral power density (mean e.i.r.p.): 23 dBm/MHz Maximum total transmit power (mean e.i.r.p.): 33 dBm Channel access and occupation rules: Techniques to mitigate interference that provide at least equivalent performance to the techniques described in harmonised standards adopted under Directive 1999/5/EC must be used. These require a transmitter power control (TPC) range of at least 30 dB. Intro (8): Harmonised standard EN 302 571 [...], thus ensuring that compliant ITS equipment avoids causing harmful interference. The EN 302 571 standard describes in detail the technical parameters mentioned above. See http://www.etsi.org/deliver/etsi_en/302500_302599/302571/01.01.01_60/en_302571v010101p.pdf This all means that the band in unlicensed and can be used by anybody compliant with the annex parameters. This interpretation was explicitly confirmed by Czech Telecommunication Office. I've also found the document ECC/DEC/(08)01 (see below) which predates 2008/671/EC, but since it also mentions 2008/671/EC it seems it is basically the same thing. ECC Decision of 14 March 2008 on the harmonised use of the 5875-5925 MHz frequency band for Intelligent Transport Systems (ITS) (ECC/DEC/(08)01) (2008/671/EC) [http://www.erodocdb.dk/docs/doc98/official/Pdf/ECCDec0801.pdf] The document, among others, says: 3. that CEPT administrations shall designate the frequency sub-band 5875-5905 MHz on a non-exclusive basis for ITS road safety applications; 8. that CEPT administrations shall exempt in-vehicle ITS equipment from individual licensing; > * If the bands are *not licensed* there is one corner case that I > still think should be reviewed by regulatory folks: having an OCB > frequency range unlicensed under the current reading of the > specification of 802.11-2012 means that 802.11 devices *can* use them > for OCB, however if OCB is not enabled on the device it seems to be > that OCB bands can be used for non OCB communication. Furthermore > 4.3.11 seems to be saying that it is only optional to use a dedicated > frequency for OCB, OCB can happen on other frequency ranges. I see it similarly. The use of OCB is not a regulatory requirement. As it was mentioned by Rostislav, IEEE 802.11-2012 specifies in section "E.2.4 5.9 GHz band in Europe (5.855–5.925 GHz)": STAs shall have dot11OCBActivated set to true. Section 4.3.11 then reads: When dot11OCBActivated is true, a STA is not a member of a BSS and it does not utilize the IEEE 802.11 authentication, association, or data confidentiality services. Note that magic words like "shall" or "should" are not present in this text. I would interpret this as that OCB mode should be forced in the 5.855–5.925 GHz band (i.e. hard-coded in the Linux kernel) and that no other modes should be allowed there. Section 10.20 uses proper words: When a STA joins a BSS, it shall set dot11OCBActivated to false. The STA shall keep dot11OCBActivated false while joined with the BSS or while the STA is the AP within a BSS. If a STA does not include the dot11OCBActivated MIB attribute, the STA shall operate as if the attribute is false. The other question is whether OCB mode should be allowed in other frequency bands. As far as I know, nothing prevents it. >> -- 2nd Quote >> Annex E (normative) Country elements and operating classes >> E.2.3 5.9 GHz band in the United States (5.850–5.925 GHz) >> ... >> STAs shall have dot11OCBActivated set to true. > > So all STAs in the US wil have OCB activated? I fail to understand how > Annex E should be read in the context of operating classes. > >> E.2.4 5.9 GHz band in Europe (5.855–5.925 GHz) >> STAs shall have dot11OCBActivated set to true. > > Ditto. I understand that dot11OCBActivated can be changed at runtime. STAs operating in the mentioned band "shall have dot11OCBActivated set to true". Best regards, -Michal -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 01, 2014 at 04:00:34PM +0200, Michal Sojka wrote: > Dear Luis and others, > > I work with Rostislav on the Linux support of ITS-G5. I did some > research on the regulatory staff for 5.9 GHz band. See my findings below > and sorry for long delay of my reply. I'm a bit late on mine as well. > On Tue, Jun 10 2014, Luis R. Rodriguez wrote: > > On Mon, Jun 9, 2014 at 7:21 AM, Rostislav Lisovy <lisovy@gmail.com> wrote: > >> Dear Luis; > >> Thank you for the introduction in the wireless-regdb mailing-list. > >> > >> On Wed, 2014-06-04 at 00:18 +0200, Luis R. Rodriguez wrote: > >>> Rostislav, can you provide documentation references which would > >>> clarify > >>> the stance on 802.11p and restrictions for only allowing OCB mode? > >> > >> If I may cite the 802.11-2012 standard: > >> -- 1st Quote > >> 4.3.11 STA transmission of data frames outside the context of a BSS > >> > >> Communication of data frames when dot11OCBActivated is true might take > >> place in a frequency band that is dedicated for its use, and such a band > >> might require licensing depending on the regulatory domain. A STA for > >> which dot11OCBActivated is true initially transmits and receives on a > >> channel known in advance, either through regulatory designation or some > >> other out-of-band communication. > >> -- End of quote > > > > OK the spec does not rule out communication on that special band for > > regular operation as such that special band is mentioned in the > > context of OCB communication, but it does say that the frequency range > > may be licensed. As it stands the public wireless-regdb only covers > > unlicensed frequency ranges, but it obviously can support licensed > > frequency ranges, just that the distribution mechanism and integration > > of the wireless-regdb files then would have to be done separately > > through separate distributors -- ie, not upstream. If the OCB bands > > are unlicensed then we can surely add them to wireless-regdb, however > > it remains unclear if those bands are unlicensed if we can use them > > for regular non OCB communication. > > > > Follow this logic to move forward then: > > > > * Poke folks to see if the US band for OCB is licensed or unlicensed > > * Poke folks to see if the EU band for OCB is licensed or unlicensed > > I only researched status in the EU. In summary, the band is unlicensed. > > The relevant document for Europe is 2008/671/EC (see below). This was > confirmed to us by Czech Telecommunication Office which is responsible > for the administration of radio frequencies in the Czech republic. > > The document can be found at > http://www.erodocdb.dk/docs/doc98/official/pdf/2008671EC.pdf and its > full name is "2008/671/EC, Commission Decision of 5 August 2008 on the > harmonised use of radio spectrum in the 5 875-5 905 MHz frequency band > for safety-related applications of Intelligent Transport Systems (ITS)". > > Few quotes from the document: > > Article 3 §1: > > Member States shall, not later than six months after entry > into force of this Decision, designate the frequency band > 5 875-5 905 MHz for Intelligent Transport Systems and, as > soon as reasonably practicable following such designation, > make that frequency band available on a non-exclusive > basis. > > Such designation shall be in compliance with the > parameters set out in the Annex. > > Annex: > > Maximum spectral power density (mean e.i.r.p.): 23 dBm/MHz > Maximum total transmit power (mean e.i.r.p.): 33 dBm > Channel access and occupation rules: > > Techniques to mitigate interference that provide at least > equivalent performance to the techniques described in > harmonised standards adopted under Directive 1999/5/EC > must be used. These require a transmitter power control > (TPC) range of at least 30 dB. > > Intro (8): > > Harmonised standard EN 302 571 [...], thus ensuring that > compliant ITS equipment avoids causing harmful interference. > > The EN 302 571 standard describes in detail the technical parameters > mentioned above. See > http://www.etsi.org/deliver/etsi_en/302500_302599/302571/01.01.01_60/en_302571v010101p.pdf > > This all means that the band in unlicensed and can be used by anybody > compliant with the annex parameters. This interpretation was explicitly > confirmed by Czech Telecommunication Office. > > I've also found the document ECC/DEC/(08)01 (see below) which predates > 2008/671/EC, but since it also mentions 2008/671/EC it seems it is > basically the same thing. > > ECC Decision of 14 March 2008 on the harmonised use of the 5875-5925 > MHz frequency band for Intelligent Transport Systems (ITS) > > (ECC/DEC/(08)01) (2008/671/EC) > > [http://www.erodocdb.dk/docs/doc98/official/Pdf/ECCDec0801.pdf] > > The document, among others, says: > > 3. that CEPT administrations shall designate the frequency sub-band > 5875-5905 MHz on a non-exclusive basis for ITS road safety > applications; > > 8. that CEPT administrations shall exempt in-vehicle ITS equipment > from individual licensing; Awesome work > > * If the bands are *not licensed* there is one corner case that I > > still think should be reviewed by regulatory folks: having an OCB > > frequency range unlicensed under the current reading of the > > specification of 802.11-2012 means that 802.11 devices *can* use them > > for OCB, however if OCB is not enabled on the device it seems to be > > that OCB bands can be used for non OCB communication. Furthermore > > 4.3.11 seems to be saying that it is only optional to use a dedicated > > frequency for OCB, OCB can happen on other frequency ranges. > > I see it similarly. > > The use of OCB is not a regulatory requirement. As it was mentioned by > Rostislav, IEEE 802.11-2012 specifies in section "E.2.4 5.9 GHz band in > Europe (5.855–5.925 GHz)": > > STAs shall have dot11OCBActivated set to true. > > Section 4.3.11 then reads: > > When dot11OCBActivated is true, a STA is not a member of a BSS and > it does not utilize the IEEE 802.11 authentication, association, > or data confidentiality services. > > Note that magic words like "shall" or "should" are not present in this > text. > > I would interpret this as that OCB mode should be forced in the > 5.855–5.925 GHz band (i.e. hard-coded in the Linux kernel) and that no > other modes should be allowed there. There I disagree, if its not a regulatory requirement forcing something on Linux is prone to be hacked around, so to avoid issues also with regulatory bodies what we do is enable R&D folks to use certain features undera CONFIG_CFG80211_CERTIFICATION_ONUS so I think a reasonable compromise is that by default Linux ships with what you say but we enable researchers and developers to customie their kernels and use the OCB bands for other purposes. That doesn't mean we need to support it -- it just means if someone wants to hack on the code to do it we should give them the freedom to do so. That means we can ignore OCB bands for non-OCB purposes for now completely and just let whoever wants to do something different to use CONFIG_CFG80211_CERTIFICATION_ONUS. I can also see conflicts with non OCB devices on OCB bands so its importan for us to not fuck with that loosely too. > Section 10.20 uses proper words: > > When a STA joins a BSS, it shall set dot11OCBActivated to false. The STA > shall keep dot11OCBActivated false while joined with the BSS or while > the STA is the AP within a BSS. If a STA does not include the > dot11OCBActivated MIB attribute, the STA shall operate as if the > attribute is false. > > The other question is whether OCB mode should be allowed in other > frequency bands. As far as I know, nothing prevents it. OK -- again CONFIG_CFG80211_CERTIFICATION_ONUS :) if someone decides to tinker lets let them. But Linux by default should be have IEEE compliant and regulatory compliant. > >> -- 2nd Quote > >> Annex E (normative) Country elements and operating classes > >> E.2.3 5.9 GHz band in the United States (5.850–5.925 GHz) > >> ... > >> STAs shall have dot11OCBActivated set to true. > > > > So all STAs in the US wil have OCB activated? I fail to understand how > > Annex E should be read in the context of operating classes. > > > >> E.2.4 5.9 GHz band in Europe (5.855–5.925 GHz) > >> STAs shall have dot11OCBActivated set to true. > > > > Ditto. > > I understand that dot11OCBActivated can be changed at runtime. STAs > operating in the mentioned band "shall have dot11OCBActivated set to > true". Cool, thanks for all your work on this. Folks -- hope this helps, chug on. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 5c7169b..6722ab2 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -115,6 +115,7 @@ enum ieee80211_band { * on this channel. * @IEEE80211_CHAN_NO_10MHZ: 10 MHz bandwidth is not permitted * on this channel. + * @IEEE80211_CHAN_OCB_ONLY: only OCB is allowed on this channel. * */ enum ieee80211_channel_flags { @@ -131,6 +132,7 @@ enum ieee80211_channel_flags { IEEE80211_CHAN_GO_CONCURRENT = 1<<10, IEEE80211_CHAN_NO_20MHZ = 1<<11, IEEE80211_CHAN_NO_10MHZ = 1<<12, + IEEE80211_CHAN_OCB_ONLY = 1<<13, }; #define IEEE80211_CHAN_NO_HT40 \ diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h index 406010d..970c5df 100644 --- a/include/uapi/linux/nl80211.h +++ b/include/uapi/linux/nl80211.h @@ -2362,6 +2362,8 @@ enum nl80211_band_attr { * 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_OCB_ONLY: no other than OCB networks are + * permitted on this channel in current regulatory domain. * @NL80211_FREQUENCY_ATTR_MAX: highest frequency attribute number * currently defined * @__NL80211_FREQUENCY_ATTR_AFTER_LAST: internal use @@ -2390,6 +2392,7 @@ enum nl80211_frequency_attr { NL80211_FREQUENCY_ATTR_GO_CONCURRENT, NL80211_FREQUENCY_ATTR_NO_20MHZ, NL80211_FREQUENCY_ATTR_NO_10MHZ, + NL80211_FREQUENCY_ATTR_OCB_ONLY, /* keep last */ __NL80211_FREQUENCY_ATTR_AFTER_LAST, @@ -2558,6 +2561,7 @@ enum nl80211_sched_scan_match_attr { * @NL80211_RRF_AUTO_BW: maximum available bandwidth should be calculated * base on contiguous rules and wider channels will be allowed to cross * multiple contiguous/overlapping frequency ranges. + * @NL80211_RRF_OCB_ONLY: no other than OCB is allowed */ enum nl80211_reg_rule_flags { NL80211_RRF_NO_OFDM = 1<<0, @@ -2570,6 +2574,7 @@ enum nl80211_reg_rule_flags { NL80211_RRF_NO_IR = 1<<7, __NL80211_RRF_NO_IBSS = 1<<8, NL80211_RRF_AUTO_BW = 1<<11, + NL80211_RRF_OCB_ONLY = 1<<12, }; #define NL80211_RRF_PASSIVE_SCAN NL80211_RRF_NO_IR diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index 0f1b18f2..c766c31 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -633,6 +633,9 @@ static int nl80211_msg_put_channel(struct sk_buff *msg, if ((chan->flags & IEEE80211_CHAN_NO_10MHZ) && nla_put_flag(msg, NL80211_FREQUENCY_ATTR_NO_10MHZ)) goto nla_put_failure; + if ((chan->flags & IEEE80211_CHAN_OCB_ONLY) && + nla_put_flag(msg, NL80211_FREQUENCY_ATTR_OCB_ONLY)) + goto nla_put_failure; } if (nla_put_u32(msg, NL80211_FREQUENCY_ATTR_MAX_TX_POWER, diff --git a/net/wireless/reg.c b/net/wireless/reg.c index e78f532..74e41f7 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -906,6 +906,8 @@ static u32 map_regdom_flags(u32 rd_flags) channel_flags |= IEEE80211_CHAN_NO_OFDM; if (rd_flags & NL80211_RRF_NO_OUTDOOR) channel_flags |= IEEE80211_CHAN_INDOOR_ONLY; + if (rd_flags & NL80211_RRF_OCB_ONLY) + channel_flags |= IEEE80211_CHAN_OCB_ONLY; return channel_flags; }
IEEE 802.11p operates in its own 5.9GHz band. When there will be a record for the 5.9GHz band in the regulatory daemon, it must be limited to the OCB mode only -- using the newly added flags. Signed-off-by: Rostislav Lisovy <rostislav.lisovy@fel.cvut.cz> --- include/net/cfg80211.h | 2 ++ include/uapi/linux/nl80211.h | 5 +++++ net/wireless/nl80211.c | 3 +++ net/wireless/reg.c | 2 ++ 4 files changed, 12 insertions(+)