On Fri, Jun 24, 2011 at 9:43 PM, Mohammed Shafi <shafi.wireless@xxxxxxxxx> wrote: > On Fri, Jun 24, 2011 at 8:13 PM, Laura Nayman <lnayman@xxxxxxxxx> wrote: >> cfg80211 'iw reg set' no longer works after trying to set invalid country >> code >> >> You can change the wireless region by using 'iw set reg'. Normally you can >> switch back and forth just fine... >> >> # iw reg set US >> # iw reg get | grep country >> country US: >> # iw reg set JP >> # iw reg get | grep country >> country JP: >> # iw reg set US >> # iw reg get | grep country >> country US: >> >> >> However, if we try to use an invalid country code, such as XX: >> # iw reg set XX >> # iw reg get | grep country >> country US: >> ... it doesn't take. Okay, no big deal. Let's try setting it back to JP: >> # iw reg set JP >> # iw reg get | grep country >> country US: >> >> We're now stuck at the country code we were at before we put the invalid one >> in. >> >> In dmesg, this exchange looks like: >> # dmesg | grep cfg80211 >> cfg80211: Calling CRDA to update world regulatory domain >> cfg80211: World regulatory domain updated: >> cfg80211: Calling CRDA for country: US >> cfg80211: Regulatory domain changed to country: US >> cfg80211: Calling CRDA for country: JP >> cfg80211: Regulatory domain changed to country: JP >> cfg80211: Calling CRDA for country: US >> cfg80211: Regulatory domain changed to country: US >> cfg80211: Calling CRDA for country: XX >> ... and we're stuck there. >> >> What looks to be happening is that the kernel uses udev to call /sbin/crda >> with a new COUNTRY= setting, but /sbin/crda bails out with -1 because of 'No >> country match in regulatory database', and never sends a netlink message >> back to the kernel to give it the regulatory information for that country. >> The kernel then seems to be stuck waiting for a message that will never >> come. >> >> The only way I can figure to unstick it is to reboot. > > true you may be using old wireless-testing/compat wireless, i too got > this issue in Jan compat wireless > > does this happens with the latest compat wireless. please check? > http://wireless.kernel.org/download/compat-wireless-2.6/ > > > this would have fixed it > > commit c989bb15e95a93e20fc86783264f6298116e8651 > Author: Luis R. Rodriguez <lrodriguez@xxxxxxxxxxx> > Date: Mon Apr 25 18:35:48 2011 -0700 > > cfg80211: fix regresion on reg user timeout > > The patch "cfg80211: add a timer for invalid user reg hints" > introduced a regression for the case where a secondary identical > regulatory hint from a user is sent. What would happen is the > second hint would schedule delayed work in to catch a timeout > but since we are never processing it given that the hint was already > applied we'd always hit the timeout and and restore regulatory > settings back to world regulatory domain. This is fixed by simply > avoiding sheduling work if the hint was already applied. > > Tested-by: Felix Fietkau <nbd@xxxxxxxxxxx> > Reported-by: Felix Fietkau <nbd@xxxxxxxxxxx> > Signed-off-by: Luis R. Rodriguez <lrodriguez@xxxxxxxxxxx> > Signed-off-by: John W. Linville <linville@xxxxxxxxxxxxx> > > diff --git a/net/wireless/reg.c b/net/wireless/reg.c > index 2714379..8982053 100644 > --- a/net/wireless/reg.c > +++ b/net/wireless/reg.c > @@ -1455,7 +1455,8 @@ static void reg_process_hint(struct > regulatory_request *reg_request) > * We only time out user hints, given that they should be the only > * source of bogus requests. > */ > - if (reg_request->initiator == NL80211_REGDOM_SET_BY_USER) > + if (r != -EALREADY && > + reg_request->initiator == NL80211_REGDOM_SET_BY_USER) > schedule_delayed_work(®_timeout, msecs_to_jiffies(3142)); > } > sorry that does not seems the commit that fixed it , i will point the correct one. > >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > > > -- > shafi > -- shafi -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
