--> System : - Post February powerbook 15'' G4 - Gentoo ! - kernel : vanilla-2.6.26 patched with latest softmac patch. - Wireless adapter : airport extreme (broadcom), driver : bcm43xx --> Bug : When essid_eth1 is set to "any", the script goes into an infinite loop when trying to find an accesspoint. When essid_eth1 is set to an AP, everything is fine. When essid_eth1 is NOT set, everything is fine and the scripts falls back to preferred_apps I hope this is enough info, this is my first bug report ! Regards, -- Jonathan Chocron
you forgot to post `emerge info` ...
Very sorry... Here is the emerge info : Portage 2.0.54 (default-linux/ppc/ppc32/2006.0/G4, gcc-3.4.5, glibc-2.3.5-r3, 2.6.16-rc6-softmac ppc) ================================================================= System uname: 2.6.16-rc6-softmac ppc 7447A, altivec supported Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="ppc" AUTOCLEAN="yes" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-O2 -mcpu=G4 -mtune=G4 -maltivec -mabi=altivec -fno-strict-aliasing -fomit-frame-pointer -pipe" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=G4 -mtune=G4 -maltivec -mabi=altivec -fno-strict-aliasing -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://ftp.snt.utwente.nl/pub/os/linux/gentoo" LINGUAS="fr" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="ppc X alsa altivec berkdb bitmap-fonts bluetooth bzip2 cdr crypt ctype cups curl dbus dlloader dri dvd encode fam fastbuild ffmpeg flac foomaticdb gdbm gif gmp gpm hal idn imagemagick imap irmc isdnlog jpeg kde kdeenablefinal lcms libwww mad memlimit mikmod mng mozilla mp3 mpeg ncurses nls nptl ogg pam pcmcianfs pcre pdflib perl png posix pppd python qt quicktime readline rtc samba sasl simplexml sockets speex spell spl ssl tcpd tidy tiff truetype truetype-fonts type1-fonts udev unicode usb vorbis xine xml xml2 xsl xv xvid zlib linguas_fr userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
Please test with baselayout-1.12.0_pre17
Hi ! I tried baselayout-1.12.0_pre17 : - Works fine with net.eth0 (sungem, this was just to test the script, as I had some problems with on the first run) - The script does not launch iwconfig on net.eth1, though it is recognized by the system as a wireless NIC. I have been working on that for two days. - The script does not seem to have a DEBUG function included (the old one did), so, I don't think I can give you any useful output (This is surely my fault, since I could not find how to activate DEBUG output). I just want to say that I do not blame the script itself, since I am using a very experimental driver, on an experimental kernel patched with the developpment snapshot of the softmac stack. However, I just wished to add the following, but I do not know if the script or the stack is responsible for this behavior : The script reported that I was connected to my access point and launched dhcpcd when I was about 1 km from my house !! Should I post a second bug report ? Thanks for your help, I'll keep trying to have the new baselayout launch iwconfig. -- Jonathan
Ok, found the VERBOSE option in /etc/rc.conf, it's not DEBUG, but it gives some usefull info : The script does try to launch iwconfig, but then reports that it cannot find wireless extensions for eth1, which is wrong, since iwlist works fine. As I said before, all this is very experimental, and I think the driver or the stack is responsible for the error in the detection of the wireless extensions. I understand if you wish to close the bug until kernel 2.6.17, which will include the bcm43xx driver, is stable. -- Jonathan
Last entry, I think, here are the condensed results : - First, I am happy to say that the script does not go into an infinite loop anymore. - To get this, I had to modify the iwconfig_exists() function in /lib/rcscripts/net.modules.d, so that it returns 0 even when no wireless extension is detected in /proc/net/wireless. Again, that seems to come from the stack or the driver. Since there is no more infinite loop, I think the bug is closed ! Thanks for the help !! -- Jonathan
Definitely an upstream issue. Thanks for working it out by yourself - saved me a big headache :)