When upgrading to kernel version 2.6.24 (vanilla sources) the bcm4311 wireless card card in my Compaq Presario C504US laptop no longer functions properly. When using B43, wlan0 does not function with wpa_supplicant. It also will not rename itself from wlan0 to eth0. This is a function that works under linux-2.6.22.14, 15, and 16. If I opt to use ndiswrapper instead, it will emerge properly. However, the wireless adapter remains nonfunctional. While it will respond to iwconfig, it doesn't set an IP address, nor can one be forced by invoking dhcpcd in a console session. This was tested using ndiswrapper versions 1.50 and 1.51. Reproducible: Always Steps to Reproduce: 1 boot with the 2.6.24 version kernel 2.automatically load ndiswrapper version 1.50 or 1.51 OR 2a attempt to load the b43 or b43legacy driver. 3.attempt to load wpa_supplicant Actual Results: If ndiswrapper is "loaded", all indications show that the network is setting itself up properly. However, no IP address is assigned to said adapter. This happens whether the /etc/conf.d/net invokes a static IP address ie: modules=( "wpa_supplicant" ) wpa_supplicant_wlan0="-Dndiswrapper" rename_wlan0="eth0" config_eth0=( "192.168.0.100" ) routes_eth0=( "default via 192.168.0.1" ) or whether I attempt to invoke dhcpcd by way of the console when ifconfig shows no IP address assigned to wlan0 OR eth0 Expected Results: I expected my wireless networking adapter to work. It didn't, and doesn't under the 2.6.24 kernel. It works perfectly fine under 2.6.22.16 and earlier. This problem seems to be peculiar to the vanilla version kernel. I will test functionality under the gentoo-sources 2.6.24 kernel and report the results
Created attachment 142580 [details] results of ping, iwconfig, and ifconfig. The file shows the results of the ping, iwconfig and ifconfig commands while the bug is "doing it's thing".
Created attachment 142581 [details] the config file for the vanilla 2.6.24 kernel in question. This is the .config file used to create the kernel in question. Please note, it only carries changes brought about by the use of "make oldconfig". While it was modified to use the b43 and b43legacy modules, they were ineffective. This configuration is the one under which I attempted to build ndiswrapper support. The 2.6.22.16 .config file is available if you would like to compare it to this one.
emerge --info Portage 2.1.3.19 (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(R) M CPU 440 @ 1.86GHz Timestamp of tree: Fri, 01 Feb 2008 06: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.1.4 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 --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa ao arts avahi avi bash-completion berkdb bitmap-fonts cairo cdr cgi cli cracklib crypt cups dbus dga dlloader dri dvd dvdr dvdread eds emboss encode esd fam ffmpeg fftw firefox flac foomaticdb fortran gdbm gif gimp gpm gstreamer gtk hal iconv imagemagic insecure-savers ipv6 isdnlog jpeg kde kdexdeltas kdgraphics lame ldap libg++ libsamplerate mad midi mikmod mime mozilla mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp oss pam pcre pdcre pdflib perl php png portaudio ppds pppd python qt3 quicktime readline reflection rss samba sdl session slang slp sndfile sox spell spl ssl swat synaptics tcpd theora tiff truetype truetype-fonts type1-fonts udev unicode vorbis wifi win32codecs wmf x86 xine xinetd xml xorg xscreensaver xv xvid 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 authn_alias authn_anon 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 deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif 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
Also note the behavior of this kernel (vanilla-sources-2.6.24) is identical to the behavior of the gentoo-sources version (linux-2.6.24-gentoo). I have the .config avaialble for that kernel version, as well as the version of 2.6.22.16 that works properly, if needed.
I use wpa_supplicant 0.5.8.
Bob, this sounds a lot like the problems I'm having with my bcm4306-based card, details here: http://bugs.gentoo.org/show_bug.cgi?id=201359 Couple of questions: 1) Can you use the bcm43xx module with latest sources? 2) When starting the interface with b43* do you get ioctl errors like those in this post? http://forums.gentoo.org/viewtopic-p-4792469.html#4792469
(In reply to comment #6) > Bob, this sounds a lot like the problems I'm having with my bcm4306-based card, > details here: http://bugs.gentoo.org/show_bug.cgi?id=201359 > > Couple of questions: > 1) Can you use the bcm43xx module with latest sources? No. I can't get any of the "native" drivers to work properly. While it appears that ndiswrapper will at least give indication that it is functioning when I enter iwconfig, there is no IP address listed for ifconfig. When using the native drivers, my networking completely flips out. By flipping out, I mean the wireless interface refuses to rename (which is necessary with my network setup). It went so far as to create wlan1, which was unnecessary, since wlan0 hadn't even been configured at that point, and was free to be used. Judging from the way the system behaved last night, when I went through to double check what was and wasn't working, I believe it's more a problem with the way wpa_supplicant interacts with the kernel, but that is merely my hypothesis. Unfortunately, the only version of wpa_supplicant accessible via portage (that isn't masked) is 0.5.8. That's a fairly old version. I know, because I used it under Slackware as well. > 2) When starting the interface with b43* do you get ioctl errors like those in > this post? > http://forums.gentoo.org/viewtopic-p-4792469.html#4792469 > No, I can't even get close to getting ioctl errors. The interface won't rename, and apparently, completely snubs wpa_supplicant. I say snubs, because when I do an iwconfig under one of the "native" drivers, I get no indication that there is even a wireless device...or that the adapter tried to associate with my w/l router. The good thing is, they just released kernel version 2.6.22.17. Fortunately, wireless networking via ndiswrapper/wpa_supplicant still works properly under that version. That said, I think it's kind of crappy to release a new kernel that doesn't at least try to allow wireless connectivity. After all, this is the age of internet flying through the air. I'd think to keep people happy, the folks who set up the kernels would at least try to make sure a program like wpa_supplicant works under that new kernel. However, it seems that the .23 and .24 versions of the 2.6 kernel don't do that. |SHRUG| Blessed be! Pappy
Please be more mindful of what you write. Your comments could be quite demotivating if read by the people who spend hours and hours getting this stuff going. You say that 2.6.22 worked for you. Which configuration and driver were you using in that kernel? ndiswrapper?
(In reply to comment #8) > Please be more mindful of what you write. Your comments could be quite > demotivating if read by the people who spend hours and hours getting this stuff > going. > > You say that 2.6.22 worked for you. Which configuration and driver were you > using in that kernel? ndiswrapper? > Firstly, I apologize for the words I used. Perhaps "crappy" was a bit strong, and I can see how it might offend. It wasn't my intention to offend. That said, it doesn't change my opinion. I understand that developing anything in the world of computers is challenging. In the world of Linux, where the only defacto standard seems to be the kernel, it can be even more mind boggling, I'm sure. However, to say that my ill chosen words might be "demotivating" seems to fly in the face of the fact that I am not the only person with these problems. A simple browse through Gentoo and Linuxquestions forums prove this is the case. When one considers that 2.6.22.xx versions of the kernel support ndiswrapper and wpa_supplicant, and everything since 2.6.23 hasn't, this gives me pause. My most recent .config will follow. I am using ndiswrapper. I have tried versions 1.50, 1.51, and 1.52 (current version, although it is masked for x86, or was when last I checked). I am currently using ndiswrapper version 1.52 with kernel 2.6.22.17 (vanilla) and 2.6.22-r9-gentoo-sources. I am also running version wpa_supplicant 0.5.8. As of my last look, it was the newest version that isn't masked in portage because of problems (=>0.6), and version 0.5.9 isn't in portage at all, at least the last time I looked. When I attempt to use ndiswrapper with 2.6.24, I get nothing. When I tried the new native driver (b43), I got less than nothing. The interface wouldn't rename (a must for my network setup), and wouldn't show up under iwconfig, either as wlan0 or eth0. I don't want to cause trouble. I want to be able to move up the kernel chain and perhaps enjoy some of the other goodies that are a part of 2.6.24 kernels. However, I can't do that if one of my basic necessities, wireless networking, is effectively removed from my machine when I attempt to move to the latest and greatest kernel versions. Once again, please know, I am not here to offend. I didn't make this bug report just to pull your chain, and the chains of others. I made it because I want functional wireless networking. I don't think that's too much to ask, especially when the older kernel gives it to me. Thanks for your time and consideration, and once again, I apologize for my word choice. Blessed be! Pappy
Created attachment 143473 [details] Current .config file for kernel version 2.6.22.17 This is the current .config for the machine in question: Compaq Presario C504US laptop (1.86 GHz Celeron, 1G RAM, 120 SATA HDD, Optiplex AD-7530B DVD burner, Realtek RTL-8139 NIC, Broadcom BCM94311MCG W/L adapter, Intel HDA audio and Intel 945 video with wide screen display).
OK, so this is primarily a ndiswrapper issue. If you'd like to work on getting the native drivers working (b43/b43legacy) then please open a new bug for that.
(In reply to comment #11) > OK, so this is primarily a ndiswrapper issue. > > If you'd like to work on getting the native drivers working (b43/b43legacy) > then please open a new bug for that. > I can do that. Would it also be prudent to file a bug on ndiswrapper as well? If so, do I file it here, or do I file it with ndsiwrapper, or both? Blessed be! Pappy
(In reply to comment #11) > OK, so this is primarily a ndiswrapper issue. > > If you'd like to work on getting the native drivers working (b43/b43legacy) > then please open a new bug for that. > There is already a bug reported for that. I am going to check it out, and see if it helps my situation. Thanks for your time and consideration. Blessed be! Pappy
I've assigned this bug to be used for the ndiswrapper problem, please don't file another for that unless explicitly asked to. 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.
(In reply to comment #14) > I've assigned this bug to be used for the ndiswrapper problem, please don't > file another for that unless explicitly asked to. > Not a problem. > 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. > To that end, I am going to try setting up my other machine (which also has a Broadcom W/L adapter (4318)), since the sound problem listed in my other bug report (http://bugs.gentoo.org/show_bug.cgi?id=208712 ) is still a problem on this machine, and not on the one I am going to test. If the info in the other bug report holds true, I'll try it on this machine. That said, I would prefer to continue to use ndiswrapper, since it gives me the ability to change the settings for the W/L adapter at will. However, for purposes of seeing if the b43 drivers can be cajoled into working, I'll try the fix listed in this bug (http://bugs.gentoo.org/show_bug.cgi?id=208251 )...assuming I have problems, which I have no reason to doubt I will. Thank you for your time and consideration... Blessed be! Pappy
UPDATE: I just tried the fix in the above listed bug. It did not work. Therefore, I am opening a new bug specifically on the b43 drivers in both 2.6.24 and 2.6.24.2 Blessed be! Pappy
Workaround for this bug was described here: http://bbs.archlinux.org/viewtopic.php?pid=330927 Short version: My system is HP nx7400 with broadcom ethernet (b44) and wireless (bcm4311 => b43, b43-legacy). Workaround - you have to load ndiswrapper BEFORE ssb: - compile kernel with: - ssb as modules (Sonics Silicon Backplane support) - b44 as modules - usb as modules (or forbid usb ohci - didn't try, but it should work) - blacklist ssb, b44, ohci_hcd - compile ndiswrapper (mine is 1.52) - set autoloading in this order: ndiswrapper, b44. Now wlan0 should be visible in iwconfig. Long version: The problem is, that ssb module is used for b43, b43-legacy and b44. When b44 is loaded, ssb comes up as its dependency and ocupies wifi device. When ndiswrapper is loaded, it is loaded ok, but it can't grab wifi, so wlanX is not listed in iwconfig. I should note, that b43 works ok for me, BUT it does not handle hibernate: - boot - load b43 - unload b43 - hibernate - unhibernate - load b43 and hang forever. So I think it is not ndiswrapper's fault, but it is a bug in the mainstream kernel module: ssb. If you look at the sources of ssb, it contains some interesting comment in b43_pci_bridge.c: /* * Broadcom 43xx PCI-SSB bridge module * * This technically is a seperate PCI driver module, but * because of its small size we include it in the SSB core * instead of creating a standalone module. I did not try to hack this kernel module and remove b43 part from it to see, if that would help. It is pain in the ass to have it combined this way, because you have to play with blacklisting etc. to prevent udev loading ssb before ndiswrapper. Oh, by the way, this bug cost me 3 man days. Quite expensive :-/
Created attachment 144452 [details] kernel config working for ndiswrapper I'm using tuxoince-2.6.24-r2. I can hibernate and wifi is working.
(In reply to comment #17) > Workaround for this bug was described here: > http://bbs.archlinux.org/viewtopic.php?pid=330927 > > Short version: > My system is HP nx7400 with broadcom ethernet (b44) and wireless (bcm4311 => > b43, b43-legacy). > Workaround - you have to load ndiswrapper BEFORE ssb: > - compile kernel with: > - ssb as modules (Sonics Silicon Backplane support) > - b44 as modules > - usb as modules (or forbid usb ohci - didn't try, but it should work) > - blacklist ssb, b44, ohci_hcd > - compile ndiswrapper (mine is 1.52) > - set autoloading in this order: ndiswrapper, b44. > Now wlan0 should be visible in iwconfig. > > Long version: > The problem is, that ssb module is used for b43, b43-legacy and b44. When b44 > is loaded, ssb comes up as its dependency and ocupies wifi device. When > ndiswrapper is loaded, it is loaded ok, but it can't grab wifi, so wlanX is not > listed in iwconfig. > > I should note, that b43 works ok for me, BUT it does not handle hibernate: > - boot > - load b43 > - unload b43 > - hibernate > - unhibernate > - load b43 and hang forever. > > So I think it is not ndiswrapper's fault, but it is a bug in the mainstream > kernel module: ssb. > > If you look at the sources of ssb, it contains some interesting comment in > b43_pci_bridge.c: > /* > * Broadcom 43xx PCI-SSB bridge module > * > * This technically is a seperate PCI driver module, but > * because of its small size we include it in the SSB core > * instead of creating a standalone module. > > I did not try to hack this kernel module and remove b43 part from it to see, if > that would help. It is pain in the ass to have it combined this way, because > you have to play with blacklisting etc. to prevent udev loading ssb before > ndiswrapper. > > Oh, by the way, this bug cost me 3 man days. Quite expensive :-/ > The only problem with your fix is that I don't load ssb at all. It is disabled in my kernel setup. My wired NIC (which works fine under 2.6.24.2) is a Realtek 8139. Is ssb supposed to load in order for ndiswrapper to work? Is that what you are saying? If so, I can set it up. Thanks for the info. I might just see if loading ssb will make ndiswrapper work later on this evening. Blessed be! Pappy
> The only problem with your fix is that I don't load ssb at all. It is disabled > in my kernel setup. My wired NIC (which works fine under 2.6.24.2) is a Realtek > 8139. Is ssb supposed to load in order for ndiswrapper to work? Is that what > you are saying? If so, I can set it up. > No, I don't say that. My ndiswrapper works without ssb. I need ssb for my wired network, nothing more.
> No, I don't say that. My ndiswrapper works without ssb. I need ssb for my wired > network, nothing more. > OK, well, I don't load ssb at all. It's not even made into a module. According to ndiswrapper -l, the ndiswrapper module is installed, and there is no other driver competing for the adapter. Well, I'm going to see if I can make it fire manually. I got pretty good at it with the last bug. Thanks for your information. Blessed be! Pappy
I am wondering if there has been any progress, or what my next step should be for this bug. Please let me know so this bug can get fixed. Blessed be! Pappy
This bug should really be closed. Ndiswrapper is known to not work with the 2.6.24 kernel since the kernel developers purposely made it that way, but then restored it's functionality in 2.6.25-rc4. Read all about the whys and wherefores here -> http://kerneltrap.org/Linux/NDISwrapper_and_the_GPL?page=1 And another article on the subject if you're still interested -> http://lwn.net/Articles/271762/ Perhaps we can have the ndiswrapper ebuild error out in an informative way if a 2.6.24* kernel is detected. Bob, you should either unmask and upgrade to kernel version 2.6.25, or stick with a kernel version smaller than 2.6.24 and wait until 2.6.25 goes stable. No problems here so far using 2.6.25.3
(In reply to comment #23) > This bug should really be closed. > > Ndiswrapper is known to not work with the 2.6.24 kernel since the kernel > developers purposely made it that way, but then restored it's functionality in > 2.6.25-rc4. > > Read all about the whys and wherefores here -> > http://kerneltrap.org/Linux/NDISwrapper_and_the_GPL?page=1 > > And another article on the subject if you're still interested -> > http://lwn.net/Articles/271762/ > > Perhaps we can have the ndiswrapper ebuild error out in an informative way if a > 2.6.24* kernel is detected. > > Bob, you should either unmask and upgrade to kernel version 2.6.25, or stick > with a kernel version smaller than 2.6.24 and wait until 2.6.25 goes stable. > > No problems here so far using 2.6.25.3 > I have no more .24 kernels on my system. As far as I am concerned, this bug can be closed. I was never all that hot on that series anyway. I can get ndiswrapper to work with .25 version kernels, but it likes to take it's time starting properly. Once the interface starts, it's as solid and sure as it ever was with the .22 kernel family. That's a really big plus in my book. Anyway, I'm going to mark this bug as
...as WONTFIX since I don't want to touch the ndiswrapper debate with a ten foot pole. That was some interesting reading. Personally, I think it was a total bogart move not to give a warning, but at least they came back around...this time. Thanks for everyone's help Blessed be! Pappy
