* 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 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
* 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
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).