When using 2.6.24.x kernel versions, the PCMCIA Broadcom wireless adapter will not initialize properly. As per the directions of Daniel Drake, "Also, unless you're sure that your *exact* issue is covered in another bug, please file a new fresh bug report for the native drivers. We can always mark it duplicate later if we determine it is the same as another one." After attempting the fix suggested in this bug, http://bugs.gentoo.org/show_bug.cgi?id=208251 , it was determined that the fix does not work in this case. Ergo, it makes sense that this is a different bug. Reproducible: Always Steps to Reproduce: 1.install kernel version 2.6.24 (or 2.6.24.2) 2.set up the b43 driver as a module. 3.call the module automatically 4.wlan0 fails to rename, wpa_supplicant fails outright, no connection to access point Please note, I also attempted to build the b43 drivers directly into the kernel. The wireless adapter still failed to function properly. I tried both 2.6.24 and 2.6.24.2 versions, and received the same results. This particular system is set up to automatically detect which PCMCIA network adapter I install, and configure a static IP address of 192.168.0.115. The wireless NIC, an ADMtek 21x4x Tulip compatible, sets up properly and works as expected. The wireless adapter, a Linksys WPC54G (bcm4318 chipset) does not. I have gathered as much information as I can, and will submit it all. Actual Results: See attachments for details Expected Results: The Broadcom wireless adapter should have initialized, connected to my access point via wpa_aupplicant, and then set itself to IP address 192.168.0.115. That did not happen.
gen_tosh ~ # emerge --info Portage 2.1.4.4 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.22-gentoo-r9 i686) ================================================================= System uname: 2.6.22-gentoo-r9 i686 Intel(R) Celeron(TM) CPU 1066MHz Timestamp of tree: Fri, 15 Feb 2008 05:30:01 +0000 distcc 2.18.3 i486-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i486-pc-linux-gnu" CFLAGS="-march=i686 -O2 -pipe" CHOST="i486-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=i686 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distcc distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac aalib acl alsa arts avahi avi berkdb bitmap-fonts cairo cdr cli cracklib crypt cups dbus dlloader dri dv dvd dvdr dvdread eds emboss encode esd fam ffmpeg firefox flac fortran gdbm gif gpm gstreamer gtk hal iconv ipv6 isdnlog jpeg kde kdexdeltas kdgraphics lame ldap libg++ live mad midi mikmod mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp oss pam pcre pdcre pdflib perl php png ppds pppd python qt3 qt4 quicktime readline reflection sdl session slang slp spell spl ssl swat tcpd truetype truetype-fonts type1-fonts udev unicode vidix vorbis wifi win32codecs wxwindows x86 xml xorg xscreensaver xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
lspci results: 00:00.0 Host bridge: Intel Corporation 82830 830 Chipset Host Bridge (rev 03) 00:02.0 VGA compatible controller: Intel Corporation 82830 CGC [Chipset Graphics Controller] (rev 03) 00:02.1 Display controller: Intel Corporation 82830 CGC [Chipset Graphics Controller] 00:1d.0 USB Controller: Intel Corporation 82801CA/CAM USB Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801CA/CAM USB Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801CA/CAM USB Controller #3 (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 41) 00:1f.0 ISA bridge: Intel Corporation 82801CAM ISA Bridge (LPC) (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801CAM IDE U100 Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801CA/CAM SMBus Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corporation 82801CA/CAM AC'97 Audio Controller (rev 01) 00:1f.6 Modem: Intel Corporation 82801CA/CAM AC'97 Modem Controller (rev 01) 02:04.0 CardBus bridge: Texas Instruments PCI1420 PC card Cardbus Controller 02:04.1 CardBus bridge: Texas Instruments PCI1420 PC card Cardbus Controller with wireless adapter installed... 07:00.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) with wired adapter installed... 07:00.0 Ethernet controller: ADMtek 21x4x DEC-Tulip compatible 10/100 Ethernet (rev 11)
Created attachment 143559 [details] the .config file for the 2.6.24 version kernel.
Created attachment 143560 [details] the .config file for the 2.6.24.2 version kernel. You will note that in this .config file, the py0 support is enabled as a module. In 2.6.24 config file, this support isn't enabled at all. It didn't seem to matter, as the final result was the same.
Below is a transcription of the error. This is what I saw on the screen after the failure of wlan0 to rename. Also note, all network dependent programs in the default runlevel failed, such as samba and distccd after this error was receieved. * starting wlan0 * renaming "wlan0" to "eth0" cannot change name of wlan0 to eth0: File exists * failed to rename interface ......unimportant stuff... * Starting eth0 SIOCSIFFLAGS: Operation not supported SIOCSIFFLAGS: Operation not supported SIOCSIFFLAGS: Operation not supported * Bringing up eth0 * 192.168.0.115 SIOCSIFFLAGS: Operation not supported SIOCSIFFLAGS: Operation not supported
Below are the results of iwconfig and ifconfig respectively during the error. iwconfig: wlan0 IEEE 802.11g ESSID:"" Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated Tx-Power=27 dBm Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 ifconfig: lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Created attachment 143561 [details] results of dmesg when running kernel version 2.6.24 Note: I also did a dmesg under kernel version 2.6.24.2. The only difference is the '.2' at the end of 2.6.24.2
The files listed below are what make up the automatic networking setup for the machine in question. I include them to give some clarity to the way my system is set up to work. Below is the main decision engine. It is installed in /etc/conf.d. It was installed into the default runlevel using rc-update. BEGIN net-select SCRIPT... #!/sbin/runscript # Copyright 2007 Pappy McFae # Original file name: net-select # Distributed under the terms of the GNU General Public License v2 # # # Automatic PCMCIA net interface identifier. # This script is not designed to support hot swapping. # depend() { before fuse # can be placed anywhere after hostname and before net.lo # depending on your init script configuration } start() { ebegin "Checking PCMCIA port for net adapter" if [ -e /sys/class/net/wlan0/address ]; then ebegin "Found wireless adapter ... configuring" rm -f /etc/conf.d/net cp /etc/net-select/net.wl /etc/conf.d/net elif [ -e /sys/class/net/eth0/address ]; then ebegin "Found wired adapter ... configuring" rm -f /etc/conf.d/net cp /etc/net-select/net.wire /etc/conf.d/net else ebegin "No net device found ... configuring" rm -f /etc/conf.d/net cp /etc/net-select/net.null /etc/conf.d/net fi eend } END net-select SCRIPT... The files below are called by net-select. They exist in the /etc/net-select directory. Below is net.wl. It is renamed to /etc/conf.d/net if the wireless adapter is installed in the PCMCIA slot. BEGIN net.wl... # Copyright 2008 Pappy McFae # Original filename: net.wl # Distributed under the terms of the GNU General Public License v2 # Installed when wireless adpater found # Modify to suit your needs. modules=( "wpa_supplicant" ) wpa_supplicant_wlan0="-Dndiswrapper -c /etc/wpa_supplicant/wpa_supplicant.conf" rename_wlan0="eth0" config_eth0=( "192.168.0.115" ) routes_eth0=( "default via 192.168.0.1" ) END net.wl... Below is net.wire. It is renamed to /etc/conf.d/net if the wiree NIC is installed in the PCMCIA slot. BEGIN net.wire... # Copyright 2008 Pappy McFae # Original filename: net.wire # Distributed under the terms of the GNU General Public License v2 # Installed when wired adpater is found. # Modify to suit your needs. config_eth0=( "192.168.0.115" ) routes_eth0=( "default via 192.168.0.1" ) END net.wire... Below is net.null. It is renamed to /etc/conf.d/net if the PCMCIA slot is empty. BEGIN net.null... # Copyright 2008 Pappy McFae # Orig filename net.null # Distributed under the terms of the GNU General Public License v2 # Used to prevent wholesale meltdown when booting sans net adapter # No need to modify this script. config_eth0=( "null" ) END net.null.. This setup works perfectly with all versions of the 2.6.22.x kernel, up to and including version .18 using ndiswrapper and wpa_supplicant. However, it does not work at all with 2.6.24.x kernels tested.
CORRECTION: > Below is the main decision engine. It is installed in /etc/conf.d. It was > installed into the default runlevel using rc-update. I meant to say it was installed into the boot runlevel using rc-update.
This is as much information as I have currently. If you need more information, I will be more than happy to comply with your requests for whatever you need. As always, I thank one and all in advance for their time and consideration. Blessed be! Pappy
One more thing. This bug is spun off of the following bug report: http://bugs.gentoo.org/show_bug.cgi?id=208705
TYPO: > The > wireless NIC, an ADMtek 21x4x Tulip compatible, sets up properly and works as > expected. I meant to write, "The *wired* NIC, an ADMtek 21x4x Tulip compatible, sets up properly and works as expected."
For the purposes of debugging, please simplify things - disable all your network scripts and start a networkless boot. When boot has completed, capture the "ifconfig -a" output to a file and upload it here later (once online again). Then, run: # ifconfig wlan0 up # iwlist wlan0 scan Do you see any scan results? Does your AP appear in the results? Then: # wpa_supplicant -Dwext -iwlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf # wpa_cli -iwlan0 Watch the output of wpa_cli, it should tell if you if it's associating/scanning/etc as events happen. Also maybe run the "status" command if the current status is unclear. Save all that output and attach here. If it does manage to associate, you might wish to try getting an IP: dhcpcd wlan0 (then run ifconfig wlan0) Finally, capture dmesg to a file (only after doing all of the above). Then, come online through whatever means and attach the requested info to this bug.
Will do. Also, the test system is sitting about three inches from this one, so coonectivity isn't an issue... :) I'll give it a go, and let you know the results. Thank you. Blessed be! Pappy
(In reply to comment #13) > For the purposes of debugging, please simplify things - disable all your > network scripts and start a networkless boot. > > When boot has completed, capture the "ifconfig -a" output to a file and upload > it here later (once online again). > > Then, run: > # ifconfig wlan0 up > # iwlist wlan0 scan > > Do you see any scan results? Does your AP appear in the results? > Yes, I can see my access point, and one other. There are a lot of wireless routers in this complex. > Then: > > # wpa_supplicant -Dwext -iwlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf > # wpa_cli -iwlan0 > Done... > Watch the output of wpa_cli, it should tell if you if it's > associating/scanning/etc as events happen. Also maybe run the "status" command > if the current status is unclear. Save all that output and attach here. > > If it does manage to associate, you might wish to try getting an IP: dhcpcd > wlan0 (then run ifconfig wlan0) > > Finally, capture dmesg to a file (only after doing all of the above). > > Then, come online through whatever means and attach the requested info to this > bug. > Ok, at this point, it appears that I have connectivity, at least as far as the Internet is concerned. I use static IP addresses on my LAN so that samba works without getting confused. Is there another method to rename wlan0 to eth0? Both of my laptop systems require the ability to change the adapter name. While the test system isn't mission critical, this one is. To lose the ability to rename cripples my setup. Thanks for the help so far. I'll upload the files you requested next. Blessed be! Pappy
Created attachment 143613 [details] dmesg done after taking steps indicated... Here is the result of dmesg. As you can see, it looks as if everything worked normally. Blessed be! Pappy
Output from wpa_cli: gen_tosh ~ # wpa_cli -iwlan0 wpa_cli v0.5.7 Copyright (c) 2004-2006, Jouni Malinen <jkmaline@cc.hut.fi> and contributors This program is free software. You can distribute it and/or modify it under the terms of the GNU General Public License version 2. Alternatively, this software may be distributed under the terms of the BSD license. See README and COPYING for more details. Interactive mode > status bssid=xx:xx:xx:xx:xx:xx ssid=pappynet id=0 pairwise_cipher=TKIP group_cipher=TKIP key_mgmt=WPA-PSK wpa_state=COMPLETED > Results of iwconfig: gen_tosh ~ # iwconfig lo no wireless extensions. dummy0 no wireless extensions. sit0 no wireless extensions. wmaster0 no wireless extensions. wlan0 IEEE 802.11g ESSID:"pappynet" Mode:Managed Frequency:2.437 GHz Access Point: xx:xx:xx:xx:xx:xx Bit Rate=54 Mb/s Tx-Power=27 dBm Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:B6FB-851A-CD88-1C47-206D-A7C0-DC4D-B3F6-3EAC-DD42-D9D2-01F8-FC28-D71D-0DBF-C55F [2] Link Quality=66/100 Signal level=-45 dBm Noise level=-71 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Results of ifconfig: gen_tosh ~ # ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) wlan0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:192.168.0.103 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::218:f8ff:fec5:a29e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:320 errors:0 dropped:0 overruns:0 frame:0 TX packets:16 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:61879 (60.4 Kb) TX bytes:2037 (1.9 Kb) wmaster0 Link encap:UNSPEC HWaddr xx-xx-xx-xx-xx-xx-xx-xx-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) I guess this makes the bug fixed. Unfortunately, I am left without the ability to use my automatic scripts. Is there a better way to do it automatically? Thank you for your time in this matter. I appreciate your efforts. Blessed be! Pappy
So I think I can conclude that there are 2 problems: 1. your /etc/conf.d/net specifies -Dndiswrapper when you actually want -Dwext (easy to fix, obviously) 2. interface renaming fails Renaming the interface is nothing to do with the driver, I'm not sure why that is failing, especially while it appears there is no eth0 anywhere. Do you have any ideas, or are you able to add some debugging info into the scripts?
(In reply to comment #18) > So I think I can conclude that there are 2 problems: > 1. your /etc/conf.d/net specifies -Dndiswrapper when you actually want -Dwext > (easy to fix, obviously) > 2. interface renaming fails > > Renaming the interface is nothing to do with the driver, I'm not sure why that > is failing, especially while it appears there is no eth0 anywhere. Do you have > any ideas, or are you able to add some debugging info into the scripts? > Frankly, I am unsure. I thought it was the driver until I did the troubleshooting you recommended. I am going to try editing the net.wl file to see if changing the invocation of wpa_supplicant might help my situation. I also thought about the possibility of not having eth0 autostart, but I get the feeling that might be a whole lot more trouble than it's worth. The thing that really puzzles me about this situation isn't how things act on the test machine, but how they act on this one. This system uses a much more complex decision engine, which includes ethtool, file deletion, and being reset by local.start. With this setup, the wired adapter is initially declared as wth0 (off the top of my head designation...Wired eTHernet 0), and the wireless is wlan0 (natch). The final fully functional net device is eth0, which is, of course, gotten by renaming either wth0 or wlan0. If it were just the renaming alone, then wth0 would not rename, either. But, it does. Wth0 will rename to eth0 using 2.6.24 (haven't tried with 2.6.24.2), and it functions as expected. When it comes to the wireless, it's the same story as the test machine...no renaming. It doesn't even seem to try. Ok...I am looking over the scripts I use for the test machine. Might it be prudent to rename wlan0 to eth0 before starting wpa_aupplicant? I guess I'm about to find out. Perhaps if I rename it first, it will be more willing to play well with others. I'll give that a try, then I'll add some tracers to the script so I know exactly when things run afoul. It just blows my mind how well my scripting works with the 2.6.22.x versions, and it even sort of works with 2.6.23.x versions, but with 2.6.24, it chokes. I'll document the next steps I take, so perhaps we can whittle away at what is exactly throwing the monkey wrench into the works. I know I have said it many times, but I truly appreciate your assistance on this issue. I can't help but feel my switch from Slackware to Gentoo was a wise move on my part. Blessed be! Pappy
(In reply to comment #18) > Renaming the interface is nothing to do with the driver, I'm not sure why that > is failing, especially while it appears there is no eth0 anywhere. Do you have > any ideas, or are you able to add some debugging info into the scripts? > Therein lies the biggest irony of this affair. Renaming shouldn't be the problem. However, according to the tracers I installed into the wireless network setup, it *IS* the problem. The script fails at rename time. The tracers run twice, when net.lo is coming up, and then when the wireless is coming up. First run through, all is well. Second, not so much. I gave myself a clue to the problem when I wrote above that wth0 on this machine was unaffected by renaming. I just went into /etc/udev/rules.d/70-persistent-net-rules, renamed wlan0 to eth0, and renamed the wired adapter (used to be eth0) to wth0. Now, there is no renaming anywhere in the wireless adapter's setup. This allows the interface to work. Wth0 doesn't care what its name is, and renames easily. And since there is physically no way the two adapters can fit in the machine at the same time, there will never be a conflict. That's the good news... The bad news is, according to the "wireless" tab on knemo's interface status box, when using the b43 driver, I get a smokin' 1Mb/sec. That's about 53Mb/sec less than I get with ndiswrapper. I'd say that's a downgrade in anyone's book. it sure is in mine. This is especially true when you consider that the antenna on the router and the adapter's antenna are less than two feet from each other. With all I know about RF, that's more than close enough to get 54Mb/sec. I get that speed on this machine, and its antenna is about two feet further. I'd say that's a problem. On the plus side, all this work may have shown a weakness in my net configuration scripts. I need to shift everything back to working with ndiswrapper, and see how things work out with the new configuration. I sure hope it works. I have no reason to think it won't. It might even be a bit more linear than it was. Here are my modifications: net.wl: # Copyright 2008 Pappy McFae # Original filename: net.wl # Distributed under the terms of the GNU General Public License v2 # Installed when wireless adpater found # Modify to suit your needs. # Version 1, works with ndiswrapper and 2.6.22.x kernels #modules=( "wpa_supplicant" ) #wpa_supplicant_wlan0="-Dndiswrapper -c #/etc/wpa_supplicant/wpa_supplicant.conf" #rename_wlan0="eth0" #config_eth0=( "192.168.0.115" ) #routes_eth0=( "default via 192.168.0.1" ) #version 2...to be tested with b43 and 2.6.24.2 # ebegin "renaming interface" # rename_wlan0="eth0" ebegin "declaring modules" modules=( "wpa_supplicant" ) ebegin "invoking wpa_supplicant" wpa_supplicant_eth0="-Dwext -ieth0 -c /etc/wpa_supplicant/wpa_supplicant.conf" ebegin "configuring IP address" config_eth0=( "192.168.0.115" ) ebegin "routing" routes_eth0=( "default via 192.168.0.1" ) (NOTE THE TRACERS) net.wire: # Copyright 2008 Pappy McFae # Original filename: net.wire # Distributed under the terms of the GNU General Public License v2 # Installed when wired adpater is found. # Modify to suit your needs. rename_wth0="eth0" config_eth0=( "192.168.0.100" ) routes_eth0=( "default via 192.168.0.1" ) and finally, the decision engine: #!/sbin/runscript # Copyright 2008 Pappy McFae # Original file name: net-select # Distributed under the terms of the GNU General Public License v2 # # # Automatic PCMCIA net interface identifier. # This script is not designed to support hot swapping. # depend() { before fuse # can be placed anywhere after hostname and before net.lo # depending on your init script configuration } start() { ebegin "Checking PCMCIA port for net adapter" if [ -e /sys/class/net/eth0/address ]; then ebegin "Found wireless adapter ... configuring" rm -f /etc/conf.d/net cp /etc/net-select/net.wl /etc/conf.d/net elif [ -e /sys/class/net/wth0/address ]; then ebegin "Found wired adapter ... configuring" rm -f /etc/conf.d/net cp /etc/net-select/net.wire /etc/conf.d/net else ebegin "No net device found ... configuring" rm -f /etc/conf.d/net cp /etc/net-select/net.null /etc/conf.d/net fi eend } END SCRIPTS... If I can't get better than 1Mb/sec out of the driver, might it be a good idea to bug report that? I'm going to do a bit more experimenting, but I get a feeling the native driver performs worse than ndiswrapper. If that is found to be the case, I'd love to get a big push with the 2.6.24.x and ndiswrapper bug. Thanks for your time and consideration... Blessed be! Pappy
Please do a networkless boot and run the following: ifrename -i wlan0 -n eth0 then use "ifconfig -a" to see if the interface has renamed
(In reply to comment #21) > Please do a networkless boot and run the following: > > ifrename -i wlan0 -n eth0 > I get the following error: Error: Can't open configuration file '/etc/iftab': No such file or directory > then use "ifconfig -a" to see if the interface has renamed > It remains wlan0. That seems to be the long and the short of it. Apparently, the problem is the fact that said file above is missing. I did a little research, and I found this article http://www.thelinuxlink.net/myblog/?p=64 about that file. It has supposedly been replaced by /etc/udev/rules.d/70-persistent-net.rules. However, no one told my machines. None of them has that file. So I think that we are getting to the root of the evil here. I'm going to see if I can find any mention of it in the Gentoo forums. Note, there are a few thunderstorms in the area...so my access may be spotty...not because of power outages, but because I take down my systems when there are storms about. This is Dallas after all. The storms here are like no others. Once again, thanks for your time, effort, consideration, and support. Blessed be! Pappy
add "-c /dev/null" to that
Hold the phone! A stroke of genius has struck me! If I use the command, "ifrename -c /etc/udev/70-persistent-net.rules -i wlan0 -n eth0", wlan0 renames to eth0. It throws an error or two, but it renames nonetheless. I am going to copy /etc/udev/70-persistent-net.rules as /etc/iftab and see if that helps the situation. Done. It gives errors, but it does rename wlan0 to eth0. I am going to tweak the file to get it in line with the way it's described in the man page, hopefully eliminating the errors, and I'll get back to you. The question remains, why is it that 2.6.24 version kernels won't rename, when 2.6.22.x and 2.6.23.x rename without the problems associated with the 2.6.24.x kernels, and why you need to use a file that is supposedly been replaced by udev? Blessed be! Pappy
(In reply to comment #23) > add "-c /dev/null" to that > I'll go you one better on that one. How about editing /etc/iftab so it is nothing but # comments? Believe it or not, apparently all that needs to happen is that the file has to exist. Ok..cool. Now, I am going to reactivate all my networking scripts and see what happens. Blessed be! Pappy
(In reply to comment #25) > (In reply to comment #23) > > add "-c /dev/null" to that > > > > I'll go you one better on that one. How about editing /etc/iftab so it is > nothing but # comments? Believe it or not, apparently all that needs to happen > is that the file has to exist. > > Ok..cool. Now, I am going to reactivate all my networking scripts and see what > happens. I get the same error screen I got in the example above. For some reason, when in automatic mode, it creates eth0 out of thin air, and then glitches finishing the setup. Apparently, there is still something else afoot here. Blessed be! Pappy > > Blessed be! > Pappy >
(In reply to comment #26) > For some reason, when in automatic mode, it creates eth0 out of thin air, and then glitches finishing the setup. What do you mean by this? eth0 exists at that point in time? How do you know? Which physical interface does it correspond to? I note that you never posted "ifconfig -a" output from a networkless boot (you missed the -a). Such output might be useful here.
Just for giggles, I set the 2.6.24.2 kernel for ndiswrapper support, emerged ndiswrapper 1.52, and gave it a try since I now had /etc/iftab. That's still a no-go as well. I won't sit here and profess to know all there is to know about the kernel, but it looks to me like the b43 driver (and perhaps interface) has been completely re-written. I base that judgment on the fact that there are numerous references to rewrites concerning the b43 code in the changelog for 2.6.24. One of those numerous rewrites not only obliterates the ability to automatically rename the interface, but it also keeps ndiswrapper from functioning properly. I wonder if it might be the same bug. Just some thoughts. Blessed be! Pappy
No, network drivers have no say in their renaming. After initialization they aren't even aware of their names. The problem is elsewhere. I am suspecting that you have another network interface present which is being given name eth0 -- the kernel will choose this for a wide variety of devices if it is free. It's difficult to confirm this without the "ifconfig -a" output but it might make sense for you to choose a different name for your "definitive" interface for this reason.
(In reply to comment #27) > (In reply to comment #26) > > For some reason, when in automatic mode, it creates eth0 out of thin air, and then glitches finishing the setup. > > What do you mean by this? eth0 exists at that point in time? How do you know? > Which physical interface does it correspond to? > > I note that you never posted "ifconfig -a" output from a networkless boot (you > missed the -a). Such output might be useful here. > It is easier to demonstrate. I made numerous files to attempt to document what I was telling you. I will be sending them along presently as attachments. I've got all kinds of documentation for you. And like I said, from all I can see, the problem happens during renaming. Hold on t your hat. Blessed be! Pappy
Created attachment 143721 [details] results of ifconfig -a, rename, and dhcpcd without /etc/iftab This is what I originally saw when I inputted the commands you requested.
Created attachment 143723 [details] results of ifconfig -a, rename, and dhcpcd with /etc/iftab These are the results of the commands you asked me to enter when there was a file named /etc/iftab. Note that the rename appears to go well. It's merely an illusion as I will show with another file.
Created attachment 143725 [details] results of ifconfig -a, and ifrename with b43 module loading automatically Note what it says about eth0. It says the same thing no matter how the b43 driver is loaded, automatically or with modprobe after boot time.
Created attachment 143726 [details] results of ifconfig -a, and ifrename with ndiswrapper loading automatically I include this as a reference. Note that the /etc/iftab file was not installed at the time this file was created. Note how it allows renaming without problems. This may also serve useful when time comes to get ndiswrapper and 2.6.24.x playing nicely with each other.
Created attachment 143731 [details] results of ifconfig -a, and ifrename with 2.6.22.18 and ndiswrapper I include this as a reference to how things look when I set up for my standard wireless operation.
(In reply to comment #29) > No, network drivers have no say in their renaming. After initialization they > aren't even aware of their names. The problem is elsewhere. > > I am suspecting that you have another network interface present which is being > given name eth0 -- the kernel will choose this for a wide variety of devices if > it is free. It's difficult to confirm this without the "ifconfig -a" output but > it might make sense for you to choose a different name for your "definitive" > interface for this reason. > I'm not too sure about that. Note that the only time that eth0 shows up "unwelcome" is when the b43 module gets loaded, manually or automatically. You can see that clearly in comment #31, and comment #33. The module eth0 doesn't exist before "modprobe b43", and does afterward. Also note that it claims eth0 isnt "Ethernet, FireWire, InfiniBand or Token Ring" Curious. The more I play with this, the more I think that when we come to the solution, it will also fix the problem with ndiswrapper...at least that's my fervent hope. I much prefer ndiswrapper. I can configure it. With b43, you get what the firmware wants to give you, and not a drop more...at least so it seems. Blessed be! Pappy There's a lot to chew on there. I hope I'm not overloading you on this issue.
(In reply to comment #36) > I'm not too sure about that. Note that the only time that eth0 shows up > "unwelcome" is when the b43 module gets loaded, manually or automatically. You > can see that clearly in comment #31, and comment #33. Are you sure about that? There is no eth0 shown in comment #31 However, there is eth0 in comment #33, and this is almost certainly showing the problem you are seeing. Something is renaming wmaster0 to eth0, and then when your stuff executes, eth0 is already taken so it cannot rename. Please attach your /etc/udev/rules.d/70-persistent-net.rules
(In reply to comment #37) > (In reply to comment #36) > > I'm not too sure about that. Note that the only time that eth0 shows up > > "unwelcome" is when the b43 module gets loaded, manually or automatically. You > > can see that clearly in comment #31, and comment #33. > > Are you sure about that? There is no eth0 shown in comment #31 How right you are. I meant to say that #31 showed the rename error occurring in the absence of /etc/iftab. Unfortunately, bugzilla doesn't allow editing, so the error will stand for all time |SHEEPISH GRIN| Oooops. > > However, there is eth0 in comment #33, and this is almost certainly showing the > problem you are seeing. Something is renaming wmaster0 to eth0, and then when > your stuff executes, eth0 is already taken so it cannot rename. > > Please attach your /etc/udev/rules.d/70-persistent-net.rules Yes, that is exactly the problem I am seeing. That is most likely why the error screen says "File Exists" (see comment # 5) > /etc/udev/rules.d/70-persistent-net.rules: # This file was automatically generated by the /lib/udev/write_net_rules # program run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single line. # PCI device 0x14e4:0x4318 (ndiswrapper) SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:18:f8:c5:a2:9e", ATTR{type}=="1", NAME="wlan0" # PCI device 0x1317:0x1985 (tulip) #SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:18:4d:ec:d1:73", NAME="eth0" Before you ask, deleting and having it rebuild doesn't help in this case. I tried that when I read about the another bug that had similar circumstances...and it was a no go. The file above was the one in place before I began today's round of experiments. Currently, there is a one in operation. Blessed be! Pappy
Please attach the file rather than pasting so that I can be sure of the formatting. Another thing to try, disable udev's renaming of interfaces just so that we can either rule it in or out: echo 'SUBSYSTEM=="net", OPTIONS+="last_rule"' >> /etc/udev/rules.d/10-local.rules then repeat the test in comment #33
(In reply to comment #39) > Please attach the file rather than pasting so that I can be sure of the > formatting. > > Another thing to try, disable udev's renaming of interfaces just so that we can > either rule it in or out: > > echo 'SUBSYSTEM=="net", OPTIONS+="last_rule"' >> > /etc/udev/rules.d/10-local.rules > > then repeat the test in comment #33 > Should I delete 70-persistent-net.rules, and not have it rebuild, or set one up with the b43 adapter? The current one uses ndiswrapper to determine the wlan0 interface. I want to make sure we are going down the same path at the same time. Blessed be! Pappy
Created attachment 143846 [details] results with a blank 70-persistent-net.rules and 10-local.rules As you will be able to see, there is no difference between this output, without 70-persistent-net.rules, and with 10-local.rules blocking the creation of a new file, and the one where 70-persistent-net.rules rebuilds itself.
Created attachment 143847 [details] results with a blank 70-persistent-net.rules without 10-local.rules Aa you will see, there is no difference between the output from this file, and the one previous. The 70-persistent-net.rules generated will follow.
Created attachment 143848 [details] 70-persistent-net.rules generated by actions above. This is the 70-persistent-net.rules file created by doing the above steps. As you can see, the only device created in the file is wlan0.
Created attachment 143851 [details] Add this to the bottom of the attachments in comment 41 AND 42 Add this line to the bottom of the attachments on comment # 41 and comment # 42. This step was left out by mistake. However, I reran the tests, duplicating the circumstances of each test, and the result was the same. Blessed be! Pappy
(In reply to comment #39) > Another thing to try, disable udev's renaming of interfaces just so that we can > either rule it in or out: > > echo 'SUBSYSTEM=="net", OPTIONS+="last_rule"' >> > /etc/udev/rules.d/10-local.rules > > then repeat the test in comment #33 I don't think you did the last step as requested. Instead you did the one in comment #32 by the looks of things?
(In reply to comment #45) > (In reply to comment #39) > > Another thing to try, disable udev's renaming of interfaces just so that we can > > either rule it in or out: > > > > echo 'SUBSYSTEM=="net", OPTIONS+="last_rule"' >> > > /etc/udev/rules.d/10-local.rules > > > > then repeat the test in comment #33 > > I don't think you did the last step as requested. Instead you did the one in > comment #32 by the looks of things? > I did forget to do it, but I reran all the tests as listed. The result of this is contained in comment #44. No matter what was done, the final result is that eth0 shows up as a non-existent device. As to why it changed from the results of comment #33, I have no idea. I started networkless, modprobed the b43 driver, and you see the results. It didn't matter whether or not 10-local-rules existed, or whether or not 70-persistent-net.rules existed. The final result is somehow, the b43 creates an instance of eth0 that doesn't exist. Considering that this only happens with the b43 driver, I'd say it's the driver. Blessed be! Pappy
In comment #33 you wrote that b43 was loading automatically. But in the most recent attachments, you are having to modprobe it manually. This does not seem to be the same experiment... In the earlier tests like comment #32 where you are modprobing manually, things are working fine - the interfaces are named with their usual names (wlan0 and wmaster0). This is the working case - it means eth0 is free, so your scripts could then go ahead and rename wlan0 to eth0. It is continuing to work in your most recent attachments - wmaster0 remains named as wmaster0. The interesting problematic case is the one in comment #33 where *something* is renaming wmaster0 to eth0, preventing your scripts from renaming wlan0 to eth0. This is the problem we need to identify - we have to find out what is renaming wmaster0 to eth0 and stop it from doing so. So, please triple check that you are doing the same experiment as in comment #33 in your most recent attachments (e.g. #44), or at least clarify exactly what the difference between the experiments in comment #32 and comment #33 actually is. To clarify again: the interesting case is illustrated in comment #33 where wmaster0 does not exist, and has instead been renamed to eth0. This is the behaviour we need to stop in order for your scripts to work. Everything else is looking fine.
The only difference, as far as I recall, is that with the experiment that resulted in the attachment of comment #33 was that the b43 module was loaded by /etc/modules.autoload.d/kernel-2.6 (which actually was an accident). With the other experiments, I decided it made sense to modprobe the b43 driver as it was the only way to show that eth0 didn't come into existence until after loading the b43 module. As far as I can tell, that's the only difference between things. I can set the machine up to autoload the b43 module to make sure if need be, but I really don't think it's necessary. But it's your puppy, and since I plan to be up for a couple more hours, I'll do what you wish. Please note, while I am doing this, I am also preparing another machine to boot with lilo, with the ultimate object of moving the Gentoo install on that machine to a larger, faster drive. It's still booting from GRUB that was installed by Debian, and I think it's time for that to stop. I'll check here about every fifteen minutes or so. Blessed be! Pappy
(In reply to comment #48) > The only difference, as far as I recall, is that with the experiment that > resulted in the attachment of comment #33 was that the b43 module was loaded by > /etc/modules.autoload.d/kernel-2.6 (which actually was an accident). > > With the other experiments, I decided it made sense to modprobe the b43 driver > as it was the only way to show that eth0 didn't come into existence until after > loading the b43 module. And in such cases (#32, #44) - eth0 doesn't come into existence until you explicitly rename it. Until you rename it, there is no eth0, so that name is available. This is the desirable situation. wmaster0 is called wmaster0. Everything is fine, and provided that this behaviour remains consistent, your scripts will work. Unfortunately it does not remain consistent. In the problematic case (comment #33), eth0 ALREADY EXISTS after boot. There are 2 problems here: 1. Your scripts require the eth0 name to be free, but an interface has been given this name, hence nothing can be renamed to eth0. 2. In this situation, eth0 is actually wmaster0! Something has renamed wmaster0 to eth0. For the majority of users, wmaster0 is useless and should not be touched. Unless you know something that I don't, we do not have an explanation for why wmaster0 is being renamed to eth0. This is what we need to figure out. As soon as we can stop this from happening, eth0 will be free again, and this bug will be solved. So, it's essential that you focus on figuring out the problematic case (comment #33) rather than any other. Do you see that?
> And in such cases (#32, #44) - eth0 doesn't come into existence until you > explicitly rename it. Until you rename it, there is no eth0, so that name is > available. This is the desirable situation. wmaster0 is called wmaster0. > Everything is fine, and provided that this behaviour remains consistent, your > scripts will work. > No, eth0 comes into existence when the b43 module is loaded, as does wlan0 and wmaster0. It doesn't matter whether I manually modprobe it, or whether it loads automatically. Before B43, no eth0 or wlan0, or wmaster0. Afterward, all three show up. I can't rename wlan0 to eth0 because eth0 supposedly exists. However, it doesn't, as shown in comment #33, it says: gen_tosh ~ # dhcpcd eth0 Error, eth0: interface is not Ethernet, FireWire, InfiniBand or Token Ring I can rerun everything and show you that this remains a problem, once again whether the b43 driver is loaded automatically or manually. > Do you see that? > I'm sorry. Things are getting somewhat convoluted. I'll rerun the test with the following conditions: 1) all network programs will be shut down. 2) all automatic networking will be shut down. 3) the b43 driver will be modprobed. 4) I will then attempt to dhcpcd eth0 I got the lilo thing working (easy!) and so, I am back to fully attentive on this issue. Be back in a few... Blessed be! Pappy
(In reply to comment #50) > No, eth0 comes into existence when the b43 module is loaded, as does wlan0 and > wmaster0. It doesn't matter whether I manually modprobe it, or whether it loads > automatically. Before B43, no eth0 or wlan0, or wmaster0. Afterward, all three > show up. Your comments do not seem to match your attachments. For example, look at comment #42. There is no eth0 anywhere. Please explain :)
(In reply to comment #51) > (In reply to comment #50) > > No, eth0 comes into existence when the b43 module is loaded, as does wlan0 and > > wmaster0. It doesn't matter whether I manually modprobe it, or whether it loads > > automatically. Before B43, no eth0 or wlan0, or wmaster0. Afterward, all three > > show up. > > Your comments do not seem to match your attachments. For example, look at > comment #42. There is no eth0 anywhere. > > Please explain :) > Yes...I think I'm getting a little soft in the head. I didn't even notice that eth0 had disappeared. Sorry. My eyes are getting a little tired. Anyway. I see what you mean. As to why all of a sudden eth0 isn't being created out of thin air, well...I'm at a loss. However, I do know this. Renaming won't work. Let me do a little playing here, and I'll be back to show you this as well...and if I'm wrong, then perhaps the gremlins have been exiled. Yeah, as if I could get that lucky. Back in a few. Blessed be! Pappy
Created attachment 143867 [details] booted with no net support, modprobe b43, attempt to rename In this, we start without any net support. Then b43 is modprobed. Then I attempt to rename it...and we get the results. Once again, as to why eth0 disappeared, I am at a loss. Part of it is my fault, as I don't recall everything I disabled to get comment #33. I do know that at the time, the automatic networking scripts weren't activated. So, once again, I am at a loss. Be that as it may, the problem remains; the interface will not successfully rename without the /etc/iftab file. While I thought just putting an empty file would make things work, or using the "-c /dev/null" as you suggested, renaming doesn't happen automatically. Perhaps I need a bona-fide /etc/iftab file. Do you have one? Do you have a pattern for one? The man page is as clear as mud on that particular issue. Anyway, here is the results of the latest test. Blessed be! Pappy
Just add "-c /dev/null" for the ifrename command. I mentioned this above. You don't need an iftab since you specify both source and target interfaces on the command line, but for some reason (maybe a deficiency in ifrename) it does want a file to exist for no apparent reason. I am confident that the rename will work once you correct the ifrename invocation. So, next test is to do this: - start networkless boot - modprobe b43 - **DON'T** run ifrename - start your network setup scripts I think everything will succeed.
(In reply to comment #54) > Just add "-c /dev/null" for the ifrename command. I mentioned this above. You > don't need an iftab since you specify both source and target interfaces on the > command line, but for some reason (maybe a deficiency in ifrename) it does want > a file to exist for no apparent reason. > > I am confident that the rename will work once you correct the ifrename > invocation. > > So, next test is to do this: > - start networkless boot > - modprobe b43 > - **DON'T** run ifrename > - start your network setup scripts > > I think everything will succeed. > I will do this when I wake up later today. For now, I think I am a bit too loopy to be dependable. Blessed be! Pappy
Just to let you know, I am here, and I am working with the machine..and getting some curious results... The conditions tested are as follows: 1) boot networkless, modprobe b43, rename to eth0, ifconfig it up, wpa_supplicant, dhcpcd, and finally, dmesg at the end of it all 2) Same as above, but no renaming. I am doing this because, frankly, I don't know how to make the /etc/conf.d/net file process after boot time. It is coming up with some curious results...and I'm not sure how to understand what it all means. I'm a bit fresher than last night, so let's have some fun and find that bug. It might lead us to the ndiswrapper bug...which would be absolutely fine with me. Blessed be! Pappy
Ok, apparently for some reason I have yet to discern from all that has gone on, b43 is now working...assuming I do not attempt to rename wlan0 to eth0. If I do that, the jig is up! It absolutely WILL NOT RENAME. It also throws up a small glitch when entering wpa_supplicant. Apparently, it's only a minor glitch, because it's working right now. I can deal with all that on the test machine. It's not mission critical that it has eth0 as the standard functional interface. It cannot accept both PCMCIA adapters at one time. It's a physical impossibility. No big deal. However, on *this* machine, both wireless and wired net adapters reside in the same case. Therefore, I have to be able to rename the interfaces in order for the networking to work properly, as in the way I want it to work...as in the way it DOESN'T work under Windoze. Since renaming simply doesn't work with this driver, there is no reason to continue messing with it. As far as I am concerned, we can call this bug basically fixed. I'll let you make the final call on that. Frankly, I'd really rather work on finding out why ndiswrapper & bcm devices refuse to work under 2.6.24.x kernels, since I prefer working with ndiswrapper. Ndiswrapper is more infinitely more configurable. Ndiswrapper-1.51 is supposed to work with the 2.6.24.x kernel, at least if you believe what they have posted in the changelog. I think I'll check right now and see if I can actually get ndiswrapper to work now that I have b43 working. Maybe whatever was causing the problem is gone now. Ndiswrapper might even allow renaming. I can hope. Blessed be! Pappy
Sorry if I am losing patience, but I feel that you are making this unneccessarily hard for both of us - pointing out things that we have already established, not running tests exactly as asked for, running loads of tests not asked for (just adds to noise...), posting things as comments when asked for attachments, etc. It's generally easiest if you keep bug commentary short and to the point, waffle-free. It would be hell for another developer unfamiliar with the bug so far to become involved now, due to the sheer length of the bug and the number of attachments... I've already established that this is very very unlikely to be a kernel bug (i.e. it's not on my turf). The only reason I am still helping you here is so that I can tell you where to file the real bug report (since we still don't actually know where this bug is originating from), and because the end result might actually be interesting. And maybe you'll learn from it too. So I'll give it one more try: We already established that b43 is working fine as a driver. This was comment #15. I already pointed out that the only unknown problem behind your issues is the renaming of the interface, this was comment #18 (40 comments ago!) I already told you that network drivers are not involved with renames. They are not even aware that they have been renamed. This was comment #29. This is not a bug in b43. Please take my word for it - I am the co-author of a popular wireless driver. Here is the story so far: You are using baselayout's network configuration to rename wlan0 to eth0. This is not working. First question: why is rename failing? It seems that the rename is failing because another interface already has name "eth0". It makes sense that two interfaces cannot have the same name. The next question: which interface has been given name eth0? Normally when you load b43, interfaces named wlan0 and wmaster0 are created. This can be seen in comment #32. wlan0 is the network interface that you should use (as a user), which is how your configuration is (correctly) written. As a user you should ignore wmaster0 and not touch it or be bothered by it's presence. In the problematic case, wmaster0 appears to have been renamed to eth0. You can see this in comment #33 by looking at the HWaddr of eth0 and comparing it to the "ifconfig -a" listing in comment #32. It is now clear why wlan0 cannot be renamed to eth0 -- something has renamed wmaster0 to eth0 beforehand. Next question: What is renaming wmaster0 to eth0? This is still a mystery. This is what we need to figure out to move on. If you don't agree with me here, please re-read the above, making sure you double check the comments I am referring to. In comment #32 you somehow did a networkless boot and ended up with wmaster0 named as eth0 (please look at the attachment and convince yourself of this). So you managed to reproduce the problem - excellent! Unfortunately you cannot recall exactly how you did this, and even though you suspect that it happened when b43 was in modules.autoload.d, you do not appear to have attempted to reproduce it. Here is what you should do next: - start networkless boot - run "ifconfig -a" - modprobe b43 - run "ifconfig -a" and check that the new interfaces are named wlan0 and wmaster0 - **DON'T** run ifrename - start your network setup scripts - run "ifconfig -a" and check that wlan0 is now eth0 and wmaster0 is still wmaster0 To start your network scripts you do the opposite of whatever you did to create a networkless boot, then run "rc". FOR EXAMPLE if you ran the following to do a networkless boot: # rc-update del net.wlan0 # rc-update del net.eth0 Then after booting up in a networkless environment and loading b43, you should do: # rc-update add net.wlan0 # rc-update add net.eth0 # rc (don't just mindlessly run those commands - I'm not sure exactly which scripts you are removing from runlevels to do a networkless boot - so please think about it and just do the opposite as illustrated by the examples). That test should work just fine - wlan0 should be renamed to eth0 and then brought up and connection established OK. This will act to confirm the situation as I have described above. In hope of reducing confusion I'll wait for you to do that test before suggesting further things to try. So please go ahead and do that (and not anything else), and post the results.
(In reply to comment #58) > Sorry if I am losing patience, but I feel that you are making this > unneccessarily hard for both of us - pointing out things that we have already > established, not running tests exactly as asked for, running loads of tests not > asked for (just adds to noise...), posting things as comments when asked for > attachments, etc. > No, forgive me for saying this, but you aren't listening to me. The problem is in renaming. PERIOD, END OF STATEMENT! I knew that when it told me the first time around that renaming failed. It's the why that is in question. I can get b43 to work IF AND ONLY IF I don't attempt to rename the interface. It can't be any more simple than that. If I edit my wireless network startup script to not rename, then the b43 will load, and work automatically...which is a far site better than it was doing when first I attempted to make things happen. > > I've already established that this is very very unlikely to be a kernel bug > (i.e. it's not on my turf). The only reason I am still helping you here is so > that I can tell you where to file the real bug report (since we still don't > actually know where this bug is originating from), and because the end result > might actually be interesting. And maybe you'll learn from it too. > > So I'll give it one more try: > > We already established that b43 is working fine as a driver. This was comment > #15. > This is also established by the fact that now the b43 can autoload, and will actually function...even if it throws errors during wpa_supplicant's startup. It works on the internet, and with samba. > > I already told you that network drivers are not involved with renames. They are > not even aware that they have been renamed. This was comment #29. This is not a > bug in b43. Please take my word for it - I am the co-author of a popular > wireless driver. > I will try the moves you suggest, and report back. Blessed be! Pappy
Created attachment 143954 [details] results of test requested Results of the test requested.
OK, so starting the net scripts renames wmaster0 to eth0 and then fails trying to do the same for wlan0. baselayout's net-tools code uses /sbin/nameif to rename the interfaces, which is based on MAC address, so it ends up attempting to rename both (and unfortunately wmaster0 first...). wlan0 and wmaster0 have the same MAC address. If you switch to using iproute2 instead of net-tools then this problem should go away, because ip renames based on interface name. "emerge iproute2" should be all that is needed, if not add the following to the top of /etc/conf.d/net modules=( "iproute2" ) Feel free to file a baselayout bug about the nameif thing - but I'm not sure if anything can be done. Perhaps it could prefer ifrename if it is available, that might solve the issue. Also, FYI, the interface renaming functionality has been removed in baselayout-2 (now openrc). But the hotplugging capabilities provided instead should serve you OK. Closing this now that we know the cause.
Cool..and thanks for your efforts. I'll give those things a try and see if they works. I apologize for being problematic. Having been on your side of the desk when it comes to fixing something, I know it can be frustrating. However, in those kind of situations, it's best if I remember that my computer is working fine, so it does me no good to get upset. It's the other guy's machine that's screwed up. I'm just along for the ride, so to speak. Anyway, thank you again for your time and consideration. Blessed be! Pappy
Final word: When moving to iproute2, make sure you add the netmask and broadcast to the /etc/conf.d/net thusly: config_eth0=( "192.168.0.115 netmask 255.255.255.0 broadcast 192.168.0.255" ). If you don't, you get no connection. I just finished a boot with b43 autoloading and renaming...and although it gave a hiccup during wpa_supplicant, it is working. Since the wpa_supplicant glitch doesn't seem to cause a problem, I don't think it is a problem. This bug is officially fixed! Many thanks to you, Mr. Drake, and my humblest apologies for any distress I may have caused you. Blessed be! Pappy
(In reply to comment #63) > Final word: When moving to iproute2, make sure you add the netmask and > broadcast to the /etc/conf.d/net thusly: > > config_eth0=( "192.168.0.115 netmask 255.255.255.0 broadcast 192.168.0.255" ). > If you don't, you get no connection. > > I just finished a boot with b43 autoloading and renaming...and although it gave > a hiccup during wpa_supplicant, it is working. Since the wpa_supplicant glitch > doesn't seem to cause a problem, I don't think it is a problem. > > This bug is officially fixed! > > Many thanks to you, Mr. Drake, and my humblest apologies for any distress I may > have caused you. > > Blessed be! > Pappy > Yes,I had the same problem. It was a rename problem after updating udev. It looks like a udev bug, with an easy solution: delete all /etc/udev/rules.d/* and reemerge udev http://forums.gentoo.org/viewtopic-t-647213-view-next.html?sid=30701c35750cb37cdaa50319712f59f9
