ssb interferes with ndiswrapper (bcm4311, bcm4318)

Bug #218763 reported by dkoes on 2008-04-17
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Nominated for Hardy by matt_hargett
Nominated for Intrepid by Pablo Castellano

Bug Description

This is a continuation of bug#197558 ssb module breaks BCM4328 with ndiswrapper (regression from 2.6.24-10)
which refers to a very specific issue, but became a dumping ground for a larger issue. Specifically, it appears that ssb prevents ndiswrapper from getting control of the wireless card. Since for several people the default b43 driver does not work, or does not work well, it is desirable to use ndiswrapper instead.

There is a workaround, which is to have a startup script modprobe -r b43,b44,ssb,ndiswrapper and then modprobe ndiswrapper,b43,b44, but this isn't a very elegant solution.

Wrath (alan1212) wrote :

I have the same issue with a bcm4318 in hardy. The ssb module would not allow ndiswrapper to take control over the wireless card without messing with the modules after boot.

SireeBob (sireebob) wrote :

Thanks for the new report. I don't really understand why the previous one couldn't be expanded to include bcm4311 and bcm4318 because it's the same problem, but whatever gets this bug the proper attention.

I have a bcm4318 and the same problem here (I'm on Kubuntu 8.04 Beta). This is definitely a regression from Gutsy. Argh. I'm using ndiswrapper because b43 offers a very unstable connection, just like bcm43xx. It was too unstable for me to even download the driver I needed for ndiswrapper, so I had to plug in.

Any ideas for a clean way to make ndiswrapper load before ssb, solving this problem?

dkoes (koes) wrote :

The workaround I'm currently using is just removing ssb, b43, and b44 altogether. My initial attempts at doing this (adding them to the blacklist file) failed (ssb insisted on loading) but somehow, after reinstalling the kernel, it started working.

SireeBob (sireebob) wrote :

I gave in and used an init script with info from and . A better solution or a fix before release would be nice.

hello.. I have ubuntu 8.04 beta plus all the upgrades and I am affected by this bug as well. I have a BCM4311 card and I needs ndiswrapper as the native driver works fine if close to the router, but perform badly when little far away...

I never got problems till ubuntu 7.10, but now I have to manually remove the modules and then modprobe them back as stated in the bug description to have the card working.
Can someone tell me in which script should I add the "modprobe -r" & "modprobe" commands to have it automatically working at start-up??

Thanks, Antonello

Tayroni Alves (tay-fisica) wrote :

Confirmed on Hardy Release Candidate. I have a bcm4311.

I am no longer affected by this bug. All I done was to remove (modprobe -r) b43,b44,ssb,ndiswrapper and then modprobe them back.
I didn't need to place this commands in any init script.. with my surprice, I got everything working even after reboot.

Confirmed on a clean install of Hardy final (both i386 and amd64 variants tried). Very [censored] annoying.
Fixed with adding "rmmod ssb && rmmod ndiswrapper && modprobe ndiswrapper" to /etc/rc.local, BUT once my laptop boots it takes a looong time trying to connect to the wireless network, which eventually fails. If I try again by clicking on the network manager applet and selecting the default network, it connects nearly instantly though.
On Gutsy my wireless (once ndiswrapper was up and running) had been more reliable than on Vista (which frequently refuses to connect because the HP driver sucks, ndiswrapper uses an older Dell driver, which appearently works better on a HP laptop. WTF).
I've heard in other discussions of this problem that the hardy kernel was compiled with an option which always loads ssb. If this is true, please get me a kernel update with that option off!

Larry Finger (larry-finger) wrote :

If you want to use ndiswrapper with a BCM43xx card with Hardy, you _MUST_ blacklist ssb. The reason is that ssb owns the BCM43xx PCI ID's. It then uses internal information in the card to decide whether to load b43 or b43legacy depending on the age of the equipment.

With the bcm43xx driver, the ssb driver was built in, not separate.

Blacklisting ssb (in /etc/modprobe.d/blacklist) has no effect, the ssb module gets loaded anyway.
Blacklisting b43, b43legacy and b44 also does not help - this is with bcm43xx still blacklisted as per default.

Now fixed by blacklist the ssb module - in the initrd image, not on the regular system.

John Rose (johnaaronrose) wrote :


How do you blacklist the ssb module in the initrd image?

@ John Rose

just worked round this myself. See my post on the ubuntu forums for details of how to rebuild the initrd on Hardy

There hasn't been any recent activity in this bug report and we were wondering if this is still an issue? The Ubuntu kernel team is actively working on the upcoming Intrepid Ibex 8.10 release. If you could please test the latest Alpha release for Intrepid it would be much appreciated - . Please let us know your results. If the issue still exists, please also provide the appropriate debugging information as outlined at . Thanks in advance.

Changed in linux:
status: New → Incomplete

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.


2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Andreas (andreas-kotowicz) wrote :

I'm still having this problem with kernel 2.6.27-2-generic. The only solution to prevent this problem to happen was to black list the ssb driver in the initrd file that come with the kernel.

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: Incomplete → Triaged

In my opinion, #227158 is not a bug duplicate but a related one.

Przemek K. (azrael) wrote :

What about bug #188621? Is it a duplicate then? Or reverse?

description: updated
yazdzik (yazdzik) wrote :

Dear Friends,

Issue with 4312(01) ndiswrapper remains for me the same in ibex, 2.6.27, grml rc, 2.6.26-7, and my own debian unstable, which is very stable indeed, using 2.6.27-4.

Thus, while related or not to the above captioned bug, it is my experience than ssb and ndiswrapper conflict, and blacklisting ssb, b43, and b44, still seems to be the least elegant, but only effective workaround for many of us.

All good wishes,


Greg (greg-thesantosfamily) wrote :

I get this on 2.6.27-8 as well. SSB interferes with ndiswrapper. I cannot seem to blacklist ssb. I use b44/ssb for my wired link BCM4401. I just want ndiswrapper to run my wireless and leave ssb and b44 alone. What do I do?

AnAnonymousKiller (iggy-mon) wrote :

Dell Vostro 1500
Ubuntu 8.10 Intrepid Ibex

   uname -r
  0c:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n (rev 03)
   lspci -n
  0c:00.0 0280: 14e4:4328 (rev 03)

Module 'ssb' inhibits ndiswrapper from functioning properly. Blacklisting 'ssb' in '/etc/modprobe.d/blacklist does not work as it is being called by module 'b44'.
   lsmod | grep ssb
               ssb 46340 1 b44

Unload module 'b44' which also unloads module 'ssb'...
   sudo modprobe -r b44

...then unload and reload module 'ndiswrapper'...
   sudo modprobe -r ndiswrapper
   sudo modprobe ndiswrapper

...and finally reload module 'b44'
   sudo modprobe b44

All this is assuming that you followed the directions here to install ndiswrapper...

Footnote: i did not have to blacklist modules 'bcm43xx', 'b43', 'b43legacy' or 'ssb'. Remember, blacklisting 'ssb' won't work anyway as it's being called by another module.

Also: lsmod | grep ssb would show any modules calling 'ssb'. I would assume, but not be 100% certain, that any other listed modules would also have to be unloaded before restarting the 'ndiswrapper' module and be reloaded afterwards.

Lastly: it seems that the order in which the modules are loaded is what matters and not that any one module or another is conflicting. Is there any way to load module 'ndiswrapper' BEFORE any module that lists 'ssb' for lsmod | grep ssb?

Przemek K. (azrael) wrote :

If blacklisting ssb doesn't work for you then run sudo update-initramfs -u
See bug #227158 for details.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to for more information. Thanks.

Przemek K. (azrael) wrote :

Can anyone check if this is still an issue on Ubuntu 9.10?

Tim (tim-cooper) wrote :

Sadly I can confirm it's still an issue on Ubuntu 9.10. Despite blacklisting ssb after each reboot it's back again and no wifi.... I'll be trying one of the not-so-nice work arounds suggested above.

Anand Hebbal (hebbal1273) wrote :

It is still a problem on Ubuntu 10.04 :(

felicity (info-herx) wrote :

I can confirm that the problem persists in 10.04 or actually has become a problem since upgrade any ideas how to restore it easily to its glorious past would be useful

dkoes, this bug report is being closed due to your last comment regarding this being fixed by reinstalling the kernel. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

Changed in linux (Ubuntu):
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers