On Fri, 19 Sep 2008 14:18:39 -0500 Larry Finger <Larry.Finger@xxxxxxxxxxxx> wrote: > Celejar wrote: > > On Fri, 19 Sep 2008 11:05:35 -0700 > > "Luis R. Rodriguez" <mcgrof@xxxxxxxxx> wrote: > > > >> On Fri, Sep 19, 2008 at 9:13 AM, Larry Finger <Larry.Finger@xxxxxxxxxxxx> 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 -- 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
