1) Depending on which WW sku number you selected, it may and may not support the DFS channels. So this is not true that we do not support DFS channels in WW mode. 2) Today, I do not believe ath9k code supports DFS detection. If that is what you mean. Therefore STA mode will not support DFS detection. However, STA does support DFS channels. DFS channel support vs DFS detection support is two different things. DFS channel support as a slave device, only has to do passive scanning. Let me know if that answers your questions. David -----Original Message----- From: mcgrof@xxxxxxxxx [mailto:mcgrof@xxxxxxxxx] On Behalf Of Luis R. Rodriguez Sent: Thursday, March 08, 2012 10:53 AM To: Seth Forshee; Quan, David; Green, Michael Cc: linux-wireless@xxxxxxxxxxxxxxx; Johannes Berg Subject: Re: Problems with regulatory domain support and BCM43224 David, Michael, below is a thread on world regulatory domains and DFS. This is a public thread so replying to this is public. The question is simple: why not add DFS channels to the world regulatory domain provided that 1) we only passive scan on them 2) STA does support DFS support. It seems logical to me now that this should be enabled, but I can't recall if perhaps I am forgetting something. The beacon hint code we have, which enables radiation upon finding a beacon from an AP on a 5 GHz channel only does beacon hints for non-DFS channels, so a device using the world regulatory domain is guaranteed to not initiate radiation on these channels. Seth, my response to you below. On Thu, Mar 8, 2012 at 9:41 AM, Seth Forshee <seth.forshee@xxxxxxxxxxxxx> wrote: > As I understand it, the DFS channels aren't included in the world > domain because Linux does not yet fully support DFS. A STA device can connect to a DFS AP when the STA device does have those DFS channels as part of its world regulatory domain, but the STA will passively scan on those channels given that sending a probe request is active radiation and active radiation requires a bit of code which is not yet complete and only used as a AP. You are right though that the Linux regulatory code though does not include any DFS channels in the world regulatory domain. The world regulatory domain is the mathematical intersection of all the regulatory domains in the world (see intersect.c on CRDA) but a few set of channels were added as well which are not DFS with the condition that we do passive scans. We did remove the DFS channels completely. > But I can then specify a > domain that's known to require DFS on these channels, and they are > enabled. This seems illogical. If passive scanning is okay when we > know DFS is required, why can't it be enabled in the world domain when > we simply don't know if it's required? Its a fair point and given the way we handle beacon hints and not enabling them for DFS channels at all, and if we only passively scan for DFS channels I think this should be good. Luis ��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
