Broadcom issues
 

I am having issues with my wireless. I have a Dell Latitude 120L with a updated fresh install of Fedora 7 kernel 2.6.21 or 22 not sure. Not being too familiar with the command line in Linux I have read what other people have tried with and without some success and therefore am able to post the following information.
when login as root and issue the command lspci I get the following output

I turned NetworkManager on for GNOME and it displays a option to enable wirless network.

My card is there my machine and Fedora sees the card this is obvious. Now I have tried the latest ndiswrapper with no success and have tried the bcm43xx-fwcutter with no success. When I got the laptop it was a windows machine and has the keyboard that has the special keys that turn the volume up and down, there is also a special key that enables the wireless card. I have tried to map my keyboard with some success. I got the volume keys to work and the suspend key to work but not the wireless key. I don't know if that has anything to do with it or not. I am stuck and have no clue on how to fix this. If anyone can help me i would appreciate it. I have also tried the infomation from the GNOME NetworkManager at [HTML]http://bcm43xx.berlios.de/[/HTML] I get commandline errors when trying the 'git' command. I am slowly learning commandline utilities but still have some trouble.

OK, you've got a 4318, which means that ndiswrapper is probably a better approach.

There are likely a couple of reasons for this. On the bcm43xx side, the numbnuts at Fedora have decided to replace bcm43xx with the experimental b43 driver, and I believe this happened in FC7. The issues are that it needs a different firmware file in order to function(see here for the files) and if you want to use ndiswrapper, blacklisting b43 isn't quite straightforward (see the last post in this thread and this thread as well). Since ndiswrapper and b43 will almost certainly interfere with each other if they are both loaded, blacklisting b43 is usually a critical step in getting ndiswrapper to work.

If I have already done the firmware cutter (assuming thats what the 'fw' is for) will that mess me up. If so how do I get rid of it. I gone through the steps on some of the threads I have seen about ndiswrapper and somewhere along the way I usually end up with an error or a bad command in the terminal. It's getting to the point where I am about to go buy a usb wireless thing and quit messing with this. It is really really starting to pi$$ me off I follow the threads that seem to have the most positive results and I end up getting errors. I guess what I really need is a really easy to follow dummies guide to doing this ndiswrapper. Also the last time I tried it I got that the driver that went with my card according to Sourceforge was an invalid driver according to an lspci -l command. I don't want to give up and I dont want to say that I have tried everything I know there is something that will work but alot of the stuff thats out there I have attempted without success.

The short answer is probably not. If you go the b43 route, just adding the correct firmware should do the trick, even if the older version is there. Ndiswrapper doesn't use firmware files, so it isn't affected at all by this.

Ndiswrapper installation is about as easy as it gets, if you're having trouble, post what you're doing and what errors you're seeing and maybe we can get you straighted out.
That could be a big mistake. USB wireless devices are a super colossal gigantic pain in the posterior in Linux. Well, most of 'em anyway.

Have a look at the ndiswrapper wiki (see my sig for the link). Easiest and best instructions available anywhere.
Please don't take this the wrong way, but I suspect you're fighting with your unfamiliarity with Linux as much as anything else. The lspci command should only tell you what devices are plugged into the pci bus, and knows nothing about what drivers are in use.

If you want to pursue this, the best course is to decide what driver you're using and then post details about what you've done and where it is causing trouble. The decision you're facing isn't an easy one however because the 4318 chipset doesn't work very well with the b43/bcm43xx driver and Fedora is probably the most ndiswrapper unfriendly distro there is. If you haven't invested too much in this Fedora install, and if wireless is important, I'd give serious consideration to switching to a different distro.

Okay in this process I have run across the following errors. i got a version that is known to work with the make of my laptop and the make of my card. I get to the point of putting installing the .inf file and it kicks this out to me

You very probably need kernel sources/headers installed before you go about compiling ndiswrapper. Either get those, and start all over, or get ndiswrapper binary package (version 1.47 works for that Broadcom card for sure, newers should also). If you plan installing binary packages, remember to get ndiswrapper and ndiswrapper-utils if they are in separate packages. Anyway, your first goal is to get ndiswrapper installed. After that use ndiswrapper -i to install the driver just like you tried ('ndiswrapper -i filename.inf'). Note that ndiswrapper executable may be in /sbin and that might not be in your $PATH variable, so either use "su -" to become root or execute it with full path, like /sbin/ndiswrapper if it got there. After installing ndiswrapper, installing the driver with it and making sure ndiswrapper module gets loaded during boot, you very probably still need to reboot for this all to work -- and before doing so, blacklist the native bcm43xx or b43 driver so that it does not get loaded during boot. If it does, there's a chance it'll interfere with ndiswrapper and then your card won't work.

That card is easy to get working with ndiswrapper, but you need to do it carefully.
1) either install ndiswrapper (and -utils) binaries, or install kernel source/headers and compile ndiswrapper like you tried to do (see the error).
2) after that blacklist the native driver, "echo blacklist b43 >> /etc/modprobe.d/blacklist" or equivalent
3) make sure modprobe.conf (or whatever you use) loads 'ndiswrapper' module during boot
4) install the Windows driver with ndiswrapper
5) reboot and try if it works - should

Is there somewhere I can find out how to do the kernel headers that you mentioned. I am not sure on how do to do that.

Well this ndiswrapper thing isnt working, I have tried it on three or 4 different installs. Would be nice if there was like a step by step for this thing or a way it could become fool proof. I imagine it has something to do with what Im doing. It's getting to the point I am about ready to switch back to windows.

You missed a REAL important step in compiling this. I went through the results you posted and you ran like this:

make distclean
make install


The problem is you never ran make, which means that nothing actually compiled. What should have happened is:

make distclean
make
make install

As for the kernel source code, yes it needs to be installed, and there should be an RPM for your kernel available either on your install CD/DVD or from a Fedora repository.

Thank you Hangdog actually the link to your page was a big help I was able to search for what the info I needed on the kernel headers and source.

compiling the kernel
 

I think I am on the right track with getting this figured out. As I understand I have to get the kernel source and header files, recompile the kernel and take the native b43 driver that is throwing the error when I try to activate my wireless card. I did manage to find out that with my Fedora installation there was not a kernel src installed. I got the source from the repo and have attempted to apply it. When I made my ISO it was Kernel version 2.6.21 so since when I boot my system up I see 2.6.22 there has been an update this is where the native b43 comes into play. So the Kernel source rpm that I downloaded from Fedora. I attemtped to install the source code and the following is my output with one error, sorry for the long post...

Since I installed the ndiswrapper without the source code being there is that going to hinder me? will I have to start all over again? and if so should I remove the now present ndiswrapper and all the stuff with it, a simple command that will help with that.

I have another question that is along the same lines. I should not have done this but hindsight is 20/20. some where I had read that wlan0=up would help or something to that effect and I found a file that has something to do with the loading of the kernel and when you boot up you can get the messages and I need to take that out. I think it is interfereing

Under no circumstances should you have to recompile your kernel to use either ndiswrapper or b43. You may need your kernel source to get ndiswrapper running however (more about that later) and if your headers aren't part of the default install, somebody needs to start slapping Red Hat around. You pretty much can't compile diddly without the headers.

What you need to take care about is not having b43 and ndiswrapper modules loaded at the same time. Practically, that means that before loading the ndiswrapper module, you need to either remove the b43 module (with the modrpobe -r command) or you need to blacklist it so it doesn't load in the first place. I believe that there are actually two kernel modules that have to be blacklisted for b43 to be really blacklisted, and there are details in the threads I linked to in my first post.

It looks like the kernel source RPM did install (you can usually ignore warnings) but I'm not sure what this command is for:
Any enlightenment would be appreciated (sorry, I'm allergic to Fedora so I'm not real familiar with all the ins and outs).

The answer is that it depends. If you compiled ndiswrapper from source code, then not having the kernel source installed is a fatal error, and nothing would have compiled. In this case it is safe to simply start from the make distclean step and keep going. If you installed ndiswrapper from a pre-compiled RPM, then you actually wouldn't need the kernel source at all, however there must be an exact match between the kernel version your running and the version ndisrwapper was compiled against. In this case, I would remove the RPM file and compile ndiswrapper from source.

By the way, since ndiswrapper is a kernel module, every time your kernel is upgraded it is likely that you will need to recompile ndiswrapper.

Yeah, you probably should remove that, I don't think it is something the kernel would understand. What you might have see was the ifup command which would be run like this:

ifup wlan0

The ifup command runs the DHCP client and requests an IP address and then brings the interface up for use.

Thank you for clearing things up, there is still a little bit I am fuzzy on but I think I am slowly learning as I go along. I am a little unclear on what this means


this came from the ndiswrapper wiki for install. When they say this does this mean that I have to tell it to "make distclean, make, make install /lib/modules/2.6.22-76.fc7"??? I think this might be a crucial step in getting this to work right for me. Sorry for this to be so time consuming. Along with the help I am receiving from LQ I have a book that is covering the rest of the little stuff for me as I go. The book covers FC5 and there is a chapter for installing the source code when the source is not present on the system. Book says

Lets see if I can clear some of this up.....

The directory /lib/modules/KERNELVERION is where all of the compiled modules are stored for that version of the kernel. So say you're running a 2.6.5 kernel, the compiled modules would be stored in /lib/modules/2.6.4/. If you then upgrade to 2.6.22, a new directory would be created (/lib/modules/2.6.22) to hold all of the compiled modules for 2.6.22 but /lib/modules/2.6.4/ would remain untouched. This is how you can have multiple kernels available to boot, and also why you have to recompile ndiswrapper every time you switch kernels. A running kernel is aware of what directory it should use when looking for modules, so if you went through this kernel switch without recompiling ndiswrapper, there would be ndiswrapper in /lib/modules/2.6.4 but not in /lib/modules/2.6.22 so the 2.6.22 kernel wouldn't be able to use it.

The make distclean command simply cleans up any previous attempts at compiling ndiswrapper. This is done in case you've switched kernel versions, but are using the same ndiswrapper version. On a clean install, this really doesn't do anything, but it also isn't harmful, so you may as well run it.

The make command actually causes the source code to be compiled into functional programs (or in this case, a kernel module). However, the make command leaves all of the newly compiled files in the directory containing the source code.

The make install command is responsible for moving the binary files created in the make step to the proper directories in the rest of the system. Usually this is the only command in this series of steps that must be run as root since you're usually installing the program to privileged parts of the system like /usr, /etc or /bin. I'm guessing that their adding the /lib/modules/2.6.22-76.fc7 bit in an attempt to tell make install exactly where to put things, however usually that isn't necessary. By default, the make install step for ndiswrapper installs into the /lib/modules/kernelversion directory for the running kernel, so unless you are compiling for a different kernel, you probably don't have to worry about adding anything to make install.

All of these variations of the make command derive their "intelligence" from the Makefile you'll find in the top level of the directory with the source code. This file contains all of the instructions for how the program is to be compiled and where to put things. For something relatively simple like a kernel module, Makefiles are usually fairly simple and can be pre-configured by the team developing the kernel module. For stand-alone programs where there are likely to be dependencies on other things like libraries, before you can run any of the make steps, you first have to run a ./configure program which will inventory your system for available libraries and then create a custom Makefile for that program on your system.

I'm not entirely sure what they're getting at here, but my best guess is that they're talking about where the kernel source code is located. Usually on Linux systems, you'll find the source code for the running kernel in /usr/src/linux. Now many flamewars have been fought over whether you should actually have the source code in /usr/src/linux or whether /usr/src/linux should be a soft link pointing to the kernel source code, and the source is actually located somewhere else. It looks to me like RedHat stores a bunch of information in the /user/src/redhat/SPECS/kernel-2.6.spec file that relates to where the source code is actually installed. My guess is that you can probably not worry about this particular detail as long as there is something in /usr/src/linux.