Craig's Guide to the Belkin F5D6020 version 2

The latest version of this document was updated August 25, 2016 05:58 PM.

Commentary, questions and suggestions go here: no spam please

Target Audience

This is my updated guide for new Linux users who have the Belkin F5D6020 version 2 wireless PCMCIA card and would like it to become functional, the original doc, now somewhat out-of-date is here. This card contains an Atmel AT76C502a chipset. This guide also equally applies to any make/model PCMCIA card that contains the same Atmel chipset as identified by it's manufacturer ID numbers, which are: 0x01bf, 0x3302.

Pre-Linux Preparation

If, once booted to Linux you won't have any internet access then you'll need to download the source code for the driver we are going to build ahead of time using whatever facility you're using to view this document. Use the following link and download the latest version (at this writing v3.2.4.4) of the atmelwlandriver source. This is a single, compressed file called a "tarball". Save it to some medium that will be accessible to you after you boot to Linux. If you're dual-booting Windows/Linux then this can be somewhere on your Windows partition. It can also be saved to a USB pendrive, compact flash card in a pcmcia adapter card, memory stick, burned on a cdrom or saved on a floppy disk. The only requirements are that the media have the free space for the source code and is accessible to Linux. Do not use any other OS to unpack the source code "tarball" file, unpack it only after booting to Linux. If you are dual-booting Windows/Linux and this card is working for you in Windows, then you may want to bring up the interface in Windows that allows you to view/set the parameters of the card and print that display so you will have the correct information available for testing and configuring the card after booting to Linux. Once you have your wireless and networking settings recorded and the source code tarball in hand, if you are not already booted to Linux, go ahead and do so.

Why do this at the Console?

One of the reasons that you don't see a particular Linux distribution, such as Slackware, Debian, Mandrake, Redhat, Fedora, or SuSE as part of this guide's title is that by using the console (CLI or command line interface) to compile, install, and test this driver, it can be nearly distribution-neutral and allow this document to apply to as many people as possible. When the time comes to configure your card for your particular distribution, we'll be forking due to the differences in the way various distributions handle network and wireless configuration. From this point onward I'm assuming that you're booted to Linux and that you have a terminal/shell/console window open in front of you. Make sure any commands listed in bold text below are typed in verbatim, case and punctuation are important. You can cut and paste the commands directly into most console windows using the mouse to highlight the text and then your browser's menu to copy it and then right-clicking the console window and choosing 'paste'. The first command I have for you is to become the root user, type: su -, followed by entering the root password, no characters will echo as you type the root password, this is normal. Once you have become the root user, I caution you to not go outside the bounds of the instructions below, you can experiment with commands and such as a normal user, don't experiment as root. Most of the instructions below are "typo-safe" in that if you mis-type something the command will simply fail and no real harm will be done.

Identifying Your Card

You must first determine that you have a card that contains the same Atmel chipset as the Belkin card I'm using and is thus fully compatible with this guide. Understand that the Atmelwlandriver source we'll be building includes support for a variety of other Atmel-based wireless devices and even if your ID numbers are different than below, the Atmel driver may yet be the correct driver for your card. I don't own these other devices and thus will not attempt to help people with devices I don't actually own. Having said that, it's time to identify your device. To do that you'll need to see it's manufacturer ID numbers. These numbers are returned from the command: cardctl ident typed in your root-console with the card inserted. Successful output looks similar to this:

Socket 0:
   product info: "Belkin", "11Mbps-Wireless-Notebook-Network-Adapter"
   manfid: 0x01bf, 0x3302
   function: 6 (network)
Socket 1:
   no product info available

As you can see, socket 0 contains my Belkin card, socket 1 is empty. Whatever the make and model of your particular card is, if "manfid: 0x01bf, 0x3302" is present in the output then this guide applies equally to your device. If not, then don't waste your time here, instead go over to http://www.linux-wlan.org/docs/wlan_adapters.html.gz to determine which driver will work with your card, the page is quite comprehensive and is huge. It will take some time to download. This identification process is extremely important as it keeps you from wasting your time with a card that is not compatible with this guide, and at the same time verifies to some degree that your pcmcia sub-system is installed and working. If something here fails, then see the troubleshooting section for this.

Verifying Your Build Environment

If you've never compiled anything from source code before on your current Linux installation, then now is a good time to verify, and if necessary, prepare what I call your "build environment". If you've already compiled an older version of this source code before, then you will already have an atmelwlandriver top-level source directory located somewhere. Understand that if you unpack the latest source code into the same directory as your existing atmelwlandriver directory, the original directory and all of it's contents will be over-written. If you want to preserve it, you'll need to rename it to something else, such as "old-atmelwlandriver" or anything else that is not "atmelwlandriver". If you're unpacking the latest source elsewhere then this step is not necessary, nor is perhaps the need to verify your build environment, so you can skip ahead if you like. For the rest of you who've not compiled this or any other kernel module before, it's time to check your build environment: you'll need to have the correct kernel sources, the development tools, and the wireless tools installed in order to compile the driver and use it with your card. In your root-console, verify the presence of the compiler, type: gcc --version successful output looks like this:

gcc (GCC) 3.2.3
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Unsuccessful output will look similar to this:
-su: gcc: command not found
You'll also need make and if gcc is installed, most likely make is also, just to be sure type: make --version and successful output looks like this:
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
with unsuccessful output similar to this:
-bash: make: command not found
Next, verify the presence of the correct version of the kernel source, type: ls /lib/modules/`uname -r`/build/Makefile those ` characters around uname -r are not single-quotes the key for them on my keyboard is the lower-case of the tilde (~) character to the left of the numeric 1 key. Successful output looks like this:
/lib/modules/2.4.24/build/Makefile
Your kernel version numbers (2.4.24) will very most likely be different, that's ok. Unsuccessful output will look similar to this:
/usr/bin/ls: /lib/modules/2.6.3/build/Makefile: No such file or directory
Now, verify the presence of the wireless-tools, type: iwconfig despite what my look like negative output, successful output looks similar to below. There may be other lines in addition to "lo" describing any other active ethernet devices in the machine that do not have wireless capability, this is all normal:
lo        no wireless extensions.
Unsuccessful output looks like this:
-su: iwconfig: command not found

If you do not meet with success from all of the commands above, then you'll need to install the appropriate package(s) on your system. Perhaps one of the most defining and differentiating characteristic of any distribution is it's package management system. As such, my instructions on how to use your distribution's package management to install any missing 'packages' are intentionally quite generic. You'll need to do the appropriate research for your distribution in order to determine how to bring up their 'Package Manager'. Menu items for this are typically: "install/remove software", sometimes "package" is used in place of "software" and "administer" or "manage" is used in place of "install/remove", you'll have to find this application on your own. Once you have it up and running, use the search facility (if there is one) and search on "kernel-source" which seems to be nearly universal as the package name for the kernel sources, once found, install it. If you are able to search the filenames contained within the packages (as opposed to the package names themselves) then search on "gcc" to determine what package to install for the compiler. If not, look for packages related to "development", verify which contains the compiler, and install. Do not install just gcc, there are a host of other utilities needed along with gcc, install the whole package. Finally, while you have your package manager up, verify that the package: "wireless-tools" is installed, this package name is also nearly universal. While not necessary for compiling, you will absolutely need them to configure and test your device. Many times these wireless-tools are not installed unless a "recognized" wireless card is inserted at installation time. Obviously, if you're here, your card was not recognized, so they are probably not installed. If something here fails, then see the troubleshooting section for this.

Finally, once you've installed or verified the presence of your kernel-source package, you'll want to make sure that a file named .config (that's a leading dot) exists in your /lib/modules/`uname -r`/build directory (backtics, not single-quotes), the atmelwlandriver Makefile looks for this file and if not present, will end up asking you for the "location of external PCMCIA:". Verify that it exists with ls -l /lib/modules/`uname -r`/build/.config Successful output looks like this and again, your kernel numbers (2.6.3) will most likely be different:

-rw-r--r--    1 craig    root        27097 Mar  6 10:58 /lib/modules/2.6.3/build/.config
and unsuccessful output looks like this:
/usr/bin/ls: /lib/modules/2.6.3/build/.config: No such file or directory

To correct this problem you'll need to copy the kernel config file from your /boot directory to your build directory, try this command: cp /boot/config-`uname -r` /lib/modules/`uname -r`/build/.config (backtics, not single-quotes), if it fails then you'll need to ls /boot and determine from the file listing what the actual filename of the correct kernel config file is and substitute it for the "config-`uname -r`" part of the command above.

Unpacking the Source Code

You'll now need to mount the medium you used previously to store the source code tarball and copy or move it to a directory on your Linux partition. Alternatively, if within Linux you have a working connection to the internet and don't yet have the source tarball, then download the latest atmelwlandriver source now. Either way, the file can be copied to any directory and unpacked there, but your home directory (yours, not root's) is the best choice. Your home directory is typically /home/ followed by your username, for instance, my home directory is /home/craig. If you're having trouble mounting the media or copying the source tarball file to your home directory then see the troubleshooting section for this.

At this point there should be a file named atmelwlandriver-x.x.x.x.tar.bz2 in your home directory, the x's represent the version numbers. Now, change to your home directory in your root-console by typing: cd /home/your_user_name, then type: tar jxf atmelwlandriver-x.x.x.x.tar.bz2. Make sure to substitute the actual complete filename of the file you downloaded, to see it, type: ls. A new directory(folder) will be created named atmelwlandriver, to see if all is well type: ls atmelwlandriver and you should see some files. My output looks like this:

CHANGES  COPYING  CVS/  Makefile  README  man/  objs/  patch/  scripts/  src/
At this point if you're short on space you can delete the tarball (atmelwlandriver-x.x.x.x.tar.bz2) file. If you have trouble unpacking the file, see the troubleshooting section for this.

Compiling the Driver

First, change to the atmelwlandriver directory, type: cd atmelwlandriver. Now, configure your options, type: make config. You'll be presented with a list of yes/no questions, answer all of them by typing: n or just <enter> except the 3 indicated below with the =>, which should be answered with a y:

Build all [y/N] :
Set extra module version information [y/N] :
Build Debug version [y/N] :
Build USB Drivers [y/N] :
=> Build PCMCIA Drivers [y/N] : y
Build PCMCIA rfmd Driver [y/N] :
Build PCMCIA 3COM Driver [y/N] :
=> Build PCMCIA rfmd revision d Driver [y/N] : y
=> Build PCMCIA rfmd revision e Driver [y/N] : y
Build PCMCIA 504 Driver [y/N] :
Build PCMCIA 504+2958 Driver [y/N] :
Build PCMCIA 504A+2958 Driver [y/N] :
Build miniPCI Driver [y/N] :
Build applications [y/N] :

Understand that these instructions apply to v3.2.4.4 of the driver, later versions may have additional questions, so use your discretion if you have a newer version of the source. When the configuration is complete you'll then be prompted to run make clean and then make all, follow these instructions and when the compiling is complete the drivers will be in the objs directory, to see if all is well, type: ls objs, you should see the file pcmf502rd.o and pcmf502re.o among the others. In direct contradiction to my previous document, and because of all the improvements to the driver source, most of you will now want to install and use the revision e driver (thanks to Lars Olson for pointing this out to me). For some of you, revision e simply will not work and you will need to fall back to the revision d driver instead. Both revision d and revision e work with my card. Revision e is preferred because it blinks the light until the card is associated which is the same behavior exhibited by the Windows driver. Revision d does not blink the light. For those of you who have other Atmel-based wireless ethernet devices such as a USB or PCI adapter, or perhaps something Atmel built-in to your notebook, your best bet is to compile everything, answering "y" to all questions except for "Build Applications". If something here fails see the troubleshooting section for this. If you're using the email address at the top of the page to let me know that the compile failed, then please include the entire output of the failed compile by cutting and pasting it from the console to your email client or a text file for attachment.

Installing the Driver

This is accomplished by typing: make install after the driver is compiled successfully. Among other things, that command copies the driver modules to the correct place and adds a file named atmel.conf which contains the needed definitions for the card to the /etc/pcmcia directory. Other than notifying cardmgr that it needs to re-read it's configuration files to include the new definitions created by the "make install" (which we'll get to in the next section), that's all there is to installing, really.

Testing the Driver

At this point your driver has been compiled and installed, now we'll run a few tests to verify it's operation. The atmel.conf file that was copied to your /etc/pcmcia directory contains the correct card definition for the manfid numbers of our cards and specifies the loading of the revision e driver upon card insertion. Before attempting to use the driver, you'll need to get cardmgr to re-read it's configuration files which will apply the changes that the make install made to the system. Do this with: kill -s SIGHUP `pidof cardmgr`, once again, those are not single quotes, instead they are called "backtics" and reside as the lower-case of the tilde (~) key on my computers. Don't be put off by the command's name (kill), nothing will be killed, instead cardmgr will receive the SIGHUP signal and re-read it's configuration file(s), effectively applying the changes. Now that the changes have been applied, if your card is not inserted, insert it now. If your card was already inserted, re-insert it with this command: cardctl eject && cardctl insert, no need to physically remove the card and more importantly, there is no need to reboot the computer, until you've finished the configuration section, rebooting will cause all settings to revert to their "unset" state and you'll have to start the testing phase from the beginning again. So, unless directed: do not reboot.

Whether you physically or programmaticly inserted your card via cardctl, you should have heard a higher-pitched beep followed by another of equal pitch, if you heard a high-pitched followed by a low-pitched beep, go ahead and hit the troubleshooting link in this section. If your computer does not normally emit any "beeps", that's ok, we're going to check things out more thoroughly in the next paragraph. You should also see that the lights on the card are lit and (with revision e of the driver) one is blinking, indicating that the card is "not associated".

First, see if the correct module is loaded by typing: lsmod, pcmf502re (the .o extension will not be listed) should be somewhere in the list. Next, see if a device was created for your card, the devicename is going to be atml0, that's a zero not a capital o. If by some strange coincidence you have another device which uses this driver also, then the first device will be atml0, the 2nd will be atml1 and so on. Type: iwconfig and there should be a listing for atml0 showing some info about it's settings and status. Successful output of the as yet unconfigured card contains this listing, and one of the lights should be blinking:

atml0     ATMEL REVE  ESSID:""
          Mode:Managed  Channel:4  Access Point: FF:00:00:00:00:00
          Bit Rate:11Mb/s
          RTS thr=2347 B   Fragment thr=2346 B
          Encryption key:off
          Link Quality:40  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Note: If you don't have WEP enabled on your access point(a really bad idea) and it's within range, you may never actually see the above listing where the card is not associated. In that case, your card will most likely already be "auto" associated with your access point and what you'll see for "Access Point:" and "Signal level:" will be different.

Now, type: ifconfig -a and atml0 should show up again having as of yet no IP address. Successful output contains this listing with the "Interrupt" and "Base address" at the bottom containing meaningful numbers, not zero's:

atml0     Link encap:Ethernet  HWaddr 00:30:BD:D0:76:D4
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:3 Base address:0x100

So far, so good. Now, we're going to manually configure the interface. This is not how you'll configure it for normal, everyday use, this kind of manual configuration is for testing purposes only. Having said that, first you'll want to manually configure the wireless parameters, but before we get to that let me just say that in testing all this I found consistently that all that was necessary was to setup my WEP key, all the other possible wireless settings had been "auto" detected, so, WEP users try this first: iwconfig atml0 key xxxx-xxxx-xx where the x's represent the digits of your hexadecimal WEP key. Non-WEP users will more than likely be looking at an already associated card and literally no iwconfig should be necessary, if this is not the case, then do this : iwconfig atml0 mode Managed channel 6 rate 11M essid linksys. The preceding "example" wireless settings for channel and essid are taken directly from the factory defaults of what seems to be a very common Linksys wireless access point (if Kismet is any indication ;^). I'm going to continue to use this router's setup as my "example settings" in the commands that follow. Obviously, you need find out what the actual settings for your access point are and to substitute the correct essid name, and channel number in the commands that follow. Now, verify that your settings have been applied: iwconfig atml0, the output is going to look similar this:

atml0     ATMEL REVE  ESSID:"linksys"
          Mode:Managed  Channel:6  Access Point: 00:03:2F:06:F4:13
          Bit Rate:11Mb/s
          RTS thr=2347 B   Fragment thr=2346 B
          Encryption key:0123-4567-89   Security mode:open
          Link Quality:40  Signal level:96  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

The main thing to look for is that "Access Point:" is no longer FF:00:00:00:00:00 and that, if present, your WEP key is listed correctly, and that the "Signal level" is not still 0, Link Quality maxes out at 40, not 100 so in the output above I'm at 100%, Signal level and Noise level will vary from 0-100 with the Noise level typically being the inverse of the Link Quality. If you don't see the right settings, wait a few moments and re-try your iwconfig command(s). If all is well, the blinking light on the card will now have become solid, indicating that the card is now fully "associated" with your access point, including WEP key if enabled.

Next, you'll want to give the card a temporary, valid, static IP address for your wireless network, to do this you'll need to know the IP address of your access point and add 1 or more to the last digit or set of digits. In the Linksys factory-default example that we're using, the access point's IP address is 192.168.1.1, so I'll add 9 to it and use 192.168.1.10 in the examples that follow, again, if your access point is different, substitute the correct numbers. For instance: if your access point is 192.168.2.1, then use 192.168.2.10 as the static address for the atml0 interface. Continuing with our Linksys factory-defaults example you would type: ifconfig atml0 192.168.1.10 and then: ifconfig (no parameters), you should see atml0 listed and having the IP address you just assigned to it. Successful output contains this along with listings for the interface "lo" and any other active ethernet interfaces:

atml0     Link encap:Ethernet  HWaddr 00:30:BD:D0:76:D4
          inet addr:192.168.1.10  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:452 (452.0 b)
          Interrupt:3 Base address:0x100

Now you can attempt to ping to your access point. Type: ping -I atml0 -c 4 192.168.1.1, successful output looks similar to this:

PING 192.168.1.1 (192.168.1.1) from 192.168.1.10 atml0: 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=127 time=5.09 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=127 time=2.30 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=127 time=2.31 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=127 time=2.32 ms

--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3036ms
rtt min/avg/max/mdev = 2.307/3.008/5.091/1.203 ms

Unsuccessful output contains negative words like "unreachable" or "100% packet loss". The "-I atml0" in the ping command above is to assure that the pings are being sent using your new wireless interface and not via another ethernet device that may be present and operational in the same machine.

If you've made it to this point, then your card is actually fully functional right now, and all that remains is a couple of network settings and then a quick ping to the internet. If you have another, working ethernet device in your machine and it is currently your access to the internet via your router, then the below commands will render it temporarily unusable as the atml0 device attempts to take over the internet chores. If something below fails and you want to get back the "other" device's connection to the internet, the easiest way is to run ifconfig atml0 down and then ifconfig eth0 up, where "eth0" is an example of the other interfaces's devicename which should be viewable via ifconfig, the interface "lo" is not the one you want. Typically, the other interface will have lost it's "default" route, which you'll need to add back to it with route add default gw 192.168.1.1 eth0, again using our example Linksys router's IP address and "eth0" as an example of the "other" device's name. Hopefully, you won't need to re-enable the "other" interface. If the following ping to the internet works, you should then be able to bring up your favorite Linux web browser and surf the web and generally do anything else requiring internet access. But first, you'll need to add a "default" route for the atml0 interface. Again, using our Linksys example the command would be: route add default gw 192.168.1.1 atml0, and then you'll want to add your access point as the DNS server for your system: echo 'nameserver 192.168.1.1' >> /etc/resolv.conf, make sure the single-quotes are included in that echo command and that you resist the urge to reboot after changing your network settings. Again: don't reboot. *grin*. Now, try and ping the HouseOfCraig server by name: ping -I atml0 -c 4 houseofcraig.net. Successful output looks like this:

houseofcraig.net (63.111.67.9) from 192.168.1.10 atml0: 56(84) bytes of data.
64 bytes from ns3.actwd.net (63.111.67.9): icmp_seq=1 ttl=43 time=46.8 ms
64 bytes from ns3.actwd.net (63.111.67.9): icmp_seq=2 ttl=43 time=42.3 ms
64 bytes from ns3.actwd.net (63.111.67.9): icmp_seq=3 ttl=43 time=40.2 ms
64 bytes from ns3.actwd.net (63.111.67.9): icmp_seq=4 ttl=43 time=45.7 ms

--- houseofcraig.net ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3031ms
rtt min/avg/max/mdev = 40.268/43.808/46.836/2.634 ms
and unsuccessful output looks like this:
PING houseofcraig.net (63.111.67.9) from 192.168.1.10 atml0: 56(84) bytes of data.
From 192.168.1.10 icmp_seq=1 Destination Host Unreachable
From 192.168.1.10 icmp_seq=2 Destination Host Unreachable
From 192.168.1.10 icmp_seq=3 Destination Host Unreachable
From 192.168.1.10 icmp_seq=4 Destination Host Unreachable

--- houseofcraig.net ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 4627ms, pipe 3

Of course, if you've had problems with this testing section see the troubleshooting section for this. But before you do, understand the actual settings used in the "examples" above are for a common, factory-defaults Linksys wireless access point/router which I don't even own. If that's not exactly what you're connecting to, then find out what the actual settings are on your access point or router for channel and essid as well as WEP key (if enabled), and of course, what it's actual IP address really is. If your access point is for multiple protocols (ie: 802.11g, 802.11a, 802.11b) then you may need to set it for a max rate of 11Mbps. Additionally, if something called "MAC Filtering" is enabled on your access point, then you must add your Belkin(atmel) card's MAC address (as returned by ifconfig -a) to the "allowed" list. I forgot about the MAC filtering thing on the last 5 of 6 devices that I bought, please, don't make the same mistake.

Final Configuration

By now you've been enjoying some wireless freedom and have begun to think about what's going to happen should you not be able to control yourself and spontaneously reboot the computer ;) This is where configuration comes in. The things you'll do in this section will preserve the settings for your wireless interface between reboots, and whenever the card is ejected and then inserted, and perhaps also on a resume from suspend, depending on if your particular notebook requires stops and restarts the PCMCIA sub-system on a suspend/resume. While I believe I've succeeded at remaining "distro-neutral" up until this point, that can no longer be maintained as there are fairly large differences in the configuration of this interface depending on your distribution.

First, I'm going to tell you that I have these distros installed on my notebook: Mandrake 9.0, 9.1, 9.2 - Slackware 9.0, 9.1 - Redhat 9.0 - Fedora Core 1 - Knoppix 3.3 on the hard-drive which is essentially Debian Sid. I have tested this card and these configuration instructions with all of them. What I have not done is test these instructions with your computer and any distro not listed. Even when using the exact same distro, there may be slight differences depending on things like your computer's bios and it's settings, whether you're using ACPI or APM and a few less important differences that very most likely exist between our computers. Having said that, the configuration details below should work for you unless you're using a radically different kind of distro, Gentoo comes to mind. Once again, if you're new to Linux, I respectfully suggest you go with one of the older more "mainstream" distributions until you're more familiar with Linux. And yes, the lack of SuSE in my list of installed distros is appalling ;), it's nothing personal, I just haven't yet found a place for it. From what I have seen it should configure using the Redhat-style of setup. See your documentation if there's any doubt, and from what I have heard and experienced nobody's graphical configuration tools will end up yielding usable results for this driver/card, so please: don't use them on this interface!. In fact, they will most likely cause problems that will have to be undone.

The breakdown as I see it, is that there are basically 3 unique "styles" of wireless network configuration: Redhat-style, Slackware-style and Debian-style. While there are more distributions than can easily be counted anymore, the vast majority "descend" from these 3, meaning they are typically built as extensions to or variations of those above. Again, not having any direct SuSE experience apart from the latest 9.0 "Live CD" test-drive (which I found delightful), I'm not including SuSE in either my assessment above or the instructions below. When I get it installed somewhere it will be represented here equally.

So the first thing to do is identify which style your particular distro is, obviously if it's named Redhat or Fedora Core, then that makes it easy. If on the other hand it's named something else like Lindows (based on Debian) or JAMD (based on Redhat) or College Linux (based on Slackware) then it's not so easy for the new person to Linux to know. Here's how to find out what your distro's "style" is:

Before we get the actual meat of configuration, let me say quickly that there are a variety of other ways within Linux to achieve our goal of getting this card configured to come up on boot, and after a re-insertion or on a resume from suspend. I strive in the instructions below to comply as completely as possible with the distro's "normal" style of network configuration in the hope that at some point in the near future their GUI config tools will recognize this card/driver and include it like any other normally supported device. Until then, configuration is going to be text-editor territory.

to be continued...(under construction)


Troubleshooting

Trouble Identifying the Card

Trouble Mounting Media

I'm not going to repeat here all of the fine documentation that's been included in your distribution to help you learn to mount and umount various media in Linux. Mounting and un-mounting media is one of the more fundamental tasks you'll need to become proficient in, as well as how to find help on a command, so man mount is a good place to begin.

Here are some general guidelines for mounting your Windows partition(s) in Linux: I'll also tell you about a couple of devices I own that would be suitable for the purpose of storing the source code, they are:

cdrom or cdrw or dvd drives (IDE) will also show up as /dev/hd<letter><digit>, I don't own any true SCSI drives so you'll need to type: cat /etc/fstab to see how your distro sets up the drive for mounting, man fstab will help you to decifer it.

Floppy drives are typically: /dev/fd0, you mount them with mount /dev/fd0 /mnt/floppy, if, which is likely in this scenario, the floppy was formatted under Windows and mount doesn't see that then mount it with this: mount -t fat /dev/fd0 /mnt/floppy the files on the floppy will be available under /mnt/floppy/. Un-mount with: umount /mnt/floppy.

General Un-mounting tips

Trouble Preparing the Build Environment

If you've come to this section of the Troubleshooting area it can only mean you're having trouble either finding and running your distro's 'package manager' or trouble using it to determine whether the kernel-source, development and wireless-tools packages are installed or having trouble using it to install them. First, seek help on using the package manager in the documentation that came with your distro, or perhaps a "help" menu item or button on the package manager itself. There is an outside chance that your chosen distro doesn't use packages at all and therefore there is no package manager (Linux From Scratch(LFS) comes to mind), if that's the case, and you're new to Linux, then I respectfully suggest you switch to a distro that uses packages until you are more familiar with Linux.

I'm trying hard to be distro-neutral here and although I have many different distros installed, I'm not going to go into each distro's specific packaging/package management which may change with new releases and then obsolete those kind of specific instructions anyway. What I will say is that virtually all distros that use packaging have provided packages for the kernel-source, development utilities and the wireless-tools (pcmcia-cs also). The previous names containing dashes are nearly universal across distros for their respective package names. So before you go running off to begin the process of compiling iwconfig or gcc from source, I suggest you take another look at the menus, any online help and perhaps some Linux forums as well. Besides being a waste of time, that "solution" has it's own set of pitfalls and you were really just trying to get your wireless card working, right?. If you still can't turn up anything that looks like a package manager, try running: (if it's installed on your system) apropos install, or apropos package, the lists returned from those commands will contain perhaps a clue as to what the names of packages are on your system and perhaps at least the command-line programs you can use from your console to query what packages are installed and to install what's missing.

I don't recommend that you solve the missing kernel-source issue by downloading what looks like a match from http://kernel.org/. It's true that they are the absolute authoritative repository of the official kernel sources, yet your distro is likely to have modified that source to suit them and that's why they provide their own kernel-source package. There are some notable exceptions to this, but typically, even those distros that don't modify the kernel source still provide a kernel-source package, so use your distro's kernel-source package only.

Trouble Unpacking the Source Tarball

If you're having trouble unpacking the atmelwlandriver source code tarball, then you're probably getting an error message returned from the tar command. It's virtually impossible these days to find that the tar program has not been installed, you would have had to dig deep to eliminate it at install time, and you would most likely have been warned not to do that. If tar is really not installed then there are most likely a lot of other things wrong with your install and I suggest you re-install and decline to use any "expert modes" this time.

Possible reasons why the tar command would fail: (yes, I have made all these mistakes, more than once ;^)

Trouble Compiling the Source

The most common cause of errors when you type make all is improper kernel-source. Either the kernel-source is not installed, or it doesn't match the running kernel's version, please re-check your kernel-source installation and the contents of your /usr/src/linux-`uname -r` directory. Some distro's "Updates" can leave your system out-of-sync, see your distro's homepage/forums for help on this. The older versions of the atmelwlandriver source had some problems finding the kernel-source, the latest version(s) does not. So, make sure you downloaded the latest version, I no longer recommend the old "snapshot" source tarball that was the last to support the Intersil radio, your card doesn't have an Intersil radio, so use the absolute latest source available as it contains many improvements.

Another very common mistake that will leave you with no drivers in your atmelwlandriver/objs directory is answering the yes/no questions that you get from running make config incorrectly. If you'd like to start fresh, run: make realclean and then begin again with make config.

Trouble Testing the Driver

this section not yet written

Trouble Configuring the Interface

this section not yet written