Index of /~andi/acx100
Name Last modified Size Description
![[DIR]](Index of -~andi-acx100_files/back.gif)
Parent Directory -
![[TXT]](Index of -~andi-acx100_files/text.gif)
ChangeLog.txt 08-Jun-2005 10:19 80K
ChangeLog_OLD.txt 19-Apr-2004 23:26 6.6K
![[ ]](Index of -~andi-acx100_files/unknown.gif)
acx100-0.2.0pre7.tar.bz2 28-Jan-2004 09:03 180K
acx100-0.2.0pre8.tar.bz2 13-Apr-2004 20:23 220K
acx100-0.2.0pre8_plus_fixes_20.tar.bz2 25-Jul-2004 22:06 195K
acx100-0.2.0pre8_plus_fixes_21.tar.bz2 01-Aug-2004 00:26 198K
acx100-0.2.0pre8_plus_fixes_22.tar.bz2 02-Aug-2004 00:29 199K
acx100-0.2.0pre8_plus_fixes_23.tar.bz2 02-Aug-2004 01:08 199K
acx100-0.2.0pre8_plus_fixes_24.tar.bz2 18-Aug-2004 20:50 214K
acx100-0.2.0pre8_plus_fixes_25.tar.bz2 22-Aug-2004 17:34 209K
acx100-0.2.0pre8_plus_fixes_26.tar.bz2 23-Aug-2004 00:37 209K
acx100-0.2.0pre8_plus_fixes_27.tar.bz2 26-Aug-2004 19:08 170K
acx100-0.2.0pre8_plus_fixes_28.tar.bz2 28-Aug-2004 01:28 171K
acx100-0.2.0pre8_plus_fixes_29.tar.bz2 30-Aug-2004 00:32 171K
acx100-0.2.0pre8_plus_fixes_30.tar.bz2 05-Sep-2004 14:41 178K
acx100-0.2.0pre8_plus_fixes_31.tar.bz2 12-Sep-2004 17:31 179K
acx100-0.2.0pre8_plus_fixes_32.tar.bz2 26-Sep-2004 17:44 179K
acx100-0.2.0pre8_plus_fixes_33.tar.bz2 27-Sep-2004 00:53 179K
acx100-0.2.0pre8_plus_fixes_34.tar.bz2 05-Oct-2004 19:38 194K
acx100-0.2.0pre8_plus_fixes_35.tar.bz2 17-Oct-2004 12:03 198K
acx100-0.2.0pre8_plus_fixes_36.tar.bz2 21-Oct-2004 19:19 198K
acx100-0.2.0pre8_plus_fixes_37.tar.bz2 24-Oct-2004 18:18 199K
acx100-0.2.0pre8_plus_fixes_38.tar.bz2 15-Nov-2004 00:14 200K
acx100-0.2.0pre8_plus_fixes_39.tar.bz2 16-Nov-2004 00:37 205K
acx100-0.2.0pre8_plus_fixes_40.tar.bz2 23-Nov-2004 10:01 205K
acx100-0.2.0pre8_plus_fixes_41.tar.bz2 02-Dec-2004 00:30 207K
acx100-0.2.0pre8_plus_fixes_42.tar.bz2 04-Dec-2004 01:30 207K
acx100-0.2.0pre8_plus_fixes_43.tar.bz2 05-Dec-2004 15:58 208K
acx100-0.2.0pre8_plus_fixes_44.tar.bz2 09-Jan-2005 01:52 203K
acx100-0.2.0pre8_plus_fixes_45.tar.bz2 30-Jan-2005 00:45 214K
acx100-0.2.0pre8_plus_fixes_46.tar.bz2 06-Mar-2005 21:04 220K
acx100-0.2.0pre8_plus_fixes_47.tar.bz2 09-Mar-2005 21:38 225K
acx100-0.2.0pre8_plus_fixes_48.tar.bz2 12-Mar-2005 19:15 227K
acx100-0.2.0pre8_plus_fixes_49.tar.bz2 28-Mar-2005 01:15 227K
acx100-0.2.0pre8_plus_fixes_50.tar.bz2 30-Mar-2005 01:07 227K
![[ ]](Index of -~andi-acx100_files/compressed.gif)
acx100-0.2.0pre8_plus_fixes_50.tar.gz 30-Mar-2005 01:07 312K
acx100-0.2.0pre8_plus_fixes_51.tar.bz2 07-Apr-2005 23:21 185K
acx100-0.2.0pre8_plus_fixes_51.tar.gz 07-Apr-2005 23:21 236K
acx100-0.2.0pre8_plus_fixes_52.tar.bz2 11-Apr-2005 20:55 184K
acx100-0.2.0pre8_plus_fixes_52.tar.gz 11-Apr-2005 20:55 236K
acx100-0.2.0pre8_plus_fixes_53.tar.bz2 20-Apr-2005 21:17 182K
acx100-0.2.0pre8_plus_fixes_53.tar.gz 20-Apr-2005 21:17 233K
acx100-0.2.0pre8_plus_fixes_54.tar.bz2 21-Apr-2005 22:57 183K
acx100-0.2.0pre8_plus_fixes_54.tar.gz 21-Apr-2005 22:57 233K
acx100-0.2.0pre8_plus_fixes_55.tar.bz2 06-May-2005 23:42 183K
acx100-0.2.0pre8_plus_fixes_55.tar.gz 06-May-2005 23:42 234K
![[DIR]](Index of -~andi-acx100_files/folder.gif)
acx100-0.2.0pre8_plus_fixes_55/ 06-May-2005 23:42 -
acx100-0.2.0pre8_plus_fixes_56.tar.bz2 07-May-2005 19:11 183K
acx100-0.2.0pre8_plus_fixes_56.tar.gz 07-May-2005 19:11 234K
acx100-0.2.0pre8_plus_fixes_57.tar.bz2 25-Jul-2005 13:14 186K
acx100-0.2.0pre8_plus_fixes_57.tar.gz 08-Jun-2005 10:01 254K
old/ 26-Aug-2004 19:13 -
*******************************************************************************
* Open-Source wireless driver for TI ACX1xx chipsets *
*******************************************************************************
An alternate, most likely infinitely much better, more detailed guide can be
found at http://www.houseofcraig.net/acx100_howto.php
Regardless of this guide, this README contains a very large amount of important
first-level driver info, so I'd definitely advise to read it as much as possible.
!!!!! MANDATORY WARNINGS !!!!!
I just learned that the WRT54G router (non-ACX1xx chipset) has trouble with its
radio when running with higher than usual Tx power (70-100mW or so)
which is possible using incredibly useful custom Linux firmwares
(e.g. the Sveasoft ones), meaning that people end up with defective radios
sometimes after 3 months even, if they choose irresponsibly high
Tx power levels!!
Since this driver can drive ACX1xx cards to use up to 100mW of power,
I really don't know how long the radio would stand that.
Thus it'd be useful to not use full output power if you can avoid it!!
Note that so far I haven't had any defects during constantly using
maximum power (our "20dBm" setting) for many months now, so it MIGHT
be safe. However you might have different hardware which doesn't take that
so easy...
(BTW: my *builtin* mini-PCI card disables its radio every few hours,
and that might be linked to overheating protection or so...)
Thus I adjusted all driver files to use a hopefully safe 18dBm per default
(which is the firmware default, too).
Please inform us immediately if you suspect a dead radio resulting from
prolonged use of overly large Tx power, we'd like to know that immediately!!!!!
UPDATE: I found out that after a large amount of use (primary development card!),
one SMD capacitor of the mini-PCI card in my notebook leaked. This is probably
due to a terrible heat situation in modern notebooks. Replaced the SMD
capacitor with a hopefully equivalent one, seems to work fine.
This could have been aggravated by the driver always recalibrating the radio
on Tx error, which might have allowed the radio to operate beyond the critical
high temperature limit...
Since our driver now does the next recalibration several minutes later only,
this should be more than enough time to notice that the card isn't working under
good conditions.
CONCLUSION: better make sure that the card isn't excessively hot in case it
stops working temporarily. It might damage the hardware after some time
otherwise...
This driver may still cause your box to lockup in very rare cases!
If this happens, then please report at/create a bug report!
Card reliability warning: The DWL-650+ seems to have a slightly too high
defect rate (see doc/general_info). Consider buying any card with FCC ID
O7J-GL242201 (0 defect reports) instead of the DWL-650+ (5+ defect/problem
reports). One might attribute this to the higher sales numbers of the
DWL-650+, but I'm not quite sure...
Hmm, no, after some more time I cannot say this for certain any more (no
further defects reported to me).
Please don't use the NDIS driver loader cludge instead of our driver.
For an incredible number of reasons against it, please see
http://acx100.sourceforge.net/ndis_cludge.html
(for a start: our driver now supports AMD64, PowerPC, MIPS and of course x86
-- now please try to do that with NDIS loader "solutions", ok?)
If for some or another reason you're unhappy with the performance of our
current driver version, then either fix it if you're capable of doing that
or immediately think of returning to the shop or, if that is not possible,
of selling your very poorly supported Taxed Sinstruments based card in
exchange for a wireless card that is well-supported under Linux.
Buying the very problematic DriverLoader product instead in an attempt
to "fix" sorely missing Linux driver support will send the entirely wrong
message to wireless card manufacturers, so please never choose to do that.
There are many commercial products very much worth buying; but this is
certainly not one of those...
If you absolutely don't want to miss out on NDIS loader functionality,
then I'd suggest trying the free alternative NDIS Loader instead,
at http://ndisloader.sourceforge.net (FIXME right URL? No internet at home... ;).
This way at least you won't be telling a company with your money
(aka: the most important way to "vote") that you think
that "doing a blatant Windows binary driver usage ripoff is the right way that
Linux wireless 'support' should be developed".
Also, please take note that I learnt that TI is using and supporting
Linux for at least TNETW1230 driver SDKs and Linux QoS management (only
commercially available, I suppose?).
However somehow they're still too elitist to actually pass (parts of) that
Linux infrastructure back to the desperate end users looking for proper
TNETW1xxx driver support, even after continuous user requests.
Returning such completely improperly supported WLAN hardware to the shop
and mentioning unacceptable terms suddenly doesn't sound like such a
chore any more...
=== CARD COMPATIBILITY (aka "the real dirt") ===
Let us first mention that this driver is supposed to support EVERY SINGLE CARD
with ACX100 chip (except for Compact Flash implementations,
which are very rare). USB support exists for both 2.6.x and 2.4.x,
however it may be not completely "stable" yet, and Linux 2.4.x USB stack
is buggy (both uhci and usb-uhci; ohci and ehci should be ok, though),
so better use 2.6.x for USB! [041203]
Determining whether your wireless card is supported by this driver can
be done by running "lspci". This should give you an idea whether it should
be ok or not.
If the driver doesn't work with your ACX100 card, then please notify us
immediately after you followed *EVERY ADVICE IN THIS FILE* (and elsewhere)
and are at your wits end as to what might still make the card fail
(trying previous versions of the driver is very important as well!).
Other Texas Instruments chips which are e.g. 802.11g capable and are named
TNETW1130/1230 (ACX111) started to actually be supported in a useful way
by this driver some time ago only, so due to different hardware
implementations some ACX111 card designs might still not be working yet,
even at this time [041203].
Also, due to confusion about similar card naming (for further information, see
bottom), people keep thinking certain cards they own work with this driver.
Cards that are *NOT* based on ACX1xx chipset (as opposed to the stupidly
similarly named ACX1xx versions DWL-120+, DWL-520+ and DWL-650+, which *do*
have ACX1xx) are:
DWL-120 (PRISM2 chipset)
DWL-520 (PRISM2)
DWL-650 (PRISM2, minus few newer variants which D-Link messed up to have the
ACX100 instead)
DWL-G120 (PRISM GT)
DWL-G520 (Atheros AR5212A)
DWL-G650, version A1 (PRISM GT)
DWL-G650, version B1 (Atheros AR5211)
DWL-G650, version B2 (Atheros AR5001)
DWL-AG520 (Atheros AR5212)
DWL-AB650 (Atheros AR5211)
DWL-AG650 (Atheros AR5212)
When looking at the DWL-G650 mess, I could puke again...
Again, the cards mentioned in the listing above will NOT work with this driver
(yet?), in most cases you will need to be able to find a different Linux driver
supporting your card's chipset... (try Google "[CHIPSET] Linux")
Feel free to send us corrections/additions to this very confusing listing above.
=== STATUS AS OF 050407 ===
Status Matrix:
ACX100 ACX100 USB ACX111
Rates 1/2/5.5/11/22 (+auto) 1/2/5.5/11/22 all up to 54Mb (+auto)
5GHz -- -- NIY (any hardware?)
Ad-Hoc * (WEP64*/128*/256*) * (WEP64?/128*/256?) * (WEP64*/128*/256?)
Managed * (WEP64*/128*/256*) * (WEP64?/128*/256?) * (WEP64?/128?/256?)
Auto mode - (DISABLED recently!!) - (dito) - (dito)
Master ? ? ?
Change Tx power * (hardware) - (may do via FW only) -
Config antennas * (currently via FW) ? -
Sensitivity * (hardware) - (no go since USB?) * (various F/W settings)
Currently this driver for standard ACX100, ACX100 USB and ACX111 cards
still is a bit experimental.
There's no development roadmap since I don't have much time and thus I cannot
say accurately enough when features will be implemented. You might want
to look at the TODO file for things planned in the future (in order of
importance).
We're still not totally sure about the status of WEP support:
ACX100: Many situations should work, but it might still not work properly
or fail sometimes.
ACX111: WEP **FINALLY** working (thanks HEAPS to Luis Padilla Visdomine for
magically pin-pointing the very hard to find issue - you're our hero!!).
If you need encryption that is much more secure than WEP, you might want to use projects like OpenVPN or others.
Also, SMP appears to be problematic (locking issues); if you have SMP,
then turn it off. We will attempt to clean this up as soon as possible.
Please report any trouble here!
Furthermore, associating with some access points might still be problematic
due to strict 802.11 compliance checks in their firmware (which we fail
to meet, of course). This should also be better now thanks to the very
astonishing work done by Denis Vlasenko. [050420]
Master mode support (aka HostAP) has not been implemented fully yet.
It looks like it will be working very soon, though. [050420]
The non-standard 4x (4X) mode (aka "44Mbps") is not supported yet and will need
several driver changes. Don't hold your breath, this is really low priority.
You might want to disable 4x mode support in your AP, since it is suspected
to cause problems sometimes.
Many other things haven't been tested (properly) yet.
Further testing versions can be downloaded from http://lisas.de/~andi/acx100/
A working FreeBSD driver that's derived from our driver can be found at
http://wlan.kewl.org and cvs.kewl.org (thanks, guys, for the cool work!).
There is a free download of the 802.11b spec at
http://standards.ieee.org/getieee802/
=== REQUIREMENTS ===
What to do or have (we will NOT remind you later about any requirements,
since this seeks to list all requirements in full):
* x86 box preferrably
(minimum reported working so far: ACX100 - 486@100MHz, 16MB)
Other architectures:
AMD64 should work now.
PPC (Powerbooks) may work since they have been tested from time to time,
but please report IMMEDIATELY if they have any trouble,
I'm very interested in that!
Users of architectures other than x86 may need to remove certain compiler
flags in src/Makefile which are unsupported by their non-x86 compiler (e.g. -march=i586)
* most likely a Bus Master capable PCI slot for PCI card versions, slave
PCI slot won't work (FIXME: is that true? Please report!)
* relatively recent Linux kernel 2.6.x or 2.4.x (>= 2.4.18 preferred)
with CONFIG_NET_RADIO enabled ("Wireless LAN")
and CONFIG_NET_WIRELESS, for wireless extensions (iwconfig etc.).
And Non-SMP (no CONFIG_SMP).
* proper kernel header files / kernel source (packages) installed
for the exact (*EXACT*!!) kernel you're running!
It is recommended that this kernel is new enough to support wireless
extensions version WIRELESS_EXT > 13
* a make package has to be installed
* a gcc package has to be installed
* The /bin/bash shell is required for the start_net/stop_net scripts
* module packages: module-init-tools for 2.5.x/2.6.x, modutils for Linux 2.4.x
* firmware image and (sometimes) radio image for your ACX1xx card
(these need to be uploaded into the card RAM on every driver initialization)
* the package containing iwconfig, iwpriv & Co. needs to be installed
on your system (on Debian: package wireless-tools)
* the Linux hotplug package is required for automatic setup of CardBus cards
and for proper ACX100 USB cards operation, and in case of a 2.6.x kernel
optionally for firmware binary hotplug loading (this will require a loaded
firmware_class.ko module as well)
What to NOT do:
* believe that this has much to do with PCMCIA. The ACX1xx cards are
CardBus cards, and thus PCI-based, NOT ISA-based (PCMCIA).
You probably need the pcmcia-cs package for certain CardBus functions,
though.
* believe that this driver uses the hotplug package's firmware upload
functionality. Right now it uses its completely separate and thus
Linux 2.4.x (which doesn't support this firmware upload)
compatible mechanism!
=== FIRMWARE INSTALLATION ===
NOTE that there are varying degrees of firmware stability and/or compatibility
with what *our* driver expects the firmware to do.
Thus you might want to use a different firmware version (the version number
can be found in the driver log) in case of problems getting the card to work
(reliably).
You may tell us about your experiences with various firmware versions
in combination with certain cards, then we'll add that info to
doc/firmware_versions.txt.
-- Firmware for ACX100 non-USB cards --
The firmware files are needed to drive the cards' onboard embedded
wireless baseband CPU.
We cannot ship this with our driver, so you will have to get it elsewhere.
There are three options:
a) run "make fetch_firmware"
This will run the shell script scripts/fetch_firmware, will DOWNLOAD
driver packages from ACX1xx vendors, extract them and copy required
firmware files to the firmware/ directory.
Once run, you are (hopefully!) finished with the firmware section.
b) you have a windows driver installed or have a zip file with all the
necessary windows files in it (for example D-Link installer).
This could be for ANY Windows version. All that matters here is that this
driver package contains relatively recent firmware image files.
c) you have a binary linux driver (not recommended, since these contain
much older firmware files)
Certain DWL-650+ and 520+ cards and Planet cards use a Maxim radio instead of
the usual RFMD, so these cards will not work with the limited proprietary
linux driver binary's firmware and so a windows firmware with proper
support for this radio type must be used.
Again, here are your options:
- Firmware provided by Windows driver -
Easy solution:
wget ftp://ftp.dlink.com/Wireless/dwl520+/Driver/dwl520+_drivers_307.zip
unzip dwl520+_drivers_307.zip
(these may be outdated, you might want to check for newer versions)
cp Win2000/WLANGEN.bin Win2000/WLANGEN.BIN Win2000/RADIO0d.BIN Win2000/RADIO11.BIN firmware/
mv firmware/WLANGEN.bin firmware/WLANGEN.BIN
Ready to roll. :)
Longer background explanation (PLEASE READ IN CASE OF PROBLEMS!):
The firmware used by the windows driver consists of several files normally
named WLANGEN.BIN, RADIO0d.BIN and RADIO11.BIN which can be found in
the c:\winnt\system32 directory, or in the install archive.
Place these files in the firmware directory, and you are ready to roll.
MAKE SURE THAT THE CASE SeNsItIvItY OF THE FILENAME CHARACTERS IS EXACTLY
AS WRITTEN ABOVE!! Otherwise the driver will not find the image files...
Note that earlier versions of the windows driver shipped with both a new
firmware file plus its individual radio files (small firmware plus RFMD
radio file plus Maxim radio file) and old combined versions (one bigger
firmware *including* radio code, which is the old concept).
Here you have a choice, you can either copy the newer individual files over
(which will need to be renamed to the firmware names given above)
or use the old combined file on its own. If for some strange reason you decide
to use the old combined file it must be renamed to "WLANGEN.BIN".
Since our driver WILL attempt to load separate radio modules even with an
old combined firmware (we don't do a version check yet), adding separate
radio files to an old combined firmware WILL cause problems, so better
don't do that...
The firmware files in the recent driver package are:
WLANGEN.BIN - Generic firmware
RADIO0d.BIN - Maxim radio module
RADIO11.BIN - RFMD radio module
RADIO15.BIN - UNKNOWN radio module, e.g. for DrayTek Vigor 520, found at
e.g. ftp://ftp.draytek.com.tw/VIGOR520/Driver/3.99.3.0/driver.zip
The firmware files in earlier packages are:
AIRPLUS.BIN - Firmware with embedded RFMD module
APLUSMX.BIN - Firmware with embedded Maxim module
APLUSGEN.BIN - Generic firmware
APLUSRFM.BIN - RFMD radio module
APLUSRMX.BIN - Maxim radio module
Other files:
SMCSN.BIN - combined(?) firmware for SMC2435W
- ACX100 Firmware from Linux binary driver (not recommended - TOO OLD) -
Several drivers are available on the internet, and they all seem to
work. But since the firmware is embedded in the binary driver, it needs
to be extracted. Place the driver in the firmware directory and make
sure it is called acx_pci.o. Then run 'make extract_firmware', and
you are set. Make sure that no radio modules (RADIO*.BIN) files are
placed in the firmware directory when using a linux firmware, otherwise
the driver will attempt to load and initialise the radio module for your
card again, with unpredictable results (FIXME: need to check against
firmware version on this one, to avoid such trouble; in other words:
which version was the last combined firmware version: please tell us!).
The linux driver already has the radio module embedded in the firmware.
The firmware version which this Linux driver contains is 1.5.0,
as printed during our driver initialisation.
-- Firmware for ACX100 USB cards (D-Link DWL-120+) --
Read the ACX100 instructions above, but keep in mind that they may be wrong
since you're using a USB card with USB specific ACX100 firmware.
FIXME: need to establish proper script support for the fact that the
ACX100 USB firmware should be copied to /usr/share/acx/ACX100_USB.bin
-- Firmware for ACX111 cards --
Read the ACX100 instructions above, but keep in mind that they may be wrong
since you're using an ACX111 card with ACX111 firmware.
NOTE: For ACX111 cards even recently there are both a combined firmware
(TIACX111.BIN or FwRad16.bin) and a non-combined firmware (FW1130.BIN?)
available (see further below).
Occasionally a firmware is also called GPLUS.BIN originally.
You need to rename it to TIACX111.BIN in this case (especially in newer
driver versions, which limited possible filename alternatives!!).
Note that D-Link makes a driver download distinction between the DWL-G650+ Rev. Ax and Bx: they are both ACX111, but contain different firmware images!
This could mean that there might be hardware differences between various ACX111
implementations, and thus you might need to use a specific firmware for your
particular card.
You need to make sure our driver has both the main firmware functionality plus
radio functionality available, otherwise you won't transmit anything!
Either by using a base firmware plus additional radio image file, or by using
a combined firmware which already includes radio functionality.
For non-radio firmwares you NEED the additional radio module, with radio
firmwares you MUST NOT have the driver load the radio module.
ACX111 cards usually have radio types 0x16 or 0x17 (see log message).
=== LINUX 2.6 DRIVER INSTALLATION ===
In order to use the acx100 driver with Linux 2.6 you'll need a complete 2.6
source tree.
In order to build the module outside of a 2.6 kernel tree, just use the
normal method as described for 2.4.x below (you'll most likely need to
compile it as root since it needs write access in your kernel source
directory).
If instead you want to build the module "in-tree" (i.e. not in a separate
acx100 module directory!), you'll have to:
> SOLUTION ONE
Run "make inject" to add the driver to an existing Linux 2.6.x source tree.
By default, the kernel source is assumed to be in /usr/src/linux/, while if
you want to specify another path, you should use the parameter KSRC, so
¨make inject KSRC=[path to your kernel source].
> SOLUTION TWO (this may be outdated)
1. Create a directory drivers/net/wireless/acx in your 2.6 source tree.
2. Copy the files
- src/Makefile
- src/*.c
- include/*.h
from the acx100 sources into drivers/net/wireless/acx in your 2.6 tree.
3. uncomment line "#EXTRA_CFLAGS += -Idrivers/net/wireless/acx -DWLAN_HOSTIF=WLAN_PCI"
in Makefile you just copied. (line 142)
4. Add a line reading "obj-m += acx/" to the bottom of
drivers/net/wireless/Makefile .
5. Then build your kernel as usual, the acx100 driver will be built as module
(acx_pci.ko). Make sure you have the required 2.6 module userspace
package (module-init-tools) and enjoy ;-)
> SOLUTION THREE (only for version before 0.2.0pre8)
Other 2.6.x kernel patches can be found at http://luca.pca.it/projects/acx100/
=== LINUX 2.4 DRIVER INSTALLATION ===
This is the usual way to get the driver running on Linux 2.4.x.
You have two choices:
The fast way:
Just run "make" in the main directory, and your driver will be ready
in a second. It is located in src/acx_pci.o .
(NOTE: changed from acx100_pci.o!!)
In case the build fails, then please make sure that the symbolic link
/lib/modules/`uname -r`/build exists and points to the matching
kernel source directory. Now copy /boot/vmlinuz.version.h to
/lib/modules/`uname -r`/build/include/linux/version.h
The slow way:
Type "make config.mk" in the main directory to cause some configuration
settings to be checked.
Then you type "make driver". This will compile a driver for
Linux 2.4.x (for 2.5 / 2.6 see below)
To run the driver, you can use the script scripts/start_net (and adapt it).
Oh, and don't forget to have a proper DNS server in /etc/resolv.conf ...
Further system configuration can be found at SYSTEM CUSTOMIZATION below.
"make install" will copy the driver modules to the current kernel's
module directory and will run depmod. If successful, the system should
attempt to auto load the driver on card insert.
The firmware files can be copied to /usr/share/acx/ (the driver's default
firmware directory) if you don't want to specify the firmware_dir= parameter
on module loading above.
In order to get the driver to autoload properly, you could add e.g. to
/etc/modprobe.d/acx_wlan (or /etc/modprobe.conf):
options acx_pci firmware_dir=/absolute/path/to/firmware_files debug=0x0
options acx_usb firmware_dir=/absolute/path/to/firmware_files debug=0x0
and run (on Debian; not sure with other systems) update-modules
(this will be added to "make install" soon).
Once you insert the card, the driver will then load automatically
without error (and will shut down the interface once you eject the card).
Note that the spinlocks inside the driver are still problematic,
so you should avoid ejecting the card in the middle of a data transfer
(OOPS may happen!). A completely safe way to eject is to ifconfig down
the interface, THEN eject the card.
Automatic networking configuration of such a setup can be achieved by
reading the guidelines at
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/HOTPLUG.txt
However, this seems to still be a bit static.
A more mobile approach might be the ifplugd/waproamd programs
(see below; configuration dependent on stations in reach).
DON'T FORGET that debugging/logging options can be changed in a pretty
powerful way (see "DEBUGGING / LOGGING").
Your hard disk will certainly thank you a lot for having saved it from
the horror of heaps of logs once you got the driver running...
To check out further module parameters and options, please use modinfo
and iwpriv (see also doc/iwpriv.txt).
The module itself can be loaded manually e.g. like:
insmod src/acx_pci.o firmware_dir=firmware
NOTE that firmware_dir has to be given as an absolute path; a relative
path will cause trouble during card reinit operations!! (suspend/resume etc.)
If you want the driver to use eth0 device name instead of wlan0,
then load with an activated use_eth_name option, like:
insmod src/acx_pci.o firmware_dir=firmware use_eth_name=1
For troubleshooting, see below.
=== USAGE HINTS ===
A VERY GOOD IDEA is to do a
cat /proc/driver/acx_wlan0_eeprom > ~/acx_card_XXX_eeprom_image.log
as soon as you get the driver running, and to store this file containing
the data of the card's *configuration* settings EEPROM in a very safe place.
In case the card somehow managed to trash its EEPROM (or EEPROM weakness),
you would thus at least be able to restore the EEPROM (once we develop
an EEPROM restore option which doesn't exist yet...).
This would also help in case Windows trashed the card EEPROM somehow.
I already managed to resurrect some DROP DEAD cable network card's EEPROM
(most likely trashed by XP driver) once, and from that time on
everybody around me called me a wizard ;-)
Needless to say this is an even better idea once we actually implement
modifying the card config EEPROM to allow for more useful settings ;-)
Want to use driver as BUILTIN kernel driver, but then driver fails to know
where the firmware files are? Use kernel boot parameter acx_firmware_dir=XXX.
Card insertion driver autoloading? You need to configure PCI hotplug layer,
*NOT* pcmcia-cs layer!
Use separate driver instances for multiple cards? Enable include/acx_config.h
SEPARATE_DRIVER_INSTANCES config setting (Linux 2.4.x only for now!!).
insmod acx_pci -o acx100_pci.wlan0 card=1 interface=wlan0
will then load a separate driver *only* for the first card in your system,
giving it the wlan0 interface.
Need to change MAC address? Use ifconfig wlan0 hw ether 112233445566
NOTE: make sure card interface is down! (driver will only update MAC
when not associated: needs reinit of card parts)
Also, this will only work in case your AP's MAC filter doesn't deny your new
MAC!
BTW, a nice tool for this might be the "GNU MAC Changer".
Wireless traffic monitoring (promiscuous mode) with Kismet? Set card type
Orinoco in kismet.conf (in case of an older Kismet release which didn't know
the acx100 type yet).
A kismet cmdline example would be "kismet -c acx100,wlan0,acx100 -- -q".
Oh, and also make sure to run "iwpriv wlan0 monitor 2 4" to enable (if required).
Wired-Wireless bridging? Driver would perhaps need to support WDS
(whatever that is). For now, proxy ARP should do:
http://www.hazard.maks.net/parprouted/
Trying to use NFS? use options 'rsize=1024,wsize=1024' in /etc/fstab .
=== DEBUGGING / LOGGING ===
Debug/log levels can be adapted by setting the module's "debug" load parameter
and/or via the "iwpriv SetDebug" command and/or the default log value
(variable "debug") in src/acx100.c.
A good default value after having managed to get the driver to run would be
0xb (thus using L_STD|L_INIT|L_ASSOC debug channels, see include/acx100.h).
Example:
insmod src/acx_pci.o ... debug=0xffff
iwpriv wlan0 SetDebug 0xffff
If you want to prevent log messages from flooding your tty,
then use setterm -msg or setterm -msglevel.
-- log file --
Log output of the driver gets written to the file which the
KERN_WARNING channel gets written to (somewhere in /var/log/).
The exact file name used for this log file is configured in the syslog
configuration file which is called /etc/sysklogd.conf or similar.
-- log console --
A log console (e.g. /dev/tty8) may be configured in /etc/syslog*.conf
(don't forget to restart syslogd).
Change to the logging console (Ctrl-Alt-F8) to view the kernel log messages
instantly (useful in case of driver crash debugging).
=== TROUBLESHOOTING / WORKAROUNDS ===
Don't forget to set the driver debug/log level (see above) to 0xffff in case
normal message logging is insufficient to resolve your card problem!
Also, cat /proc/driver/acx* might give some clues...
-- Driver build problems --
If the driver compile or loading keeps failing, then it might be caused
by a module version conflict of your current kernel, such as:
./../src/acx_pci.o: unresolved symbol unregister_netdev_Rdbdb76d4
Consider completely recompiling the kernel (make sure to keep any old
.config file with previous config settings!), then removing the WHOLE
/lib/modules/KERNELVERSION/ directory tree, then reinstalling this kernel and
rebooting. Hopefully the driver compiling works then.
On some systems (e.g. Conectiva distribution), it may be required
to run a "make prepare-all" in the Linux source tree before building
the driver...
Also, I hope you haven't downloaded the driver via Windows CVS (since it
may insert bogus end-of-line chars).
-- Driver init failure (sorted according to init progress) --
If you get the message
insmod: error inserting './../src/acx_pci.ko': -1 Invalid module format
Error while inserting module! Bailing...
during insmod, then it's probably a binary incompatibility (gcc version
or CPU architecture or (non-)register calling convention or kernel version
-- see syslog for evidence!!)
and you should make sure to compile the driver with the same build settings
that you used for compiling the kernel.
Running "depmod -ae" might actually fix the problem already, though.
insmod message "Unknown symbol in module" and then in syslog
"acx_pci: Unknown symbol release_firmware"?
Load the firmware_class.ko module.
- CardBus specific -
You need to make sure you're having CardBus support (otherwise you'll have
strange PCI init failures), and it should be kernel CardBus support, not
pcmcia-cs CardBus modules! (yenta socket module instead of e.g. i82365 module)
On SUSE: "kernel" type instead of "external".
Thinkpad notebook? Make sure your CardBus feature is enabled in the
configuration utility...
If your card gets recognized as "Anonymous Memory" (i.e. gets inserted,
but doesn't get recognized as a CardBus card), then try to use
further memory and port areas in /etc/pcmcia/config.opts (restart
pcmcia-cs). Also, try *restricting* the areas it probes instead: sometimes it
fails to detect a card if there are large amounts of ranges to be probed.
And of course also trying the other CardBus slot in case you are lucky
enough to have 2 slots sometimes actually helped to fix IRQ problems...
With certain Toshiba notebooks you need to go into the system bios
and set the PCIC *not* to be "auto", set to the other option.
- General -
If the system detects your card, but the driver is unable to initialize the
card due to the card having IDs 0xffff etc., then play with Linux boot
parameters, specifically the "pci=XXXX" flags, and most specifically,
"pci=assign-busses", since this managed to fix it for several persons
(DWL-650+, Vigor520).
If a PCI memory region cannot be reserved, then you may need to tell the
CardBus driver to use a different memory region, as reported in one case.
Please tell us if these managed to resolve some issue with a particular card!
Use tools like "cardctl info", "lspci -v", "dump_cis".
Also, make sure to shuffle cards in different PCI slots!! The ACX1xx probably
needs PCI bus mastering support, and some motherboards either don't support it
at all or not in certain crippled PCI slots.
And of course there are also cases where it is PCI interrupt sharing which
causes init trouble. A log message like "PCI: Sharing IRQ 3 with 00:01.1"
indicates that sharing is happening, which might cause trouble.
Using APM instead of ACPI has also been reported several times as fixing
init problems, so reconfigure your kernel to use the other one...
(kernel boot parameter "pci=noacpi" might be useful here, and it also
helped several times!)
Oh, and last but not least, always make sure to get the latest BIOS for your
computer - that also helped in some cases of broken power management code or
resource allocation!
If you have trouble with the ACX100 mini-PCI card in your notebook (i.e.
the notebook restarts immediately after suspending), then you have a
notebook with BIOS troubles as well (the BIOS needs to handle the PME#
pin activity properly). Workaround: disconnect/hide the PME# signal
on the card (pin 34, see mini-PCI spec).
If your firmware upload fails due to upload corruption (see log!) or
there is some other I/O port communication weirdness during driver use
such as reading back strange data, then this could indicate I/O timing issues:
Set ACX_IO_WIDTH=16 in the Makefile, then recompile, to use 16bit I/O access
instead of slightly problematic but faster 32bit access.
The reason why 32bit access causes problems with some cards on some
machines (it might be tied to the CardBus controller) is not known yet.
If you have any useful additional information, please report.
If you get messages similar to
"Failed to allocate shared memory for Rx buffer...", then please report.
This shouldn't happen any more, unless you have very little memory,
in which case buying more RAM (which is always VERY important in Linux!) may
help.
A huge delay when loading the firmware files means that the driver is
trying to load the firmware via Linux 2.6.x hotplug firmware loader,
but the firmware file isn't where it expects it, so after a long timeout
the driver can continue with the old firmware upload method.
-- Driver locked up the box (OOPS etc.) --
Umm... ouch!
First, use newest driver version.
Then please configure a log console (see "DEBUGGING / LOGGING").
Run
sleep 10 && insmod acx_pci ......
Then change to the log console, wait 10 seconds and write down the crash dump.
Then please file a bug report. Thanks!
This could also happen due to some PCI bus incompatibility (the ACX100
states a PCI2.2 requirement!!). If you happen to have a SB Live! card and
lose sound or have crashes when using an ACX card (both 802.11b *and* 802.11g
chipsets are affected, according to reports!), then try loading the ACX1xx
driver BEFORE loading the SB Live! (this managed to fix sound for one person)
Hmm, OTOH someone else reported that inserting the WLAN card AFTER
bootup manages to fix it. So simply try swapping the sound/network
module init sequence.
Also, using an SB Live! with ACX1xx may result in crashes and data corruption.
You might choose to avoid any potential issues by getting rid of either
the ACX card (much preferred; reason: TI support policy...) or the SB Live!
-- Wireless config failure --
If you get log messages like
Buffer for request 8B0B too small (0<564)
or other strange/erratic wireless config behaviour, then make damn sure that
your wireless-tools version is correct. There are tons of possibilities
for version conflicts!
A message like
Warning: Driver for device wlan0 has been compiled with version 16
of Wireless Extension, while this program is using version 15.
Some things may be broken...
also means that you should consider upgrading your wireless-tools,
since it's a version that doesn't match the one of your currently running
kernel (or acx100 build kernel).
-- Network failure --
First, did you ifup the card? (ifconfig wlan0 up)
Without an activated interface there won't be any net connection at all,
since the wireless part (and much more) of the card will be deactivated...
Also, make absolutely sure you're using correct settings for
association to the wireless network!
It's of no use to try to associate to a set of access points using
Ad-Hoc mode, or maybe the other way around (to use Managed mode to
associate with a card set to Peer).
NOTE that we recently abandoned the Auto mode setting; you need to do an
explicit configuration by specifying Managed or Ad-Hoc mode, otherwise
the driver won't do anything (policy: "don't connect to random networks
if the user isn't sure what he wants").
Further, the ESSID is CaSe SEnsITivE!
Since the driver is currently doing passive scan only, your peer station HAS
to be configured to send Beacon frames (100ms Beacon period works best).
Then read the file containing the driver log (see "DEBUGGING / LOGGING").
Make sure that network association is working properly!
(all steps that get listed in the log from STARTED, SCANNING, WAIT_AUTH,
AUTHENTICATED to ASSOCIATED finish successfully)
Also make sure your peer AP has reliable Beacon period settings
(100ms is the standard value which our driver always detects during scan,
longer periods may cause trouble).
Maybe basic or operational rate set is set incorrectly, so association
to an AP fails.
Try to fix it, e.g. something like iwpriv wlan0 SetRates "1,2 1,2,5,11".
This is also required to let Ad-Hoc Beacons from acx111 cards get recognized
by 11Mbps cards, since otherwise the Beacon Tx speed will exceed 11Mbps!
(will be done automatically in a future driver version)
Also, check whether you actually use the newest or a working firmware version.
In some cases it's actually not this driver but the firmware which is
misbehaving...
If you connect to an AP with hidden ESSID ("") and you happen to have
several APs with hidden ESSID in your environment, then you need to also
specify the AP MAC address in order to make sure that the *single attempt*
we're making connects to the AP you want...
If you get some "link failed" message or similar, try using
MII_NOT_SUPPORTED=yes in your /etc/sysconfig/network-scripts/ifcfg-wlan0
or similar file.
Disable packet fragmentation on your AP, since our driver doesn't
support Rx and Tx (de-)fragmentation yet, so this may cause problems.
Disable any 4X mode feature on your 22Mbps AP, since our driver doesn't support
4X mode yet and 4X mode is known to cause problems sometimes.
Using IPv6? Make sure to configure an MTU >= 1280, otherwise setting
the address will fail with an obscure "not enough buffer space" kernel error!
If your transfer speed is very low in auto rate mode, then make sure to use
a maximum rate that's compatible with the maximum rate of your peer
(non-auto-rate mode wouldn't get any connection in that case, BTW...).
If traffic is problematic in case other peers are active, then fiddling with
iwconfig rts might help.
Multicast not working? The driver is currently not fully handling multicast.
See https://sourceforge.net/forum/message.php?msg_id=2361212 for discussion
and (semi-)solutions.
IRQ lockup (no more IRQs from card) after some time? Try booting with or
without ACPI enabled, has been reported once to fix it.
If you are still having trouble, then make sure that you didn't get an iwconfig
version incompatibility warning. This can mess up terribly many settings :-(
Get new wireless-tools then...
We tried to make the driver log as dumbed down as possible to make sure
even casual wireless users are able to follow the network association steps
towards the final successful association.
Usual power levels for a connection are (at least for my PheeNet WL-0022
CardBus, other people WILL have better or worse results!):
Signal level 86/100 (extremely good, at least to my PheeNet AP with DWL-900AP+
firmware; directly neighbouring the AP)
Signal level 29/100 (anything less: connection lost @22Mbps)
Signal level 26/100 (anything less: connection lost @11Mbps)
Signal level 21/100 (anything less: connection lost @1Mbps)
Noise level 0/100 (anything more can be problematic, > 10 is deadly)
Link Quality == reverse of Noise level
Note that these signal levels are *NOT* expressed in dBm, instead it's a
percentage value (of course, since xx/100 is percentage) which as closely as
possible matches values of the current Windows driver (although I guess
it's not as closely matching as we thought!).
I still hope that we'll be able to calibrate our driver eventually to show dBm
values :-\
Note that signal levels in Ad-Hoc mode are being displayed relative to the station
which answered during our initial scanning period, so the signal level source
(and thus the average level!!) might change with every new association.
UPDATE: changed driver to update level from every packet received, no matter
which peer.
Also try other channel values to reduce interference by cordless phones,
microwaves etc.
If you keep getting Tx errors, also try setting other values for
"iwconfig sens" (e.g. 92, useful values are between 30 and 100 and
between 160 and 200). Most useful range is 85 to 91 (91 best).
In case of Tx error 0x20, use iwconfig retry (set both values!).
If you experience complete traffic lockups after some random time,
then don't use hdparm -u1, since it may lockup/delay driver IRQ
operation for some yet unknown reason.
Some connection problems might also be caused by the Access Point using a
problematic antenna configuration setting (e.g. "internal" instead of
"external" or so).
If you still have trouble getting a connection, or if the connection is
problematic, then try
http://www.houseofcraig.net/acx100_howto.php
or visit our Wiki HOWTO/troubleshooting pages for more info.
And if that still doesn't give you the info you need,
then consider NOT posting a request on the Forum or writing to the mailing
lists, since we cannot track these properly.
Instead, post a Tracker item at one of Bugs, Support Requests, Feature
Requests. This way development will be much more organized, with proper
status and processing assigned to each request, and hopefully nothing
falling through the cracks. Please try to not post anonymously,
since this severely degrades tracking quality. Thanks!
****************************************
A useful report would include:
- the acx_proc.txt file created via
"cat /proc/driver/acx* > /tmp/acx_proc.txt"
- in case you're experiencing connection issues or similar:
the output log files of the debug=XXXX parameter (see "DEBUGGING / LOGGING")
****************************************
Thanks for listening!
=== BUGS / SHORTCOMINGS / PATCHES ===
- might not work on SMP multi-processor kernels sometimes
(some problems, maybe even crashes). Reported to work, currently
- power management (suspend/resume) handlers are not completely stable yet
- several advanced features are not implemented yet
For current tasks, please read TODO (or grep driver for FIXME and TODO).
In case of bugs that didn't exist in previous versions,
PLEASE do regression testing via CVS:
http://www.winehq.org/site/docs/wine-devel/cvs-regression
(remember: WE are doing the driver, so it's YOUR responsibility to get any
problems fixed that might happen in between...;)
If you manage to fix or implement something, then please immediately
send patches for inclusion to the acx100-devel@lists.sf.net mailing list.
************************* !!!!!!!!!!!!!!!!!!!!! *************************
NOTE that by sending us patches, you implicitly accept that we also publish
them in BSD licensed form eventually, since we want to keep this driver
functionality usable by BSD systems and we assume that you've read this note
about patch submission in this main README file that everybody is
supposed to read before making use of our project (and projects in general!).
If you don't want to accept this implicit licensing, then please make
sure to let us know which code parts are not supposed to be used by BSD
systems. Thanks!
************************* !!!!!!!!!!!!!!!!!!!!! *************************
=== SYSTEM CUSTOMIZATION ===
Again, no automatic system installation is provided, since the various Linux
distributions often differ in their exact network configuration methods
and it's really not our job to care about maybe 5 to 10 different
distribution scripts (at least not now as long as our driver is
especially experimental).
Thus maybe simply adapt and use our scripts/start_net script. Or add
that script as a properly executed init script in /etc/[rc.d]/init.d/
(use e.g. /etc/init.d/skeleton as an example)
Then create e.g. runlevel 2 symlinks ("ln -s") from K* and S* scripts in e.g.
/etc/rc2.d/ to your init script in /etc/init.d/ and it should hopefully
get loaded automatically on system bootup.
module autoloading configuration (e.g. in /etc/modprobe.conf or
/etc/modules.conf) could be:
options acx_pci firmware_dir=/home/ivor/cvs/acx100-0_1a-rc1/firmware
alias wlan0 acx_pci
ACX111 card support can be changed to use 32 ring buffers instead of 16
(we are using 16 since 32 often fails to allocate enough memory!) by
changing the RXBUFFERCOUNT_ACX111/TXBUFFERCOUNT_ACX111 defines to 32.
USING WAPROAMD
The waproamd is "a roaming daemon for wireless IEEE 802.11 NICs supporting
the Linux wireless extensions".
1. install waproamd (http://0pointer.de/lennart/projects/waproamd/) [debian package available] so it will be started before you insert the pcmcia wlan card;
2. put your pcmcia card in;
4. waproamd shall make all work for you.
3. if driver was not loaded or loaded with errors do from console
Remove acx_driver if loaded with errors
"rmmod acx_pci"
Load acx_pci driver (change paths according to Your settings. The below is for acx100 module build in 2.6.x kernel tree. [This is a one line command]
"insmod /lib/modules/`uname -r`/kernel/drivers/net/wireless/acx100/acx_pci.ko use_eth_name=1 debug=0x01 firmware_dir=/lib/modules/acx100_fmwe/"
The waproamd daemon has to look for available access points and set the eth1 nic properly.
4. And finally try to use dhcp
"dhclient eth1"
or set ifconfig manually.
=== AND FINALLY... ===
Let me mention that we REALLY dislike the way very stupid hardware vendors
name their cards containing DIFFERENT chipsets!!
One of these vendors is SpeedStream/Siemens: a card that uses the same
name "SS1021" is available in both Orinoco chip and ACX100 chip versions.
USRobotics also just started to enjoy these terrible misdeeds:
the USR2210 usually has the ACX100, however newer versions with UNCHANGED
naming (e.g. at tigerdirect.com) contain a newer incompatible 802.11g
TI chipset.
Sitecom recently also joined the devilish party with their "WL-120" (ACX111)
and "WL-120 v2" (Harris) cards. Plus, they had GPL non-compliance issues with
some of their products and were ultimately told by the court to obey it properly.
But the worst offender is D-Link: they have "DWL-650" and "DWL-650+".
"DWL-650+" is simply an improved version of the "DWL-650", right?
WRONG!
The standard versions use Prism2.5, whereas the "+" versions use ACX100
chipset. Good luck in finding a (correct) driver!!
And it's even WORSE: I just found out that there is some newer
version of the "DWL-650" out that also contains the ACX100
(it uses the same hardware as the "+" versions).
Not to mention that D-Link now uses the DWL*650* naming for about 6 or 7
different products!
This BRAINDEAD STUPIDITY in device naming easily entitles D-Link
for the "Most Braindead Hardware Vendor 2003" award. And of course
they were also talking about developing another Linux driver for some time,
without any results (although I guess that's because they wanted to
develop it, but were not allowed to, unfortunately, so it's understandable).
IF you dare to release cards with a different incompatible chipset
that doesn't even have proper driver support for a popular alternative OS,
then AT LEAST change the card name in order to let people know and discern
which hardware to avoid like the plague, for heaven's sake!
This is such a <CENSORED>, I could <OUCH, CENSORED!>...
Also, we just learned that D-Link tech support can be rather clueless, too:
one guy, after having been ill-advised by D-Link support that his DWL-120+
uses an Atmel chipset, spent considerable time trying to get this card to work
with an incompatible Linux driver (it's the DWL-120 which uses an Atmel chip -
the DWL-120+ is using an ACX100 in USB mode!).
However, all things considered, it seems like D-Link does care more about us
than some other vendors: someone asked them for a redistribution license
of the binary firmware files, and they (D-Link Germany) rather quickly
followed up and granted redistribution (which quite surprised me, I have
to admit). Together with actually wanting to release a Linux driver for
TI cards (see above), this puts D-Link in a rather positive light...
Finally, let me mention that we really dislike the way how
Texas Instruments handles Linux driver support. It's a shameful pity,
with delays to be measured in years versus the Windows driver
support, and with poor and buggy binary driver support.
All in all our team would be very grateful to receive proper
development support and cooperation from TI in order to create
proper Linux drivers. That would be The Good Way to do it...
(although admittedly that would still only be the second-best way to do it,
with the best way being to have paid company developers work on a
well-working OSS driver...)
After all it's the hardware VENDOR that's earning money via OUR, the
customers', payment, so it should be the damn responsibility of the
hardware vendor to ensure good driver support (if by no other means
than providing sufficient specs to OSS developers), not the other way around!
Just imagine the weird looks of thousands and thousands of Linux users
when they discovered the lack of support for the product that they just
shelled out considerable amounts of money for...
For an example of a vendor whose actions I deem useful, let me just mention
Sitecom. They list Linux compatibility status for many of their products on
their website, and from the look of it they clearly support Linux quite
actively. (UPDATE: they also screwed up in a big way. See above. :-\)
Have fun!
The ACX100/ACX111 OSS driver project team :-)
http://acx100.sourceforge.net