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.

--------------"It felt kind of like having a pitbull terrier on my rear end."-- meo (copyright(c)2008, all rights reserved)

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 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.

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.

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.

--------------"It felt kind of like having a pitbull terrier on my rear end."-- meo (copyright(c)2008, all rights reserved)