(SOLVED) Broadcom 4311 issue with PCLOS 2012

[gseaman]

Is there any changes we can make to the packages or the hardware detection to fix this?
(Terry? )

Galen

[dsonyay]

I can see your confusion too. It comes from this:

Quote from: dsonyay on October 24, 2012, 08:39:52 PM

....

Now I went into PCC > Network & Internet > Set up a new network interface > Wifeless (WiFi) > wlan0:wlan0

From this point I went to the folder holding the .inf file for the broadcom 4311 driver I downloaded from here:
http://download.cnet.com/Broadcom-4311-4312-WLAN-Driver-v4-170-25-19-zip/3000-2112_4-200920.html

After this my wifi worked.

Dsonyay, could you clarify that? Did you selected "use Windows driver (with ndiswrapper)" when you configured the card, or did you select the default Linux driver?

Both options can be used, but they are mutually exclusive. That is why we are confused, on which one was the option that eventually worked for you.

In any case, anyone having this same problem can look at your post, follow your steps, and get it working; one of the two methods should work.
Explaining which one worked for you will be just to make the post more clear.

Good job in getting it working by the way.

Hi, Sorry for the delay.  I'll be honest, I did so many attempts to get this friggin wireless up over a period of 5 days, I almost can't remember what I did now, and it's been three days since I had it up and running.  Only by looking at my last post can I remember vaguely what I did.

I'll attempt to clarify....
The reason I choice "wlan0:wlan0" was because if I chose to install a driver with ndiswrapper (while in PCC) I'd get an error message (can't remember what it was, but seems I remember something about an interface issue)

If I tried to choose the first option,  the Broadcom BCM4311, I'd get the error about "can't load with wl" or something like that.   

So I chose the wlan0:wlan0, and it asked me to choose a driver from a file (which I had downloaded and extracted earlier from the broadcom site).  It then worked.   

But the weird thing was my wifi connection was now showing as ETH01 and not WLAN.

I then removed ALL connections, ETH0, ETH1, and WLAN, and I started from scratch.  I rebuilt my Eth0 connection and then I rebuilt my Wifi.  I was then asked to choose a driver with NDIS wrapper (the only option I could choose at this point) ... I pointed to the folder I had my Broadcom .inf file, and this time it worked. And now I have Wifi showing as "WLAN0"  and my wired ethernet as Eth0.

I did remove the most current dkms-broadcom-wl package and replace with the older one(5.60.48.38), but it was not in synaptic.  Had to download it and load the rpm myself.   The rpm would not run until I completely removed the latest kernel for 2012.  I had the latest kernel loaded, but was using the older one when booting up.  RPM would not work until I actually removed the newer kernel from my laptop.

I hope I'm not causing more questions now. 

[TheGhost]

Dsonyay.

Thanks for the clarification, I believe it's all clear now. In your case, it was ndiswrapper which in the end got your card working; son anyone having the same problem can try your solution as well.
And the key to the solution seems to be removing the current Broadcom dkms from the kernel, because it causes the card not to work while installed.

Good job!

[dsonyay]

Thanks.. hopefully this might help someone, or at least get them in the right direction. 

Will running an old kernel in PCLOS 2012 cause me problems later on when upgrades come out?  I was thinking about this last night..  I was thinking I might need to be very careful when doing the upgrades every couple of weeks.  Or if I try to upgrade some of the packages, having the old kernel might cause complications. 

I'm glad I'm up and running again.  PCLOS is such a nice OS to run. 

[TerryN]

Will running an old kernel in PCLOS 2012 cause me problems later on when upgrades come out?  I was thinking about this last night..  I was thinking I might need to be very careful when doing the upgrades every couple of weeks.  Or if I try to upgrade some of the packages, having the old kernel might cause complications.  

A couple of months ago the package glibc-headers-devel-3.2.18 was released into the repo.  The effect of this is that all packages built since then are built on the assumption of a 3.2.18 kernel.  So it is possible that packages will be built which use functions which are not present in older kernels and will therefore fail.  I would say it is very small chance but a chance nevertheless.  For example, we already know that webcam apps (and other apps which use V4L) could be affected if they are updated.

Terry

[TerryN]

Is there any changes we can make to the packages or the hardware detection to fix this?
(Terry? )

To be honest, you would think that the wl driver was the right choice.  After all, you'd expect Broadcom to write decent drivers for their chipsets     However, we are not the only distro that has seen problems with this driver.

Personally, before making changes I would want to have more idea of the success/failure proportions for the different drivers.  If it's 50-50 there's not much point changing ... it would just annoy the other 50% of users who are not already annoyed  

Terry.