EDIT! This document has been edited from the original. It has been edited for reasons of accuracy and clarity, but not brevity. It has also been added to my web site

I am going to start right off with a warning. These instructions are going to be a bit long-winded. In order to make sure that I am as complete as possible, I will put forth every step I took in getting my wireless network running under Slackware Linux. Many of these steps will cross over into other Linux distributions. However, some steps and file names are exclusive to Slackware. If you find a file or a directory that isn't in your particular distribution, you will have to know which files in your distribution are analogous to the files named herein. Perhaps an enterprising person (or persons) out there can re-write this document specifically for their particular distribution. As far as I am concerned, the GNU ideal applies even to this document. All I ask is if you do rewrite this document for your distribution, please list me, Pappy McFae, as the original author. Thanks in advance.

I wrote this because the documentation for setting up wireless networking is both sparse and cryptic. While there are some older cards that apparently set themselves up more or less automatically, many do not.

One of the currently popular wireless chipsets are made by Broadcom. There are versions of these built into laptops, or available in PCMCIA and PCI cards. This document is applicable to all Broadcom chipset devices.

Quick History:

This would all be academic as well as non-existent had I not recently purchased a new Compaq C504US laptop computer. It came with a Broadcom bcm4311 wireless network adapter built in. I made my choice of machine due to monetary constraints. It was cheap...well, sort of. It came with Windows Vista pre-installed. That wasn't going to work for me! Windows Vista is complete garbage. I had no intention of having my new computer run slower than the old PII sitting next to my foot. I replaced Windows Vista with Windows XP Professional, and set up a dual boot with Slackware.

The bcm43xx driver has been included in the Linux kernel since version 2.6.17-rc2. However, it requires firmware to be extracted from the windows drivers. I am not going to discuss that method. I found little documentation on that method. Besides, that method doesn't support the 802.11g 54Mbit/sec standard.

Instead, I used ndiswrapper, and wpa_supplicant to get the wireless network to operate. I also worked with cabextract just for those who don't dual boot their systems. The only documentation for these programs is recycled man pages, especially ndiswrapper. Therein was the root my problem, and the reason for this document. After a week and a half of searching and researching, I finally hit upon a workable method for getting the wireless network up and running. I am sharing it in the spirit of GNU and GPL.

Document Conventions:

File and directory names will be given in italics. Commands typed at a command prompt will be given in "quotes". Assumptions:

It is assumed that you are logged in as the root user. If you are not, you should log out and log back in as root. You may be able to cheat by using "su", but that's not how I did it. It is also assumed you know enough about Slackware Linux to be able to compile a kernel, expand a .tar.gz file, and compile those files contained in the .tar.gz package. It is also assumed that you know how to install a standard Slackware *.tgz file using the Slackware package manager. If you are unfamiliar with these terms or operations, familiarize yourself with them before proceeding. Finally, it is assumed you realize that I am using the "latest and greatest" versions of the required packages. Since version numbers have a tendency to change every once in a while, it's best to use the most current versions.

How I did it:

I: Prep work

1) The programs ndiswrapper and wpa_supplicant only work under the 2.6.xx.x version of the Linux kernel. Therefore, the first step is to make sure the 2.6.17.13 (or greater) version of the kernel is installed on your system. Slackware 11 ships with two different 2.6.xx.x kernel sources, and Slackware 12 ships with one. The kernel source files are located on the Slackware distribution media. You can also get the most current kernel version here.

If you do opt to compile your own kernel, there are numerous instructions on the Internet for compiling it successfully. I'll only add these important caveats: be sure to compile file system support directly into the kernel. Don't expect modules to load the file system properly. They won't, and neither will initrd. You'll be left with kernel panic. Do the same with ACPI. In order for ndiswrapper to locate the adapter, ACPI is required.

2) Open package manager. Make absolutely sure that some version of wireless-tools wireless-tools-28-i486-3 (Slack-11) or wireless-tools-28-i486-5 (Slack-12) is installed. It will be required later in the installation process. If you made a choice to install everything when you first set Slackware up, the package is installed by default.

II: Getting the Windows Drivers

Note: This computer uses a Broadcom bcm 4311 adapter. The windows drivers for it can be downloaded from the HP web site; file name sp34152.exe.
EDIT: Since there are numerous file names, it is suggested that you use the drivers that shipped with your computer or wireless adapter. If they are unavailable, they can be downloaded from the web site for the computer or adapter, whichever appies.

1) If you are set up for a Windows XP dual boot like myself, the drivers you need will be on your Windows XP partition. Under Linux, copy the Windows driver files to your Linux partition, and skip to the next section.

2) If you don't have a machine set up to run Windows, you can use cabextract to extract the required files from your Windows driver file.

3) The cabextract package is available here.

4) Download the .tar.gz archive, and extract the contained files.

5) "cd" to the extracted directory.

6) Type "./configure && make && make install" to configure, compile, and install cabextract.

7) Place the Windows driver arcive into its own directory.

8) "cd" to the directory containing the driver file archive.

9) Type "cabextract sp34152.exe".

10) This will expand the files contained in the archive.

11) Ndiswrapper uses only the .inf and the .sys files (bmcwl5.inf and bmcwl5.sys for this machine). The other files extracted can be deleted, if you wish.

III: Setting up ndiswrapper

1) Blacklist the native bcm43xx wireless driver. This must be done, or the bcm43xx driver will conflict with ndiswrapper. Just add "blacklist bcm43xx" to the /etc/modprobe.d/blacklist file.

2) Download the ndiswrapper source archive and extract it.

3) "cd" to the extracted source directory for ndiswrapper.

4) Type "make uninstall".

5) Type "make"

6) Type "make install"

7) "cd" to the directory with the expanded bmcwl5.inf and bmcwl5.sys files.

8) Type "ndiswrapper -i bmcwl5.inf".

9) Type "ndiswrapper -l". You should receive the following message:
10) Type "ndiswrapper -m" to write the modprobe configuration for ndiswrapper.

11) Type "ndiswrapper -ma" to write the module alias to the /lib/modules/2.6.xx.x/modules.alias file.

12) Type "ndiswrapper -mi" to write the module to /lib/modules/2.6.xx.x/modules.conf file.

Note: At this point, I recommend a reboot. That way, you can check your work to this point to make sure that ndiswrapper does indeed come up. To make sure that all is well, once you finish your reboot, enter an X Windows session, start a terminal, and type "dmesg". If all is well to this point, you should see the following:
If you have successfully come to this point in the process, you are fairly close to getting your wireless adapter up and running. There are only a few steps left.

EDIT:Note the name ndiswrapper gives to your wireless adapter. In the case of the response given above, the device was named "wlan0". For some, it may be "eth1", or some other device. Substitute that device name for any instance of wlan0 below.

IV: Setting up wpa_supplicant

NOTE! This is the trickiest part of the installation!

1) Download wpa_supplicant source code here.

2) Extract wpa_supplicant in its own directory.

3) "cd" to the extracted source directory.

4) Create a hidden text file called .config and open it.

5) Open the file called defconfig

6) Copy all the text from defconfig to .config and save the file.

7) There is an undocumented GUI application that comes with wpa_supplicant, wpa_gui. To enable it, edit the Makefile thusly: Add last entry manually.

8) Type "make" to compile.

9) Copy the executable files to the /usr/local/bin directory by using the command "cp wpa_cli wpa_supplicant wpa_passphrase wpa_gui /usr/local/bin".

10) Copy the file wpa_supplicant.conf from the source directory into the /etc directory.

11) Open /etc/wpa_supplicant.conf. Keep the wpa_supplicant.conf file in the source directory pristine just in case.

12) Edit out everything in that file after the line that reads: 13) Open a terminal (konsole).

14) Type "wpa_passphrase *ssid* *passphrase*" where *ssid* is the wireless indentifier (without the "*" 's) and *passphrase* is your default passphrase (once again, without the "*" 's).

15) This will generate the following:
where "your_ssid" is *ssid*,and "your_passphrase" is *passphrase* as entered in line fourteen above. The psk=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx line is a 64 digit hex code key generated by wpa_passphrase.

16) Use your mouse to select this code. Alternatively, you can also type "wpa_passphrase <ssid> [PASSPHRASE] > passphrase.txt" to redirect the output to the file passphrase.txt.

17) Paste this code into the /etc/wpa_supplicant.conf file after the line that reads 18) Save the file wpa_supplicant.conf.

19) Type "wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf -d". You will see numerous chunks of code go flying past your screen. The code rushing by should slow in about ten to thirty seconds depending on your system.

20) Open another konsole session then type the command "wpa_cli". This command will enter you into an interactive session with wpa_cli.

21) At the > prompt, type the following: "passphrase *ssid* *passphrase*" where *ssid* is the wireless identifier (without the "*" 's) and *passphrase* is the passphrase for that ssid (once again, without the "*" 's).

22) After you hit <enter>, wpa_cli will output OK, then the > prompt will come back.

23) Type "quit" to exit wpa_cli.

24) Type "dhcpcd wlan0". If everything is proper, you should come up with an IP address when you type "iwconfig".

25) If that happens, take five. Smoke 'em if you got 'em. We're almost done here.

V: Finishing steps:

1) Open your /etc/rc.d/rc.local file...or whatever your *.local file is named.

2) Add the following lines to the file:3) Save your /etc/rc.d/rc.local file.

4) Right click on rc.local, select "properties", then select the "permissions" tab, and check the "is executable" check box.

5) Quit your X Windows session and reboot.

If all went well, you should come up with a fully functional wireless network connection. If you have any further problems, go back and make sure you took all the listed steps, especially the steps for wpa_supplicant. I personally had the greatest amount of trouble getting wpa_supplicant working properly. It really is tricky!

The above listed steps have rendered my Broadcom bcm4311 wireless adapter functional. Since the original posting of this article, I have also used the same steps to add wireless netorking to my older Toshiba laptop.

EDIT:You can also add samba functionality to your wireless network if you copy the lines which invoke samba from your /etc/rc.d/rc.M file and place them in your /etc/rc.d/rc.local file after DHCP is invoked. You can also add NTP functionality by doing the same thing with the lines that invoke ntpd. Be sure to comment their invocation out in the /etc/rc.d/rc.M file, and make sure that /etc/rc.d/rc.samba and /etc/rc.d/rc.ntpd are executable. See example below
It is my hope that these instructions will save you the time I lost, and the frustration I felt trying to get things running. If you are appreciative, reply here and let me know. It's nice to know I am appreciated. Since I am not going to make any money on this, a nice "thanks" goes miles with me!

Happy networking!

Blessed be!
Pappy

A very nice bit of work Pappy. I'd like to make two suggestions.

1) You never mention the native bcm43xx driver. Since this is increasingly included in distros, you probably want to at least mention blacklisting it since having bcm43xx and ndiswrapper loaded at the same time will cause trouble.

2) You never mention the specific chipset that you use, and that might be a nice bit of information to have. Since bcm43xx works fine with some Broadcom chipsets and really stinks with others, knowing what one you have might be nice.

3) (OK, I lied about a couple of suggestions) I'd submit this to either the Tutorials section or add it under your wireless card in the HCL. Threads like this will sink and those two locations will make this easier to find.

Also (I'm continuing to lie about the couple of things) Since this is a Slackware based example, you might mention that a Slackware package of wpa_supplicant is available in the /extras folder of Slackware 11. Hey, it saves a compile.

I'm also curious in your wpa_supplicant section you never mention what wpa_supplicant driver you're using. Ndiswrapper can work with both ndiswrapper and wext. I'm guessing that since wext is a more generic interface, wpa_supplicant may develop that and leave ndiswrapper behind. I'd modify your example to show how to start wpa_supplicant with both the wext and ndiswrapper driver since I've seen cases were using wext worked but using ndiswrapper didn't.

You're quite correct. Whether they were compiled into the kernel, or set up as modules, the bcm43xx drivers would not initialize no matter what I tried. Had they worked, I would have written an article about using those specific drivers. Because none of my bcm43xx driver attempts resulted in functionality, I declined to even mention them.

While I'm pretty sure they'd have been a far site easier to use and less involved in the explanation, they simply wouldn't work for me. Frankly, I was upset they didn't work. I assume they would have worked like the wired network adapter: Invoke and dhcp.

The focus of the article was to inform others how I made it happen without the standard Linux claptrap and garbage. The bcm drives were a part of that claptrap, because they didn't work. Given the focus of this article. I felt it would add too much to an already overloaded article to mention them.

If you know how to trick the bcm43xx drivers into working, I'd love to have you tell me how. I'm sure if they can be made to work, they would requires a lot fewer steps than those I listed for my solution. Whatch' think?
Once again, you're quite correct. The simple reason is I don't know the exact chipset numbers. That's the short answer.

The long answer is, there is no way of knowing the exact chipset numbers without opening up the machine. Since it is still covered by a warranty until next April, I am not about to open it other than to add another memory module. The lspci utility responded thusly: 06:00.0 Network controller: Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card (rev 01). Since I know that this is, in fact, a Compaq, not a Dell, I know that it's also not a 1390 "card". I'm sure if I looked somewhere on the 'net, I could find the exact chipset numbers.

Once again, it wasn't important in the article to exactly identify the chip set. If you have the same basic machine as mine, you know what you have. If you are a Linux guru, you most likely know every chip inside your machine, or can guess what will or won't work. Besides, it seems from what I read on the 'net that many new laptops have the bcm43xx chipset. In other words, this article should cover many machines, even if the owners of those machines don't know the exact chipset number.

Since most new machines come pre-loaded with some iteration of Windoze, it is assumed that the drivers for the wireless adapter that work are easily accessible. By using ndiswrapper, it is guaranteed that if the drivers in question work properly under Windoze, by goddess, they WILL work under Linux. It is my understanding this is the idea behind ndiswrapper in the first place. It is also my understanding that the makers of ndiswrapper are expanding its functionality beyond the ubiquitous wireless networking adapter.
You may be right. I was actually going to post in the Slackware distributions forum as well. Fortunately, I still have the original document saved as I wrote it using K-Word, so I can post it pretty much anywhere it would fit. I was also going to post it at an Internet site dedicated specifically to wireless networking. I'm not too sure it will "fly" on that site as it seems to be a Windoze specific site, but nothing ventured means nothing gained.
I'd have done that, had I known there as a version of it available on the disk. Frankly, I never even considered that it would be a part of the Slackware distribution. Of course, I never thought that checkinstall would be there, much less wpa_supplicant.

Besides, not to blow my machine's horn, but it was quicker to download the latest and greatest version of wpa_supplicant and compile it than it would have been to have read it off the DVD, install it under package manager, and configure it thereafter. I love fast computers!
I thought I was quite clear in how I invoked wpa_supplicant. Once again, the article was how *I* did it. I didn't do any fancy machinations outside the listed steps. In the Assumptions section of the article, I said that the versions of the packages were "the latest and greatest" available from the listed Internet sources. I hadn't read anything about wext until you mentioned it, therefore, I wouldn't have included any information about a package I didn't know existed.

The version numbers are as follows:

bcmwl5.sys: 0x4640f05 (as reported by ndiswrapper)
cabextract: 1.2 (I didn't need this program. I tried it and included it for the purists.)
ndiswrapper: 1.4.2
wpa_supplicant: 0.5.7.

Thanks for the feedback. Hope this clarifies your questions.

Blessed be!
Pappy

I agree with you completely except that since bcm43xx can (and does) conflict with ndiswrapper, someone installing ndiswrapper needs to know about how to blacklist it. There are lots of threads around here where ndiswrapper doesn't function until bcm43xx is removed.

I've actually got a section on my help site detailing how to get bcm43xx to work, and I bet you ran into my new favorite four-letter word: Firmware.

The problem with several of the native Linux wireless drivers is that the kernel module is released under the GPL, and so can be distributed. However, the firmware that is required in order for the card to function, is almost always proprietary, and therefore is not distributed by any distro I'm aware of. So practically, distros are giving you only half of what you need in order for your card to function. What makes it truly ugly is that since the card is recognized by the native Linux driver, it appears to be installed, it just doesn't work. Most new users aren't aware that they have to install firmware, so unless they do some digging they usually either move to ndiswrapper or just give up on Linux.

You are right about the intent of the ndsiwrapper team, however there are plenty of Windows drivers that don't work properly under ndiswrapper. The unfortunate reality is not all driver writers follow instructions. If you spend some time hanging out in this forum you'll see lots of black eyes and bloody noses from crummy Windows drivers.

Uh, no, not by a long shot. Of course there is always Google, but if lspci doesn't show the chipset, it is usually worth installing lshw as it does a good job of picking up hardware.

Don't do that, I'm pretty sure the mods would consider it double posting. Tutorials or HCL are the way to go here.
Ah, yes you were, I just missed it.

I hope you take this in the spirit it is intended. You've done an excellent job of writing a plain-language how-to and I'd like to see it get a permanent place here.

I must have done something accidentally right, because as I listed in the article, once I invoked wpa_supplicant, things popped into functionality. It wouldn't be the first time I accidentally did the right thing. heheheh

Ok, I'll bite. What's the URL to this discussion?

I assume your mentioning of firmware will bring up the discussion of fwcutter. Yes, I did find it. Yes, I did "cut" the firmware from the Windoze driver. Yes, the cut files are still on this hard drive. No, I couldn't figure out what I was supposed to do from getting the firmware cut. Fwcutter was, without a doubt, the most cryptic package I ran into in my search. I'm not sure why that is...but it was/is.

I did the digging, but I found nothing. Fwcutter was heavy on cutting the firmware, and light on making it go. Perhaps I just missed the point, which wouldn't surprise me at all. I may have tried to make it fly under the 2.4.x kernel and just gave up on it before I attempted trying it under the 2.6.x kernel. Frankly, once I figured out how to make my wireless adapter work with ndiswrapper, I chucked the idea of trying any other method.

However, if it can be proved that using the native bcm43xx drivers and their associated firmware is a better option than the rather cumbersome ndiswrapper/wpa_supplicant set up I am currently running, I'd be willing to give it a go. Perhaps getting an IP address earlier in the boot sequence might make Samba work better over the wireless network. That would make certain operations much easier since apparently, NetBEUI doesn't fly over the airwaves (at least it doesn't appear to with my wireless router).

It makes sense that GPL would restrict so-called "proprietary" drivers, firmware, etc. Even though the Linux kernel and all the software that runs under it are free, and there is really no one that "owns" Linux, I'm sure the software "industry" giants would find some way to defecate all over Linux for using their "proprietary" code. We really don't want that now, do we?

I know I don't want that. Microsoft already ripped off Linux with Windoze Vista, and did a really sorry job, IMHO. They'd have done better to have made a play for Ubuntu or someone else in the real Linux world, and put the Microsoft name on that illegitimate offspring of Open Source software. It might have worked better, been more secure, and taken only a bare fraction of the space that Windoze Vista gobbles up on the hard drive. You can tell that the demon Gates is no longer at the helm. M$'s robber baron spirit is as long gone as the 386 16.

Well, I guess I am lucky that I got this mess working then. I would have been forced to stick with Microsoft to use my wireless network adapter. I use M$ because a lot of my business files and such were birthed under the auspices of M$ based software. I also use it because there is still no real fully functional audio editing/multitrack recording software that runs under Linux. Finally, I use M$ because there is a lot in the way of software that only functions under it.

The point is, I want the ability to make a choice. Linux does many things better than any Windoze iteration. Windows does somethings better than Linux, and it runs more software. That's why if I set up Linux on a machine, it's set up as a dual boot. I like to have the best of all worlds at my fingertips if I can get it.

The long answer is, there is no way of knowing the exact chipset numbers without opening up the machine.

Yes, it really throws up some stuff. The problem is, it STILL doesn't answer your question as to the chipset number. Here's it's output (man, I love a fast computer. It took no time to compile it)...

configuration: driver=pcieport-driver
*-network
description: Wireless interface
product: Dell Wireless 1390 WLAN Mini-PCI Card
vendor: Broadcom Corporation
physical id: 0
bus info: pci@06:00.0
logical name: wlan0
version: 01
serial: 00:1a:73:20:85:cb
width: 32 bits
clock: 33MHz
capabilities: bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=ndiswrapper driverversion=1.42 firmware=Broadcom,10/12/2006, 4.100.15.5 ip=xxx.xxx.xxx.xxx latency=0 link=yes multicast=yes wireless=IEEE 802.11g

The question remains unanswered. Oh well, life is like that sometimes.

I was actually going to post in the Slackware distributions forum as well.

Ok, I surely don't want to upset the powers that be here if I can avoid it. Goddess knows, I can really bunch some panties over at OpEdNews.com with my controversial nature. I'd prefer to have some place where the more acidic part of my personality falls into the background. How about posting links to it in other places here? Is that verbotten as well?

I thought I was quite clear in how I invoked wpa_supplicant.

No-ey problemo, dude!

As would I. I put a lot of work into that document, both in the research time behind it, and in the actual writing, rewriting, re-rewriting, re-re-rewriting, etc. I'd love to see it find a place of prominence. If I can't make my literary name by slicing certain politicans to ribbons at OpEdNews.com, I'll do it here by writing dull tech-docs. Frankly, I don't care, as long as the moniker of Pappy McFae garners his fifteen minutes of Warhalian fame.

I take this discussion in the spirit of two people communicating and attempting to assist each others' understanding of a fairly complicated, geeky, and dull yet somehow wildly interesting subject. I am the first to admit I don't know all there is to know about all there is to know. Only the incredibly arrogant, the incredibly stupid, or the perpetually lost in the fog would pretend they can't learn something from someone else.

For me, learning Linux is as much about gaining skills to use in my business as it is attempting to mediate the weight of the yoke placed around my neck by the Microsoft software cartel. If something I learn here, or on my own as I delve further into the wilds of Linux can be profitable, then all this time spent will be worth it. Even if that doesn't happen (and it hasn't happened as of yet), I will know more about my computer than the average human...and probably more about it than the zit-faced kid behind the counter at Fry's Electronics who wants to have a crack at sticking his fingers into the guts of my computer.

So no worries from the end of my spectrum. So far, you are the only one to make any comments about my article. I love being noticed, so I am not going to do anything to upset you, insult you, or slam you about here.

This is a forum for Linux. I have visited numerous Linux forums populated by absolute rude pigs, buttheads, and ultra "My digital poopie smells like roses" geeks. I have no need for that crap. I surely don't want to come off as one myself.

To me, coming here and sharing is part of the ideal of GNU and Linux. I don't know enough C++ yet to write or debug a program (working on it). However, I can write a good technical paper and step by step instructions. It's the least I can do to contribute, so I'll do it. It's in the spirit of GNU, Open Source, and the ideal of Linus Torvalds that I wrote and shared this document. I hope that fact comes out between the lines of ASCII characters that make up the document, and these discussions about it.

Blessed be!
Pappy

I forgot to mention, it is in my sig. However, from the rest of your post, it sounds like you noodled your way through it.

Yeah, the documentation on fwcutter is pathetic. However, here is the procedure in a nutshell:

1) compile fwcutter (unpack the source and run make)
2) fwcutter /path/to/Windows/driver (use wl_apsta.o if you can find it). That creates a bunch of files ending in .fw
3) (as root) make installfw. That copies all the .fw files to /lib/firmware (you can also just copy them) which is where bcm43xx looks for them.


Once firmware files are in in /lib/firmware, whenever bcm43xx loads, it loads the firmware without any user intervention.

At the moment, ndiswrapper is the better performing option. Bcm43xx is limited to 802.11b speeds and it doesn't work with all Broadcom chipsets, whereas ndiswrapper is good at 11g speeds and seems to work with all of them. Also, moving to bcm43xx doesn't relieve the dependency on wpa_supplicant to handle WPA encrypted networks. That might be changed when the kernel moves the guts of the wireless support from the current SoftMAC stack to the Devicescape stack, which should happen in another kernel version or two. Apparently the Devicescape stack handles encryption much better than SoftMAC.

In addition to the usual knee-jerk "I want my code to be proprietary" attitude, some of the wireless chipset makers (Broadcom included) have engineered themselves into a bit of a pickle. The chipsets are fairly generic, and a lot of the functions are controlled by the firmware, so if they made the firmware open, people could do things like change the frequency the chips broadcast on or do some serious messing with the signal power just by changing the firmware code. I'm reasonably certain that the chipset makers are terrified of government agencies like the FCC landing on them hard if they allowed that sort of nonsense to go on.

I've never seen any rules against linking to LQ from other sites. As long as you're not violating any rules on other sites, it is probably fine.

Believe it or not, tonight is the first time I have ever visited your site. I only took a cursory look, but I'll be sure to give it a better view later on tonight or some time tomorrow.

I did all that, and I have the stuff on my hard drive. It was all installed according to the cryptic instructions. I did fwcutter before I compiled the 2.6.x kernel, and it still failed to find the bcm43xx drivers. There was no mention of those drivers loading at boot time, and no indication they loaded with dmesg. Ergo, I was forced to hop on the ndiswrapper bandwagon. So far, so good.

In that case, I think I'll keep my set up as is. I'm not about to run my wireless router without encryption, and I like the fact that I am running at full throttle 802.11g speed, whether or not the data flows from the internet that quickly. With all the hell I went through trying to get the W/L adapter on this machine working properly, I think I'll keep things as they are for the time being at least. As soon as a better option presents itself, this present configuration works well. There are still some issues with Samba, but, to my amazement, NetBEUI does actually flow across the W/L when I am running under XP. Since I can do W/L file sharing with the rest of my LAN, I am happy. That was one of the things I hoped I would get happening with the W/L adapter.

That makes me wonder what kind of dweebs work for Broadcom. This is 2007. Computer hackers have been a reality since the Commodore 64, if not before. Why on Earth would they make their chips so easily compromised?

I know you don't know any more than I do. I was being rhetorical..hehehe

Still, it makes no sense. One would think that companies would be working towards greater security with their systems, both hardware and software, not the other way. I understand the need for maintaining proprietary secrets. Goddess knows, there are some tactics that are rather unique to the way I do things and run my business that I'll not easily divulge. However, one doesn't have to give away the farm to make sure no one steals the chickens. To me, that seems like a waste of time, effort, and resources.

Then I'll have to add some links to the thread on the Slackware forum. I'm sure if I have gone through hell trying to get things working, Others have as well. Hopefully, those who come to it will read through the entire thread so they get the information about blacklisting and so on. I'd hate to think that somehow something on my machine kept the bcm43xx drivers from loading properly, but on some other machine, that something wasn't there.

Oh, and if you'd like, I can send you the original file so you can add it to your web site. Since it seems you have already set up for doing Linux wireless networking, and you seem to agree that other than some seemingly missing points, my document is of excellent quality, you are more than welcome to it. The more people that work with Linux, the better as far as I am concerned.

Blessed be!
Pappy

With the help of this thread, I just got wireless working between my HP Pavilion ze5730us notebook and a Westell 327W DSL modem/router. Pretty neat -- Thanks.

I didn't try to use WPA encryption. I did try WEP 128 bit encryption, but that didn't work (though it does in Windows XP), so I dropped back to a 64 bit WEP key. I compared upload and download speeds to the Internet with what I got using Windows XP on the same computer -- they're about the same.

as are all the rest of you out there who find this thread informational. I am thinking about doing a complete set of step by step directions for Linux operations. I may not know C++, but I can write step by step instructions on how to make things happen.

I have a few other documents of this kind tucked away in the crazy directory structure one sees under Linux. I may post those as well. Maybe if people weren't so scared of life without Microsoft, there would be a lot more people running Linux; a superior system in every way.

I'm glad I could help. It's the least I can do for the team. hehehe

Blessed be!
Pappy

...I was sitting doing some research on wpa_supplicant. Sometimes, my wireless router likes to hiccup. After it does this, I lose my wireless connection. I was researching to see if there was a way to bring things back into proper operation WITHOUT having to reboot. While I am working under Windoze, all it does is temporarily shut off the wireless connection. It always comes back.

Not so with Linux. After the hiccup, there is no more connectivity until I reboot the effected machine. As anyone with a brain is sure to realize, this is a little less than a good thing, especially when you consider that one of the things I do most with all of my machines is writing stuff for publication at OpEdNews.com and other political blogs. Just today, I spent three hours on one essay. While I usually log into an internet radio outlet in order to keep the connection open, I didn't do so today. I finished my writing just in time to have the router hiccup. While it wasn't a major problem since I had written the essay using K-word, there have been other times when the hiccup occurred while I was in the middle of using a web-based editor.

There is nothing that sucks quite like writing for an hour and a half and having a computer glitch destroy that work. Ergo, I was trying to find out if there was a way to re-initialize wpa_supplicant so I didn't have to reboot. So, I went to the wpa_supplicant web site. There I discovered that there also exists a GUI version of wpa_supplicant known as wpa_gui.

Now the sticky wicket in this story is they don't give you a direct path to make that particular program. No, there is no documentation on "make"ing wpa_gui. There is no mention of it in the documentation. There is no mention of it anywhere other than on the web site above.

Being one to love a challenge, I decided to take a quick look at the makefile in the main directory of the extracted package. Once I found that the string "gui" was actually there in the makefile, I knew there had to be a way to have "make" make wpa_gui.

Here is the beginning snippet of the makefile:
The last line originally ended with wpa_cli. I simply added wpa_gui, and viola, I had a GUI interface for wpa_supplicant.

This obviously begs the question, "have you tried it to see if it will restore your connection?" No, I haven't tried yet. However, I am sure I will get a chance to try it out soon. I'll sign back in once I have the hiccup happen and let everyone know whether or not it was the answer to my problem. If not, at least it's a cool program that allows you to scan for wireless networks and log into them, as long as you have the key. It works a lot faster and more consistently as a wireless network scanner than KWiFiManager.

Blessed be!
Pappy

What does a gui for wpa_supplicant have to do with re-establishing a failed connection?

That's what I wanted to find out. I am in the process of finding a way to get the wireless connection back up once it dies WITHOUT having to reboot. If you had taken the time to read all of that message you would have seen the following...

This obviously begs the question, "have you tried it to see if it will restore your connection?" No, I haven't tried yet. However, I am sure I will get a chance to try it out soon. I'll sign back in once I have the hiccup happen and let everyone know whether or not it was the answer to my problem. If not, at least it's a cool program that allows you to scan for wireless networks and log into them, as long as you have the key. It works a lot faster and more consistently as a wireless network scanner than KWiFiManager.

I posted the message to inform those that didn't know that wpa_gui exists that it does. Before last night, I didn't know it existed, either. Now I do. I have actually had a chance to try it out today. It doesn't work for bringing the network back up fully, however, it is a useful tool for some other things.

Specifically, it allows you to go to places with secured wireless networks and logging into them. It allows you to scan for networks, select one, and enter the passphrase so that you can log on. That's a nice tool to have.

I am still looking for the way to get a sleeping wireless network back up when it stops working, and will continue to look until I find the proper tool. If you know how to do this, I am all eyes.

Thanks

Blessed be!
Pappy

It's valuable information that wpa_supplicant has a hidden gui and thanks for telling us. It might deserve it's own thread.

I've never used wpa_supplicant, so I don't know anything directly relevant. But it seems to me that if you mimic what goes on in rebooting with respect to the network, you might get a connection back. I.e., stop wpa_supplicant, "ifconfig <iface> down", "modprobe -r <iface>", then re-insert the module (whatever it is) with modprobe, and go through the other steps to initialize the network. If there's an appropriate init-script in your system, something like "/etc/init.d/network restart" might do it.

Wpa_gui deserving its own thread might be stretching it a bit. However, it is worthy to note that it at least exists. Considering the pain in the rear it can be to get wpa_supplicant operating properly (it took hours to get it right the first time around), anything that can make working with that particular daemon (well named for its almost Satanic quality) is, to my way of thinking, a VERY good thing.

Considering the steps you list above as a way to get things going without a reboot, I'd much rather reboot. Perhaps when the day comes when I'm much more comfortable writing a script to fix the problem, I might be willing to tackle a restart script for my wireless network. Until then, I'd like to find some way to keep the network from being dropped in the first place.

It's not a problem when I am working under Windoze because Windoze is decent enough to have their wireless control system operate more or less automatically. Linux isn't that nice.

Then again, Linux has come a long way since I first installed Slackware in 1993 on a 486 SX 33 with a math co-processor sixteen megs of RAM, and a ATI Mach series VLB video card. Who knows, maybe someone will hack into whatever magic Windoze uses to automate wireless networking. Until then, I'd like to be able to respond to messages like this one without worrying that the network will fall on its face before I get a chance to hit the "Submit Reply" or "Preview Post" buttons below.

Blessed be!
Pappy

I went through the installation of wpa_supplicant etc. but then got no further. The /etc/wpa_supplicant.conf file contains the lines
but the file /var/run/wpa_supplicant does not exist. Furthermore, I get this:

So it doesn't work, at least for me.