Following up on the old-ish ?[ath5k-devel] Race condition in CRDA calls?? thread?
I independently experienced this problem, debugged it, and came to the same conclusion. There is in fact a race between regulatory requests being made via regulatory_hint and CRDA actually updating regulatory data. I see this on a system with two cards that come up one after the other during boot.
1. cfg80211 calls CRDA to update the world regulatory domain and CRDA does so. The regulatory domain is now 00.
2. The first card?s driver (in my case, ath9k) calls regulatory_hint to provide US as a driver hint. ignore_request decides against intersection because the last request came from the core. There?s a CRDA call, but CRDA isn?t quick enough to respond. The regulatory domain is still 00, because CRDA hasn?t changed it yet.
3. The second card?s driver (also ath9k) calls regulatory_hint to provide US as a driver hint. ignore_request sees that the last request came from a driver (instead of the core) and since the regulatory domain is changing from 00 to US, decides that intersection must be performed.
4. When CRDA finally responds to the request from #2 or #3, cfg80211 sees that last_request->intersect is true, and intersects. The regulatory domain is set to the intersection of 00 and US.
The race here is between CRDA providing data and the second card?s request being made via regulatory_hint. regulatory_hint and ignore_request assume that last_request is in sync with the currently-set regulatory domain, but there is no such synchronization.
Here?s my openwrt-devel post describing the above in a slightly different level of detail:https://lists.openwrt.org/pipermail/openwrt-devel/2010-November/008570.html.
>>>> On Mon, Nov 8, 2010 at 11:40 AM, Mark Mentovai <[email protected]> wrote:
>>>>> 3. The second card’s driver (also ath9k) calls regulatory_hint to provide US as a driver hint. ignore_request sees that the last request came from a driver (instead of the core) and since the regulatory domain is changing from 00 to US, decides that intersection must be performed.
This interpretation however is incorrect, as a driver hint shall
always be respected if the current regulatory domain is 00. We do end
up with an intersection but there is another reason and that is the
bug. I will try to track it down.
Luis
On Mon, Nov 8, 2010 at 11:40 AM, Mark Mentovai <[email protected]> wrote:
> Following up on the old-ish “[ath5k-devel] Race condition in CRDA calls?” thread…
>
> I independently experienced this problem, debugged it, and came to the same conclusion. There is in fact a race between regulatory requests being made via regulatory_hint and CRDA actually updating regulatory data. I see this on a system with two cards that come up one after the other during boot.
>
> 1. cfg80211 calls CRDA to update the world regulatory domain and CRDA does so. The regulatory domain is now 00.
>
> 2. The first card’s driver (in my case, ath9k) calls regulatory_hint to provide US as a driver hint. ignore_request decides against intersection because the last request came from the core. There’s a CRDA call, but CRDA isn’t quick enough to respond. The regulatory domain is still 00, because CRDA hasn’t changed it yet.
>
> 3. The second card’s driver (also ath9k) calls regulatory_hint to provide US as a driver hint. ignore_request sees that the last request came from a driver (instead of the core) and since the regulatory domain is changing from 00 to US, decides that intersection must be performed.
>
> 4. When CRDA finally responds to the request from #2 or #3, cfg80211 sees that last_request->intersect is true, and intersects. The regulatory domain is set to the intersection of 00 and US.
>
> The race here is between CRDA providing data and the second card’s request being made via regulatory_hint. regulatory_hint and ignore_request assume that last_request is in sync with the currently-set regulatory domain, but there is no such synchronization.
>
> Here’s my openwrt-devel post describing the above in a slightly different level of detail:https://lists.openwrt.org/pipermail/openwrt-devel/2010-November/008570.html.--
I'll take a look at this once I get done with the
compat-wireless-2.6.37 release. Thanks for the report.
Luis
On Thu, Nov 11, 2010 at 4:04 PM, Luis R. Rodriguez <[email protected]> wrote:
>>>>> On Mon, Nov 8, 2010 at 11:40 AM, Mark Mentovai <[email protected]> wrote:
>>>>>> 3. The second card’s driver (also ath9k) calls regulatory_hint to provide US as a driver hint. ignore_request sees that the last request came from a driver (instead of the core) and since the regulatory domain is changing from 00 to US, decides that intersection must be performed.
>
> This interpretation however is incorrect, as a driver hint shall
> always be respected if the current regulatory domain is 00. We do end
> up with an intersection but there is another reason and that is the
> bug. I will try to track it down.
OK fixed, please try the posted patch.
Luis
On Thu, Nov 11, 2010 at 3:36 PM, Luis R. Rodriguez <[email protected]> wrote:
> On Tue, Nov 9, 2010 at 1:19 PM, Luis R. Rodriguez <[email protected]> wrote:
>> On Mon, Nov 8, 2010 at 11:40 AM, Mark Mentovai <[email protected]> wrote:
>>> Following up on the old-ish “[ath5k-devel] Race condition in CRDA calls?” thread…
>>>
>>> I independently experienced this problem, debugged it, and came to the same conclusion. There is in fact a race between regulatory requests being made via regulatory_hint and CRDA actually updating regulatory data. I see this on a system with two cards that come up one after the other during boot.
>>>
>>> 1. cfg80211 calls CRDA to update the world regulatory domain and CRDA does so. The regulatory domain is now 00.
>>>
>>> 2. The first card’s driver (in my case, ath9k) calls regulatory_hint to provide US as a driver hint. ignore_request decides against intersection because the last request came from the core. There’s a CRDA call, but CRDA isn’t quick enough to respond. The regulatory domain is still 00, because CRDA hasn’t changed it yet.
>>>
>>> 3. The second card’s driver (also ath9k) calls regulatory_hint to provide US as a driver hint. ignore_request sees that the last request came from a driver (instead of the core) and since the regulatory domain is changing from 00 to US, decides that intersection must be performed.
>>>
>>> 4. When CRDA finally responds to the request from #2 or #3, cfg80211 sees that last_request->intersect is true, and intersects. The regulatory domain is set to the intersection of 00 and US.
>>>
>>> The race here is between CRDA providing data and the second card’s request being made via regulatory_hint. regulatory_hint and ignore_request assume that last_request is in sync with the currently-set regulatory domain, but there is no such synchronization.
>>>
>>> Here’s my openwrt-devel post describing the above in a slightly different level of detail:https://lists.openwrt.org/pipermail/openwrt-devel/2010-November/008570.html.--
>>
>> I'll take a look at this once I get done with the
>> compat-wireless-2.6.37 release. Thanks for the report.
>
> I'm looking at this now, can you do me a favor and test against
> today's wireless-testing to verify the issue is still present? I'll be
> digging at this in the mean time.
I can reproduce this easily now with:
mcgrof@flash ~ $ sudo cat /sbin/crda
#!/bin/bash
echo $COUNTRY >> /tmp/log
sleep 2
/sbin/crda.orig
mcgrof@flash ~ $ iw reg get
country 98:
(2402 - 2472 @ 40), (N/A, 20)
(2457 - 2482 @ 20), (N/A, 20), PASSIVE-SCAN, NO-IBSS
(2474 - 2482 @ 8), (N/A, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS
(5170 - 5250 @ 40), (N/A, 20), PASSIVE-SCAN, NO-IBSS
You don't even have to use ath9k, just use mac80211_hwsim with:
modprobe mac80211_hwsim regtest=2
I get (I'm trimming irrelevant output)
Wiphy phy1
Band 1:
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)
Band 2:
Frequencies:
* 5180 MHz [36] (20.0 dBm)
* 5200 MHz [40] (20.0 dBm)
* 5220 MHz [44] (20.0 dBm)
* 5240 MHz [48] (20.0 dBm)
* 5260 MHz [52] (20.0 dBm) (radar detection)
* 5280 MHz [56] (20.0 dBm) (radar detection)
* 5300 MHz [60] (20.0 dBm) (radar detection)
* 5320 MHz [64] (20.0 dBm) (radar detection)
* 5500 MHz [100] (20.0 dBm) (radar detection)
* 5520 MHz [104] (20.0 dBm) (radar detection)
* 5540 MHz [108] (20.0 dBm) (radar detection)
* 5560 MHz [112] (20.0 dBm) (radar detection)
* 5580 MHz [116] (20.0 dBm) (radar detection)
* 5600 MHz [120] (20.0 dBm) (radar detection)
* 5620 MHz [124] (20.0 dBm) (radar detection)
* 5640 MHz [128] (20.0 dBm) (radar detection)
* 5660 MHz [132] (20.0 dBm) (radar detection)
* 5680 MHz [136] (20.0 dBm) (radar detection)
* 5700 MHz [140] (20.0 dBm) (radar detection)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)
Wiphy phy0
Band 1:
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm) (passive scanning, no IBSS)
* 2472 MHz [13] (20.0 dBm) (passive scanning, no IBSS)
* 2484 MHz [14] (disabled)
Band 2:
Frequencies:
* 5180 MHz [36] (20.0 dBm) (passive scanning, no IBSS)
* 5200 MHz [40] (20.0 dBm) (passive scanning, no IBSS)
* 5220 MHz [44] (20.0 dBm) (passive scanning, no IBSS)
* 5240 MHz [48] (20.0 dBm) (passive scanning, no IBSS)
* 5260 MHz [52] (disabled)
* 5280 MHz [56] (disabled)
* 5300 MHz [60] (disabled)
* 5320 MHz [64] (disabled)
* 5500 MHz [100] (disabled)
* 5520 MHz [104] (disabled)
* 5540 MHz [108] (disabled)
* 5560 MHz [112] (disabled)
* 5580 MHz [116] (disabled)
* 5600 MHz [120] (disabled)
* 5620 MHz [124] (disabled)
* 5640 MHz [128] (disabled)
* 5660 MHz [132] (disabled)
* 5680 MHz [136] (disabled)
* 5700 MHz [140] (disabled)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)
Luis
T24gVGh1LCBOb3YgMTEsIDIwMTAgYXQgNDowMCBQTSwgTHVpcyBSLiBSb2RyaWd1ZXogPG1jZ3Jv
ZkBnbWFpbC5jb20+IHdyb3RlOgo+IE9uIFRodSwgTm92IDExLCAyMDEwIGF0IDM6MzYgUE0sIEx1
aXMgUi4gUm9kcmlndWV6IDxtY2dyb2ZAZ21haWwuY29tPiB3cm90ZToKPj4gT24gVHVlLCBOb3Yg
OSwgMjAxMCBhdCAxOjE5IFBNLCBMdWlzIFIuIFJvZHJpZ3VleiA8bWNncm9mQGdtYWlsLmNvbT4g
d3JvdGU6Cj4+PiBPbiBNb24sIE5vdiA4LCAyMDEwIGF0IDExOjQwIEFNLCBNYXJrIE1lbnRvdmFp
IDxtYXJrQG1veGllbmV0LmNvbT4gd3JvdGU6Cj4+Pj4gRm9sbG93aW5nIHVwIG9uIHRoZSBvbGQt
aXNoIOKAnFthdGg1ay1kZXZlbF0gUmFjZSBjb25kaXRpb24gaW4gQ1JEQSBjYWxscz/igJ0gdGhy
ZWFk4oCmCj4+Pj4KPj4+PiBJIGluZGVwZW5kZW50bHkgZXhwZXJpZW5jZWQgdGhpcyBwcm9ibGVt
LCBkZWJ1Z2dlZCBpdCwgYW5kIGNhbWUgdG8gdGhlIHNhbWUgY29uY2x1c2lvbi4gVGhlcmUgaXMg
aW4gZmFjdCBhIHJhY2UgYmV0d2VlbiByZWd1bGF0b3J5IHJlcXVlc3RzIGJlaW5nIG1hZGUgdmlh
IHJlZ3VsYXRvcnlfaGludCBhbmQgQ1JEQSBhY3R1YWxseSB1cGRhdGluZyByZWd1bGF0b3J5IGRh
dGEuIEkgc2VlIHRoaXMgb24gYSBzeXN0ZW0gd2l0aCB0d28gY2FyZHMgdGhhdCBjb21lIHVwIG9u
ZSBhZnRlciB0aGUgb3RoZXIgZHVyaW5nIGJvb3QuCj4+Pj4KPj4+PiAxLiBjZmc4MDIxMSBjYWxs
cyBDUkRBIHRvIHVwZGF0ZSB0aGUgd29ybGQgcmVndWxhdG9yeSBkb21haW4gYW5kIENSREEgZG9l
cyBzby4gVGhlIHJlZ3VsYXRvcnkgZG9tYWluIGlzIG5vdyAwMC4KPj4+Pgo+Pj4+IDIuIFRoZSBm
aXJzdCBjYXJk4oCZcyBkcml2ZXIgKGluIG15IGNhc2UsIGF0aDlrKSBjYWxscyByZWd1bGF0b3J5
X2hpbnQgdG8gcHJvdmlkZSBVUyBhcyBhIGRyaXZlciBoaW50LiBpZ25vcmVfcmVxdWVzdCBkZWNp
ZGVzIGFnYWluc3QgaW50ZXJzZWN0aW9uIGJlY2F1c2UgdGhlIGxhc3QgcmVxdWVzdCBjYW1lIGZy
b20gdGhlIGNvcmUuIFRoZXJl4oCZcyBhIENSREEgY2FsbCwgYnV0IENSREEgaXNu4oCZdCBxdWlj
ayBlbm91Z2ggdG8gcmVzcG9uZC4gVGhlIHJlZ3VsYXRvcnkgZG9tYWluIGlzIHN0aWxsIDAwLCBi
ZWNhdXNlIENSREEgaGFzbuKAmXQgY2hhbmdlZCBpdCB5ZXQuCj4+Pj4KPj4+PiAzLiBUaGUgc2Vj
b25kIGNhcmTigJlzIGRyaXZlciAoYWxzbyBhdGg5aykgY2FsbHMgcmVndWxhdG9yeV9oaW50IHRv
IHByb3ZpZGUgVVMgYXMgYSBkcml2ZXIgaGludC4gaWdub3JlX3JlcXVlc3Qgc2VlcyB0aGF0IHRo
ZSBsYXN0IHJlcXVlc3QgY2FtZSBmcm9tIGEgZHJpdmVyIChpbnN0ZWFkIG9mIHRoZSBjb3JlKSBh
bmQgc2luY2UgdGhlIHJlZ3VsYXRvcnkgZG9tYWluIGlzIGNoYW5naW5nIGZyb20gMDAgdG8gVVMs
IGRlY2lkZXMgdGhhdCBpbnRlcnNlY3Rpb24gbXVzdCBiZSBwZXJmb3JtZWQuCj4+Pj4KPj4+PiA0
LiBXaGVuIENSREEgZmluYWxseSByZXNwb25kcyB0byB0aGUgcmVxdWVzdCBmcm9tICMyIG9yICMz
LCBjZmc4MDIxMSBzZWVzIHRoYXQgbGFzdF9yZXF1ZXN0LT5pbnRlcnNlY3QgaXMgdHJ1ZSwgYW5k
IGludGVyc2VjdHMuIFRoZSByZWd1bGF0b3J5IGRvbWFpbiBpcyBzZXQgdG8gdGhlIGludGVyc2Vj
dGlvbiBvZiAwMCBhbmQgVVMuCj4+Pj4KPj4+PiBUaGUgcmFjZSBoZXJlIGlzIGJldHdlZW4gQ1JE
QSBwcm92aWRpbmcgZGF0YSBhbmQgdGhlIHNlY29uZCBjYXJk4oCZcyByZXF1ZXN0IGJlaW5nIG1h
ZGUgdmlhIHJlZ3VsYXRvcnlfaGludC4gcmVndWxhdG9yeV9oaW50IGFuZCBpZ25vcmVfcmVxdWVz
dCBhc3N1bWUgdGhhdCBsYXN0X3JlcXVlc3QgaXMgaW4gc3luYyB3aXRoIHRoZSBjdXJyZW50bHkt
c2V0IHJlZ3VsYXRvcnkgZG9tYWluLCBidXQgdGhlcmUgaXMgbm8gc3VjaCBzeW5jaHJvbml6YXRp
b24uCj4+Pj4KPj4+PiBIZXJl4oCZcyBteSBvcGVud3J0LWRldmVsIHBvc3QgZGVzY3JpYmluZyB0
aGUgYWJvdmUgaW4gYSBzbGlnaHRseSBkaWZmZXJlbnQgbGV2ZWwgb2YgZGV0YWlsOmh0dHBzOi8v
bGlzdHMub3BlbndydC5vcmcvcGlwZXJtYWlsL29wZW53cnQtZGV2ZWwvMjAxMC1Ob3ZlbWJlci8w
MDg1NzAuaHRtbC4tLQo+Pj4KPj4+IEknbGwgdGFrZSBhIGxvb2sgYXQgdGhpcyBvbmNlIEkgZ2V0
IGRvbmUgd2l0aCB0aGUKPj4+IGNvbXBhdC13aXJlbGVzcy0yLjYuMzcgcmVsZWFzZS4gVGhhbmtz
IGZvciB0aGUgcmVwb3J0Lgo+Pgo+PiBJJ20gbG9va2luZyBhdCB0aGlzIG5vdywgY2FuIHlvdSBk
byBtZSBhIGZhdm9yIGFuZCB0ZXN0IGFnYWluc3QKPj4gdG9kYXkncyB3aXJlbGVzcy10ZXN0aW5n
IHRvIHZlcmlmeSB0aGUgaXNzdWUgaXMgc3RpbGwgcHJlc2VudD8gSSdsbCBiZQo+PiBkaWdnaW5n
IGF0IHRoaXMgaW4gdGhlIG1lYW4gdGltZS4KPgo+IEkgY2FuIHJlcHJvZHVjZSB0aGlzIGVhc2ls
eSBub3cgd2l0aDoKPgo+IG1jZ3JvZkBmbGFzaCB+ICQgc3VkbyBjYXQgL3NiaW4vY3JkYQo+ICMh
L2Jpbi9iYXNoCj4gZWNobyAkQ09VTlRSWSA+PiAvdG1wL2xvZwo+IHNsZWVwIDIKPiAvc2Jpbi9j
cmRhLm9yaWcKPgo+Cj4gbWNncm9mQGZsYXNoIH4gJCBpdyByZWcgZ2V0Cj4gY291bnRyeSA5ODoK
PiDCoCDCoCDCoCDCoCgyNDAyIC0gMjQ3MiBAIDQwKSwgKE4vQSwgMjApCj4gwqAgwqAgwqAgwqAo
MjQ1NyAtIDI0ODIgQCAyMCksIChOL0EsIDIwKSwgUEFTU0lWRS1TQ0FOLCBOTy1JQlNTCj4gwqAg
wqAgwqAgwqAoMjQ3NCAtIDI0ODIgQCA4KSwgKE4vQSwgMjApLCBOTy1PRkRNLCBQQVNTSVZFLVND
QU4sIE5PLUlCU1MKPiDCoCDCoCDCoCDCoCg1MTcwIC0gNTI1MCBAIDQwKSwgKE4vQSwgMjApLCBQ
QVNTSVZFLVNDQU4sIE5PLUlCU1MKPgo+IFlvdSBkb24ndCBldmVuIGhhdmUgdG8gdXNlIGF0aDlr
LCBqdXN0IHVzZSBtYWM4MDIxMV9od3NpbSB3aXRoOgo+Cj4gbW9kcHJvYmUgbWFjODAyMTFfaHdz
aW0gcmVndGVzdD0yCj4KPiBJIGdldCAoSSdtIHRyaW1taW5nIGlycmVsZXZhbnQgb3V0cHV0KQo+
Cj4gV2lwaHkgcGh5MQo+IMKgIMKgIMKgIMKgQmFuZCAxOgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgRnJlcXVlbmNpZXM6Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDI0
MTIgTUh6IFsxXSAoMjAuMCBkQm0pCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAqIDI0MTcgTUh6IFsyXSAoMjAuMCBkQm0pCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAqIDI0MjIgTUh6IFszXSAoMjAuMCBkQm0pCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAqIDI0MjcgTUh6IFs0XSAoMjAuMCBkQm0pCj4gwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAqIDI0MzIgTUh6IFs1XSAoMjAuMCBkQm0pCj4gwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDI0MzcgTUh6IFs2XSAoMjAuMCBkQm0pCj4gwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDI0NDIgTUh6IFs3XSAoMjAuMCBkQm0p
Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDI0NDcgTUh6IFs4XSAoMjAu
MCBkQm0pCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDI0NTIgTUh6IFs5
XSAoMjAuMCBkQm0pCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDI0NTcg
TUh6IFsxMF0gKDIwLjAgZEJtKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
KiAyNDYyIE1IeiBbMTFdICgyMC4wIGRCbSkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCogMjQ2NyBNSHogWzEyXSAoMjAuMCBkQm0pCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAqIDI0NzIgTUh6IFsxM10gKDIwLjAgZEJtKQo+IMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgKiAyNDg0IE1IeiBbMTRdIChkaXNhYmxlZCkKPiDCoCDCoCDC
oCDCoEJhbmQgMjoKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEZyZXF1ZW5jaWVzOgo+IMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1MTgwIE1IeiBbMzZdICgyMC4wIGRCbSkK
PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogNTIwMCBNSHogWzQwXSAoMjAu
MCBkQm0pCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDUyMjAgTUh6IFs0
NF0gKDIwLjAgZEJtKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1MjQw
IE1IeiBbNDhdICgyMC4wIGRCbSkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCogNTI2MCBNSHogWzUyXSAoMjAuMCBkQm0pIChyYWRhciBkZXRlY3Rpb24pCj4gwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDUyODAgTUh6IFs1Nl0gKDIwLjAgZEJtKSAocmFk
YXIgZGV0ZWN0aW9uKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1MzAw
IE1IeiBbNjBdICgyMC4wIGRCbSkgKHJhZGFyIGRldGVjdGlvbikKPiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCogNTMyMCBNSHogWzY0XSAoMjAuMCBkQm0pIChyYWRhciBkZXRl
Y3Rpb24pCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU1MDAgTUh6IFsx
MDBdICgyMC4wIGRCbSkgKHJhZGFyIGRldGVjdGlvbikKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCogNTUyMCBNSHogWzEwNF0gKDIwLjAgZEJtKSAocmFkYXIgZGV0ZWN0aW9u
KQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1NTQwIE1IeiBbMTA4XSAo
MjAuMCBkQm0pIChyYWRhciBkZXRlY3Rpb24pCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAqIDU1NjAgTUh6IFsxMTJdICgyMC4wIGRCbSkgKHJhZGFyIGRldGVjdGlvbikKPiDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogNTU4MCBNSHogWzExNl0gKDIwLjAg
ZEJtKSAocmFkYXIgZGV0ZWN0aW9uKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgKiA1NjAwIE1IeiBbMTIwXSAoMjAuMCBkQm0pIChyYWRhciBkZXRlY3Rpb24pCj4gwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU2MjAgTUh6IFsxMjRdICgyMC4wIGRCbSkg
KHJhZGFyIGRldGVjdGlvbikKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCog
NTY0MCBNSHogWzEyOF0gKDIwLjAgZEJtKSAocmFkYXIgZGV0ZWN0aW9uKQo+IMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1NjYwIE1IeiBbMTMyXSAoMjAuMCBkQm0pIChyYWRh
ciBkZXRlY3Rpb24pCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU2ODAg
TUh6IFsxMzZdICgyMC4wIGRCbSkgKHJhZGFyIGRldGVjdGlvbikKPiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCogNTcwMCBNSHogWzE0MF0gKDIwLjAgZEJtKSAocmFkYXIgZGV0
ZWN0aW9uKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1NzQ1IE1IeiBb
MTQ5XSAoZGlzYWJsZWQpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU3
NjUgTUh6IFsxNTNdIChkaXNhYmxlZCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCogNTc4NSBNSHogWzE1N10gKGRpc2FibGVkKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgKiA1ODA1IE1IeiBbMTYxXSAoZGlzYWJsZWQpCj4gwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU4MjUgTUh6IFsxNjVdIChkaXNhYmxlZCkKPiBXaXBoeSBw
aHkwCj4gwqAgwqAgwqAgwqBCYW5kIDE6Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBGcmVxdWVu
Y2llczoKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogMjQxMiBNSHogWzFd
ICgyMC4wIGRCbSkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogMjQxNyBN
SHogWzJdICgyMC4wIGRCbSkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCog
MjQyMiBNSHogWzNdICgyMC4wIGRCbSkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCogMjQyNyBNSHogWzRdICgyMC4wIGRCbSkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCogMjQzMiBNSHogWzVdICgyMC4wIGRCbSkKPiDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCogMjQzNyBNSHogWzZdICgyMC4wIGRCbSkKPiDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogMjQ0MiBNSHogWzddICgyMC4wIGRCbSkKPiDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogMjQ0NyBNSHogWzhdICgyMC4wIGRCbSkKPiDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogMjQ1MiBNSHogWzldICgyMC4wIGRC
bSkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogMjQ1NyBNSHogWzEwXSAo
MjAuMCBkQm0pCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDI0NjIgTUh6
IFsxMV0gKDIwLjAgZEJtKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiAy
NDY3IE1IeiBbMTJdICgyMC4wIGRCbSkgKHBhc3NpdmUgc2Nhbm5pbmcsIG5vIElCU1MpCj4gwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDI0NzIgTUh6IFsxM10gKDIwLjAgZEJt
KSAocGFzc2l2ZSBzY2FubmluZywgbm8gSUJTUykKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCogMjQ4NCBNSHogWzE0XSAoZGlzYWJsZWQpCj4gwqAgwqAgwqAgwqBCYW5kIDI6
Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBGcmVxdWVuY2llczoKPiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCogNTE4MCBNSHogWzM2XSAoMjAuMCBkQm0pIChwYXNzaXZlIHNj
YW5uaW5nLCBubyBJQlNTKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1
MjAwIE1IeiBbNDBdICgyMC4wIGRCbSkgKHBhc3NpdmUgc2Nhbm5pbmcsIG5vIElCU1MpCj4gwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDUyMjAgTUh6IFs0NF0gKDIwLjAgZEJt
KSAocGFzc2l2ZSBzY2FubmluZywgbm8gSUJTUykKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCogNTI0MCBNSHogWzQ4XSAoMjAuMCBkQm0pIChwYXNzaXZlIHNjYW5uaW5nLCBu
byBJQlNTKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1MjYwIE1IeiBb
NTJdIChkaXNhYmxlZCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogNTI4
MCBNSHogWzU2XSAoZGlzYWJsZWQpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAqIDUzMDAgTUh6IFs2MF0gKGRpc2FibGVkKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgKiA1MzIwIE1IeiBbNjRdIChkaXNhYmxlZCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCogNTUwMCBNSHogWzEwMF0gKGRpc2FibGVkKQo+IMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1NTIwIE1IeiBbMTA0XSAoZGlzYWJsZWQpCj4gwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU1NDAgTUh6IFsxMDhdIChkaXNhYmxl
ZCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogNTU2MCBNSHogWzExMl0g
KGRpc2FibGVkKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1NTgwIE1I
eiBbMTE2XSAoZGlzYWJsZWQpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAq
IDU2MDAgTUh6IFsxMjBdIChkaXNhYmxlZCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCogNTYyMCBNSHogWzEyNF0gKGRpc2FibGVkKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgKiA1NjQwIE1IeiBbMTI4XSAoZGlzYWJsZWQpCj4gwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU2NjAgTUh6IFsxMzJdIChkaXNhYmxlZCkKPiDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogNTY4MCBNSHogWzEzNl0gKGRpc2FibGVk
KQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiA1NzAwIE1IeiBbMTQwXSAo
ZGlzYWJsZWQpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIDU3NDUgTUh6
IFsxNDldIChkaXNhYmxlZCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCog
NTc2NSBNSHogWzE1M10gKGRpc2FibGVkKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgKiA1Nzg1IE1IeiBbMTU3XSAoZGlzYWJsZWQpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAqIDU4MDUgTUh6IFsxNjFdIChkaXNhYmxlZCkKPiDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogNTgyNSBNSHogWzE2NV0gKGRpc2FibGVkKQoKSSdsbCBm
aXggdGhhbmtzIGZvciByZXBvcnRpbmcgdGhpcy4KCiAgTHVpcwo=
On Tue, Nov 9, 2010 at 1:19 PM, Luis R. Rodriguez <[email protected]> wrote:
> On Mon, Nov 8, 2010 at 11:40 AM, Mark Mentovai <[email protected]> wrote:
>> Following up on the old-ish “[ath5k-devel] Race condition in CRDA calls?” thread…
>>
>> I independently experienced this problem, debugged it, and came to the same conclusion. There is in fact a race between regulatory requests being made via regulatory_hint and CRDA actually updating regulatory data. I see this on a system with two cards that come up one after the other during boot.
>>
>> 1. cfg80211 calls CRDA to update the world regulatory domain and CRDA does so. The regulatory domain is now 00.
>>
>> 2. The first card’s driver (in my case, ath9k) calls regulatory_hint to provide US as a driver hint. ignore_request decides against intersection because the last request came from the core. There’s a CRDA call, but CRDA isn’t quick enough to respond. The regulatory domain is still 00, because CRDA hasn’t changed it yet.
>>
>> 3. The second card’s driver (also ath9k) calls regulatory_hint to provide US as a driver hint. ignore_request sees that the last request came from a driver (instead of the core) and since the regulatory domain is changing from 00 to US, decides that intersection must be performed.
>>
>> 4. When CRDA finally responds to the request from #2 or #3, cfg80211 sees that last_request->intersect is true, and intersects. The regulatory domain is set to the intersection of 00 and US.
>>
>> The race here is between CRDA providing data and the second card’s request being made via regulatory_hint. regulatory_hint and ignore_request assume that last_request is in sync with the currently-set regulatory domain, but there is no such synchronization.
>>
>> Here’s my openwrt-devel post describing the above in a slightly different level of detail:https://lists.openwrt.org/pipermail/openwrt-devel/2010-November/008570.html.--
>
> I'll take a look at this once I get done with the
> compat-wireless-2.6.37 release. Thanks for the report.
I'm looking at this now, can you do me a favor and test against
today's wireless-testing to verify the issue is still present? I'll be
digging at this in the mean time.
Luis