* More confusion with regulatory issues.
@ 2014-06-11 0:11 Ben Greear
2014-06-11 9:10 ` Luis R. Rodriguez
0 siblings, 1 reply; 9+ messages in thread
From: Ben Greear @ 2014-06-11 0:11 UTC (permalink / raw)
To: linux-wireless
I have a Fedora 19 system with two ath10k NICs in them. I'm not sure
they have any regulatory info in them at all, based on logs
and some poking at what firmware reports.
I have /etc/sysconfig/regdomain set to:
COUNTRY=US
I am configuring the country-code as US in the hostapd.
I installed the latest regulatory.bin, downloaded and built today.
And still, it shows up as 'country 98' and DFS-UNSET,
which keeps DFS from working, evidently.
[root@ath10k-2220 lanforge]# iw reg get
country 98: DFS-UNSET
(2402 - 2472 @ 70), (N/A, 20)
(2457 - 2472 @ 70), (N/A, 20), PASSIVE-SCAN
(5170 - 5250 @ 80), (N/A, 17), PASSIVE-SCAN
(5250 - 5330 @ 80), (N/A, 20), DFS, PASSIVE-SCAN
(5735 - 5835 @ 80), (N/A, 20), PASSIVE-SCAN
(57240 - 63720 @ 2160), (N/A, 0)
Another Fedora 17 system, with ath10k and ath9k (hacked to use regdomain 0)
NIC shows up as more what I expected, using slightly older regulatory.bin:
[root@ct523-9292 ~]# iw reg get
country US:
(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@ct523-9292 ~]#
I just want to start hostapd on a DFS channel for some testing...any
idea what is making the regulatory domain weird? Could it actually
be coming from ath10k somehow?
[root@ath10k-2220 lanforge]# dmesg|grep cfg80211
[ 6.059919] cfg80211: Calling CRDA to update world regulatory domain
[ 6.259155] cfg80211: World regulatory domain updated:
[ 6.259156] cfg80211: DFS Master region: unset
[ 6.259158] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 6.259160] cfg80211: (2402000 KHz - 2472000 KHz @ 0 KHz), (N/A, 2000 mBm), (N/A)
[ 6.259162] cfg80211: (2457000 KHz - 2482000 KHz @ 0 KHz), (N/A, 2000 mBm), (N/A)
[ 6.259163] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
[ 6.259165] cfg80211: (5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A, 2000 mBm), (N/A)
[ 6.259166] cfg80211: (5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 6.259168] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 6.259169] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 6.259171] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[ 7.925339] cfg80211: Updating information on frequency 5180 MHz with regulatory rule:
[ 7.925342] cfg80211: 5140000 KHz - 5360000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.925345] cfg80211: Updating information on frequency 5200 MHz with regulatory rule:
[ 7.925348] cfg80211: 5140000 KHz - 5360000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.925350] cfg80211: Updating information on frequency 5220 MHz with regulatory rule:
[ 7.925353] cfg80211: 5140000 KHz - 5360000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.925355] cfg80211: Updating information on frequency 5240 MHz with regulatory rule:
[ 7.925358] cfg80211: 5140000 KHz - 5360000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.925360] cfg80211: Updating information on frequency 5260 MHz with regulatory rule:
[ 7.925363] cfg80211: 5140000 KHz - 5360000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.925365] cfg80211: Updating information on frequency 5280 MHz with regulatory rule:
[ 7.925368] cfg80211: 5140000 KHz - 5360000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.925370] cfg80211: Updating information on frequency 5300 MHz with regulatory rule:
[ 7.925373] cfg80211: 5140000 KHz - 5360000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.925375] cfg80211: Updating information on frequency 5320 MHz with regulatory rule:
[ 7.925378] cfg80211: 5140000 KHz - 5360000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.925380] cfg80211: Disabling freq 5500 MHz as custom regd has no rule that fits it
[ 7.925382] cfg80211: Disabling freq 5520 MHz as custom regd has no rule that fits it
[ 7.925384] cfg80211: Disabling freq 5540 MHz as custom regd has no rule that fits it
[ 7.925386] cfg80211: Disabling freq 5560 MHz as custom regd has no rule that fits it
[ 7.925388] cfg80211: Disabling freq 5580 MHz as custom regd has no rule that fits it
[ 7.925390] cfg80211: Disabling freq 5600 MHz as custom regd has no rule that fits it
[ 7.925392] cfg80211: Disabling freq 5620 MHz as custom regd has no rule that fits it
[ 7.925394] cfg80211: Disabling freq 5640 MHz as custom regd has no rule that fits it
[ 7.925396] cfg80211: Disabling freq 5660 MHz as custom regd has no rule that fits it
[ 7.925398] cfg80211: Disabling freq 5680 MHz as custom regd has no rule that fits it
[ 7.925399] cfg80211: Disabling freq 5700 MHz as custom regd has no rule that fits it
[ 7.925402] cfg80211: Updating information on frequency 5745 MHz with regulatory rule:
[ 7.925405] cfg80211: 5715000 KHz - 5860000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.925407] cfg80211: Updating information on frequency 5765 MHz with regulatory rule:
[ 7.925410] cfg80211: 5715000 KHz - 5860000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.925412] cfg80211: Updating information on frequency 5785 MHz with regulatory rule:
[ 7.925415] cfg80211: 5715000 KHz - 5860000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.925417] cfg80211: Updating information on frequency 5805 MHz with regulatory rule:
[ 7.925420] cfg80211: 5715000 KHz - 5860000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.925422] cfg80211: Updating information on frequency 5825 MHz with regulatory rule:
[ 7.925425] cfg80211: 5715000 KHz - 5860000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.925490] cfg80211: Ignoring regulatory request set by core since the driver uses its own custom regulatory domain
[ 7.925964] cfg80211: Calling CRDA for country: US
[ 7.926309] cfg80211: Updating information on frequency 2412 MHz with regulatory rule:
[ 7.926313] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 7.926316] cfg80211: Updating information on frequency 2417 MHz with regulatory rule:
[ 7.926320] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 7.926323] cfg80211: Updating information on frequency 2422 MHz with regulatory rule:
[ 7.926327] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 7.926329] cfg80211: Updating information on frequency 2427 MHz with regulatory rule:
[ 7.926330] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 7.926332] cfg80211: Updating information on frequency 2432 MHz with regulatory rule:
[ 7.926333] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 7.926335] cfg80211: Updating information on frequency 2437 MHz with regulatory rule:
[ 7.926336] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 7.926338] cfg80211: Updating information on frequency 2442 MHz with regulatory rule:
[ 7.926339] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 7.926341] cfg80211: Updating information on frequency 2447 MHz with regulatory rule:
[ 7.926342] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 7.926343] cfg80211: Updating information on frequency 2452 MHz with regulatory rule:
[ 7.926345] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 7.926346] cfg80211: Updating information on frequency 2457 MHz with regulatory rule:
[ 7.926348] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 7.926349] cfg80211: Updating information on frequency 2462 MHz with regulatory rule:
[ 7.926351] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 7.926352] cfg80211: Updating information on frequency 2467 MHz with regulatory rule:
[ 7.926353] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 7.926355] cfg80211: Disabling freq 2472 MHz as custom regd has no rule that fits it
[ 7.926356] cfg80211: Disabling freq 2484 MHz as custom regd has no rule that fits it
[ 7.926358] cfg80211: Updating information on frequency 5180 MHz with regulatory rule:
[ 7.926360] cfg80211: 5140000 KHz - 5360000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.926362] cfg80211: Updating information on frequency 5200 MHz with regulatory rule:
[ 7.926364] cfg80211: 5140000 KHz - 5360000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.926365] cfg80211: Updating information on frequency 5220 MHz with regulatory rule:
[ 7.926367] cfg80211: 5140000 KHz - 5360000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.926368] cfg80211: Updating information on frequency 5240 MHz with regulatory rule:
[ 7.926370] cfg80211: 5140000 KHz - 5360000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.926372] cfg80211: Updating information on frequency 5260 MHz with regulatory rule:
[ 7.926374] cfg80211: 5140000 KHz - 5360000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.926375] cfg80211: Updating information on frequency 5280 MHz with regulatory rule:
[ 7.926377] cfg80211: 5140000 KHz - 5360000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.926379] cfg80211: Updating information on frequency 5300 MHz with regulatory rule:
[ 7.926381] cfg80211: 5140000 KHz - 5360000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.926383] cfg80211: Updating information on frequency 5320 MHz with regulatory rule:
[ 7.926384] cfg80211: 5140000 KHz - 5360000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.926385] cfg80211: Disabling freq 5500 MHz as custom regd has no rule that fits it
[ 7.926387] cfg80211: Disabling freq 5520 MHz as custom regd has no rule that fits it
[ 7.926388] cfg80211: Disabling freq 5540 MHz as custom regd has no rule that fits it
[ 7.926389] cfg80211: Disabling freq 5560 MHz as custom regd has no rule that fits it
[ 7.926390] cfg80211: Disabling freq 5580 MHz as custom regd has no rule that fits it
[ 7.926391] cfg80211: Disabling freq 5600 MHz as custom regd has no rule that fits it
[ 7.926392] cfg80211: Disabling freq 5620 MHz as custom regd has no rule that fits it
[ 7.926393] cfg80211: Disabling freq 5640 MHz as custom regd has no rule that fits it
[ 7.926395] cfg80211: Disabling freq 5660 MHz as custom regd has no rule that fits it
[ 7.926396] cfg80211: Disabling freq 5680 MHz as custom regd has no rule that fits it
[ 7.926397] cfg80211: Disabling freq 5700 MHz as custom regd has no rule that fits it
[ 7.926398] cfg80211: Updating information on frequency 5745 MHz with regulatory rule:
[ 7.926400] cfg80211: 5715000 KHz - 5860000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.926401] cfg80211: Updating information on frequency 5765 MHz with regulatory rule:
[ 7.926403] cfg80211: 5715000 KHz - 5860000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.926404] cfg80211: Updating information on frequency 5785 MHz with regulatory rule:
[ 7.926406] cfg80211: 5715000 KHz - 5860000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.926408] cfg80211: Updating information on frequency 5805 MHz with regulatory rule:
[ 7.926409] cfg80211: 5715000 KHz - 5860000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.926411] cfg80211: Updating information on frequency 5825 MHz with regulatory rule:
[ 7.926412] cfg80211: 5715000 KHz - 5860000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.926456] cfg80211: Updating information on frequency 2412 MHz with regulatory rule:
[ 7.926460] cfg80211: 2402000 KHz - 2472000 KHz @ 0 KHz), (N/A mBi, 2000 mBm)
[ 7.926464] cfg80211: Updating information on frequency 2417 MHz with regulatory rule:
[ 7.926469] cfg80211: 2402000 KHz - 2472000 KHz @ 0 KHz), (N/A mBi, 2000 mBm)
[ 7.926473] cfg80211: Updating information on frequency 2422 MHz with regulatory rule:
[ 7.926477] cfg80211: 2402000 KHz - 2472000 KHz @ 0 KHz), (N/A mBi, 2000 mBm)
[ 7.926478] cfg80211: Updating information on frequency 2427 MHz with regulatory rule:
[ 7.926480] cfg80211: 2402000 KHz - 2472000 KHz @ 0 KHz), (N/A mBi, 2000 mBm)
[ 7.926482] cfg80211: Updating information on frequency 2432 MHz with regulatory rule:
[ 7.926483] cfg80211: 2402000 KHz - 2472000 KHz @ 0 KHz), (N/A mBi, 2000 mBm)
[ 7.926486] cfg80211: Updating information on frequency 2437 MHz with regulatory rule:
[ 7.926487] cfg80211: 2402000 KHz - 2472000 KHz @ 0 KHz), (N/A mBi, 2000 mBm)
[ 7.926489] cfg80211: Updating information on frequency 2442 MHz with regulatory rule:
[ 7.926491] cfg80211: 2402000 KHz - 2472000 KHz @ 0 KHz), (N/A mBi, 2000 mBm)
[ 7.926492] cfg80211: Updating information on frequency 2447 MHz with regulatory rule:
[ 7.926494] cfg80211: 2402000 KHz - 2472000 KHz @ 0 KHz), (N/A mBi, 2000 mBm)
[ 7.926496] cfg80211: Updating information on frequency 2452 MHz with regulatory rule:
[ 7.926497] cfg80211: 2402000 KHz - 2472000 KHz @ 0 KHz), (N/A mBi, 2000 mBm)
[ 7.926499] cfg80211: Updating information on frequency 2457 MHz with regulatory rule:
[ 7.926501] cfg80211: 2402000 KHz - 2472000 KHz @ 0 KHz), (N/A mBi, 2000 mBm)
[ 7.926502] cfg80211: Updating information on frequency 2462 MHz with regulatory rule:
[ 7.926505] cfg80211: 2402000 KHz - 2472000 KHz @ 0 KHz), (N/A mBi, 2000 mBm)
[ 7.926506] cfg80211: Updating information on frequency 2467 MHz with regulatory rule:
[ 7.926508] cfg80211: 2402000 KHz - 2472000 KHz @ 0 KHz), (N/A mBi, 2000 mBm)
[ 7.926510] cfg80211: Updating information on frequency 2472 MHz with regulatory rule:
[ 7.926512] cfg80211: 2457000 KHz - 2482000 KHz @ 0 KHz), (N/A mBi, 2000 mBm)
[ 7.926513] cfg80211: Updating information on frequency 2484 MHz with regulatory rule:
[ 7.926515] cfg80211: 2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A mBi, 2000 mBm)
[ 7.926517] cfg80211: Updating information on frequency 5180 MHz with regulatory rule:
[ 7.926519] cfg80211: 5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926521] cfg80211: Updating information on frequency 5200 MHz with regulatory rule:
[ 7.926523] cfg80211: 5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926525] cfg80211: Updating information on frequency 5220 MHz with regulatory rule:
[ 7.926527] cfg80211: 5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926528] cfg80211: Updating information on frequency 5240 MHz with regulatory rule:
[ 7.926530] cfg80211: 5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926532] cfg80211: Updating information on frequency 5260 MHz with regulatory rule:
[ 7.926533] cfg80211: 5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926535] cfg80211: Updating information on frequency 5280 MHz with regulatory rule:
[ 7.926537] cfg80211: 5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926539] cfg80211: Updating information on frequency 5300 MHz with regulatory rule:
[ 7.926541] cfg80211: 5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926543] cfg80211: Updating information on frequency 5320 MHz with regulatory rule:
[ 7.926545] cfg80211: 5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926547] cfg80211: Updating information on frequency 5500 MHz with regulatory rule:
[ 7.926548] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926550] cfg80211: Updating information on frequency 5520 MHz with regulatory rule:
[ 7.926552] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926554] cfg80211: Updating information on frequency 5540 MHz with regulatory rule:
[ 7.926555] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926557] cfg80211: Updating information on frequency 5560 MHz with regulatory rule:
[ 7.926559] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926561] cfg80211: Updating information on frequency 5580 MHz with regulatory rule:
[ 7.926563] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926564] cfg80211: Updating information on frequency 5600 MHz with regulatory rule:
[ 7.926566] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926568] cfg80211: Updating information on frequency 5620 MHz with regulatory rule:
[ 7.926570] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926571] cfg80211: Updating information on frequency 5640 MHz with regulatory rule:
[ 7.926573] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926575] cfg80211: Updating information on frequency 5660 MHz with regulatory rule:
[ 7.926577] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926579] cfg80211: Updating information on frequency 5680 MHz with regulatory rule:
[ 7.926581] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926582] cfg80211: Updating information on frequency 5700 MHz with regulatory rule:
[ 7.926584] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 7.926586] cfg80211: Updating information on frequency 5745 MHz with regulatory rule:
[ 7.926587] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 2000 mBm)
[ 7.926589] cfg80211: Updating information on frequency 5765 MHz with regulatory rule:
[ 7.926591] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 2000 mBm)
[ 7.926592] cfg80211: Updating information on frequency 5785 MHz with regulatory rule:
[ 7.926594] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 2000 mBm)
[ 7.926595] cfg80211: Updating information on frequency 5805 MHz with regulatory rule:
[ 7.926597] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 2000 mBm)
[ 7.926598] cfg80211: Updating information on frequency 5825 MHz with regulatory rule:
[ 7.926600] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 2000 mBm)
[ 7.927057] cfg80211: Calling CRDA for country: US
[ 7.930942] cfg80211: Ignoring regulatory request set by driver since the driver requires its own regulatory domain to be set first
[ 7.930946] cfg80211: Updating information on frequency 5180 MHz with regulatory rule:
[ 7.930947] cfg80211: 5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A mBi, 1700 mBm)
[ 7.930948] cfg80211: Updating information on frequency 5200 MHz with regulatory rule:
[ 7.930950] cfg80211: 5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A mBi, 1700 mBm)
[ 7.930951] cfg80211: Updating information on frequency 5220 MHz with regulatory rule:
[ 7.930952] cfg80211: 5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A mBi, 1700 mBm)
[ 7.930953] cfg80211: Updating information on frequency 5240 MHz with regulatory rule:
[ 7.930955] cfg80211: 5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A mBi, 1700 mBm)
[ 7.930957] cfg80211: Updating information on frequency 5260 MHz with regulatory rule:
[ 7.930959] cfg80211: 5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A mBi, 2300 mBm)
[ 7.930961] cfg80211: Updating information on frequency 5280 MHz with regulatory rule:
[ 7.930962] cfg80211: 5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A mBi, 2300 mBm)
[ 7.930964] cfg80211: Updating information on frequency 5300 MHz with regulatory rule:
[ 7.930966] cfg80211: 5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A mBi, 2300 mBm)
[ 7.930967] cfg80211: Updating information on frequency 5320 MHz with regulatory rule:
[ 7.930969] cfg80211: 5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A mBi, 2300 mBm)
[ 7.930970] cfg80211: Disabling freq 5500 MHz for good
[ 7.930971] cfg80211: Disabling freq 5520 MHz for good
[ 7.930972] cfg80211: Disabling freq 5540 MHz for good
[ 7.930974] cfg80211: Disabling freq 5560 MHz for good
[ 7.930975] cfg80211: Disabling freq 5580 MHz for good
[ 7.930977] cfg80211: Disabling freq 5600 MHz for good
[ 7.930979] cfg80211: Disabling freq 5620 MHz for good
[ 7.930980] cfg80211: Disabling freq 5640 MHz for good
[ 7.930981] cfg80211: Disabling freq 5660 MHz for good
[ 7.930982] cfg80211: Disabling freq 5680 MHz for good
[ 7.930983] cfg80211: Disabling freq 5700 MHz for good
[ 7.930985] cfg80211: Updating information on frequency 5745 MHz with regulatory rule:
[ 7.930986] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.930988] cfg80211: Updating information on frequency 5765 MHz with regulatory rule:
[ 7.930990] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.930992] cfg80211: Updating information on frequency 5785 MHz with regulatory rule:
[ 7.930993] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.930995] cfg80211: Updating information on frequency 5805 MHz with regulatory rule:
[ 7.930998] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.930999] cfg80211: Updating information on frequency 5825 MHz with regulatory rule:
[ 7.931001] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.931007] cfg80211: Current regulatory domain intersected:
[ 7.931008] cfg80211: DFS Master region: unset
[ 7.931009] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 7.931012] cfg80211: (2402000 KHz - 2472000 KHz @ 0 KHz), (N/A, 2000 mBm), (N/A)
[ 7.931014] cfg80211: (2457000 KHz - 2472000 KHz @ 0 KHz), (N/A, 2000 mBm), (N/A)
[ 7.931018] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 1700 mBm), (N/A)
[ 7.931020] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A, 2000 mBm), (0 s)
[ 7.931022] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 7.931024] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[ 7.931041] cfg80211: Calling CRDA for country: US
[ 7.934863] cfg80211: Updating information on frequency 2412 MHz with regulatory rule:
[ 7.934866] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 3000 mBm)
[ 7.934868] cfg80211: Updating information on frequency 2417 MHz with regulatory rule:
[ 7.934869] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 3000 mBm)
[ 7.934870] cfg80211: Updating information on frequency 2422 MHz with regulatory rule:
[ 7.934872] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 3000 mBm)
[ 7.934873] cfg80211: Updating information on frequency 2427 MHz with regulatory rule:
[ 7.934874] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 3000 mBm)
[ 7.934875] cfg80211: Updating information on frequency 2432 MHz with regulatory rule:
[ 7.934876] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 3000 mBm)
[ 7.934878] cfg80211: Updating information on frequency 2437 MHz with regulatory rule:
[ 7.934880] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 3000 mBm)
[ 7.934881] cfg80211: Updating information on frequency 2442 MHz with regulatory rule:
[ 7.934883] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 3000 mBm)
[ 7.934885] cfg80211: Updating information on frequency 2447 MHz with regulatory rule:
[ 7.934886] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 3000 mBm)
[ 7.934888] cfg80211: Updating information on frequency 2452 MHz with regulatory rule:
[ 7.934890] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 3000 mBm)
[ 7.934891] cfg80211: Updating information on frequency 2457 MHz with regulatory rule:
[ 7.934893] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 3000 mBm)
[ 7.934895] cfg80211: Updating information on frequency 2462 MHz with regulatory rule:
[ 7.934896] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 3000 mBm)
[ 7.934898] cfg80211: Updating information on frequency 2467 MHz with regulatory rule:
[ 7.934899] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 3000 mBm)
[ 7.934900] cfg80211: Disabling freq 2472 MHz for good
[ 7.934901] cfg80211: Disabling freq 2484 MHz for good
[ 7.934903] cfg80211: Updating information on frequency 5180 MHz with regulatory rule:
[ 7.934904] cfg80211: 5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A mBi, 1700 mBm)
[ 7.934905] cfg80211: Updating information on frequency 5200 MHz with regulatory rule:
[ 7.934906] cfg80211: 5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A mBi, 1700 mBm)
[ 7.934907] cfg80211: Updating information on frequency 5220 MHz with regulatory rule:
[ 7.934909] cfg80211: 5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A mBi, 1700 mBm)
[ 7.934910] cfg80211: Updating information on frequency 5240 MHz with regulatory rule:
[ 7.934911] cfg80211: 5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A mBi, 1700 mBm)
[ 7.934912] cfg80211: Updating information on frequency 5260 MHz with regulatory rule:
[ 7.934913] cfg80211: 5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A mBi, 2300 mBm)
[ 7.934915] cfg80211: Updating information on frequency 5280 MHz with regulatory rule:
[ 7.934916] cfg80211: 5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A mBi, 2300 mBm)
[ 7.934917] cfg80211: Updating information on frequency 5300 MHz with regulatory rule:
[ 7.934918] cfg80211: 5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A mBi, 2300 mBm)
[ 7.934920] cfg80211: Updating information on frequency 5320 MHz with regulatory rule:
[ 7.934922] cfg80211: 5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A mBi, 2300 mBm)
[ 7.934923] cfg80211: Disabling freq 5500 MHz for good
[ 7.934924] cfg80211: Disabling freq 5520 MHz for good
[ 7.934926] cfg80211: Disabling freq 5540 MHz for good
[ 7.934927] cfg80211: Disabling freq 5560 MHz for good
[ 7.934928] cfg80211: Disabling freq 5580 MHz for good
[ 7.934929] cfg80211: Disabling freq 5600 MHz for good
[ 7.934931] cfg80211: Disabling freq 5620 MHz for good
[ 7.934932] cfg80211: Disabling freq 5640 MHz for good
[ 7.934933] cfg80211: Disabling freq 5660 MHz for good
[ 7.934934] cfg80211: Disabling freq 5680 MHz for good
[ 7.934935] cfg80211: Disabling freq 5700 MHz for good
[ 7.934937] cfg80211: Updating information on frequency 5745 MHz with regulatory rule:
[ 7.934939] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.934940] cfg80211: Updating information on frequency 5765 MHz with regulatory rule:
[ 7.934941] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.934942] cfg80211: Updating information on frequency 5785 MHz with regulatory rule:
[ 7.934943] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.934945] cfg80211: Updating information on frequency 5805 MHz with regulatory rule:
[ 7.934946] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.934947] cfg80211: Updating information on frequency 5825 MHz with regulatory rule:
[ 7.934948] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.934954] cfg80211: Updating information on frequency 5180 MHz with regulatory rule:
[ 7.934955] cfg80211: 5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A mBi, 1700 mBm)
[ 7.934956] cfg80211: Updating information on frequency 5200 MHz with regulatory rule:
[ 7.934958] cfg80211: 5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A mBi, 1700 mBm)
[ 7.934959] cfg80211: Updating information on frequency 5220 MHz with regulatory rule:
[ 7.934960] cfg80211: 5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A mBi, 1700 mBm)
[ 7.934962] cfg80211: Updating information on frequency 5240 MHz with regulatory rule:
[ 7.934963] cfg80211: 5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A mBi, 1700 mBm)
[ 7.934964] cfg80211: Updating information on frequency 5260 MHz with regulatory rule:
[ 7.934965] cfg80211: 5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A mBi, 2300 mBm)
[ 7.934966] cfg80211: Updating information on frequency 5280 MHz with regulatory rule:
[ 7.934968] cfg80211: 5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A mBi, 2300 mBm)
[ 7.934969] cfg80211: Updating information on frequency 5300 MHz with regulatory rule:
[ 7.934970] cfg80211: 5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A mBi, 2300 mBm)
[ 7.934971] cfg80211: Updating information on frequency 5320 MHz with regulatory rule:
[ 7.934973] cfg80211: 5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A mBi, 2300 mBm)
[ 7.934973] cfg80211: Disabling freq 5500 MHz
[ 7.934974] cfg80211: Disabling freq 5520 MHz
[ 7.934975] cfg80211: Disabling freq 5540 MHz
[ 7.934976] cfg80211: Disabling freq 5560 MHz
[ 7.934977] cfg80211: Disabling freq 5580 MHz
[ 7.934977] cfg80211: Disabling freq 5600 MHz
[ 7.934978] cfg80211: Disabling freq 5620 MHz
[ 7.934979] cfg80211: Disabling freq 5640 MHz
[ 7.934980] cfg80211: Disabling freq 5660 MHz
[ 7.934980] cfg80211: Disabling freq 5680 MHz
[ 7.934981] cfg80211: Disabling freq 5700 MHz
[ 7.934982] cfg80211: Updating information on frequency 5745 MHz with regulatory rule:
[ 7.934983] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.934984] cfg80211: Updating information on frequency 5765 MHz with regulatory rule:
[ 7.934986] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.934987] cfg80211: Updating information on frequency 5785 MHz with regulatory rule:
[ 7.934988] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.934989] cfg80211: Updating information on frequency 5805 MHz with regulatory rule:
[ 7.934990] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.934991] cfg80211: Updating information on frequency 5825 MHz with regulatory rule:
[ 7.934993] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
[ 7.934995] cfg80211: Current regulatory domain intersected:
[ 7.934996] cfg80211: DFS Master region: unset
[ 7.934997] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 7.934999] cfg80211: (2402000 KHz - 2472000 KHz @ 0 KHz), (N/A, 2000 mBm), (N/A)
[ 7.935000] cfg80211: (2457000 KHz - 2472000 KHz @ 0 KHz), (N/A, 2000 mBm), (N/A)
[ 7.935002] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 1700 mBm), (N/A)
[ 7.935003] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A, 2000 mBm), (0 s)
[ 7.935005] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 7.935006] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[ 63.664229] cfg80211: Found new beacon on frequency: 5180 MHz (Ch 36) on wiphy0
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: More confusion with regulatory issues.
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:15 ` Ben Greear
0 siblings, 2 replies; 9+ messages in thread
From: Luis R. Rodriguez @ 2014-06-11 9:10 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
On Tue, Jun 10, 2014 at 5:11 PM, Ben Greear <greearb@candelatech.com> wrote:
> I have a Fedora 19 system with two ath10k NICs in them. I'm not sure
> they have any regulatory info in them at all, based on logs
> and some poking at what firmware reports.
>
> I have /etc/sysconfig/regdomain set to:
>
> COUNTRY=US
I don't know who thought adding a sysconfig / default file with
regdomain with a value specified would be a good idea but users should
then just be aware that user regulatory settings *help* compliance
further, specially with cards that have regulatory stuff designed into
it, like ath5k, ath9k and ath10k.
There is one caveat too -- Atheros sells 802.11 cards to manufacturers
and for some time and maybe still today they set the regulatory domain
to 0x0 and override the regulatory setting in software since this is
economically cheaper than overriding it through changing the EEPROM /
OTP / whatever. This is actually not allowed in certain countries like
the US and JP, and what makes this worse is that the 0x0 regulatory
domain maps to the US on the ath module given that that is what is
designed by Atheros for STAs so that is what we do for ath. AP
manufacturers have the regulatory onus on them though -- so Atheros
cannot control what they do -- they can only provide EEPROM tools,
etc, and if folk are doing stupid things in software or using software
to do sloppy things -- Atheros needs to educate customers that that is
not a feature that is supported, and actually issue a bulletin on it,
otherwise boneheads that have been doing it for a long time will not
change.
In short don't use the userspace stuff to set the regulatory domain
and use the OTP / EEPROM tools to set it. Setting it in software is
not allowed explicitly at least by the US and JP. It may be allowed in
other countries and if your country has that option you can look at
the ath module for some kconfig options I added before leaving Atheros
that enables some of this functionality for those countries.
Apart from all this -- the fact that you get an intersection for all
reg hints going for US seems rather odd and should not be happening,
specially since if a regdomain was set to US then -EALREADY should be
issued and that regulatory domain should just be used to set onto the
cards (if the cards had an EEPROM / OTP thing with US). Even if the
user sets US twice, -EALREADY and the implications of it should
happen.
Luis
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: More confusion with regulatory issues.
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 14:15 ` Ben Greear
1 sibling, 1 reply; 9+ messages in thread
From: Janusz Dziedzic @ 2014-06-11 10:34 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Ben Greear, linux-wireless
On 11 June 2014 11:10, Luis R. Rodriguez <mcgrof@do-not-panic.com> wrote:
> On Tue, Jun 10, 2014 at 5:11 PM, Ben Greear <greearb@candelatech.com> wrote:
>> I have a Fedora 19 system with two ath10k NICs in them. I'm not sure
>> they have any regulatory info in them at all, based on logs
>> and some poking at what firmware reports.
>>
>> I have /etc/sysconfig/regdomain set to:
>>
>> COUNTRY=US
>
> I don't know who thought adding a sysconfig / default file with
> regdomain with a value specified would be a good idea but users should
> then just be aware that user regulatory settings *help* compliance
> further, specially with cards that have regulatory stuff designed into
> it, like ath5k, ath9k and ath10k.
>
> There is one caveat too -- Atheros sells 802.11 cards to manufacturers
> and for some time and maybe still today they set the regulatory domain
> to 0x0 and override the regulatory setting in software since this is
> economically cheaper than overriding it through changing the EEPROM /
> OTP / whatever. This is actually not allowed in certain countries like
> the US and JP, and what makes this worse is that the 0x0 regulatory
> domain maps to the US on the ath module given that that is what is
> designed by Atheros for STAs so that is what we do for ath. AP
> manufacturers have the regulatory onus on them though -- so Atheros
> cannot control what they do -- they can only provide EEPROM tools,
> etc, and if folk are doing stupid things in software or using software
> to do sloppy things -- Atheros needs to educate customers that that is
> not a feature that is supported, and actually issue a bulletin on it,
> otherwise boneheads that have been doing it for a long time will not
> change.
>
> In short don't use the userspace stuff to set the regulatory domain
> and use the OTP / EEPROM tools to set it. Setting it in software is
> not allowed explicitly at least by the US and JP. It may be allowed in
> other countries and if your country has that option you can look at
> the ath module for some kconfig options I added before leaving Atheros
> that enables some of this functionality for those countries.
>
> Apart from all this -- the fact that you get an intersection for all
> reg hints going for US seems rather odd and should not be happening,
> specially since if a regdomain was set to US then -EALREADY should be
> issued and that regulatory domain should just be used to set onto the
> cards (if the cards had an EEPROM / OTP thing with US). Even if the
> user sets US twice, -EALREADY and the implications of it should
> happen.
>
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 ...
BR
Janusz
BR
Janusz
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: More confusion with regulatory issues.
2014-06-11 9:10 ` Luis R. Rodriguez
2014-06-11 10:34 ` Janusz Dziedzic
@ 2014-06-11 14:15 ` Ben Greear
1 sibling, 0 replies; 9+ messages in thread
From: Ben Greear @ 2014-06-11 14:15 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
On 06/11/2014 02:10 AM, Luis R. Rodriguez wrote:
> On Tue, Jun 10, 2014 at 5:11 PM, Ben Greear <greearb@candelatech.com> wrote:
>> I have a Fedora 19 system with two ath10k NICs in them. I'm not sure
>> they have any regulatory info in them at all, based on logs
>> and some poking at what firmware reports.
>>
>> I have /etc/sysconfig/regdomain set to:
>>
>> COUNTRY=US
>
> I don't know who thought adding a sysconfig / default file with
> regdomain with a value specified would be a good idea but users should
> then just be aware that user regulatory settings *help* compliance
> further, specially with cards that have regulatory stuff designed into
> it, like ath5k, ath9k and ath10k.
Otherwise, the OS tries to use time-zone, so one way or another
it's getting user-configurables off of the disk.
My ath10k cards are pre FCC approved (beta-ish NICs), so maybe
that is why they have no regulatory info in them.
And, I'm making test gear...I'm not just trying to use my
laptop at a coffee shop. I understand why regulatory stuff
exists, I just need to set up a specific test to try to
debug some ath10k firmware problems.
> There is one caveat too -- Atheros sells 802.11 cards to manufacturers
> and for some time and maybe still today they set the regulatory domain
> to 0x0 and override the regulatory setting in software since this is
> economically cheaper than overriding it through changing the EEPROM /
> OTP / whatever. This is actually not allowed in certain countries like
> the US and JP, and what makes this worse is that the 0x0 regulatory
> domain maps to the US on the ath module given that that is what is
> designed by Atheros for STAs so that is what we do for ath. AP
> manufacturers have the regulatory onus on them though -- so Atheros
> cannot control what they do -- they can only provide EEPROM tools,
> etc, and if folk are doing stupid things in software or using software
> to do sloppy things -- Atheros needs to educate customers that that is
> not a feature that is supported, and actually issue a bulletin on it,
> otherwise boneheads that have been doing it for a long time will not
> change.
>
> In short don't use the userspace stuff to set the regulatory domain
> and use the OTP / EEPROM tools to set it. Setting it in software is
> not allowed explicitly at least by the US and JP. It may be allowed in
> other countries and if your country has that option you can look at
> the ath module for some kconfig options I added before leaving Atheros
> that enables some of this functionality for those countries.
>
> Apart from all this -- the fact that you get an intersection for all
> reg hints going for US seems rather odd and should not be happening,
> specially since if a regdomain was set to US then -EALREADY should be
> issued and that regulatory domain should just be used to set onto the
> cards (if the cards had an EEPROM / OTP thing with US). Even if the
> user sets US twice, -EALREADY and the implications of it should
> happen.
I'll try the patch Janusz suggested, maybe that will fix the problem.
For what it's worth, I added a wrapper to replace /sbin/regdb and printed
out the value of COUNTRY before calling the original regdb. On the troubled
system, it was: 00, US, US, US, US
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: More confusion with regulatory issues.
2014-06-11 10:34 ` Janusz Dziedzic
@ 2014-06-11 14:31 ` Ben Greear
2014-06-11 15:48 ` Ben Greear
0 siblings, 1 reply; 9+ messages in thread
From: Ben Greear @ 2014-06-11 14:31 UTC (permalink / raw)
To: Janusz Dziedzic; +Cc: Luis R. Rodriguez, linux-wireless
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 ~]#
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: More confusion with regulatory issues.
2014-06-11 14:31 ` Ben Greear
@ 2014-06-11 15:48 ` Ben Greear
2014-06-11 16:31 ` Ben Greear
0 siblings, 1 reply; 9+ messages in thread
From: Ben Greear @ 2014-06-11 15:48 UTC (permalink / raw)
To: Janusz Dziedzic; +Cc: Luis R. Rodriguez, linux-wireless
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;
}
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: More confusion with regulatory issues.
2014-06-11 15:48 ` Ben Greear
@ 2014-06-11 16:31 ` Ben Greear
2014-06-11 19:24 ` Janusz Dziedzic
0 siblings, 1 reply; 9+ messages in thread
From: Ben Greear @ 2014-06-11 16:31 UTC (permalink / raw)
To: Janusz Dziedzic; +Cc: Luis R. Rodriguez, linux-wireless
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: More confusion with regulatory issues.
2014-06-11 16:31 ` Ben Greear
@ 2014-06-11 19:24 ` Janusz Dziedzic
2014-06-23 19:33 ` Luis R. Rodriguez
0 siblings, 1 reply; 9+ messages in thread
From: Janusz Dziedzic @ 2014-06-11 19:24 UTC (permalink / raw)
To: Ben Greear; +Cc: Luis R. Rodriguez, linux-wireless
On 11 June 2014 18:31, Ben Greear <greearb@candelatech.com> wrote:
> 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:
>
Get newest:
crda,
wireless-regdb and revert
wireless-regdb: set AUTO bandwidth for world regulatory
(shouldn't be there)
iw,
Use my patch: cfg80211: reg: setup correct alpha2 after intersection
(Ben could you
Load driver and set eg. PL (iw reg set PL)
You should get correct country and DFS region.
Next you can try hostapd :)
BR
Janusz
>
> [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
>
> --
> 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] 9+ messages in thread
* Re: More confusion with regulatory issues.
2014-06-11 19:24 ` Janusz Dziedzic
@ 2014-06-23 19:33 ` Luis R. Rodriguez
0 siblings, 0 replies; 9+ messages in thread
From: Luis R. Rodriguez @ 2014-06-23 19:33 UTC (permalink / raw)
To: Janusz Dziedzic; +Cc: Ben Greear, linux-wireless
On Wed, Jun 11, 2014 at 09:24:54PM +0200, Janusz Dziedzic wrote:
> On 11 June 2014 18:31, Ben Greear <greearb@candelatech.com> wrote:
> > 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:
> >
> Get newest:
> crda,
> wireless-regdb and revert
> wireless-regdb: set AUTO bandwidth for world regulatory
> (shouldn't be there)
> iw,
> Use my patch: cfg80211: reg: setup correct alpha2 after intersection
> (Ben could you
> Load driver and set eg. PL (iw reg set PL)
> You should get correct country and DFS region.
> Next you can try hostapd :)
I'll Cc you folks on a thread that I believe identifies the real source
of the issue here.
Luis
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-06-23 19:33 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2014-06-11 19:24 ` Janusz Dziedzic
2014-06-23 19:33 ` Luis R. Rodriguez
2014-06-11 14:15 ` Ben Greear
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.