Need help getting Broadcom BCM43228 working on Jessie

Getting your soundcard to work, using Debian on non-i386 hardware, etc

Need help getting Broadcom BCM43228 working on Jessie

Postby Breaking Jessie » 2015-02-01 21:07

It's for a Lenovo x140e laptop with Jessie. Specs online commonly describe the laptop as having BCM43142 but I ran "lspci -knn | grep -iA2 net" and the output says I have BCM43228. Not sure why there is that discrepancy but I am assuming the latter, BCM43228, is what is actually in my computer.

Anyway, I originally installed "broadcom-sta-common", "module-assistant", and "broadcom-sta-source", but that resulted in nothing happening so I think I am going to "apt-get purge" those and start over.

I know about the Debian wiki "wl" page but it only provides instructions up to Wheezy, not Jessie. And I read many previous threads but they often contain different instructions and mixed results, plus there are many moving parts here (kernel, OS, driver, packages) and the instructions seem to be changing over time, so I thought I'd make a new thread and get the latest advice about what to do.

I was thinking I'd install these:

1) firmware-realtek
2) wireless-tools
3) module-assistant
4) broadcom-sta-common
5) broadcom-sta-dkms
6) broadcom-sta-source

Does the order of install for those above packages matter at all? Do I need the kernel header or not and, if so, how do I use it? Are there any other packages I need? What is the process? Please help.

Output of "lspci -knn | grep -iA2 net"
Code: Select all
01:00.0 Network controller [0280]: Broadcom Corporation BCM43228 802.11a/b/g/n [14e4:4359] Subsystem: Broadcom Corporation Device [14e4:0607] 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 07) Subsystem: Lenovo Device [17aa:2219] Kernel driver in use: r8169
I use 64-bit Debian Buster with Plasma 5 DE.
Breaking Jessie
 
Posts: 28
Joined: 2013-10-26 20:45

Re: Need help getting Broadcom BCM43228 working on Jessie

Postby Head_on_a_Stick » 2015-02-01 21:39

I would go by the `lspci` output rather than online specifications.

Accordingly, you will need the wl driver:
https://wiki.debian.org/wl#Debian_7_.22Wheezy.22

EDIT: Sorry OP, I didn't read your post properly...

@stevepusser: thanks for picking up the pieces I dropped (again) :)
Last edited by Head_on_a_Stick on 2015-02-01 22:06, edited 1 time in total.
Black Lives Matter

Debian buster-backports ISO image: for new hardware support
User avatar
Head_on_a_Stick
 
Posts: 12486
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: Need help getting Broadcom BCM43228 working on Jessie

Postby stevepusser » 2015-02-01 21:59

Yes, the dkms packages did nothing because of no kernel headers--maybe other missing compilers, too.

Simple fix:

install module-assistant

open a terminal and execute
Code: Select all
su -c 'm-a prepare'


Now you will be ready to compile kernel modules.

The kernel header use is transparent: if you have them, the builds should work.

Also, the Wheezy wiki clearly states to install the headers. This is unlikely to change for quite some time.

Debian 7 "Wheezy"

Add a "non-free" component to /etc/apt/sources.list, for example:

# Debian 7 "Wheezy"
deb http://http.debian.net/debian/ wheezy main contrib non-free

Update the list of available packages. Install the relevant linux-headers and broadcom-sta-dkms packages
:
MX Linux packager and developer
User avatar
stevepusser
 
Posts: 11982
Joined: 2009-10-06 05:53

Re: Need help getting Broadcom BCM43228 working on Jessie

Postby Breaking Jessie » 2015-02-02 05:19

Thanks very much. Everything worked smoothly. I installed "broadcom-sta-dkms" but not "broadcom-sta-common" and "broadcom-sta-source", because as I understand it those two latter packages are an alternative way of installing the driver seperate from the dkms approach?

One last question: dkms will automatically put the Broadcom module into the kernel every time that Debian upgrades the kernel, right? But if the driver ever reaches the mainline kernel would dkms still automatically attempt to place "broadcom-sta-dkms" into Linux and run into problems at that point?

Thanks again.
I use 64-bit Debian Buster with Plasma 5 DE.
Breaking Jessie
 
Posts: 28
Joined: 2013-10-26 20:45

Re: Need help getting Broadcom BCM43228 working on Jessie

Postby v&n » 2015-02-04 04:19

Breaking Jessie wrote:One last question: dkms will automatically put the Broadcom module into the kernel every time that Debian upgrades the kernel, right? But if the driver ever reaches the mainline kernel would dkms still automatically attempt to place "broadcom-sta-dkms" into Linux and run into problems at that point?

Yes to both questions.

Would be a good idea to mark your thread as [Solved] now. :)
v&n
 
Posts: 624
Joined: 2015-02-04 02:57

Re: Need help getting Broadcom BCM43228 working on Jessie

Postby Breaking Jessie » 2015-02-08 06:24

Thanks v&n. If I'm understanding correctly, at some point in the future the driver might make it into the mainline kernel, and if that happens and I upgrade to the newer kernel, then there will be some conflict because dkms is still attempting to place the module into the kernel which now already comes with the driver. So I should be monitoring what goes into new kernels and proactively prevent dkms from adding the module should that need arise. Seems a bit perplexing that the system would actually work that way.

Edit: I'll mark this as solved in a few days so that before then I give others a chance to see that I still have questions.
I use 64-bit Debian Buster with Plasma 5 DE.
Breaking Jessie
 
Posts: 28
Joined: 2013-10-26 20:45

Re: Need help getting Broadcom BCM43228 working on Jessie

Postby v&n » 2015-02-08 14:03

Breaking Jessie wrote:If I'm understanding correctly, at some point in the future the driver might make it into the mainline kernel, and if that happens and I upgrade to the newer kernel, then there will be some conflict because dkms is still attempting to place the module into the kernel which now already comes with the driver.

Actually the possibility of problem is very thin, and it shouldn't take more than a restart if a problem arises at all. Here's why -

The sta driver package that you are using now, blacklists the native drivers during its installation process. As such, even if the support for your card gets included in native drivers, they won't get loaded, so there won't be any conflict situation. The blacklisting is done for this very same reason - avoid possible conflict.

The only momentary problem (not lasting more than one reboot) that *may* arise is when the kernel gets upgraded, but the sta driver package is not. In this case, after the reboot that the system will prompt you for after kernel upgrade, the native driver (say, b43) will get loaded. Now dkms will detect the new kernel and will try to re-compile and reload the sta driver. This is where *sometimes* the system freezes sometimes - the exact moment when the native driver is unloaded OR if the sta driver is loaded before the native one is removed.

But even if this happens, all it would take is a reboot - hot reboot if absolutely necessary. On next boot, the native one won't be loaded (since the sta one blacklisted it) and there won't be any conflict.

There could be a few more 'If/Buts' but I don't think we need to think too much about this. Please do let us know if you have more questions though. :)
v&n
 
Posts: 624
Joined: 2015-02-04 02:57


Return to Hardware

Who is online

Users browsing this forum: No registered users and 8 guests

fashionable