Celejar wrote:
> On Thu, 18 Sep 2008 17:33:12 -0500
> Larry Finger <[email protected]> wrote:
>
>> Celejar wrote:
>>> Okay, I built and installed CRDA, and I now get:
>>>
>>> Band 1:
>>> Frequencies:
>>> * 2412 MHz
>>> * 2417 MHz
>>> * 2422 MHz
>>> * 2427 MHz
>>> * 2432 MHz
>>> * 2437 MHz
>>> * 2442 MHz
>>> * 2447 MHz
>>> * 2452 MHz
>>> * 2457 MHz
>>> * 2462 MHz
>>> * 2467 MHz (disabled)
>>> * 2472 MHz (disabled)
>>> * 2484 MHz (disabled)
>>>
>>> [This is also what I get with an earlier kernel.]
>>>
>>> But the card *still* won't associate with the hidden essid AP; is there
>>> anything else I need to do after 'make, make install' CRDA?
>> No, with this output, you have definitely connected with CRDA. Now
>> that you have CRDA working, I think you may have to bisect again.
>> Certainly, the passive scanning would have made it difficult, if not
>> impossible, to connect to a hidden essid. As you say, you now have the
>> same channel listing as you had with the earlier kernel, thus your
>> bisection may converge on a different patch. Fortunately, it shouldn't
>> take too long. You can go a couple of patches earlier than the
>> regulatory change with a 'git bisect good dbcabfe1a5cfa192e'.
>>
>> Another option would be to uninstall CRDA by deleting /sbin/crda and
>> setting the CONFIG_WIRELESS_OLD_REGULATORY variable to y. At that
>> point, everything should be exactly as in the kernels prior to
>> adopting CRDA.
>
> This works fine, so I'm happy. If a bisection will help the devs,
> though, I'll be glad to do it.
I do not think a bisection is necessary. Your successful test of the
old regulatory code suggests to me that there is some kind of problem
with the CRDA database.
Luis - to fill you in, he can connect to an AP with a hidden essid
using the old regulatory code, but not using CRDA. There seems to be
some critical difference between them.
Thanks,
Larry
On Fri, 19 Sep 2008 11:05:35 -0700
"Luis R. Rodriguez" <[email protected]> wrote:
> On Fri, Sep 19, 2008 at 9:13 AM, Larry Finger <[email protected]> wrote:
>
> > I do not think a bisection is necessary. Your successful test of the
> > old regulatory code suggests to me that there is some kind of problem
> > with the CRDA database.
>
> BTW the "old regulatory code" is actually not "old regulatory code"
> but instead static regulatory definitions slapped in the kernel just
> as they were before but under the new regulatory infrastructure guise.
>
> > Luis - to fill you in, he can connect to an AP with a hidden essid
> > using the old regulatory code, but not using CRDA. There seems to be
> > some critical difference between them.
>
> Thanks for bringing this up Larry.
>
> If by old regulatory code you mean with CONFIG_WIRELESS_OLD_REGULATORY
> then I would narrow the search down to testing as follows:
>
> --- Without crda:
>
> mv /sbin/crda /sbin/crda-foo
> sudo rmmod your_driver mac80211 cfg80211
> sudo modprobe your_driver
>
> # Check channels using iw
>
> --- With crda:
> mv /sbin/crda-foo /sbin/crda
> sudo rmmod your_driver mac80211 cfg80211
> sudo modprobe your_driver
>
> # check channels using iw
> ---
>
> By default when CONFIG_WIRELESS_OLD_REGULATORY is set the built-in
> "US" static regulatory domain is used. If crda is present though a new
> regulatory domain will be updated onto the kernel, so we'll get the
> new regulatory domain built by crda from the original db.txt. Without
> crda present the static regulatory domain shall be used.
>
> What frequency is the AP on?
I (the user) am currently connecting successfully with CRDA to a hidden
essid AP. I previously had claimed that it was still not working, even
though the iw channel output looked good, but it currently seems to be
okay. I may have previously done something wrong, such as not
rebuilding CRDA for the current kernel, although in that case I'm not
sure why the iw output would have been correct. In any event, at this
point it seems that it may have been some mistake on my part. Thanks
for the help, sorry for the noise, and I'll report back if I see any
more trouble.
> Luis
Celejar
--
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
On Fri, Sep 19, 2008 at 9:13 AM, Larry Finger <[email protected]> wrote:
> I do not think a bisection is necessary. Your successful test of the
> old regulatory code suggests to me that there is some kind of problem
> with the CRDA database.
BTW the "old regulatory code" is actually not "old regulatory code"
but instead static regulatory definitions slapped in the kernel just
as they were before but under the new regulatory infrastructure guise.
> Luis - to fill you in, he can connect to an AP with a hidden essid
> using the old regulatory code, but not using CRDA. There seems to be
> some critical difference between them.
Thanks for bringing this up Larry.
If by old regulatory code you mean with CONFIG_WIRELESS_OLD_REGULATORY
then I would narrow the search down to testing as follows:
--- Without crda:
mv /sbin/crda /sbin/crda-foo
sudo rmmod your_driver mac80211 cfg80211
sudo modprobe your_driver
# Check channels using iw
--- With crda:
mv /sbin/crda-foo /sbin/crda
sudo rmmod your_driver mac80211 cfg80211
sudo modprobe your_driver
# check channels using iw
---
By default when CONFIG_WIRELESS_OLD_REGULATORY is set the built-in
"US" static regulatory domain is used. If crda is present though a new
regulatory domain will be updated onto the kernel, so we'll get the
new regulatory domain built by crda from the original db.txt. Without
crda present the static regulatory domain shall be used.
What frequency is the AP on?
Luis
Celejar wrote:
> On Fri, 19 Sep 2008 11:05:35 -0700
> "Luis R. Rodriguez" <[email protected]> wrote:
>
>> On Fri, Sep 19, 2008 at 9:13 AM, Larry Finger <[email protected]> wrote:
>>
>>> I do not think a bisection is necessary. Your successful test of the
>>> old regulatory code suggests to me that there is some kind of problem
>>> with the CRDA database.
>> BTW the "old regulatory code" is actually not "old regulatory code"
>> but instead static regulatory definitions slapped in the kernel just
>> as they were before but under the new regulatory infrastructure guise.
>>
>>> Luis - to fill you in, he can connect to an AP with a hidden essid
>>> using the old regulatory code, but not using CRDA. There seems to be
>>> some critical difference between them.
>> Thanks for bringing this up Larry.
>>
>> If by old regulatory code you mean with CONFIG_WIRELESS_OLD_REGULATORY
>> then I would narrow the search down to testing as follows:
>>
>> --- Without crda:
>>
>> mv /sbin/crda /sbin/crda-foo
>> sudo rmmod your_driver mac80211 cfg80211
>> sudo modprobe your_driver
>>
>> # Check channels using iw
>>
>> --- With crda:
>> mv /sbin/crda-foo /sbin/crda
>> sudo rmmod your_driver mac80211 cfg80211
>> sudo modprobe your_driver
>>
>> # check channels using iw
>> ---
>>
>> By default when CONFIG_WIRELESS_OLD_REGULATORY is set the built-in
>> "US" static regulatory domain is used. If crda is present though a new
>> regulatory domain will be updated onto the kernel, so we'll get the
>> new regulatory domain built by crda from the original db.txt. Without
>> crda present the static regulatory domain shall be used.
>>
>> What frequency is the AP on?
>
> I (the user) am currently connecting successfully with CRDA to a hidden
> essid AP. I previously had claimed that it was still not working, even
> though the iw channel output looked good, but it currently seems to be
> okay. I may have previously done something wrong, such as not
> rebuilding CRDA for the current kernel, although in that case I'm not
> sure why the iw output would have been correct. In any event, at this
> point it seems that it may have been some mistake on my part. Thanks
> for the help, sorry for the noise, and I'll report back if I see any
> more trouble.
Is it correct that your current setup has
CONFIG_WIRELESS_OLD_REGULATORY set? If I remember correctly, your
previous failure with CRDA was with CONFIG_WIRELESS_OLD_REGULATORY
unset. If that is true, could you please unset it and try again. The
code paths are different.
I think that CRDA runs in userspace and should be relatively
independent of kernel version.
Larry
On Fri, Sep 19, 2008 at 11:27 AM, Celejar <[email protected]> wrote:
> On Fri, 19 Sep 2008 11:05:35 -0700
> I (the user) am currently connecting successfully with CRDA to a hidden
> essid AP. I previously had claimed that it was still not working, even
> though the iw channel output looked good, but it currently seems to be
> okay. I may have previously done something wrong, such as not
> rebuilding CRDA for the current kernel, although in that case I'm not
> sure why the iw output would have been correct. In any event, at this
> point it seems that it may have been some mistake on my part. Thanks
> for the help, sorry for the noise, and I'll report back if I see any
> more trouble.
Thanks for letting us know.
Luis
On Fri, 19 Sep 2008 14:18:39 -0500
Larry Finger <[email protected]> wrote:
> Celejar wrote:
> > On Fri, 19 Sep 2008 11:05:35 -0700
> > "Luis R. Rodriguez" <[email protected]> wrote:
> >
> >> On Fri, Sep 19, 2008 at 9:13 AM, Larry Finger <[email protected]> wrote:
> >>
> >>> I do not think a bisection is necessary. Your successful test of the
> >>> old regulatory code suggests to me that there is some kind of problem
> >>> with the CRDA database.
> >> BTW the "old regulatory code" is actually not "old regulatory code"
> >> but instead static regulatory definitions slapped in the kernel just
> >> as they were before but under the new regulatory infrastructure guise.
> >>
> >>> Luis - to fill you in, he can connect to an AP with a hidden essid
> >>> using the old regulatory code, but not using CRDA. There seems to be
> >>> some critical difference between them.
> >> Thanks for bringing this up Larry.
> >>
> >> If by old regulatory code you mean with CONFIG_WIRELESS_OLD_REGULATORY
> >> then I would narrow the search down to testing as follows:
> >>
> >> --- Without crda:
> >>
> >> mv /sbin/crda /sbin/crda-foo
> >> sudo rmmod your_driver mac80211 cfg80211
> >> sudo modprobe your_driver
> >>
> >> # Check channels using iw
> >>
> >> --- With crda:
> >> mv /sbin/crda-foo /sbin/crda
> >> sudo rmmod your_driver mac80211 cfg80211
> >> sudo modprobe your_driver
> >>
> >> # check channels using iw
> >> ---
> >>
> >> By default when CONFIG_WIRELESS_OLD_REGULATORY is set the built-in
> >> "US" static regulatory domain is used. If crda is present though a new
> >> regulatory domain will be updated onto the kernel, so we'll get the
> >> new regulatory domain built by crda from the original db.txt. Without
> >> crda present the static regulatory domain shall be used.
> >>
> >> What frequency is the AP on?
> >
> > I (the user) am currently connecting successfully with CRDA to a hidden
> > essid AP. I previously had claimed that it was still not working, even
> > though the iw channel output looked good, but it currently seems to be
> > okay. I may have previously done something wrong, such as not
> > rebuilding CRDA for the current kernel, although in that case I'm not
> > sure why the iw output would have been correct. In any event, at this
> > point it seems that it may have been some mistake on my part. Thanks
> > for the help, sorry for the noise, and I'll report back if I see any
> > more trouble.
>
> Is it correct that your current setup has
> CONFIG_WIRELESS_OLD_REGULATORY set? If I remember correctly, your
> previous failure with CRDA was with CONFIG_WIRELESS_OLD_REGULATORY
> unset. If that is true, could you please unset it and try again. The
> code paths are different.
My current setup does not have CONFIG_WIRELESS_OLD_REGULATORY set.
> I think that CRDA runs in userspace and should be relatively
> independent of kernel version.
You are right. I had thought that although it runs in userspace, since
the build seems to use headers specific to the running kernel, that
might be significant, but I have tested and it does not seem to make a
difference, at least between the two fairly recent -rc6 kernel that I
tried. From the CRDA Makefile:
ifeq ($(origin $(KLIB)), undefined)
KLIB:= /lib/modules/$(shell uname -r)
endif
KLIB_BUILD ?= $(KLIB)/build
...
CFLAGS += -I$(KLIB_BUILD)/include -DUSE_GCRYPT
I think the problem I had was that on boot, the b43 / 80211 modules get
loaded, but they don't seem to be calling CRDA, and I can't access my
hidden essid AP. Doing the module removal and reloading that Luis
suggested causes CRDA to be called, and then things work fine.
> Larry
Celejar
--
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
On Fri, Sep 19, 2008 at 01:01:15PM -0700, Celejar wrote:
> I think the problem I had was that on boot, the b43 / 80211 modules get
> loaded, but they don't seem to be calling CRDA, and I can't access my
> hidden essid AP. Doing the module removal and reloading that Luis
> suggested causes CRDA to be called, and then things work fine.
b43 drivers don't yet use regulatory_hint() so you get stuck with the
defualt regulatory domain, which is world. To get out of world you
can use iw to set the regulatory domain as follows:
iw reg set US
this would be for the United States regulatory domain. To find your
alpha2 please check:
http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
Our current database can be viewed here:
Web view:
http://wireless.kernel.org/en/developers/Regulatory/Database
gitweb:
http://git.kernel.org/?p=linux/kernel/git/mcgrof/crda.git;a=blob;f=db.txt;hb=HEAD
(Note: this database will soon be moved to another separate tree apart
from crda)
If you have updates for this database please read this:
http://wireless.kernel.org/en/developers/Regulatory#Sendingupdatestotheregulatorydatabase
Please note though that you *don't have to reload the module* to fix
this issue, all you have to do is to use iw to set the regulatory domain.
Eventually what can be done is userspace networking applets like
NetworkManager can send the same nl80211 request to the wireless core
after bootup. A country can then be configurable by the user through the
applet.
Another alternative is for distributions to call the iw command on the
country alpha2 based on the locale. Basically there's many ways to do
it. Drivers can also just call the regulatory hint based on their
EEPROM, an example driver doing this already is zd1211rw.
Luis