From: Ben Greear <greearb@candelatech.com>
To: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: More confusion with regulatory issues.
Date: Wed, 11 Jun 2014 09:31:31 -0700 [thread overview]
Message-ID: <53988463.4040303@candelatech.com> (raw)
In-Reply-To: <53987A6A.7080209@candelatech.com>
On 06/11/2014 08:48 AM, Ben Greear wrote:
> On 06/11/2014 07:31 AM, Ben Greear wrote:
>> On 06/11/2014 03:34 AM, Janusz Dziedzic wrote:
>>
>>> This could be the same issue like fixed in:
>>> cfg80211: reg: setup correct alpha2 after intersection (Ben could you
>>> try with this patch?)
>>>
>>> Orginal scenario I descibe:
>>> - insmod cfg80211.ko
>>> - iw reg set FR (1)
>>> - modprobe ath10k_pci (US hint)
>>> - intersection and country set as "98"
>>> - no way to setup new country using iw reg set (here hostapd startup
>>> will failed)
>>>
>>> But I can imagine also that we have two cards, both using cfg80211.ko
>>> So, first card driver loaded set regulatory eg. FR
>>> Next we load ath10k --> intersection "98"
>>> Next run hostapd - and fail because no way to change regulatory and
>>> get correct DFS region
>>>
>>> BTW:
>>> There is no problem (no intersection) when move "iw reg set" after
>>> modprobe ath10k - seems strange logic issue here ...
>>
>> With your patch, I no longer see the '98' regdomain, but
>> I still see DFS-UNSET. Is that expected? How do I get DFS
>> to work (and, should it actually be enabled in this case?)
>>
>> [root@ath10k-2220 ~]# iw reg get
>> country US: DFS-UNSET
>> (2402 - 2472 @ 40), (N/A, 30)
>> (5170 - 5250 @ 80), (N/A, 17)
>> (5250 - 5330 @ 80), (N/A, 23), DFS
>> (5735 - 5835 @ 80), (N/A, 30)
>> (57240 - 63720 @ 2160), (N/A, 40)
>> [root@ath10k-2220 ~]#
>
> After more debugging, I noticed this:
>
> We are getting regulatory update from core, intersecting US with world-regulatory
> domain. But, the dfs region is un-specified for both of these. I was expecting
> the US domain to use the FCC dfs region.
>
> [ 7.895189] cfg80211: 5715000 KHz - 5860000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
> [ 7.895190] cfg80211: Updating information on frequency 5825 MHz with regulatory rule:
> [ 7.895191] cfg80211: 5715000 KHz - 5860000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
> [ 7.895260] cfg80211: Ignoring regulatory request set by core since the driver uses its own custom regulatory domain
> [ 7.895929] cfg80211: Calling CRDA for country: US
> [ 7.895942] cfg80211: Calling CRDA for country: US
> [ 7.901380] cfg80211: set-regdom, lr->initiator: 2 domain: US
> [ 7.907423] cfg80211: regdom-intersect, rd1: ffff880220ea5000 rd2: ffff8800371aa700
> [ 7.915047] cfg80211: regdom-intersect, rd1: US rd2: 00
> ....
> [ 8.220870] cfg80211: reg-rules-intersect, US 00
> [ 8.224454] cfg80211: reg-rules-intersect, US 00
> [ 8.227943] cfg80211: dfs-region, region1: 0 region2: 0
>
> And a bit related, I was thinking the dfs-region intersection might
> be more useful as is written below?
>
> static enum nl80211_dfs_regions
> reg_intersect_dfs_region(const enum nl80211_dfs_regions dfs_region1,
> const enum nl80211_dfs_regions dfs_region2)
> {
> pr_err("dfs-region, region1: %d region2: %d\n",
> dfs_region1, dfs_region2);
> if (dfs_region1 != dfs_region2) {
> if (dfs_region1 == NL80211_DFS_UNSET)
> return dfs_region2;
> if (dfs_region2 == NL80211_DFS_UNSET)
> return dfs_region1;
> return NL80211_DFS_UNSET;
> }
> return dfs_region1;
> }
Well, maybe making some progress now.
I notice that if I do a 'make;make install' for the wireless-regdb, then
crda tools say the regulatory.bin is invalid. I do not know why this
is the case, but if I skip the 'make' and just do a 'make install',
then regdbdump appears happy.
I think the patch to dfs_region intersection above is still needed,
and with it in, I now get this after bootup:
[root@ath10k-2220 ~]# iw reg get
country 98: DFS-FCC
(2402 - 2472 @ 70), (N/A, 20)
(2457 - 2472 @ 70), (N/A, 20), PASSIVE-SCAN, NO-IBSS
(5170 - 5250 @ 80), (N/A, 17), PASSIVE-SCAN, NO-IBSS
(5250 - 5330 @ 80), (N/A, 20), DFS, PASSIVE-SCAN, NO-IBSS
(5735 - 5835 @ 80), (N/A, 20), PASSIVE-SCAN, NO-IBSS
(57240 - 63720 @ 2160), (N/A, 0)
[root@ath10k-2220 ~]#
Does this look proper for a US region?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2014-06-11 16:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-11 0:11 More confusion with regulatory issues Ben Greear
2014-06-11 9:10 ` Luis R. Rodriguez
2014-06-11 10:34 ` Janusz Dziedzic
2014-06-11 14:31 ` Ben Greear
2014-06-11 15:48 ` Ben Greear
2014-06-11 16:31 ` Ben Greear [this message]
2014-06-11 19:24 ` Janusz Dziedzic
2014-06-23 19:33 ` Luis R. Rodriguez
2014-06-11 14:15 ` Ben Greear
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53988463.4040303@candelatech.com \
--to=greearb@candelatech.com \
--cc=janusz.dziedzic@tieto.com \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@do-not-panic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.