Native Drivers for Broadcom Wireless
Forum: Networking
Topic: Native Drivers for Broadcom Wireless
started by: Juanito
Posted by Juanito on Jan. 17 2008,05:04
Looking at the < linux wireless b43 site >, it seems like the reverse engineered drivers for broadcom wireless devices are only for 2.6.22 and up.Does anyone know of patches for the drivers that would allow them to work with dsl-3.x and/or dsl-4.x - I've spent a long time searching without luck so far...
Posted by lucky13 on Jan. 17 2008,12:26
I'm using a card that requires the same driver and that's given me the same set of frustrations you have. The 2.6 bcm43xx driver, in my experience thus far, has been hit and miss. I tried it with one particular distro and it worked off the bat; then I used it on an updated and modified (light) version of the same distro (fresher kernel!) and I had to revert to ndiswrapper. The first one uses KDE and I don't. Not on that laptop anyway. I don't know what accounts for the difference, but I didn't care enough about it to inquire further because I wouldn't have used the light version even if it had worked (I have a different definition of "light").The distro I'm currently using on my laptop (maybe for not much longer) loads the bcm43xx module but it, too, fails. It works very well with ndiswrapper -- full scanning, can connect to hidden ESSID, WPA works, etc. -- but even though it's somewhat "light" in comparison to other distros it's still heftier than I care to run.
I can't say much about it right now, but I've been working on this issue and made a lot of progress yesterday. I have a couple things left to do before I can see if it's an improvement over what we have now, and just how much of an improvement it is. I also have a hectic schedule today so I don't know if I'll get far today. I'll do what I can and maybe there will be news one way or another shortly.
Posted by curaga on Jan. 17 2008,15:26
Hey, what's with all this secrecy?Everyone mentions they are up to something, but tell nothing more
Posted by lucky13 on Jan. 17 2008,16:51
| Quote |
| Everyone mentions they are up to something, but tell nothing more |
If I tell you, it wouldn't be a secret anymore.
Posted by lucky13 on Jan. 19 2008,16:03
I apologize for the delays. And for not succeeding with this. And for the length of this. I'll lay it all out in the open.I would modify my apology to "for not succeeding *yet*," but I'll get to why later in this rant. I haven't totally given up, but I'm resigned that it's probably going to take too much work to get it all working right.
The secret was supposed to be...
| Code Sample |
$ iwlist --version && uname -a iwlist Wireless-Tools version 29 Compatible with Wireless Extension v11 to v22. Kernel Currently compiled with Wireless Extension v18. Linux box 2.4.31dsl-2008.1 #1 SMP Fri Jan 18 15:05:13 EST 2008 i686 unknown |
Or with something "fresher" you can see below from the 16th.
The WE patches and WT update alone should've made a significant difference in support for various cards. Maybe they do with those that work easily in open source operating systems. Unfortunately, those patches were the easiest part.
I also wanted to update ndiswrapper (and wpa_supplicant) while I was at it. Like many other projects, ndiswrapper has abandoned 2.4. Worse, imo, ndiswrapper's later versions require gcc 3.4+. I had several choices, including scaling my plans down or getting carried away and trying to make a new build environment. My efforts were unsatisfactory regardless of what I tried.
| Code Sample |
| $ sudo modprobe ndiswrapper /lib/modules/2.4.31dsl-2008.1/misc/ndiswrapper.o: insmod /lib/modules/2.4.31dsl-2008.1/misc/ndiswrapper.o failed /lib/modules/2.4.31dsl- 2008.1/misc/ndiswrapper.o: insmod ndiswrapper failed |
I tried several variations to try and get it to work. I started at 2.4.36 but every version of ndiswrapper I tried acted screwy if it even loaded. I backed down to the WE17/18 patches on the 2.4.31 kernel using gcc 2.95. The above was the result. For every step forward, I've felt like I'm taking two back.
Or maybe more steps back:
| Code Sample |
| $ ls -l /lib/modules/ drwxr-xr-x 4 root root 4096 Jan 17 23:47 2.4.31 drwxrwxr-x 7 root root 4096 Jan 17 13:22 2.4.31-original drwxr-xr-x 4 root root 4096 Jan 17 15:52 2.4.31L13DSL drwxr-xr-x 4 root root 4096 Jan 16 21:32 2.4.36 drwxr-xr-x 3 root root 4096 Jan 18 16:08 2.6.23.14 -rw-rw-r-- 1 root root 5002 Sep 3 07:47 modprobe.conf -rw-r--r-- 1 root root 5002 Jan 17 13:22 modprobe.conf-DSL |
I have a couple more things I want to try before I totally abandon this. I'm not in despair, just wising up to the reality that 2.4 is history. I wrote in a note the other day that it's going to be a lot easier going forward to find 2.6 patches for deprecated legacy hardware issues than it will be to find backports for newer hardware in 2.4. Nearly all of these issues we're facing -- VIA southbridge, wireless technologies, etc. -- aren't issues in the 2.6 world.
But they're unresolved issues that are going to be increasingly more difficult to address going forward. Complicating matters is that nobody is really on the same page if they even have the 2.4 book open anymore. If they haven't abandoned 2.4 in newer releases (as ndiswrapper has; their last 2.4 version is 1.48), they have myriad requirements that don't always fit what others are doing (such as needing gcc 3.4+ and new c libraries).
Short of resorting to rebuilding DSL's base, we're nearing the end of the road with what we can do with it. What worked great with everything in the era of Knoppix 3.4 and Debian Woody is a pain in the neck now.
Why do that? Why rebuild? It seems counterproductive to me build a fresh base just to use a kernel that everything and everyone else is increasingly abandoning. If there's a rebuilding effort, it needs to be with what's current and will be worth the effort. You do that looking forward, not backward. That means 2.6.
I don't know to what significance/benefit the WE17/18 patches make over what DSL already has. Maybe those of you with cards that don't require ndiswrapper would realize some benefit from better scanning and improved WPA. The problem for me is ndiswrapper. I can't test beyond ndiswrapper with any of my new kernels. I loaned a Prism-based USB adapter to a friend on vacation and I sold my other card. I'm down to a bcm43xx that only seems to work with ndiswrapper in 2.6 (I installed Knoppix 5.1 on a spare partition last night; the bcm43xx driver loads as soon as I insert the card, but it doesn't work; I used ndiswrapper to load the inf and it started broadcasting dhcp -- to a neighbor's unhidden, unencrypted essid -- as soon as I ran modprobe). I'd get another card, but I can get it working the way I want (albeit with ndiswrapper) in 2.6: I can connect to hidden SSIDs, I can use WPA, I can scan adequately, etc.
I don't know if anyone else wants to mess with this. Maybe I missed something obvious, maybe I screwed something up. I'm human. All three (except the 2.6 kernel) are packaged, and iirc only one has cloops (untested because I was stuck with bleeping ndiswrapper). All were "make oldconfig" against the dsl.config file, with an exception that I remembered to leave some of the more obscure and unsupported (in DSL anyway) fs modules out of the last 2.4.31 compile. If you want to mess with it, let me know. I've just about run out of ideas and patience.
Posted by curaga on Jan. 19 2008,21:53
It happens. In fact I had a similar fight today with Gnucash.First 15+ gnome libraries went along really smoothly. Then came the show stopper, gnome-print.
I fought with that for about 5 hours until I finally beat it. But even if I did get it to compile, I didn't get it to act nicely (fsckin autotools!). No matter what I did, libtool/auto* always removed the freetype during linking. But I was close. I could stand that, since after finishing no-one would ever compile against these.
Then, finally, gnucash. After messing with configure for 2 hours, the actual compile was error-less.
Phew. Not. The damn system seemed to do it, but it didn't work after installation. Because the build system had silently decided to not build shared libraries at all. Despite they being the only thing that keeps gnucash going. Around here I finally decided to ditch it, once and for all.
And then, 15min after rm -rf, I miraculously find the cure for the shared library problem, that was nowhere to be found during the problem. So tomorrow again.
Lessons learned: try again. And the fact I hate autotools.
Why don't you try the last ndiswrapper that supports 2.4?
Posted by lucky13 on Jan. 20 2008,05:41
| Quote |
| Why don't you try the last ndiswrapper that supports 2.4? |
That was one of my goals. The later (and even earlier, fwiw) versions of ndiswrapper require gcc 3.4 or higher, etc. It would require a fix of many things from the ground up just to ride out the last gasps of 2.4. I'm resigned to accepting that the time for doing that is past. I'm also convinced after the time I spent measuring my results in a similar environment this afternoon that the benefits would be marginal and uninspiring had I succeeded.
That's the problem working with a hack to get a closed-source piece of ___ ("hardware" or whatever word you think is suitable) working in an open source environment. Whether ndiswrapper is a good or bad hack is a subjective call. I have no complaints with it using what I am right now -- kernel 2.6.22.14 with WE22, WT28, and ndiswrapper 1.49. It works almost as well as in the OS for which the card was intended to work. Maybe it will get even better with more development.
It's another story in 2.4. What works well enough for some now in 2.4 is fine, but it won't get any better than it already is for *anyone* because ndiswrapper and wireless extensions developers have abandoned it.
Which gets back to the main point of my answer to your question. Why work at making a small improvement on a dead end when it'll take the same or less effort to get a *lot* more improvement with greater chance of even more progress?
Posted by roberts on Jan. 20 2008,06:34
Hang in there. I am working on a 2.6. It needs to work for me before I ask for some help from the community.