I have a Linksys WPC300N v1 “Wireless-N Notebook Adapter” which uses the Broadcom 4329 chipset. Is there a way to troubleshoot and configure this card to use wl, b43, ssb? Preferrably via CLI. I have a couple years of CLI experience in Debian/derivatives (but only in my spare time :’().
I have this card recognized and running adequately in Debian (and derivatives) using the ‘wl’ driver (sometimes supplied by debian.org, other times by broadcom.com). The one hint at a solution for this particular card/chipset I have found searching the OpenSUSE (SuSE for short?) forum points me to using ndiswrapper, which I’ve never used nor care to if it requires wine. I’m trying to ultimately connect to a b/g/n WPA-1 TKIP wlan.
lsmod | grep ‘ssb’ returns nothing (neither do ‘b43’ or ‘wl’) but ‘pcmcia’ returns:
pcmcia_core 41748 3 pcmcia,yenta_socket,rsrc_nonstatic
When configuring this card in Debian, I first plugged in the card which resulted in some hard disk activity but the LED was not lit. After installing the driver, the LED came on but no network. After configuring the network, it works ‘adequately’ (no roaming mode) using the wpa_supplicant package and is readily identified during init.
Thanks in advance for your consideration. This is not mission critical by any means so I’m not in a hurry and willing to try almost anything. However, this is an old laptop so I’m even somewhat surprised that KDE4 is running as well as it is (KDE 3.5.10 runs quite well, which is more than I can say for the latest Gnome DE; xfce “screams” relatively). Dell Latitude C-610 PIII-M 1.2 GHz 512 KB cache 512 MB RAM (YaST2 reports this as a C-640 but this does not agree with the BIOS splash). The display is an ATI Radeon LY using the ‘radeon’ server (default). I don’t do compositing here.
Yes, actually I did that last night and rebooted at least twice since (checking things in Debian and I haven’t set up a virtual machine yet).
Module ‘ssb’ used to load and it’s listed in YaST2 Hardware but not in lsmod. ‘ssb’ and the usual suspects are blacklisted now (by virtue of YaST2 – I didn’t do it myself).
Thinking that the interface with the LED may be suspect I checked some more but still believe my session is not “seeing” the ‘eth1’ or ‘wlan0’ part of ‘…4329’.
“sudo /sbin/lspci -n” yields:
03:00.0 0280: 14e4:4329 (rev 01)
(well, the relevant part anyway)
On 03/13/2010 01:36 PM, HunkirDowne wrote:
>
> caf4926;2135886 Wrote:
>> Have you installed the broadcom driver from Packman?
>
> Yes, actually I did that last night and rebooted at least twice since
> (checking things in Debian and I haven’t set up a virtual machine yet).
>
> Module ‘ssb’ used to load and it’s listed in YaST2 Hardware but not in
> lsmod. ‘ssb’ and the usual suspects are blacklisted now (by virtue of
> YaST2 – I didn’t do it myself).
>
> “/etc/modprobe.d/50-broadcom-wl-blacklist.conf” reads:
> # modules blacklisted for broadcom-wl
> blacklist bcm43xx
> blacklist ssb
> blacklist b43
> blacklist ndiswrapper
>
> Thinking that the interface with the LED may be suspect I checked some
> more but still believe my session is not “seeing” the ‘eth1’ or ‘wlan0’
> part of ‘…4329’.
>
> “sudo /sbin/lspci -n” yields:
> 03:00.0 0280: 14e4:4329 (rev 01)
> (-well, the relevant part anyway-)
Does lsmod list wl? On Broadcom’s site, theysay that the wl driver supports
“Broadcom’s BCM4311-, BCM4312-, BCM4313-, BCM4321-, and BCM4322-based hardware.”
What does “lspci” say for the model? Perhaps they do not cover your device. You
can reach Broadcom at linux-wlan-client-support-list@broadcom.com.
So while the ‘4329’ is not listed explicitly as being supported, “/usr/share/doc/packages/broadcom-wl/README.txt” reads: “Cards not listed here may also work.” Furthermore, I have this card working with the ‘wl’ module on this computer in Debian but only after some configuration.
I’ve searched for guidance in setting this card up in OpenSUSE using ‘wl’ but have not yet found anything definitive. That said, just because it works in Debian doesn’t rule out that it may not work in OpenSUSE. I don’t recall which derivative of Debian I was using (Mepis? Mint?) but I could not get the card to work from the command line but did get it to work from the graphical interface. Debian worked fine from the command line as did Ubuntu, but honestly the easiest way in Ubuntu is the graphical method but the connection is never 100% stable. The only time my connection was dropped in Debian was due to my 17-yo daughter “fixing” her connection by rebooting the modem. (Mac user!)lol! (implied derision here is purely sarcastic–she’s just CLI-challenged).
But when hacking the files in Debian, I never had a hang-up here but I have an idea that may (should) kick me off so I’ll get back at some point.
(idea: modprobe ssb out and wl in – I’ll have to review my notes as I don’t usually tickle the innards this low down.)[/size]
I am using the ‘debug’ kernel to boot. Once I first booted using ‘debug’ (vmlinuz-2.6.31.12-0.1-debug) the card’s LED lit up, lsmod showed ‘wl’ was loaded, and I configured the card using YaST2 but only after getting a warning and selecting ‘Traditional’ which released the hold NetworkManager apparently had on it.
I still have questions about a few things, though.
(1) Why debug and will I always have to use debug? Using the default (vmlinuz-2.6.31.12-0.1-default) does not work (LED not lit, ‘wl’ not loaded).
(2) I tried the CLI but that didn’t work. Would this have been because NetworkManager had it locked? What should I have done to check to see what had control over the WLAN settings?
My CLI routine that has worked in the past (or so I recall):
Sounds attractive. I will definitely check into this.
Even though I have this working, I would like to do this without the fuss in the future. I have a couple more laptops to “play” with and want to get my config pat on this one (tester) before putting it on a platform that I prefer to be more stabilized.
I did the above and got the same result in ‘debug’ but have not yet tried it in ‘default’. But I’m not sure what this is supposed to tell me quite yet. Obviously I will know the answer to that if I boot into ‘default’ and it doesn’t show. lol!
A couple of posts have crossed paths and I’ve declared this “solved” despite my many questions (posted above). Nonetheless, I’m wireless now.
On 03/13/2010 05:16 PM, HunkirDowne wrote:
>
> caf4926;2136079 Wrote:
>> Another option is add the kernel head repo and update
>> ‘Index of /repositories/Kernel:/HEAD/openSUSE_11.2’
>> (http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_11.2/)
>>
>> It had added support, without the need for added drivers.
>
> Sounds attractive. I will definitely check into this.
If you had a 14e4:4315 device, then these kernels would give you a native
driver, but for 802.11n devices such as your 4329, it will be at least 2.6.35
until they are supported by the b43 driver.
OK, maybe I’m slow but I’m a bit confused. I admit it’s probably just a case of being not yet versed in things openSUSE. I see in the posts above what appear to be potentially conflicting information and at the same time not quite sure what rpm I should download from ‘HEAD’ per caf4926’s post.
The post from caf4926’s suggests downloading a new kernel from (http://download.opensuse.org/reposit...openSUSE_11.2/) that would have drivers for Broadcom. The version I see here is 2.6.33-31.1 whereas I currently have 2.6.31.12-0.1 so I can see how this is an upgrade. However, per the post from lwfinger, the 4329 will not be supported until 2.6.35.
So I guess my questions are these:
(1) Will ‘HEAD’ (2.6.33-31.1) support my 14e4:4329 device?
(2) Which kernel family and type should I download?
If I were to guess at the latter, it would be the default from i586 (kernel-default-2.6.33-31.1.i586.rpm). Or do I compile from src? Or do I simply update my sources.list and key and then update and upgrade?
I’ve done some reading on the different repositories and have disabled all but the main four (plus maybe Packman). Nevertheless, I found no reference to ‘HEAD’ nor to some of the other repositories either searching the forum directly, via Google, or the external Google search results on the matter. Some I could easily guess by their name but wound up with about a dozen or so that were enabled before I read a post that suggested the main four only.
On 03/15/2010 12:36 AM, HunkirDowne wrote:
>
> OK, maybe I’m slow but I’m a bit confused. I admit it’s probably just a
> case of being not yet versed in things openSUSE. I see in the posts
> above what appear to be potentially conflicting information and at the
> same time not quite sure what rpm I should download from ‘HEAD’ per
> caf4926’s post.
>
> The post from caf4926’s suggests downloading a new kernel from
> (http://download.opensuse.org/reposit...openSUSE_11.2/) that would have
> drivers for Broadcom. The version I see here is 2.6.33-31.1 whereas I
> currently have 2.6.31.12-0.1 so I can see how this is an upgrade.
> However, per the post from lwfinger, the 4329 will not be supported
> until 2.6.35.
The 2.6.35 is only a guess. The code for the 802.11n devices missed 2.6.34, and
if the driver development runs into problems, it might not be ready for 2.6.35.
> So I guess my questions are these:
> (1) Will ‘HEAD’ (2.6.33-31.1) support my 14e4:4329 device?
No. If you had a BCM4312 (14e4:4315), which is much more common, then 2.6.33
would support it, but not your 14e4:4329.
> (2) Which kernel family and type should I download?
>
> If I were to guess at the latter, it would be the default from i586
> (kernel-default-2.6.33-31.1.i586.rpm). Or do I compile from src? Or do
> I simply update my sources.list and key and then update and upgrade?
You can use the standard kernel; however, you will need the Broadcom wl driver
from Packman.
> I’ve done some reading on the different repositories and have disabled
> all but the main four (plus maybe Packman). Nevertheless, I found no
> reference to ‘HEAD’ nor to some of the other repositories either
> searching the forum directly, via Google, or the external Google search
> results on the matter. Some I could easily guess by their name but
> wound up with about a dozen or so that were enabled before I read a post
> that suggested the main four only.
As you were advised earlier, use only those 4 repos unless you need another for
some special situation.
I’m running openSUSE using the debug kernel and the Broadcom wl driver from Packman. I’ve done a dist-upgrade since disabling all the other repos that I had up to get things back closer to “stock” (“Factory”?). I still cannot get service from my card in the standard (default?) kernel.
The only thing I could think of that might be different would be in the kernels themselves. When getting my card up in Debian I had to download and ‘make’ the source package (see wl - Debian Wiki for details) and wondered if something of the sort might be done in ‘default’ with similar results.
Currently in ‘debug’ the card is activated but I have to “tickle” it after startup to get a viable connection and then it is not entirely persistent. By “tickle” I mean running from CLI:
‘ifdown eth1 && ifdown eth0 && ifup eth1’. Occassionally, I will lose my connection and have to repeat the above (which seems to work a bit better than ‘/etc/init.d/network restart’ as the eth0 seems to block the eth1 – they don’t work and play well with each other (this behavior has been recognized in at least one of the Debian derivatives so I don’t think it’s special to openSUSE).
FYI @lwfinger
Is arguably the most knowledgeable user here in the networking/wireless etc…
So you are in good hands with him.
Sorry if I offered conflicting advice:)
On 03/20/2010 07:16 AM, caf4926 wrote:
>
> FYI
> @lwfinger
> Is arguably the most knowledgeable user here in the networking/wireless
> etc…
> So you are in good hands with him.
> Sorry if I offered conflicting advice:)
Thanks for the compliment. I must state that once I get past the recommendation
that wl is the required driver, I’m done. Like most kernel developers, I do not
waste any time trying to debug situations involving closed-source software.
Well, I appreciate both of your input. I had to chuckle at lwfingers last statement, though. Without getting into too much detail, I completely understand and certainly agree with his statement. We have a somewhat analagous situation with measurement devices where I work and I adopt the same policy as much as I can. If nothing else, it is a matter of efficiency. I can support ten standard devices for the amount of time it would take to support one non-standard device. Put another way, do I make ten people happy and one un-happy, or ten unhappy and one happy. That one happy camper isn’t enough to stem the tide of the mob forming outside my door. lol!
I fully agree with the open source concept as well as I undertand it and would say that burden for support rests on the person utilizing a closed source driver, in this case me. Had I actually purchased this card I would have been more careful but as it was it was a gift. Nonetheless, I am fully appreciative of the help I have received both in the wikis and in here. I’m learning more about my system, learning about specific devices, and learning even more about the philosophy of open source.
On 03/21/2010 07:56 AM, HunkirDowne wrote:
> I fully agree with the open source concept as well as I undertand it
> and would say that burden for support rests on the person utilizing a
> closed source driver, in this case me. Had I actually purchased this
> card I would have been more careful but as it was it was a gift.
> Nonetheless, I am fully appreciative of the help I have received both in
> the wikis and in here. I’m learning more about my system, learning
> about specific devices, and learning even more about the philosophy of
> open source.
To make you feel better about your gift wireless device, the open-source driver
is nearly complete. If not for exams being taken by the person translating the
specs into Linux code, I would have expected it to be limping by now. I
certainly hope for 802.11n support in b43 by 2.6.35/.36.
