The last update to this document was on September 17, 2005 04:37 PM. If that's more than a week ago, you are probably looking at old information, you can get the latest version here
This is my updated guide for new Linux users who have Texas Instruments' acx100 or acx111 based devices and would like them to become functional, the original doc, now rather out-of-date is here and not maintained. This guide applies to any make/model device that actually contains the acx100 or acx111 chipset, including CardBus (PCMCIA) cards, PCI cards, and USB devices. If you're wondering whether your device(s) contain that chipset, then read on, since one of the very first things we're going to do is determine that very thing so you don't end up wasting your time trying to use the acx100/111 driver on a non-acx100 or non-acx111 device. This guide is based entirely on using the open source driver located at acx100.sourceforge.net because it's my opinion that this open-source driver project offers the most robust, feature-filled, and stable driver available for these devices.
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 to download the same, recent source version that I'm using and have tested and verified to be functional with my devices (which may not necessarily be the absolute 'latest' version). Here's the link: acx100-0.2.0pre8_plus_fixes_51.tar.bz2. This is a single, compressed file, called a "tarball". While there may indeed be a newer version, this guide is based entirely and only on the version and link listed above, and only that version (remember, this driver is still considered 'experimental' and incremental versions can have their problems and are intended for testing purposes). Save the file to some media that will be accessible to you after you boot into 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. You will also need the firmware, so download it here: acx_firmware.tar.bz2. Do not use any other OS to unpack either of these "tarballs", unpack them 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 or make note of 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 and firmware tarballs in hand, if you are not already booted to Linux, go ahead and do so.
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, we 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 from your browser into most console windows using the mouse to highlight the text and then your browser's menu to copy it, and then either right-clicking the console window and choosing 'paste' or using the middle mouse button in your shell/console/terminal window.
The first command I have for you is to temporarily 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, upon success, your command prompt should be different and typing whoami should return: root. Once you have become the root user, I would caution you to not go outside the bounds of the instructions below, you can (and should) experiment with commands as your "normal" user, but don't experiment as root. Most of the instructions below are fairly "typo-safe" in that if you somewhat mis-type something the command will simply fail and no harm will be done, however, grossly mis-typed commands could conceivably do enough damage to your linux setup that you'll have to re-install, so, please, type carefully, or use cut/paste.
You must first determine that you have a device that contains a chipset that is compatible with the acx100/111 driver and this guide. Understand that due to continuing unfortunate and ill-advised model naming by some device manufacturers, there is a lot of confusion about this issue, please verify your chipset as instructed, and do not trust the model number on your device. Chipsets internal to these devices have and will change unannounced, you must verify before continuing in order to save yourself the headache of trying to use the wrong driver with your device. Having said that, it's time to identify your device. To do that you'll need to run lspci -n with your PCI card installed and/or your CardBus card plugged in. Successful output looks similar to this:
# lspci -n 00:00.0 Class 0600: 8086:7192 (rev 02) 00:02.0 Class 0607: 104c:ac16 (rev 02) 00:02.1 Class 0607: 104c:ac16 (rev 02) 00:03.0 Class 0300: 10c8:0004 (rev 01) 00:07.0 Class 0680: 8086:7110 (rev 01) 00:07.1 Class 0101: 8086:7111 (rev 01) 00:07.2 Class 0c03: 8086:7112 (rev 01) 00:07.3 Class 0680: 8086:7113 (rev 01) 05:00.0 Class 0280: 104c:8400
That listing is taken from running lspci -n on my ThinkPad 600 with my SMC 2435w CardBus card plugged in. Out of those 9 lines listed, we're only interested in that last one:
05:00.0 Class 0280: 104c:8400
because it contains one of the 3 combinations listed below at it's end:
If the lspci -n command comes back with something like "command not found" then most likely you have not used the su - command properly to "become" the root user, you may have used only the "su" part of that command without the " -", which will not work the way we need it to. If that's the case, then type exit followed by: su - and then the root password and please learn that every character, and every character's case are important when using Linux and then make sure to type all commands exactly as listed. Anyway, back to the task at hand, if you're not using a USB device and don't see one of those combinations listed above anywhere in the lspci listing, then sadly, I can't say with any certainty that the acx100 open-source driver or this guide will be of any assistance to you, in fact, it will definitely not since you don't have a supported device. USB device owners, for now, you'll just have to trust your model number, since at this time there is only one USB device available that uses the acx100 chipset that I'm aware of: it is the D-Link DWL-120+ (which I own and am using/testing), with heavy emphasis on the "+" part of that model number. Regular DWL-120 (notice, no "+") USB devices are not acx100 based, they are either Atmel(H/W:E1) or Prism(H/W:D1) based (I own the H/W:D1 model). For PCI/CardBus card owners, whatever the make and model of your particular card is, if you don't see one of those 3 combinations of numbers, then don't waste your time here, instead go over to http://www.linux-wlan.org/docs/wlan_adapters.html.gzto determine what chipset is in your device, and hopefully, what driver will work with your card, that page is quite comprehensive and is therefore huge. It may take some time to download completely to your browser. Understand that this identification process is extremely important as it keeps you from wasting your time with a device that is not compatible with this guide, and at the same time verifies to some degree that your cardbus/pcmcia/usb sub-system is installed and working. If lspci returns what you think is your acx100 device with a lot of f's on it's line, and you're using a CardBus(PCMCIA) card, then see the troubleshooting section for this.
Next, we need to discover if your chosen distribution of Linux has already installed an older version of this driver on your system. If you're using a recent release (Mandrake and SuSE users take notice!), then there is a decent chance that an older version of this driver is already installed on your system, so this step is absolutely necessary if you want to use the very recent version of the driver that we'll be building in the following sections. You may now be wondering why this older version of the driver hasn't rendered your card functional. This is typically because while several distributions of Linux now provide the driver module, they do not provide the necessary firmware in their download editions, the boxed versions of some of these distros correct this problem.
First, let's see if a driver is already installed, so type: find /lib/modules/`uname -r` -name "*acx*", (those are not single-quotes around uname -r, they are backtics and are the lower-case of the "~" key on my keyboard). If there is no output from that command and you are simply returned to your command prompt, then no driver is already installed and you should proceed on to the next section. If you get something back with "acx100_pci" in it, then your distro has installed a very old version of this driver and you need to get it out of the way before proceeding. If you get something back with "acx_pci" in it, then it's possible that the already-installed driver will work, and all you need to do now is install the firmware, to give that a try, you can jump to this section. Suse users: If you are going to use Suse's built-in acx_pci module, then understand that it's compiled to look for the firmware in /lib/firmware, not /usr/share/acx, so please bear this is mind and modify your firmware location accordingly. Some other distros that provide pre-compiled acx_pci modules compile them to look for the firmware in /usr/lib/firmware.
Notice: If your card was identified as a 104c:9066 in the previous section and an older driver was found (above), then I will insist that you take the following steps to get the older driver out of the way and then continue on with building and installing a newer driver. Most of the improvements in the driver are targeted at these devices, and far more importantly, WEP for these devices is supported only in this latest version: 0.2.0pre8_plus_fixes_51 or later. I'm going to repeat that again: WEP for acx111 devices (lspci -n = 104c:9066) is supported only in version: 0.2.0pre8_plus_fixes_51 or later, so please upgrade, even if your distro has provided it's own version of the driver, it will most certainly not have WEP support. In keeping with this warning, I do not want to hear from people trying to use earlier versions and WEP with their acx111 devices. So, please, read and understand: only 0.2.0pre8_plus_fixes_51 and later support WEP for acx111 devices, any earlier version does not.
Moving old drivers out of the way
If an older driver was found on
your system (above) and you'd like to move it out of the way, then type:
find /lib/modules/`uname -r` -name "*acx*" -exec mv {} /root \;
to
move the older driver to your /root directory. I've placed that command on it's
own line because you need to be careful to get it right the first time, I
recommend you cut/paste it. Then, type: depmod -a to update the module
dependencies, it may take a while to complete. You can verify that the old
driver was moved by typing: ls -ltr /root and it should be the last line
in the list, then continue on to the next section.
If you've never compiled a kernel module* (note this is not the same as compiling the kernel) from source code before on your current Linux installation, then now you must verify, and if necessary, prepare, what I call your "build environment". If you've already compiled some other kernel module, or an older version of the acx100 source code before on your current Linux installation, then your build environment is most likely fine, and outside of verifying the presence of the wireless tools, this step is not necessary, so you can skip ahead if you like. For the rest of you who've not compiled this or any other kernel module before (note: compiling a kernel module is not the same as compiling other applications, and has different requirements), it's time to check your build environment: you'll need to have the correct kernel sources, the listed development tools, and the wireless tools installed in order to compile the driver and then use it with your device. In your root-console, verify the presence of the compiler, type: gcc --version successful output looks like this with your version (3.2.3) possibly being different, that's ok:
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, but just to be sure type: make --version and successful output looks like this with your version (3.80) possibly being different, that's ok:
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/include/linux/version.h 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.6.10/build/include/linux/version.h
Your kernel version numbers (2.6.10) will very most likely be different, that's ok. Unsuccessful output will look similar to this:
/usr/bin/ls: /lib/modules/2.6.10/build/include/linux/version.h: No such file or directory
Now, verify the presence of the wireless-tools, type: iwconfig despite what may 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 (those are backtics, not single-quotes). 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 to view the contents of your /boot directory and determine from the listing what the actual filename of the correct kernel config file is and then substitute it for the "config-`uname -r`" part of the command above.
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 acx100-0.2.0pre8_plus_fixes_51.tar.bz2 tarball 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 acx100-0.2.0pre8_plus_fixes_51.tar.bz2 in your home directory. Before unpacking it, change it's owner to your normal username, type: chown your_normal_username /home/your_normal_username/acx100-0.2.0pre8_plus_fixes_51.tar.bz2. Now you'll want to briefly switch users back to your normal username, so type: exit. Next, change to your home directory in your now non-root console by typing: cd /home/your_normal_user_name, then type: tar jxf acx100-0.2.0pre8_plus_fixes_51.tar.bz2. Make sure to use the actual complete filename of the file you downloaded, to see it, you can type: ls. A new directory(folder) will be created named acx100-0.2.0pre8_plus_fixes_51, to see if all is well type: ls acx100-0.2.0pre8_plus_fixes_51 and you should see some files. My output looks like this:
ChangeLog Configure* LICENSE Makefile README TODO config.mk doc/ firmware/ include/ scripts/ src/
At this point it's time to go back to being the root user, so once again type: su -, followed by the root password. If you have trouble unpacking the file, see the troubleshooting section for this.
First, change to the acx100-0.2.0pre8_plus_fixes_51 top-level directory, type: cd /home/your_normal_username/acx100-0.2.0pre8_plus_fixes_51. Now, build the driver, type: make and oddly enough, successful output has these as it's last 2 lines:
*** Compilation finished. Make sure to copy required firmware files to /usr/share/acx/ before proceeding! *** make[1]: Leaving directory `/home/craig/acx100-0.2.0pre8_plus_fixes_51/src'
You will no doubt have something different for the "/home/craig" part of that, that's ok. 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 add it as an attachment. To help you, I need to see what happened.
Driver:
To install the drivers (PCI/Cardbus/USB) type: make
install. This will copy the files you just compiled to a location under
/lib/modules/`uname -r` and then run depmod to update your module dependencies.
It will not do any configuration for you.
Firmware:
Next, you'll need to take care
of installing the firmware. The easiest way to do this is by downloading this
file: acx_firmware.tar.bz2
to your home directory and then unpacking it with this commmand: tar Pjxf
/home/your_normal_username/acx_firmware.tar.bz2. Take care to type that
command exactly as listed and it will both create and then populate a
/usr/share/acx directory with the same firmware that I use and have tested with
both my acx100/acx111 CardBus cards and my acx100 USB adapter. To verify that it
succeeded you may type: ls /usr/share/acx and this is what it should look
like:
root@Slack91:/home/craig/acx100-0.2.0pre8_plus_fixes_43# ls /usr/share/acx ACX100_USB.bin RADIO0d.BIN RADIO11.BIN RADIO15.BIN TIACX111.BIN WLANGEN.BIN
If all looks good you can proceed to the next section. Otherwise, if you'd prefer to use the firmware from your own Windows' driver CD then this is what you need to know: These are separate small files found on the Windows' driver CD or in a downloaded Windows' driver archive. For the acx100 they are named: RADIO0d.BIN, RADIO11.BIN, RADIO15.BIN, and WLANGEN.BIN. For the acx111 they are named gplus.bin, FwRad16.bin, FwRad17.bin, TIACX111.BIN. and for the dwl-120+ usb device: ACX100.bin, which must be renamed to ACX100_USB.bin for use with this driver. You'll need to first create the directory where they need to be installed, type: mkdir /usr/share/acx, this is the "default" directory that the driver now looks in for the firmware. Then you'll need to copy the aforementioned files to that directory, taking care that their names are preserved, and if necessary changed to be exactly as listed above. You may not have all of them in your Windows' driver, just copy the ones that you do have. Use this command 'template' to copy the files: cp /fullpath/to/firmware/filename.ext /usr/share/acx, where you'll substitute the actual full path to where they are located for the "/fullpath/to/firmware" part and substitute the filename's listed above for the "filename.ext" part. When finished placing the firmware in the /usr/share/acx directory. If you're unsure of what files to copy and/or what they should be named, then consult the section in the acx100 team's readme (acx100-0.2.0pre8_plus_fixes_51/README) beginning with "=== FIRMWARE INSTALLATION ===".
Alternatively, if you have a working internet connection in this machine, you can type make fetch_firmware (with your device installed or plugged in) and you will be met with this:
# make fetch_firmware scripts/fetch_firmware Locating a suitable download tool... Searching for ACX1xx cards on this system... DETECTED ACX100-based wireless card! Which firmware files package would you like to download? a) for ACX100 (TNETW1100) chipset based cards b) for ACX111 (TNETW1130/1230) chipset based cards c) for both chipsets d) none > c
Enter your selection and when it has finished, successful output looks like this:
Extracting driver file ./dwl520+_drivers_307.zip...Archive: ./dwl520+_drivers_307.zip Done. Extracting driver file ./dwl-g650+_drv_v1.0.zip...Archive: ./dwl-g650+_drv_v1.0.zip Done. Finished! (Hopefully!) If something failed, then please report it!
After running the make fetch_firmware, you will now have all the firmware files (not including the usb firmware) in the acx100-0.2.0pre8_plus_fixes_51/firmware directory. You should then copy those files to /usr/share/acx, type: cp firmware/* /usr/share/acx.
Dwl-120+ (USB) device users will need to locate the file: ACX100.bin on their Windows' driver CD, or perhaps in a downloaded zip file and copy it to the /usr/share/acx directory, making sure to rename it to exactly this: ACX100_USB.bin.
At this point your driver has been completely compiled and installed. You may now be tempted to bring up whatever GUI tool for configuring network cards came with your distribution, understand that I can't help you if you use one of these tools to configure this device. The tool may work, or, it may not, and if it fails, it will most certainly do a number of things that will have to be undone, and, not having every version of every Linux distro installed on my machines, I won't be able to tell you what needs to be "undone". So, please: do not use your distro's network configuration tool on this interface. USB device users, this applies to you also, just take note of the extra edit required.
To bring your device up, you will want to open the file named start_net found in the /home/your_normal_username/acx100-0.2.0pre8_plus_fixes_51/scripts directory using your favorite text editor. Here's what the editable area of that script file looks like, don't modify anything else unless you run into trouble:
# Please edit below
# syntax is: VARIABLENAME=VALUE, with _no_ spaces in between
# make sure to _preserve_ any double-quotes (")
# text beginning with the comment delimiter (#) is ignored
# make sure to _preserve_ at least one space before any
# comment delimiters (#) that do not begin a line
# "uncommenting" a line means to remove it's leading "#" character
ESSID="network_down" # THIS IS CASE SeNsItIvE!! any == associate to any ESSID
# Default rate configured as 11Mbps to not cause speed problems (while
# using auto rate) or connection problems (while not using auto rate)
# with non-22Mbps hardware...
RATE=11M
AUTORATE=1 # only disable auto rate if you know what you're doing...
CHAN=1 # it's useful to try to stick to channels 1, 6 or 11 only, since these don't overlap with other channels
#SHORTPREAMBLE=1 # set a value of 1 in order to force "Short Preamble" (incompatible with very old WLAN hardware!) instead of peer autodetect
#TXPOWER=20 # 0..20 (dBm) (18dBm is firmware default) overly large setting might perhaps destroy your radio eventually!
MODE=Managed # Managed for infrastructure, Ad-hoc for peer-to-peer, or Auto to auto-select depending on environment
DEBUG=0xb # 0xffff for maximum debug info, 0 for none
# WEP Key(s)
# ascii keys (passphrase) should look like this: KEY="s:asciikey"
# hex keys should look like this: KEY="4378c2f43a"
# most wep users will want to use this line
KEY=""
# [ *** NOTE ***: WEP still doesn't work with acx111 cards yet! ]
# alternatively, you can uncomment and use these lines to
# set all 4 possible WEP keys
#KEY1="1234567890" #WEP64
#KEY2="1234567890"
#KEY3="1234567890"
#KEY4="1234567890"
# you must select which of the 4 keys above to use here:
#KEY="[1]" # for KEY1, "[2]" for KEY2, etc
ALG=open # open == Open System, restricted == Shared Key
#IP address
USE_DHCP=0 # set to 1 for auto configuration instead of fixed IP setting
IP=192.168.1.98 # set this if you did not set USE_DHCP=1
NETMASK=255.255.255.0 # set this if you did not set USE_DHCP=1
GATEWAY=192.168.1.254 # set this if you did not set USE_DHCP=1
LED_OFF=1 # set to 1 to turn off the power LED to save power
MTU_576=0 # set to 1 if you have buffer management problems
# DO NOT EDIT BELOW THIS LINE
##################################################################
The items: ESSID and CHAN should be set to match your wireless router or access point's station name and channel. If your wireless router or access point is 22Mbps (or more) capable, then once things are working, you can go back and set the rate higher, or you can just let auto-rate do it for you. for initial testing you should leave it at 11M. If you're trying to connect to a wireless Access Point or router (infrastructure mode) then set MODE=Managed, otherwise set to "Auto" or "Ad-hoc" depending. I recommend you leave the rest of the lines alone for now.
Next, you'll want to set the WEP key correctly, (acx111 WEP support is now functional and working!, with version: 0.2.0pre8_plus_fixes_51 or later) if your wireless router or access point is using WEP encryption, which is something you would have had to set up when you installed your wireless router or access point, so I'm assuming you know what the WEP key is ;-). To use WEP, place your key between the quotes on the KEY="" line. Note that if you're using an ASCII key (a text-based, "pass phrase" type of WEP key), you'll need to preface it with the characters s:, so the line would look like this: KEY="s:passphrase". Only ASCII keys should be prefaced this way, hex keys should be entered between the quotes as-is.
Finally, if you want your card to get it's IP address "automatically" from your router or access point, (this is the same as "obtain an address automatically" in Windows) Then set the next line to USE_DHCP=1. For those connecting to wireless Access Points or routers, I recommend you set this to 1 and use DHCP. The script will attempt to find and use whatever dhcp client is installed on your system.
If you are not using DHCP on your wireless network, then you'll need to set USE_DHCP=0, and instead edit the IP, NETMASK and GATEWAY lines to suit your network, typically you can leave the NETMASK as-is. Additionally, if not using DHCP, you'll need to edit /etc/resolv.conf and add a line like this to it: nameserver 192.168.0.1, again using the actual IP address of your wireless router or access point.
If you are not using DHCP, and don't want the script to attempt to set the default gateway, then be sure to comment out the GATEWAY= line like this: #GATEWAY=...
If you're using a USB device, you have a couple more edits to make, so scroll down further to where it looks like this:
case "`uname -r`" in
2.4*)
MODULE_AT="${SCRIPT_AT}/../src/acx_pci.o"
;;
*)
MODULE_AT="${SCRIPT_AT}/../src/acx_pci.ko"
;;
esac
and make it look like this:
case "`uname -r`" in
2.4*)
MODULE_AT="${SCRIPT_AT}/../src/acx_usb.o"
;;
*)
MODULE_AT="${SCRIPT_AT}/../src/acx_usb.ko"
;;
esac
USB users will also need to replace acx_pci in the scripts/stop_net script with acx_usb.
All we're doing here is replacing "acx_pci" with "acx_usb". Also note that removing the usb cable from your machine without first running: ifconfig wlan0 down is a very good way to completely lockup your machine and so should be avoided. You will also need to make the same edit in the file: scripts/stop_net, again replacing acx_pci with acx_usb on one line, usb users: do not fail to edit stop_net or things will get rather strange if you re-run start_net. Note also, that at this point, the acx_usb module will not auto-load as the acx_pci module does when a supported device (the dwl-120+) is plugged in, use of the start_net and stop_net scripts with the "local" method outlined below is recommended.
That should do it for editing the start_net script, now save the file and return to your root-console and type cd scripts and then ./start_net, successful output looks similar this:
#./start_net using wlan0. Module successfully inserted. Setting rate to 11M auto. Setting channel 1. Going to try to join or setup ESSID network_down. Setting mode to Managed. Setting power LED to off. Waiting for association...10 9 8 OK. Attempting to use /sbin/dhcpcd for DHCP, this may take a moment...OK. Interface has been set up successfully.
Your output may vary a bit depending on your DHCP client and your ESSID setting. If you see a line like this near the end of start_net's output:
SIOCADDRT: File exists
Don't worry. This is the result of start_net attempting to set your default gateway and finding it already set. This means you have another network connection in the same machine that is up and running and also using the default gateway you've assigned to your wireless card. This is ok.
If you get errors with the word "bailing" in them then see the troubleshooting section for this. If all goes well, you should be able to ping your wireless router or access point with ping -c 4 -I wlan0 192.168.0.1. The "192.168.0.1" part of that command needs to be substituted with the actual IP address of your wireless router or access point, which will be similar to those numbers. Successful output looks similar to this:
64 bytes from 192.168.2.1: icmp_seq=1 ttl=126 time=7.87 ms 64 bytes from 192.168.2.1: icmp_seq=2 ttl=126 time=7.27 ms 64 bytes from 192.168.2.1: icmp_seq=3 ttl=126 time=6.32 ms 64 bytes from 192.168.2.1: icmp_seq=4 ttl=126 time=6.27 ms --- 192.168.2.1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 6.271/6.934/7.876/0.676 ms
Unsuccessful output returns various errors with the word "unreachable" in them, if start_net completed successfully, yet you are getting "unreachable" errors, then see the troubleshooting section for this.
If instead, you get an error like this:
ping: bad interface address 'wlan0'
Then you'll need to use the actual IP address of wlan0 instead of it's interface name in the above ping command. To discover what IP address is assigned to the interface wlan0, type: ifconfig wlan0, the line we're interested in looks like this on one of my systems:
inet addr:192.168.2.101 Bcast:192.168.2.255 Mask:255.255.255.0
So, on that system, the IP address returned for wlan0 was 192.168.2.101. So, I'd substitute 192.168.2.101 for wlan0 in the above ping command, which would then look like this: ping -c 4 -I 192.168.2.101 192.168.2.1. Of course, you'll be substituting both the actual IP address of wlan0 returned on your system for "192.168.2.101" along with the actual IP address of your wireless access point/router for "192.168.2.1" in that command.
Next, you'll want to try to ping a host on the internet by name, type: ping -c 4 -I wlan0 cnet.com and successful output looks like this:
PING cnet.com (206.16.0.28) from 192.168.2.98 wlan0: 56(84) bytes of data. 64 bytes from abv-sfo1-x-redirect1.cnet.com (206.16.0.28): icmp_seq=1 ttl=234 time=102 ms 64 bytes from abv-sfo1-x-redirect1.cnet.com (206.16.0.28): icmp_seq=2 ttl=234 time=100 ms 64 bytes from abv-sfo1-x-redirect1.cnet.com (206.16.0.28): icmp_seq=3 ttl=234 time=98.9 ms 64 bytes from abv-sfo1-x-redirect1.cnet.com (206.16.0.28): icmp_seq=4 ttl=234 time=98.4 ms
Unsuccessful output looks like this:
ping: unknown host cnet.com
And again, if you get the "bad interface address" error from that ping command, you'll need to substitute wlan0's IP address for "wlan0". If you were able to successfully ping your wireless router or access point, but not a host on the internet by name, then re-check the contents of your /etc/resolv.conf file, type: cat /etc/resolv.conf to see what's there. You need to have a line in that file like this: nameserver 192.168.1.1, where you'll substitute the IP address of your wireless router or access point for 192.168.1.1 part. To add that line you can type: echo -e '\nnameserver 192.168.1.1\n' >> /etc/resolv.conf in your root-console and retry the ping. Understand though, that if any ethernet interface in your machine is using DHCP, that the contents of that file will re-written when that interface obtains it's DHCP 'lease'.
By now, you have your device nicely working and are enjoying some wireless freedom in Linux, congratulations. You may be wondering what's going to happen should you decide to shut down the computer or reboot it. No doubt you'd like your device to come up automatically the next time you boot.
While there are a number of ways to accomplish this goal, I'm going to outline one that I consider to be the safest for new linux users and the simplest to implement. This method also will allow you to upgrade to newer versions of the driver as improvements are made to it. First, see if the file /etc/rc.d/rc.local exists, type ls -l /etc/rc.d/rc.local and successful output looks like this:
-rwxr-xr-x 1 root root 399 Apr 26 19:24 /etc/rc.d/rc.local*
If the file does not exist, you'll get this:
/usr/bin/ls: /etc/rc.d/rc.local: No such file or directory
If that happens, then try ls -l /etc/rc.d/boot.local instead.
If that file also is not found, then skip to the next paragraph. Otherwise, if you have an rc.local or boot.local file, type this: echo -e '\n#Bring acx100 device up\ncd /home/your_normal_username/acx100-0.2.0pre8_plus_fixes_51/scripts\n./start_net\n' >> /etc/rc.d/rc.local to add 3 lines to the end of it that will bring up your device on bootup. Be sure to substitute your "normal" username and the correct filename (rc.local or boot.local) in the appropriate place in that command.
If no /etc/rc.d/rc.local or /etc/rc.d/boot.local file exists, see if a directory named init.d does, type: ls -l /etc/init.d, successful and unsuccessful output mimics the listings above. If init.d exists, then type: echo -e '\n#!/bin/sh\n#Bring acx100 device up\ncd /home/your_normal_username/acx100-0.2.0pre8_plus_fixes_51/scripts\n./start_net\n' > /etc/init.d/local to create an rc.local-like file that will bring your device up on bootup. Be sure to substitute your "normal" username in the appropriate place in that command. Then, make the newly-created file executable with: chmod +x /etc/init.d/local. One more step is required to get your newly created "local" file into the startup system, type: update-rc.d local defaults 99.
When you decide to upgrade to a newer version of the acx100 driver, after running make and make install, be sure to replace the "acx100-0.2.0pre8_plus_fixes_51" in your "local" script file with the new acx100 top-level directory name.
Understand also that if you upgrade/update your running kernel, you must go back to your acx100 top-level directory and run make clean, followed by the usual: make and make install. Linux kernels require that loadable modules (drivers) be compiled against the same kernel version that is running, also using the same gcc version that was used to compile the kernel itself.
Although I've tried to remain distribution-neutral and have tested the above method of "final configuration" on more than one version of: Slackware, Knoppix(Debian), Mepis(Debian), Redhat/Fedora Core, Mandrake and SuSE, I should mention that with a couple of the aforementioned distributions I have had success using their supplied setup tools. I'm going to outline what I did. If you don't see your distribution listed, then you can assume that I tried and was not successful using their tools. Note that the below configuration methods are not compatible with the "local" method outlined above, so try only one at a time.
Fedora Core 2 and 3
SuSE 9.1, 9.2
If you need assistance with any of this, feel free to email me: 
. Though I can't
always solve every issue, I'm willing to try. I currently have Slackware
9.0-10.1, Mandrake 10-10.2, Fedora Core 2-4, SuSE 9.1-9.3, Knoppix 3.7-3.9, and
MEPIS 3.3 installed on my machines here and can verify that the driver works
with all of them.
If you're emailing me for assistance, please include as much of the information below as possible in your first correspondence. I can't help you if I don't know what you're using and where in the process you ran into errors. If you don't know how to provide the info below, then let me know that, and I'll explain how to do it. Please: understand that not including the below info in your email will just extend the number of emails required to get you going (ie: I'll just have to ask you to send it in my emails back to you).
Please, do not send me debug=0xffff logs!. The information listed above is usually enough to troubleshoot simple issues, and if not I'll ask you for any additional info.
Finally, you should know that I am not a developer, nor even a member of the acx100 project, just someone trying to help. So, when your card comes up and you're enjoying the wireless freedom, I strongly encourage you to go to the acx100 project's forum and thank the developers for all the many hours they've freely given to make this driver possible. If you're able, I would also encourage you to make a donation to the project's originator and lead developer: andim2. Donations to the project will be used to further it's development, testing and feature-set, so please, if you are able, make a donation.
CardBus(PCMCIA) users, I recommend you begin here: http://pcmcia-cs.sourceforge.net/ for troubleshooting the pcmcia sub-system and then here: http://www.linux-laptop.net/ for more specific help on your particular notebook.
PCI card users, re-check the physical installation of the card, and try switching it to another PCI slot, if possible.
Of course, it's entirely possible that your device does not contain an acx100 or acx111 chipset. The lspci -n command should be considered completely authoritative since those numbers are how the driver determines whether you have a supported device.
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: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 tipsIf 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.
Unless you're using Knoppix, 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.
If you're having trouble unpacking the acx100 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 ;^)The most common cause of errors (99% of the time!) when you type make is improper kernel-source. Either the kernel-source is not installed at all, or it is, but doesn't match the running kernel's version, please re-check your kernel-source installation and the contents of your /lib/modules/`uname -r`/build directory. Some distro's "Updates" can leave your system out-of-sync, see your distro's homepage/forums for help on this. Remember, this guide applies only to version 0.2.0pre8_plus_fixes_51 of the acx100 source, and no other versions, neither older or newer.
If you've verified the presence of your kernel-source and you're using a 2.6.xx kernel and still get errors when you try to compile complaining about version.h not being found, then you need to prepare your kernel source (this is not the same as compiling the kernel) before you can compile the acx driver using it. To do that, you'll want to change to the kernel source directory with: cd /lib/modules/`uname -r`/build. Then, make sure you have a matching .config file, type: cp /boot/config-`uname -r` .config (that's dot config). Now prepare the kernel source, type: make prepare-all. If that ends without error, then type: ls include/linux/version.h and successful output looks like this:
include/linux/version.h
Once you have prepared the kernel source, return to the acx top-level source directory, type: cd /home/your_normal_username/acx100-0.2.0pre8_plus_fixes_51 and then: make clean. Now return to the compiling section and continue on.
SuSE 9.2 users if you get an error about wireless.h not being found, then you'll need to create a symlink to it with this command: ln -s /usr/include/linux/wireless.h /lib/modules/`uname -r`/build/include/linux/. Understand that this is not exactly how things should really be done, but appears to be a necessary hack to compile this driver module on SuSE 9.2. I'll post more info if/when it becomes available and experienced SuSE users please email me if you have a better solution to this issue with wireless.h.
Another commonly received error looks like this:
Kernel configuration found, performing sanity checks
All of the following items are required by the driver:
Loadable modules support is enabled.
Wireless LAN (non-hamradio) support is enabled.
Wireless extensions support is DISABLED.
The following is needed for PCMCIA/CardBus cards:
PCMCIA support is enabled.
CardBus support is enabled.
The following is needed for USB cards:
USB support is enabled.
The following is needed for PCI card support:
PCI support is enabled.
Kernel configuration lacks needed options, please correct! ABORTING.
make: *** [config.mk] Error 1
If you get this error and are using a recent distribution along with the default or "stock" kernel, then try issuing this command to add the missing line to your .config file: echo -e '\nCONFIG_NET_WIRELESS=y\n' >> /lib/modules/`uname -r`/build/.config, now try make again. If, on the other hand, you are using a kernel that you compiled and installed yourself, then it's likely you left out something important and will need to re-compile it with the proper wireless networking support.
If you are re-compiling the source, start with make clean and then make, followed by make install
If you get errors like these when you run start_net:
Error for wireless request "Set Bit Rate" (8B20) :
SET failed on device wlan0 ; No such device.
Failed.
...
...
...
Error in "/sbin/ifconfig wlan0 mtu 576". Bailing...
The most common cause is incorrect or missing firmware, please revisit the section in the acx100 team's readme (acx100-0.2.0pre8_plus_fixes_51/README) about firmware. If you're using a CardBus card, then it's also possible that the card is not enabled or powered on. Type: cardctl status and see if the card is considered "present", if not, try: cardctl insert, then check again. If you're using some kind of built-in device, then verify that it's powered-on and if necessary, that it's "radio" is also enabled using whatever special keys you would normally use to enable the device.
Another commonly received error that will cause start_net to "bail" contains the words invalid module format in it. This indicates a mis-match between the kernel that is currently running and the acx module you are trying to load. Just after receiving this error, type: dmesg and at the end it should tell you what the mis-match is. It can be either the kernel version (your kernel-source version does not match your running kernel's version), or the target CPU (i386, PII, PIII, P4, Athlon, i686, etc), or the version of gcc that was used to compile the acx module does not match the version that was used to compile the running kernel. You can type: cat /proc/version to see exactly how your running kernel was compiled.
There are a number of reasons why pinging your wireless access point would fail. First and foremost, and by far the most common, is that your card failed to associate with your access point. Association between your wireless access point and your wireless card is very similar to having the wire plugged into a regular, wired ethernet card. Without the wire plugged in, the device can be brought "up", but obviously, no communication will take place.
To see whether your device has achieved association with your access point you'll need to type: iwconfig in your root-console, output will look like this:
# iwconfig
lo no wireless extensions.
wlan0 IEEE 802.11b+ ESSID:"network_down" Nickname:"acx100 v0.2.0pre8.34"
Mode:Managed Channel:1 Access Point: 00:03:2F:06:F4:13
Bit Rate=22Mb/s Tx-Power:20 dBm Sensitivity=187/0
Retry min limit:7 RTS thr:off
Encryption key:off
Power Management:off
Link Quality:71/0 Signal level:-193 dBm Noise level:-255 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
First, ignoring the line beginning with "lo", we see below it my acx100 card identified as "wlan0". On wlan0's second line is a field called "Access Point:" and the listed value is the MAC address of my SMC wireless router: 00:03:2F:06:F4:13. If, instead you see "00:00:00:00:00:00" in that field, you can consider the "wire" to be unplugged, and nothing is going to work until you get it "plugged in". Your info regarding the other fields will most likely be different than mine, that's ok, all we're looking for here is association.
Toward that end, the first thing is to determine if your device can "see" any access points, so type: ifconfig wlan0 up to make sure the device is up, and then type: iwlist wlan0 scan, and successful output looks similar to this:
# iwlist wlan0 scan
wlan0 Scan completed :
Cell 01 - Address: 00:03:2F:06:F4:13
ESSID:"network_down"
Mode:Master
Frequency:2.412GHz
Quality:52/0 Signal level:-222 dBm Noise level:-256 dBm
Encryption key:off
Bit Rate:22Mb/s
Cell 02 - Address: 02:00:16:1D:AA:40
ESSID:"adhoc"
Mode:Ad-Hoc
Frequency:2.412GHz
Quality:50/0 Signal level:-225 dBm Noise level:-256 dBm
Bit Rate:11Mb/s
Cell 03 - Address: 00:0F:66:8B:52:D5
ESSID:"linksys"
Mode:Master
Frequency:2.437GHz
Quality:41/0 Signal level:-239 dBm Noise level:-256 dBm
Encryption key:off
Bit Rate:11Mb/s
Cell 04 - Address: 00:09:5B:DC:E2:86
ESSID:"DAVESNET"
Mode:Master
Frequency:2.462GHz
Quality:31/0 Signal level:-252 dBm Noise level:-256 dBm
Encryption key:on
Bit Rate:11Mb/s
Here we see mine: "network_down" and "adhoc" as well as 2 other wireless access points found, along with some info about each station. If you get an error instead of a completed scan, I suggest you re-run start_net, which will unload the driver and reload it, then try the scan again. If you still do not get a scan, skip down a couple of paragraphs to the discussion about examining the log.
If the scan completed successfully and you see your access point listed, then try to associate again, first, type: ifconfig wlan0 up to make sure the card is "up", then type: iwconfig wlan0 essid name. Substitute your access point's ssid name for the "name" part of that command, and be aware that it's case-sensitive, so "Default" is not the same as "default". Also be aware that if the name contains spaces, you'll need to enclose it with quotes like this: iwconfig wlan0 essid "name with spaces". Now, see if you have achieved association by typing iwconfig again. If so, you can return to the ping section and continue.
If the scan completed successfully and yet you don't see your access point listed, then it's possible that you've set it to not 'broadcast' it's ssid (station name). I recommend you go to your access point's setup and set it to broadcast it's ssid, non-broadcasting stations are not exactly "hidden" from those who want to see them, so this kind of "security" measure is dubious at best.
If more than one station is found, and you see other stations with "key: off", using the same channel(frequency), and the same essid name (such as "linksys") as your access point, then I suggest you change your access point's channel, ssid name, and, if not using an acx111 device, enable WEP as well. Otherwise your device will have a hard time telling them apart.
If you still have no association with your access point (all zero's) it's time to take a look at the logs. On most distributions you can examine the log by typing: tail -100 /var/log/messages. The "100" in that command indicates how many lines at the end of the log you'd like to see and you can adjust it to suit you. On some distributions the command would be: tail -100 /var/log/syslog instead, so if nothing relevant shows up in the first command, try the 2nd. What we're looking for are messages related to the activities of the driver and device in attempting to associate with your access point, here's an excerpt from my log showing a successful association from start to finish:
Sep 4 14:47:34 Slack91 kernel: Starting radio scan
Sep 4 14:47:34 Slack91 kernel: acx100_set_status: Setting status = 1 (SCANNING)
Sep 4 14:47:34 Slack91 kernel: acx100_process_probe_response: found and registered station 0: ESSID "network_down" on channel 1, BSSID 00:03:2F:06:F4:13, Access Point/0Mbps, Caps 0x0061, SIR 64, SNR 0.
Sep 4 14:47:35 Slack91 kernel: acx100_process_probe_response: found and registered station 1: ESSID "linksys" on channel 6, BSSID 00:0F:66:8B:52:D5, Access Point/0Mbps, Caps 0x0005, SIR 42, SNR 1.
Sep 4 14:47:35 Slack91 kernel: acx100: Tx timeout!
Sep 4 14:47:36 Slack91 kernel: acx100_process_probe_response: found and registered station 2: ESSID "DAVESNET" on channel 11, BSSID 00:09:5B:DC:E2:86, Access Point/0Mbps, Caps 0x0431, SIR 31, SNR 9.
Sep 4 14:47:36 Slack91 kernel: Got Info IRQ: status 0x0000, type 0x0001: scan complete
Sep 4 14:47:36 Slack91 kernel: Radio scan found 3 stations in this area.
Sep 4 14:47:36 Slack91 kernel: <Scan Table> 0: SSID="network_down",CH=1,SIR=64,SNR=0
Sep 4 14:47:36 Slack91 kernel: peer_cap 0x0061, needed_cap 0x0001
Sep 4 14:47:36 Slack91 kernel: Found station with matching ESSID!! ("network_down" station, "network_down" config)
Sep 4 14:47:36 Slack91 kernel: acx100_complete_dot11_scan: matching station FOUND (idx 0), JOINING (00 03 2F 06 F4 13).
Sep 4 14:47:36 Slack91 kernel: <acx_join_bssid> BSS_Type = 2
Sep 4 14:47:36 Slack91 kernel: <acx_join_bssid> JoinBSSID MAC:00 03 2F 06 F4 13
Sep 4 14:47:36 Slack91 kernel: Sending authentication1 request, awaiting response!
Sep 4 14:47:36 Slack91 kernel: acx100_set_status: Setting status = 2 (WAIT_AUTH)
Sep 4 14:47:38 Slack91 kernel: acx100_timer: status = 2
Sep 4 14:47:38 Slack91 kernel: resend authen1 request (attempt 2).
Sep 4 14:47:38 Slack91 kernel: Sending authentication1 request, awaiting response!
Sep 4 14:47:38 Slack91 kernel: acx100_process_authen: UNVERIFIED.
Sep 4 14:47:38 Slack91 kernel: 00:03:2F:05:44:D200:03:2F:05:44:D200:03:2F:06:F4:1300:03:2F:06:F4:1300:03:2F:06:F4:13<4>
Sep 4 14:47:38 Slack91 kernel: Algorithm is ok
Sep 4 14:47:38 Slack91 kernel: Got current client for sta hash tab
Sep 4 14:47:38 Slack91 kernel: Found acceptable client
Sep 4 14:47:38 Slack91 kernel: acx100_process_authen auth seq step 2.
Sep 4 14:47:38 Slack91 kernel: acx100_set_status: Setting status = 3 (AUTHENTICATED)
Sep 4 14:47:38 Slack91 kernel: Sending association request, awaiting response! NOT ASSOCIATED YET.
Sep 4 14:47:38 Slack91 kernel: association: requesting capabilities 0x0061
Sep 4 14:47:38 Slack91 kernel: acx100_set_status: Setting status = 4 (ASSOCIATED)
Sep 4 14:47:38 Slack91 kernel: ASSOCIATED!
Sep 4 14:47:39 Slack91 kernel: acx100_timer: status = 4
Of course, you'll be looking at the sequence of events for where in the process it breaks down and (hopefully) an explanation of what the problem is. "Milestones" are written by the driver in all caps. A very simplified description of the sequence listed above would be:
If you have achieved association, but your pings to your wireless access point still come back "unreachable", then possible causes are:
That's about the end of my bag-o-tricks for troubleshooting these devices. As I discover new problems/solutions, I'll be updating this section.
-->