Re: Can't connect to AP with hidden essid with 2.6.27-rc6

[Celejar <celejar@gmail.com>]

On Fri, 19 Sep 2008 14:18:39 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:

> Celejar wrote:
> > On Fri, 19 Sep 2008 11:05:35 -0700
> > "Luis R. Rodriguez" <mcgrof@gmail.com> wrote:
> > 
> >> On Fri, Sep 19, 2008 at 9:13 AM, Larry Finger <Larry.Finger@lwfinger.net> 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