linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* DFS CAC time
@ 2014-12-18 16:21 Helmut Schaa
  2014-12-19 11:27 ` Zefir Kurtisi
  0 siblings, 1 reply; 7+ messages in thread
From: Helmut Schaa @ 2014-12-18 16:21 UTC (permalink / raw)
  To: linux-wireless

Hi,

Using ath10k I get the following when checking the CAC times for an
ETSI regulatory domain:

iw list | grep CAC -B 2
* 5260 MHz [52] (20.0 dBm) (radar detection)
  DFS state: available (for 342 sec)
  DFS CAC time: 60000 ms
* 5280 MHz [56] (20.0 dBm) (radar detection)
  DFS state: available (for 342 sec)
  DFS CAC time: 60000 ms
* 5300 MHz [60] (20.0 dBm) (radar detection)
  DFS state: available (for 342 sec)
  DFS CAC time: 60000 ms
* 5320 MHz [64] (20.0 dBm) (radar detection)
  DFS state: available (for 342 sec)
  DFS CAC time: 60000 ms
* 5500 MHz [100] (27.0 dBm) (radar detection)
  DFS state: usable (for 408 sec)
  DFS CAC time: 60000 ms
* 5520 MHz [104] (27.0 dBm) (radar detection)
  DFS state: usable (for 408 sec)
  DFS CAC time: 60000 ms
* 5540 MHz [108] (27.0 dBm) (radar detection)
  DFS state: usable (for 408 sec)
  DFS CAC time: 60000 ms
* 5560 MHz [112] (27.0 dBm) (radar detection)
  DFS state: usable (for 408 sec)
  DFS CAC time: 60000 ms
* 5580 MHz [116] (27.0 dBm) (radar detection)
  DFS state: usable (for 408 sec)
  DFS CAC time: 60000 ms
* 5600 MHz [120] (27.0 dBm) (radar detection)
  DFS state: usable (for 408 sec)
  DFS CAC time: 60000 ms
* 5620 MHz [124] (27.0 dBm) (radar detection)
  DFS state: usable (for 408 sec)
  DFS CAC time: 60000 ms
* 5640 MHz [128] (27.0 dBm) (radar detection)
  DFS state: usable (for 408 sec)
  DFS CAC time: 60000 ms
* 5660 MHz [132] (27.0 dBm) (radar detection)
  DFS state: usable (for 408 sec)
  DFS CAC time: 60000 ms
* 5680 MHz [136] (27.0 dBm) (radar detection)
  DFS state: usable (for 408 sec)
  DFS CAC time: 60000 ms
* 5700 MHz [140] (27.0 dBm) (radar detection)
  DFS state: usable (for 408 sec)
  DFS CAC time: 60000 ms

So, every channel has a CAC time of 60 seconds.

Checking version 1.7.2 of the ETSI regulation indicates that we might
need some modifications to cfg80211:

>From [1] page 79:

"NOTE 1: For channels whose nominal bandwidth falls completely or
partly within the
band 5 600 MHz to 5 650 MHz, the Channel Availability Check Time shall be
10 minutes.
NOTE 2: For channels whose nominal bandwidth falls completely or
partly within the
band 5 600 MHz to 5 650 MHz, the Off-Channel CAC Time shall be within the
range 1 hour to 24 hours."

So, for these channels we should select a longer initial CAC time.

Is anyone aware of this issue?

Thanks,
Helmut


[1] http://www.etsi.org/deliver/etsi_en/301800_301899/301893/01.07.02_20/en_301893v010702a.pdf

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: DFS CAC time
  2014-12-18 16:21 DFS CAC time Helmut Schaa
@ 2014-12-19 11:27 ` Zefir Kurtisi
  2014-12-19 12:28   ` Janusz Dziedzic
  2014-12-19 13:19   ` Helmut Schaa
  0 siblings, 2 replies; 7+ messages in thread
From: Zefir Kurtisi @ 2014-12-19 11:27 UTC (permalink / raw)
  To: Helmut Schaa, linux-wireless

On 12/18/2014 05:21 PM, Helmut Schaa wrote:
> Hi,
> 
> [...]
> 
> So, every channel has a CAC time of 60 seconds.
> 
> Checking version 1.7.2 of the ETSI regulation indicates that we might
> need some modifications to cfg80211:
> 
> From [1] page 79:
> 
> "NOTE 1: For channels whose nominal bandwidth falls completely or
> partly within the
> band 5 600 MHz to 5 650 MHz, the Channel Availability Check Time shall be
> 10 minutes.
> NOTE 2: For channels whose nominal bandwidth falls completely or
> partly within the
> band 5 600 MHz to 5 650 MHz, the Off-Channel CAC Time shall be within the
> range 1 hour to 24 hours."
> 
> So, for these channels we should select a longer initial CAC time.
> 
> Is anyone aware of this issue?
> 
> Thanks,
> Helmut
> 
> 
> [1] http://www.etsi.org/deliver/etsi_en/301800_301899/301893/01.07.02_20/en_301893v010702a.pdf
> --

Hello Helmut,

just forget about those aka 'weather channels' that require a pracitcally
impossible to achieve radar detection probability rate (99.99% during CAC, see
table D.5).

They should simply be disabled, either at mac layer, or at least in ath/regd.c.


Cheers,
Zefir

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: DFS CAC time
  2014-12-19 11:27 ` Zefir Kurtisi
@ 2014-12-19 12:28   ` Janusz Dziedzic
  2014-12-19 13:18     ` Helmut Schaa
  2014-12-20 10:27     ` YanBo
  2014-12-19 13:19   ` Helmut Schaa
  1 sibling, 2 replies; 7+ messages in thread
From: Janusz Dziedzic @ 2014-12-19 12:28 UTC (permalink / raw)
  To: Zefir Kurtisi; +Cc: Helmut Schaa, linux-wireless

On 19 December 2014 at 12:27, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
> On 12/18/2014 05:21 PM, Helmut Schaa wrote:
>> Hi,
>>
>> [...]
>>
>> So, every channel has a CAC time of 60 seconds.
>>
>> Checking version 1.7.2 of the ETSI regulation indicates that we might
>> need some modifications to cfg80211:
>>
>> From [1] page 79:
>>
>> "NOTE 1: For channels whose nominal bandwidth falls completely or
>> partly within the
>> band 5 600 MHz to 5 650 MHz, the Channel Availability Check Time shall be
>> 10 minutes.
>> NOTE 2: For channels whose nominal bandwidth falls completely or
>> partly within the
>> band 5 600 MHz to 5 650 MHz, the Off-Channel CAC Time shall be within the
>> range 1 hour to 24 hours."
>>
>> So, for these channels we should select a longer initial CAC time.
>>
>> Is anyone aware of this issue?
>>
>> Thanks,
>> Helmut
>>
>>
>> [1] http://www.etsi.org/deliver/etsi_en/301800_301899/301893/01.07.02_20/en_301893v010702a.pdf
>> --
>
> Hello Helmut,
>
> just forget about those aka 'weather channels' that require a pracitcally
> impossible to achieve radar detection probability rate (99.99% during CAC, see
> table D.5).
>
> They should simply be disabled, either at mac layer, or at least in ath/regd.c.
>

You can use internal regdb and set this correctly in db.txt, eg

+       (5490 - 5600 @ 80), (27), DFS, AUTO-BW
+       (5600 - 5650 @ 40), (27), (600000), DFS, AUTO-BW
+       (5650 - 5710 @ 40), (27), DFS, AUTO-BW

There are also patches for crda/wireless-regdb but not merged, so use
internal regdb.

BR
Janusz

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: DFS CAC time
  2014-12-19 12:28   ` Janusz Dziedzic
@ 2014-12-19 13:18     ` Helmut Schaa
  2014-12-20 10:27     ` YanBo
  1 sibling, 0 replies; 7+ messages in thread
From: Helmut Schaa @ 2014-12-19 13:18 UTC (permalink / raw)
  To: Janusz Dziedzic; +Cc: Zefir Kurtisi, linux-wireless

On Fri, Dec 19, 2014 at 1:28 PM, Janusz Dziedzic
<janusz.dziedzic@tieto.com> wrote:
> On 19 December 2014 at 12:27, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
>> On 12/18/2014 05:21 PM, Helmut Schaa wrote:
>>> Hi,
>>>
>>> [...]
>>>
>>> So, every channel has a CAC time of 60 seconds.
>>>
>>> Checking version 1.7.2 of the ETSI regulation indicates that we might
>>> need some modifications to cfg80211:
>>>
>>> From [1] page 79:
>>>
>>> "NOTE 1: For channels whose nominal bandwidth falls completely or
>>> partly within the
>>> band 5 600 MHz to 5 650 MHz, the Channel Availability Check Time shall be
>>> 10 minutes.
>>> NOTE 2: For channels whose nominal bandwidth falls completely or
>>> partly within the
>>> band 5 600 MHz to 5 650 MHz, the Off-Channel CAC Time shall be within the
>>> range 1 hour to 24 hours."
>>>
>>> So, for these channels we should select a longer initial CAC time.
>>>
>>> Is anyone aware of this issue?
>>>
>>> Thanks,
>>> Helmut
>>>
>>>
>>> [1] http://www.etsi.org/deliver/etsi_en/301800_301899/301893/01.07.02_20/en_301893v010702a.pdf
>>> --
>>
>> Hello Helmut,
>>
>> just forget about those aka 'weather channels' that require a pracitcally
>> impossible to achieve radar detection probability rate (99.99% during CAC, see
>> table D.5).
>>
>> They should simply be disabled, either at mac layer, or at least in ath/regd.c.
>>
>
> You can use internal regdb and set this correctly in db.txt, eg
>
> +       (5490 - 5600 @ 80), (27), DFS, AUTO-BW
> +       (5600 - 5650 @ 40), (27), (600000), DFS, AUTO-BW
> +       (5650 - 5710 @ 40), (27), DFS, AUTO-BW
>
> There are also patches for crda/wireless-regdb but not merged, so use
> internal regdb.

Nice, didn't know about that one.

Thanks for the suggestion,
Helmut

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: DFS CAC time
  2014-12-19 11:27 ` Zefir Kurtisi
  2014-12-19 12:28   ` Janusz Dziedzic
@ 2014-12-19 13:19   ` Helmut Schaa
  2014-12-19 15:56     ` Zefir Kurtisi
  1 sibling, 1 reply; 7+ messages in thread
From: Helmut Schaa @ 2014-12-19 13:19 UTC (permalink / raw)
  To: Zefir Kurtisi; +Cc: linux-wireless

Hi Zefir,

On Fri, Dec 19, 2014 at 12:27 PM, Zefir Kurtisi
<zefir.kurtisi@neratec.com> wrote:
> On 12/18/2014 05:21 PM, Helmut Schaa wrote:
>> Hi,
>>
>> [...]
>>
>> So, every channel has a CAC time of 60 seconds.
>>
>> Checking version 1.7.2 of the ETSI regulation indicates that we might
>> need some modifications to cfg80211:
>>
>> From [1] page 79:
>>
>> "NOTE 1: For channels whose nominal bandwidth falls completely or
>> partly within the
>> band 5 600 MHz to 5 650 MHz, the Channel Availability Check Time shall be
>> 10 minutes.
>> NOTE 2: For channels whose nominal bandwidth falls completely or
>> partly within the
>> band 5 600 MHz to 5 650 MHz, the Off-Channel CAC Time shall be within the
>> range 1 hour to 24 hours."
>>
>> So, for these channels we should select a longer initial CAC time.
>>
>> Is anyone aware of this issue?
>>
>> Thanks,
>> Helmut
>>
>>
>> [1] http://www.etsi.org/deliver/etsi_en/301800_301899/301893/01.07.02_20/en_301893v010702a.pdf
>> --
>
> Hello Helmut,
>
> just forget about those aka 'weather channels' that require a pracitcally
> impossible to achieve radar detection probability rate (99.99% during CAC, see
> table D.5).

Hmm, ok :)

Would it make sense to mark these somehow in the wireless-regdb in a
special way?

Thanks,
Helmut

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: DFS CAC time
  2014-12-19 13:19   ` Helmut Schaa
@ 2014-12-19 15:56     ` Zefir Kurtisi
  0 siblings, 0 replies; 7+ messages in thread
From: Zefir Kurtisi @ 2014-12-19 15:56 UTC (permalink / raw)
  To: Helmut Schaa; +Cc: linux-wireless

On 12/19/2014 02:19 PM, Helmut Schaa wrote:
> Hi Zefir,
> 
> On Fri, Dec 19, 2014 at 12:27 PM, Zefir Kurtisi
> <zefir.kurtisi@neratec.com> wrote:
>>
>> Hello Helmut,
>>
>> just forget about those aka 'weather channels' that require a pracitcally
>> impossible to achieve radar detection probability rate (99.99% during CAC, see
>> table D.5).
> 
> Hmm, ok :)
> 
> Would it make sense to mark these somehow in the wireless-regdb in a
> special way?
> 

To reflect the fact that channels are available from regulatory's point of view
but not usable from driver's perspective, the correct way would be to
* set the correct CAC time in crda
* disable them in the driver internal regdb

In practice, that's an overhead to manage channels that we know will never be
available for WLAN master devices.


Cheers,
Zefir


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: DFS CAC time
  2014-12-19 12:28   ` Janusz Dziedzic
  2014-12-19 13:18     ` Helmut Schaa
@ 2014-12-20 10:27     ` YanBo
  1 sibling, 0 replies; 7+ messages in thread
From: YanBo @ 2014-12-20 10:27 UTC (permalink / raw)
  To: Janusz Dziedzic; +Cc: Zefir Kurtisi, Helmut Schaa, linux-wireless

One correct based on the patch, the 5600 should be change with 5590,
or else the channel 128 will be disabled in my testing.


+       (5490 - 5590 @ 80), (27), DFS, AUTO-BW
+       (5590 - 5650 @ 40), (27), (600000), DFS, AUTO-BW
+       (5650 - 5710 @ 40), (27), DFS, AUTO-BW

BR /Yanbo

On Fri, Dec 19, 2014 at 8:28 PM, Janusz Dziedzic
<janusz.dziedzic@tieto.com> wrote:
> On 19 December 2014 at 12:27, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
>> On 12/18/2014 05:21 PM, Helmut Schaa wrote:
>>> Hi,
>>>
>>> [...]
>>>
>>> So, every channel has a CAC time of 60 seconds.
>>>
>>> Checking version 1.7.2 of the ETSI regulation indicates that we might
>>> need some modifications to cfg80211:
>>>
>>> From [1] page 79:
>>>
>>> "NOTE 1: For channels whose nominal bandwidth falls completely or
>>> partly within the
>>> band 5 600 MHz to 5 650 MHz, the Channel Availability Check Time shall be
>>> 10 minutes.
>>> NOTE 2: For channels whose nominal bandwidth falls completely or
>>> partly within the
>>> band 5 600 MHz to 5 650 MHz, the Off-Channel CAC Time shall be within the
>>> range 1 hour to 24 hours."
>>>
>>> So, for these channels we should select a longer initial CAC time.
>>>
>>> Is anyone aware of this issue?
>>>
>>> Thanks,
>>> Helmut
>>>
>>>
>>> [1] http://www.etsi.org/deliver/etsi_en/301800_301899/301893/01.07.02_20/en_301893v010702a.pdf
>>> --
>>
>> Hello Helmut,
>>
>> just forget about those aka 'weather channels' that require a pracitcally
>> impossible to achieve radar detection probability rate (99.99% during CAC, see
>> table D.5).
>>
>> They should simply be disabled, either at mac layer, or at least in ath/regd.c.
>>
>
> You can use internal regdb and set this correctly in db.txt, eg
>
> +       (5490 - 5600 @ 80), (27), DFS, AUTO-BW
> +       (5600 - 5650 @ 40), (27), (600000), DFS, AUTO-BW
> +       (5650 - 5710 @ 40), (27), DFS, AUTO-BW
>
> There are also patches for crda/wireless-regdb but not merged, so use
> internal regdb.
>
> BR
> Janusz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2014-12-20 10:27 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-18 16:21 DFS CAC time Helmut Schaa
2014-12-19 11:27 ` Zefir Kurtisi
2014-12-19 12:28   ` Janusz Dziedzic
2014-12-19 13:18     ` Helmut Schaa
2014-12-20 10:27     ` YanBo
2014-12-19 13:19   ` Helmut Schaa
2014-12-19 15:56     ` Zefir Kurtisi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).