Bug 34872 - cfg80211 fails to update regulatory domain w/o rfkill
Summary: cfg80211 fails to update regulatory domain w/o rfkill
Status: RESOLVED DOCUMENTED
Alias: None
Product: Networking
Classification: Unclassified
Component: Wireless (show other bugs)
Hardware: All Linux
: P1 low
Assignee: networking_wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-10 17:23 UTC by John Nielsen
Modified: 2012-08-23 14:06 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.38.5
Tree: Mainline
Regression: No


Attachments

Description John Nielsen 2011-05-10 17:23:03 UTC
Found using an AR9220 (ath9k) card on an Alix 3d2 (Geode) board, but I don't think it's hardware-specific.

I built a minimal custom kernel with no modules intended for use as an 802.11a access point. Kernel built fine, wireless drivers worked in station mode and as an 802.11g AP, but had incorrect regulatory settings (00 instead of US) which prevented AP use in 802.11a channels.

After some trial and error I found that in order for regulatory domain changes to happen I needed a kernel with both module support and CONFIG_RFKILL enabled (and built as a module along with cfg80211 and ath9k). CRDA is installed and functional and even setting CONFIG_CFG80211_INTERNAL_REGDB did not resolve the issue.

If cfg80211 really depends on rfkill then it should be documented and the kernel config system should enforce that dependency. If it doesn't (or shouldn't) then it should be possible to fully use cfg80211 without it, including updating the regulatory domain.

Similarly, if the wireless subsystem needs to be built as modules instead of compiled in to the kernel, that should be documented and enforced. If it doesn't (or shouldn't), a module-less kernel that includes the necessary bits should be fully functional in this regard.

Thanks,

JN
Comment 1 Luis Chamberlain 2011-05-10 21:30:28 UTC
Huh? The APIs for changing regulatory domains are used to *help* compliance, not to override compliance [1]. If the card has 00 on the EEPROM it will map the US regulatory domain by design [2]. Your issue is completely irrelevant to overriding regulatory settings.

The issue you seem to be reporting is that udev events are not getting sent to userspace if cfg80211 is built-in and rfkill is disabled. Is that right? If so please review debugging CRDA [3] to see if you see udev events hit userspace. Please confirm and clarify your issue.

[1] http://wireless.kernel.org/en/developers/Regulatory/CRDA#Helping_compliance_by_allowing_to_change_regulatory_domains
[2] http://wireless.kernel.org/en/users/Drivers/ath#The_0x0_regulatory_domain
[3] http://wireless.kernel.org/en/developers/Regulatory/CRDA#Debugging_kernel_to_CRDA_communication
Comment 2 John Nielsen 2011-05-10 22:58:08 UTC
I'm not trying to override the settings; I was surprised it didn't "Just Work" with my custom kernel since it does under others.

Here's a "happy" dmesg snippet:

[    2.880434] cfg80211: Calling CRDA to update world regulatory domain
[    3.631954] cfg80211: World regulatory domain updated:
[    3.632095] cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[    3.632123] cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    3.632149] cfg80211:     (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[    3.632173] cfg80211:     (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[    3.632198] cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    3.632223] cfg80211:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    5.773655] ath: EEPROM regdomain: 0x0
[    5.773671] ath: EEPROM indicates default country code should be used
[    5.773688] ath: doing EEPROM country->regdmn map search
[    5.773709] ath: country maps to regdmn code: 0x3a
[    5.773724] ath: Country alpha2 being used: US
[    5.773738] ath: Regpair used: 0x3a
[    7.660087] cfg80211: Calling CRDA for country: US
[    8.734333] cfg80211: Regulatory domain changed to country: US
[    8.734354] cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[    8.734381] cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[    8.734406] cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[    8.734431] cfg80211:     (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    8.734456] cfg80211:     (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    8.734482] cfg80211:     (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    8.734507] cfg80211:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)


And here's the same snippet from a kernel without rfkill and/or modules:

[    0.107215] cfg80211: Calling CRDA to update world regulatory domain
[    2.228041] ath: EEPROM regdomain: 0x0
[    2.228056] ath: EEPROM indicates default country code should be used
[    2.228072] ath: doing EEPROM country->regdmn map search
[    2.228093] ath: country maps to regdmn code: 0x3a
[    2.228108] ath: Country alpha2 being used: US
[    2.228122] ath: Regpair used: 0x3a


It still decides to use "US" in the latter case, it just doesn't have any effect.

Under the same kernel I have run "udevadm monitor --environment kernel" followed by (in another terminal) "iw reg set US". Udevadm does not show any events and while iw doesn't return an error it doesn't do anything either.

JN
Comment 3 John Nielsen 2011-05-10 23:18:02 UTC
On May 10, 2011, at 9:30 PM, bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=34872
> 
> 
> 
> 
> 
> --- Comment #1 from Luis R. Rodriguez <mcgrof@gmail.com>  2011-05-10 21:30:28
> ---
> Huh? The APIs for changing regulatory domains are used to *help* compliance,
> not to override compliance [1]. If the card has 00 on the EEPROM it will map
> the US regulatory domain by design [2]. Your issue is completely irrelevant
> to
> overriding regulatory settings.

I'm not trying to override the settings.

> The issue you seem to be reporting is that udev events are not getting sent
> to
> userspace if cfg80211 is built-in and rfkill is disabled. Is that right? If
> so
> please review debugging CRDA [3] to see if you see udev events hit userspace.
> Please confirm and clarify your issue.

Correct. The udev events never seem to get generated. When it works (rfkill+modules), I see cfg80211 messages in dmesg about the domain being updated from World to US without having to do anything. When it doesn't work (static kernel or no rfkill) I see the initial messages about World domain but not any about changing to US. Additionally running "iw reg set US" manually has no effect--the domain is not updated and no events are shown in udevadm's debug output.
Comment 4 Jeremy Murphy 2011-06-05 13:04:32 UTC
I'm seeing similar strange behaviour on my laptop: there is a 50/50 chance whether the kernel will call the CRDA for country AU or DE.  (I'm in Australia.)  "iw reg get" reports country 00.
Comment 5 and 2011-06-05 14:09:16 UTC
I can conform it and thanks to John Nielsen for pointing out.

"iw reg set <COUNTRY>" doesnt work with a monolithic kernel.
We see only this kernel message:
kernel: cfg80211: Pending regulatory request, waiting for it to be processed...

Reason: udev never receive platform:regulatory "change" request from kernel.

Enabling wireless modules AND rfkill support udev see now kernel request.

linux-2.6.38-8 # grep =m /usr/src/linux/.config
CONFIG_CFG80211=m
CONFIG_MAC80211=m
CONFIG_RFKILL=m
CONFIG_SCSI_WAIT_SCAN=m
CONFIG_ATH_COMMON=m
CONFIG_ATH9K_HW=m
CONFIG_ATH9K_COMMON=m
CONFIG_ATH9K=m

# grep change /dev/.udev/udevmonitor.log 
KERNEL[1307289066.744647] change   /devices/platform/regulatory.0 (platform)
KERNEL[1307289066.910243] change   /devices/pci0000:00/0000:00:1c.2/0000:04:00.0/ieee80211/phy0/rfkill0 (rfkill)
UDEV  [1307289068.518418] change   /devices/platform/regulatory.0 (platform)
UDEV  [1307289068.518768] change   /devices/pci0000:00/0000:00:1c.2/0000:04:00.0/ieee80211/phy0/rfkill0 (rfkill)

Any solution for a monolithic kernel without modules?

Note You need to log in before you can comment on or make changes to this bug.