[RFC 0/4 v2] cfg80211/mac80211: Add new interface type for OCB (Outside the Context of a BSS) mode

[RFC 0/4 v2] cfg80211/mac80211: Add new interface type for OCB (Outside the Context of a BSS) mode

[Rostislav Lisovy]

The IEEE 802.11p amendment defines a procedure for data frames
transmission by an STA that is not a member of a BSS. Such data
frames are defined as being transmitted "outside the context of a
BSS" (this is allowed only if the MIB variable dot11OCBActivated is
true).  This patchset adds new interface type (NL80211_IFTYPE_OCB)
for an STA in the OCB mode.

When an OCB mode is used, all the STAs communicate with each other
without the need for a coordinator. In such case no beacons are
sent and BSSID is set to wildcard (all 1's). Every STA receives all
frames from every STA in range and transmits to every STA tuned to
the same channel. The communication is taking place in a reserved
frequency band (5.9 GHz).

This patchset presents work in progress. Patches adding *_leave_ocb()
functions and modifying RX/TX path in mac80211 to work with OCB
mode will come in near future.


Changes v1 --> v2:
* Added proper (__)cfg80211_join_ocb function
* Removed the infrastructure for ocb_housekeeping
  (has to be reworked and added in the future)
* OCB_ONLY channel flags are checked in __cfg80211_join_ocb()

Rostislav Lisovy (4):
  cfg80211: Add channel flags limiting availability to OCB mode only
  cfg80211: Add new interface type for OCB mode
  nl80211: Do not ignore 5/10MHz wide channels in nl80211_send_chandef()
  mac80211: OCB mode interface configuration

 include/net/cfg80211.h       |  9 ++++++
 include/uapi/linux/nl80211.h |  8 +++++
 net/mac80211/Makefile        |  3 +-
 net/mac80211/cfg.c           | 22 +++++++++++++
 net/mac80211/chan.c          |  1 +
 net/mac80211/driver-ops.h    |  3 +-
 net/mac80211/ieee80211_i.h   |  3 ++
 net/mac80211/iface.c         | 22 +++++++++++++
 net/mac80211/ocb.c           | 22 +++++++++++++
 net/mac80211/util.c          |  5 +++
 net/wireless/Makefile        |  2 +-
 net/wireless/chan.c          |  2 ++
 net/wireless/core.h          |  8 +++++
 net/wireless/nl80211.c       |  6 ++++
 net/wireless/ocb.c           | 75 ++++++++++++++++++++++++++++++++++++++++++++
 net/wireless/rdev-ops.h      | 11 +++++++
 net/wireless/reg.c           |  2 ++
 net/wireless/trace.h         | 17 ++++++++++
 net/wireless/util.c          |  5 ++-
 19 files changed, 222 insertions(+), 4 deletions(-)
 create mode 100644 net/mac80211/ocb.c
 create mode 100644 net/wireless/ocb.c

-- 
2.0.0.rc4

[RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only

[Rostislav Lisovy]

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(+)

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;
 }
 
-- 
2.0.0.rc4

Re: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only

[Johannes Berg]

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

Re: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only

[Luis R. Rodriguez]

[-- Attachment #1: Type: text/plain, Size: 4313 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: [wireless-regdb] [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only

[Luis R. Rodriguez]

[-- Attachment #1.1: Type: text/plain, Size: 4313 bytes --]

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 835 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only

[Rostislav Lisovy]

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

Re: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only

[Luis R. Rodriguez]

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

Re: [wireless-regdb] [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only

[Luis R. Rodriguez]

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

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only

[Luis R. Rodriguez]

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

Regulatory of 5.9 GHz band and OCB mode (was: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only)

[Michal Sojka]

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

Regulatory of 5.9 GHz band and OCB mode (was: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only)

[Michal Sojka]

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

Re: Regulatory of 5.9 GHz band and OCB mode (was: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only)

[Luis R. Rodriguez]

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

Re: [wireless-regdb] Regulatory of 5.9 GHz band and OCB mode (was: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only)

[Luis R. Rodriguez]

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

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: Regulatory of 5.9 GHz band and OCB mode (was: [RFC 1/4] cfg80211: Add channel flags limiting availability to OCB mode only)

[Luis R. Rodriguez]

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

[RFC 2/4] cfg80211: Add new interface type for OCB mode

[Rostislav Lisovy]

Add new OCB mode (outside the context of the BSS) interface
type as well as functions necessary to configure the interface
when 'joining' such network.

Signed-off-by: Rostislav Lisovy <rostislav.lisovy@fel.cvut.cz>
---
 include/net/cfg80211.h       |  7 +++++
 include/uapi/linux/nl80211.h |  3 ++
 net/wireless/Makefile        |  2 +-
 net/wireless/chan.c          |  2 ++
 net/wireless/core.h          |  8 +++++
 net/wireless/nl80211.c       |  1 +
 net/wireless/ocb.c           | 75 ++++++++++++++++++++++++++++++++++++++++++++
 net/wireless/rdev-ops.h      | 11 +++++++
 net/wireless/trace.h         | 17 ++++++++++
 net/wireless/util.c          |  5 ++-
 10 files changed, 129 insertions(+), 2 deletions(-)
 create mode 100644 net/wireless/ocb.c

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 6722ab2..c3879b8 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1314,6 +1314,11 @@ struct mesh_setup {
 	u32 basic_rates;
 };
 
+struct ocb_setup {
+	struct cfg80211_chan_def chandef;
+	u32 basic_rates;
+};
+
 /**
  * struct ieee80211_txq_params - TX queue parameters
  * @ac: AC identifier
@@ -2371,6 +2376,8 @@ struct cfg80211_ops {
 			     const struct mesh_setup *setup);
 	int	(*leave_mesh)(struct wiphy *wiphy, struct net_device *dev);
 
+	int	(*join_ocb)(struct wiphy *wiphy, struct net_device *dev,
+			    struct ocb_setup *setup);
 	int	(*change_bss)(struct wiphy *wiphy, struct net_device *dev,
 			      struct bss_parameters *params);
 
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 970c5df..250b8d8 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1994,6 +1994,8 @@ enum nl80211_attrs {
  *	and therefore can't be created in the normal ways, use the
  *	%NL80211_CMD_START_P2P_DEVICE and %NL80211_CMD_STOP_P2P_DEVICE
  *	commands to create and destroy one
+ * @NL80211_IF_TYPE_OCB: outside context of a bss
+ *	this mode corresponds to the MIB variable dot11OCBActivated=true
  * @NL80211_IFTYPE_MAX: highest interface type number currently defined
  * @NUM_NL80211_IFTYPES: number of defined interface types
  *
@@ -2013,6 +2015,7 @@ enum nl80211_iftype {
 	NL80211_IFTYPE_P2P_CLIENT,
 	NL80211_IFTYPE_P2P_GO,
 	NL80211_IFTYPE_P2P_DEVICE,
+	NL80211_IFTYPE_OCB,
 
 	/* keep last */
 	NUM_NL80211_IFTYPES,
diff --git a/net/wireless/Makefile b/net/wireless/Makefile
index a761670..4c9e39f 100644
--- a/net/wireless/Makefile
+++ b/net/wireless/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_WEXT_SPY) += wext-spy.o
 obj-$(CONFIG_WEXT_PRIV) += wext-priv.o
 
 cfg80211-y += core.o sysfs.o radiotap.o util.o reg.o scan.o nl80211.o
-cfg80211-y += mlme.o ibss.o sme.o chan.o ethtool.o mesh.o ap.o trace.o
+cfg80211-y += mlme.o ibss.o sme.o chan.o ethtool.o mesh.o ap.o trace.o ocb.o
 cfg80211-$(CONFIG_CFG80211_DEBUGFS) += debugfs.o
 cfg80211-$(CONFIG_CFG80211_WEXT) += wext-compat.o wext-sme.o
 cfg80211-$(CONFIG_CFG80211_INTERNAL_REGDB) += regdb.o
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 84d686e..a457085 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -370,6 +370,7 @@ int cfg80211_chandef_dfs_required(struct wiphy *wiphy,
 	case NL80211_IFTYPE_AP_VLAN:
 	case NL80211_IFTYPE_WDS:
 	case NL80211_IFTYPE_P2P_DEVICE:
+	case NL80211_IFTYPE_OCB:
 	case NL80211_IFTYPE_UNSPECIFIED:
 		break;
 	case NUM_NL80211_IFTYPES:
@@ -892,6 +893,7 @@ cfg80211_get_chan_state(struct wireless_dev *wdev,
 				*radar_detect |= BIT(wdev->chandef.width);
 		}
 		return;
+	case NL80211_IFTYPE_OCB:
 	case NL80211_IFTYPE_MONITOR:
 	case NL80211_IFTYPE_AP_VLAN:
 	case NL80211_IFTYPE_WDS:
diff --git a/net/wireless/core.h b/net/wireless/core.h
index e9afbf1..3d8fde5 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -290,6 +290,14 @@ int cfg80211_set_mesh_channel(struct cfg80211_registered_device *rdev,
 			      struct wireless_dev *wdev,
 			      struct cfg80211_chan_def *chandef);
 
+/* OCB */
+int __cfg80211_join_ocb(struct cfg80211_registered_device *rdev,
+			struct net_device *dev,
+			struct ocb_setup *setup);
+int cfg80211_join_ocb(struct cfg80211_registered_device *rdev,
+		      struct net_device *dev,
+		      struct ocb_setup *setup);
+
 /* AP */
 int __cfg80211_stop_ap(struct cfg80211_registered_device *rdev,
 		       struct net_device *dev, bool notify);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c766c31..79bae31 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1859,6 +1859,7 @@ static bool nl80211_can_set_dev_channel(struct wireless_dev *wdev)
 	 * operation to set the monitor channel if possible.
 	 */
 	return !wdev ||
+		wdev->iftype == NL80211_IFTYPE_OCB ||
 		wdev->iftype == NL80211_IFTYPE_AP ||
 		wdev->iftype == NL80211_IFTYPE_MESH_POINT ||
 		wdev->iftype == NL80211_IFTYPE_MONITOR ||
diff --git a/net/wireless/ocb.c b/net/wireless/ocb.c
new file mode 100644
index 0000000..66da583
--- /dev/null
+++ b/net/wireless/ocb.c
@@ -0,0 +1,75 @@
+/* OCB mode implementation
+ * Copyright 2014, Czech Technical University in Prague, Rostislav Lisovy
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/ieee80211.h>
+#include <net/cfg80211.h>
+#include "nl80211.h"
+#include "core.h"
+#include "rdev-ops.h"
+
+
+int __cfg80211_join_ocb(struct cfg80211_registered_device *rdev,
+			struct net_device *dev,
+			struct ocb_setup *setup)
+{
+	struct wireless_dev *wdev = dev->ieee80211_ptr;
+	int err;
+
+	ASSERT_WDEV_LOCK(wdev);
+
+	if (dev->ieee80211_ptr->iftype != NL80211_IFTYPE_OCB)
+		return -EOPNOTSUPP;
+
+	if (!setup->chandef.chan)
+		WARN_ON(!setup->chandef.chan);
+
+	 /* In OCB mode only those channels flagged with 'CHAN_OCB_ONLY'
+	  * may be used
+	  */
+	if (dev->ieee80211_ptr->iftype == NL80211_IFTYPE_OCB &&
+	    !(setup->chandef.chan->flags & IEEE80211_CHAN_OCB_ONLY))
+		return -EINVAL;
+
+	 /* check if basic rates are available otherwise use mandatory
+	  * rates as basic rates
+	  */
+	if (!setup->basic_rates) {
+		enum nl80211_bss_scan_width scan_width;
+		struct ieee80211_supported_band *sband =
+				rdev->wiphy.bands[setup->chandef.chan->band];
+		scan_width = cfg80211_chandef_to_scan_width(&setup->chandef);
+		setup->basic_rates = ieee80211_mandatory_rates(sband,
+							       scan_width);
+	}
+
+	err = cfg80211_can_use_iftype_chan(rdev, wdev, wdev->iftype,
+					   setup->chandef.chan,
+					   CHAN_MODE_EXCLUSIVE, 0);
+	if (err)
+		return err;
+
+	err = rdev_join_ocb(rdev, dev, setup);
+	if (!err)
+		wdev->chandef = setup->chandef;
+
+	return err;
+}
+
+int cfg80211_join_ocb(struct cfg80211_registered_device *rdev,
+		      struct net_device *dev,
+		      struct ocb_setup *setup)
+{
+	struct wireless_dev *wdev = dev->ieee80211_ptr;
+	int err;
+
+	wdev_lock(wdev);
+	err = __cfg80211_join_ocb(rdev, dev, setup);
+	wdev_unlock(wdev);
+
+	return err;
+}
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index 00cdf73..2f2fa14 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -322,6 +322,17 @@ static inline int rdev_leave_mesh(struct cfg80211_registered_device *rdev,
 	return ret;
 }
 
+static inline int rdev_join_ocb(struct cfg80211_registered_device *rdev,
+				struct net_device *dev,
+				struct ocb_setup *setup)
+{
+	int ret;
+	trace_rdev_join_ocb(&rdev->wiphy, dev, setup);
+	ret = rdev->ops->join_ocb(&rdev->wiphy, dev, setup);
+	trace_rdev_return_int(&rdev->wiphy, ret);
+	return ret;
+}
+
 static inline int rdev_change_bss(struct cfg80211_registered_device *rdev,
 				  struct net_device *dev,
 				  struct bss_parameters *params)
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index cdfbb00..f4e2cc3 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -1256,6 +1256,23 @@ TRACE_EVENT(rdev_join_ibss,
 		  WIPHY_PR_ARG, NETDEV_PR_ARG, MAC_PR_ARG(bssid), __entry->ssid)
 );
 
+TRACE_EVENT(rdev_join_ocb,
+	TP_PROTO(struct wiphy *wiphy, struct net_device *netdev,
+		 const struct ocb_setup *setup),
+	TP_ARGS(wiphy, netdev, setup),
+	TP_STRUCT__entry(
+		WIPHY_ENTRY
+		NETDEV_ENTRY
+	),
+	TP_fast_assign(
+		WIPHY_ASSIGN;
+		NETDEV_ASSIGN;
+	),
+	TP_printk(WIPHY_PR_FMT ", " NETDEV_PR_FMT,
+		  WIPHY_PR_ARG, NETDEV_PR_ARG)
+);
+
+
 TRACE_EVENT(rdev_set_wiphy_params,
 	TP_PROTO(struct wiphy *wiphy, u32 changed),
 	TP_ARGS(wiphy, changed),
diff --git a/net/wireless/util.c b/net/wireless/util.c
index a756429..019e34c 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -441,7 +441,8 @@ int ieee80211_data_to_8023(struct sk_buff *skb, const u8 *addr,
 		break;
 	case cpu_to_le16(0):
 		if (iftype != NL80211_IFTYPE_ADHOC &&
-		    iftype != NL80211_IFTYPE_STATION)
+		    iftype != NL80211_IFTYPE_STATION &&
+		    iftype != NL80211_IFTYPE_OCB)
 				return -1;
 		break;
 	}
@@ -517,6 +518,7 @@ int ieee80211_data_from_8023(struct sk_buff *skb, const u8 *addr,
 		memcpy(hdr.addr3, skb->data, ETH_ALEN);
 		hdrlen = 24;
 		break;
+	case NL80211_IFTYPE_OCB:
 	case NL80211_IFTYPE_ADHOC:
 		/* DA SA BSSID */
 		memcpy(hdr.addr1, skb->data, ETH_ALEN);
@@ -935,6 +937,7 @@ int cfg80211_change_iface(struct cfg80211_registered_device *rdev,
 			if (dev->ieee80211_ptr->use_4addr)
 				break;
 			/* fall through */
+		case NL80211_IFTYPE_OCB:
 		case NL80211_IFTYPE_P2P_CLIENT:
 		case NL80211_IFTYPE_ADHOC:
 			dev->priv_flags |= IFF_DONT_BRIDGE;
-- 
2.0.0.rc4

Re: [RFC 2/4] cfg80211: Add new interface type for OCB mode

[Johannes Berg]

On Fri, 2014-05-30 at 18:56 +0200, Rostislav Lisovy wrote:
> Add new OCB mode (outside the context of the BSS) interface
> type as well as functions necessary to configure the interface
> when 'joining' such network.

I think you also want some API to leave (stop operating in) the network
again, and call that appropriately (e.g. on ifdown) and allow userspace
to call it.

> +struct ocb_setup {
> +	struct cfg80211_chan_def chandef;
> +	u32 basic_rates;
> +};

The channel seems obvious - but basic rates? Wouldn't OCB always just
use a single rate, basically? Certainly not *basic* rates (which are
required to be implemented for joining the BSS) since there is no BSS?


> +	if (!setup->chandef.chan)
> +		WARN_ON(!setup->chandef.chan);

That makes very little sense to me?


> @@ -892,6 +893,7 @@ cfg80211_get_chan_state(struct wireless_dev *wdev,
>                                 *radar_detect |=
> BIT(wdev->chandef.width);
>                 }
>                 return;
> +       case NL80211_IFTYPE_OCB:
>         case NL80211_IFTYPE_MONITOR:
>         case NL80211_IFTYPE_AP_VLAN:
>         case NL80211_IFTYPE_WDS:

That certainly doesn't seem correct, in particular if you consider the
comment that's two lines down.

        case NL80211_IFTYPE_P2P_DEVICE:
                /* these interface types don't really have a channel
*/   

It seems for OCB you need some indication that it's joined (maybe the
channel being non-NULL could do?) and then treat it here correctly has
having an exclusive lock on the channel.

johannes

[RFC 3/4] nl80211: Do not ignore 5/10MHz wide channels in nl80211_send_chandef()

[Rostislav Lisovy]

Signed-off-by: Rostislav Lisovy <rostislav.lisovy@fel.cvut.cz>
---
 net/wireless/nl80211.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 79bae31..3a50d1a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2281,6 +2281,8 @@ static int nl80211_send_chandef(struct sk_buff *msg,
 			chandef->chan->center_freq))
 		return -ENOBUFS;
 	switch (chandef->width) {
+	case NL80211_CHAN_WIDTH_5:
+	case NL80211_CHAN_WIDTH_10:
 	case NL80211_CHAN_WIDTH_20_NOHT:
 	case NL80211_CHAN_WIDTH_20:
 	case NL80211_CHAN_WIDTH_40:
-- 
2.0.0.rc4

[RFC 4/4] mac80211: OCB mode interface configuration

[Rostislav Lisovy]

Add functions necessary for OCB mode interface configuration
used in interface bring-up and when 'joining' the network.

Signed-off-by: Rostislav Lisovy <rostislav.lisovy@fel.cvut.cz>
---
 net/mac80211/Makefile      |  3 ++-
 net/mac80211/cfg.c         | 22 ++++++++++++++++++++++
 net/mac80211/chan.c        |  1 +
 net/mac80211/driver-ops.h  |  3 ++-
 net/mac80211/ieee80211_i.h |  3 +++
 net/mac80211/iface.c       | 22 ++++++++++++++++++++++
 net/mac80211/ocb.c         | 22 ++++++++++++++++++++++
 net/mac80211/util.c        |  5 +++++
 8 files changed, 79 insertions(+), 2 deletions(-)
 create mode 100644 net/mac80211/ocb.c

diff --git a/net/mac80211/Makefile b/net/mac80211/Makefile
index 1e46ffa..1b9d37f 100644
--- a/net/mac80211/Makefile
+++ b/net/mac80211/Makefile
@@ -26,7 +26,8 @@ mac80211-y := \
 	event.o \
 	chan.o \
 	trace.o mlme.o \
-	tdls.o
+	tdls.o \
+	ocb.o
 
 mac80211-$(CONFIG_MAC80211_LEDS) += led.o
 mac80211-$(CONFIG_MAC80211_DEBUGFS) += \
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 7c56445..ac15b59 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -228,6 +228,7 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev,
 	case NUM_NL80211_IFTYPES:
 	case NL80211_IFTYPE_P2P_CLIENT:
 	case NL80211_IFTYPE_P2P_GO:
+	case NL80211_IFTYPE_OCB:
 		/* shouldn't happen */
 		WARN_ON_ONCE(1);
 		break;
@@ -2032,6 +2033,26 @@ static int ieee80211_leave_mesh(struct wiphy *wiphy, struct net_device *dev)
 }
 #endif
 
+static int ieee80211_join_ocb(struct wiphy *wiphy, struct net_device *dev,
+			      struct ocb_setup *setup)
+{
+	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+	int err;
+
+	sdata->flags |= IEEE80211_SDATA_OPERATING_GMODE;
+	sdata->smps_mode = IEEE80211_SMPS_OFF;
+	sdata->needed_rx_chains = sdata->local->rx_chains;
+
+	mutex_lock(&sdata->local->mtx);
+	err = ieee80211_vif_use_channel(sdata, &setup->chandef,
+					IEEE80211_CHANCTX_EXCLUSIVE);
+	mutex_unlock(&sdata->local->mtx);
+	if (err)
+		return err;
+
+	return ieee80211_start_ocb(sdata);
+}
+
 static int ieee80211_change_bss(struct wiphy *wiphy,
 				struct net_device *dev,
 				struct bss_parameters *params)
@@ -3768,6 +3789,7 @@ const struct cfg80211_ops mac80211_config_ops = {
 	.join_mesh = ieee80211_join_mesh,
 	.leave_mesh = ieee80211_leave_mesh,
 #endif
+	.join_ocb = ieee80211_join_ocb,
 	.change_bss = ieee80211_change_bss,
 	.set_txq_params = ieee80211_set_txq_params,
 	.set_monitor_channel = ieee80211_set_monitor_channel,
diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 3702d64..62002de 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -675,6 +675,7 @@ void ieee80211_recalc_smps_chanctx(struct ieee80211_local *local,
 		case NL80211_IFTYPE_ADHOC:
 		case NL80211_IFTYPE_WDS:
 		case NL80211_IFTYPE_MESH_POINT:
+		case NL80211_IFTYPE_OCB:
 			break;
 		default:
 			WARN_ON_ONCE(1);
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index df1d502..ccf770d 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -214,7 +214,8 @@ static inline void drv_bss_info_changed(struct ieee80211_local *local,
 				    BSS_CHANGED_BEACON_ENABLED) &&
 			 sdata->vif.type != NL80211_IFTYPE_AP &&
 			 sdata->vif.type != NL80211_IFTYPE_ADHOC &&
-			 sdata->vif.type != NL80211_IFTYPE_MESH_POINT))
+			 sdata->vif.type != NL80211_IFTYPE_MESH_POINT &&
+			 sdata->vif.type != NL80211_IFTYPE_OCB))
 		return;
 
 	if (WARN_ON_ONCE(sdata->vif.type == NL80211_IFTYPE_P2P_DEVICE ||
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 4668ce9..002fd8f 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1421,6 +1421,9 @@ int ieee80211_ibss_csa_beacon(struct ieee80211_sub_if_data *sdata,
 int ieee80211_ibss_finish_csa(struct ieee80211_sub_if_data *sdata);
 void ieee80211_ibss_stop(struct ieee80211_sub_if_data *sdata);
 
+/* OCB code */
+int ieee80211_start_ocb(struct ieee80211_sub_if_data *sdata);
+
 /* mesh code */
 void ieee80211_mesh_work(struct ieee80211_sub_if_data *sdata);
 void ieee80211_mesh_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata,
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 79fc988..23e573e 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -258,6 +258,15 @@ static int ieee80211_check_concurrent_iface(struct ieee80211_sub_if_data *sdata,
 	list_for_each_entry(nsdata, &local->interfaces, list) {
 		if (nsdata != sdata && ieee80211_sdata_running(nsdata)) {
 			/*
+			 * Only OCB and monitor mode may coexist
+			 */
+			if ((sdata->vif.type == NL80211_IFTYPE_OCB &&
+			     nsdata->vif.type != NL80211_IFTYPE_MONITOR) ||
+			    (sdata->vif.type != NL80211_IFTYPE_MONITOR &&
+			     nsdata->vif.type == NL80211_IFTYPE_OCB))
+				return -EBUSY;
+
+			/*
 			 * Allow only a single IBSS interface to be up at any
 			 * time. This is restricted because beacon distribution
 			 * cannot work properly if both are in the same IBSS.
@@ -519,6 +528,7 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
 	case NL80211_IFTYPE_MONITOR:
 	case NL80211_IFTYPE_ADHOC:
 	case NL80211_IFTYPE_P2P_DEVICE:
+	case NL80211_IFTYPE_OCB:
 		/* no special treatment */
 		break;
 	case NL80211_IFTYPE_UNSPECIFIED:
@@ -618,6 +628,9 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
 			ieee80211_configure_filter(local);
 		} else if (sdata->vif.type == NL80211_IFTYPE_ADHOC) {
 			local->fif_probe_req++;
+		} else if (sdata->vif.type == NL80211_IFTYPE_OCB) {
+			local->fif_other_bss++;
+			ieee80211_configure_filter(local);
 		}
 
 		if (sdata->vif.type != NL80211_IFTYPE_P2P_DEVICE)
@@ -629,6 +642,7 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
 		case NL80211_IFTYPE_ADHOC:
 		case NL80211_IFTYPE_AP:
 		case NL80211_IFTYPE_MESH_POINT:
+		case NL80211_IFTYPE_OCB:
 			netif_carrier_off(dev);
 			break;
 		case NL80211_IFTYPE_WDS:
@@ -1274,6 +1288,9 @@ static void ieee80211_recalc_smps_work(struct work_struct *work)
 static void ieee80211_setup_sdata(struct ieee80211_sub_if_data *sdata,
 				  enum nl80211_iftype type)
 {
+	static u8 bssid_wildcard[ETH_ALEN] = { 0xff, 0xff, 0xff,
+					       0xff, 0xff, 0xff };
+
 	/* clear type-dependent union */
 	memset(&sdata->u, 0, sizeof(sdata->u));
 
@@ -1324,6 +1341,9 @@ static void ieee80211_setup_sdata(struct ieee80211_sub_if_data *sdata,
 		sdata->vif.bss_conf.bssid = sdata->u.mgd.bssid;
 		ieee80211_sta_setup_sdata(sdata);
 		break;
+	case NL80211_IFTYPE_OCB:
+		sdata->vif.bss_conf.bssid = bssid_wildcard;
+		break;
 	case NL80211_IFTYPE_ADHOC:
 		sdata->vif.bss_conf.bssid = sdata->u.ibss.bssid;
 		ieee80211_ibss_setup_sdata(sdata);
@@ -1371,6 +1391,7 @@ static int ieee80211_runtime_change_iftype(struct ieee80211_sub_if_data *sdata,
 	case NL80211_IFTYPE_AP:
 	case NL80211_IFTYPE_STATION:
 	case NL80211_IFTYPE_ADHOC:
+	case NL80211_IFTYPE_OCB:
 		/*
 		 * Could maybe also all others here?
 		 * Just not sure how that interacts
@@ -1386,6 +1407,7 @@ static int ieee80211_runtime_change_iftype(struct ieee80211_sub_if_data *sdata,
 	case NL80211_IFTYPE_AP:
 	case NL80211_IFTYPE_STATION:
 	case NL80211_IFTYPE_ADHOC:
+	case NL80211_IFTYPE_OCB:
 		/*
 		 * Could probably support everything
 		 * but WDS here (WDS do_open can fail
diff --git a/net/mac80211/ocb.c b/net/mac80211/ocb.c
new file mode 100644
index 0000000..2dd9723
--- /dev/null
+++ b/net/mac80211/ocb.c
@@ -0,0 +1,22 @@
+ /* OCB mode implementation
+ * Copyright 2014, Czech Technical University in Prague, Rostislav Lisovy
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "ieee80211_i.h"
+
+int ieee80211_start_ocb(struct ieee80211_sub_if_data *sdata)
+{
+	u32 changed = BSS_CHANGED_BEACON_ENABLED;
+
+	sdata->vif.bss_conf.enable_beacon = false;
+	ieee80211_bss_info_change_notify(sdata, changed);
+
+	/* MORE TO BE DONE ... */
+
+	netif_carrier_on(sdata->dev);
+	return 0;
+}
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 7e0dd4b..bf4fd61 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1689,6 +1689,11 @@ int ieee80211_reconfig(struct ieee80211_local *local)
 			ieee80211_bss_info_change_notify(sdata, changed);
 			sdata_unlock(sdata);
 			break;
+		case NL80211_IFTYPE_OCB:
+			changed |= BSS_CHANGED_IBSS |
+				   BSS_CHANGED_BEACON_ENABLED;
+			ieee80211_bss_info_change_notify(sdata, changed);
+			break;
 		case NL80211_IFTYPE_ADHOC:
 			changed |= BSS_CHANGED_IBSS;
 			/* fall through */
-- 
2.0.0.rc4

Re: [RFC 4/4] mac80211: OCB mode interface configuration

[Johannes Berg]

On Fri, 2014-05-30 at 18:56 +0200, Rostislav Lisovy wrote:
> +	static u8 bssid_wildcard[ETH_ALEN] = { 0xff, 0xff, 0xff,
> +					       0xff, 0xff, 0xff };

const

that doesn't actually exist anywhere already? Maybe not I guess.

> +int ieee80211_start_ocb(struct ieee80211_sub_if_data *sdata)
> +{
> +	u32 changed = BSS_CHANGED_BEACON_ENABLED;
> +
> +	sdata->vif.bss_conf.enable_beacon = false;
> +	ieee80211_bss_info_change_notify(sdata, changed);

Why would beacon_enabled be changing?

> +	/* MORE TO BE DONE ... */

>From a brief look it seems that you should at least be setting the QoS
parameters, but what, if anything, else is there?

Certainly there should also be some indication to the low-level driver
that it should now consider being part of the OCB network though.

> +	netif_carrier_on(sdata->dev);
> +	return 0;
> +}
> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> index 7e0dd4b..bf4fd61 100644
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@ -1689,6 +1689,11 @@ int ieee80211_reconfig(struct ieee80211_local *local)
>  			ieee80211_bss_info_change_notify(sdata, changed);
>  			sdata_unlock(sdata);
>  			break;
> +		case NL80211_IFTYPE_OCB:
> +			changed |= BSS_CHANGED_IBSS |
> +				   BSS_CHANGED_BEACON_ENABLED;

CHANGED_IBSS?

I guess you need a new CHANGED_OCB flag and ocb_active bool value.

johannes

Re: [RFC 0/4 v2] cfg80211/mac80211: Add new interface type for OCB (Outside the Context of a BSS) mode

[Johannes Berg]

On Fri, 2014-05-30 at 18:56 +0200, Rostislav Lisovy wrote:

> This patchset presents work in progress. Patches adding *_leave_ocb()
> functions and modifying RX/TX path in mac80211 to work with OCB
> mode will come in near future.

Oh, sorry - I commented on that but failed to read the cover letter
first. My bad.

Overall you're off on a good start I think - see the comments I had on
the patches.

I'm hoping that drivers implementing this won't actually need any
station entries. Apart from that, it's unclear to me how the bitrate is
selected, are there even different bitrates?

johannes

Re: [RFC 0/4 v2] cfg80211/mac80211: Add new interface type for OCB (Outside the Context of a BSS) mode

[Rostislav Lisovy]

On Tue, 2014-06-03 at 22:15 +0200, Johannes Berg wrote:
> it's unclear to me how the bitrate is
> selected, are there even different bitrates?

My understanding is that since we are using OFDM we have to support at
least 3, 6, 12 Mb/s data rates (says 802.11-2012, Chapter 18.1.1, second
paragraph). How to choose it when transmitting? That should probably be
defined in some standard built on top of "802.11p" -- the European
"Intelligent Transport System" standard ETSI EN 302 663 defines
different channels in 5.9 Ghz band along with the "default data
rate" (Table 2, Chapter 4.3). For example Control Channel (nr. 180) has
data rate 6 Mb/s, while Service Channel 2 (nr. 178) has data rate 12
Mb/s.

Regards;
Rostislav

Re: [RFC 0/4 v2] cfg80211/mac80211: Add new interface type for OCB (Outside the Context of a BSS) mode

[Johannes Berg]

On Mon, 2014-06-09 at 16:09 +0200, Rostislav Lisovy wrote:
> On Tue, 2014-06-03 at 22:15 +0200, Johannes Berg wrote:
> > it's unclear to me how the bitrate is
> > selected, are there even different bitrates?
> 
> My understanding is that since we are using OFDM we have to support at
> least 3, 6, 12 Mb/s data rates (says 802.11-2012, Chapter 18.1.1, second
> paragraph). How to choose it when transmitting? That should probably be
> defined in some standard built on top of "802.11p" -- the European
> "Intelligent Transport System" standard ETSI EN 302 663 defines
> different channels in 5.9 Ghz band along with the "default data
> rate" (Table 2, Chapter 4.3). For example Control Channel (nr. 180) has
> data rate 6 Mb/s, while Service Channel 2 (nr. 178) has data rate 12
> Mb/s.

But that probably means then that you have to select the rate in the
join command.

johannes