https://www.slackwiki.com/index.php?title=ACX100_Wireless&feed=atom&action=historyACX100 Wireless - Revision history2024-03-29T09:05:52ZRevision history for this page on the wikiMediaWiki 1.40.0https://www.slackwiki.com/index.php?title=ACX100_Wireless&diff=86&oldid=prevErik: Copy from old, had no category, placed in Hardware2009-06-02T03:26:43Z<p>Copy from old, had no category, placed in Hardware</p>
<p><b>New page</b></p><div>[[Category:Hardware]]<br />
== Introduction ==<br />
This is a Howto on how I was able to get the ACX100 open source driver to work with my card and Slackware. There are several other good resources for this driver on the 'net, but I thought it would be good to create one more that included the specific steps I took in Slackware to get my wireless internet running.<br />
<br />
For the time being, this is mostly just a placeholder, I will update this when I can find some spare time. Check out http://acx100.sourceforge.net for more info.<br />
<br />
<br />
== ACX100 Readme ==<br />
This tarball is targeted at 2.6 inclusion only.<br />
Not designed to work or even compile with 2.4.<br />
<br />
Contact:<br />
netdev@vger.kernel.org<br />
acx100-devel@lists.sourceforge.net<br />
acx100-users@lists.sourceforge.net<br />
<br />
Bug reports:<br />
<br />
Visit http://www.catb.org/~esr/faqs/smart-questions.html<br />
<br />
Please describe your wireless setup, manufacturer and type<br />
(acx100/acx100usb/acx111?) of your hardware. Which firmware image(s)<br />
are you using? If problem is reproducible, #define ACX_DEBUG 2<br />
in acx_config.h and modprobe driver with debug=0xffff.<br />
Post resulting kernel log (bzipped). It is large but very useful<br />
for bug hunting. Try older versions of the driver.<br />
<br />
Firmware images:<br />
<br />
You should not supply firmware_dir= parameter anymore. Driver will try<br />
to load the following images via hotplug (not from /usr/share/acx<br />
directory as older driver did, hotplug firmware directory location<br />
varies for different distros, try /lib/firmware or<br />
/usr/lib/hotplug/firmware):<br />
<br />
PCI driver:<br />
'tiacxNNNcMM' (NNN=100/111, MM=radio module ID (in uppercase hex)):<br />
combined firmware for specified chipset and radio.<br />
Failing that, it will try to load images named 'tiacxNNN'<br />
(main firmware for specified chipset) and 'tiacxNNNrMM' (corresponding<br />
radio module). For example, my firmware is in file named 'tiacx111c16'.<br />
Alternatively, I may remove it and use pair of files 'tiacx111' and<br />
'tiacx111r16' instead.<br />
USB driver:<br />
image is named 'tiacxNNNusbcMM'<br />
<br />
Build instructions:<br />
<br />
* Create drivers/net/wireless/acx subdirectory inside<br />
your kernel tree.<br />
* BTW, if your kernel has drivers/net/wireless/tiacx directory,<br />
you already may have acx driver (some different version).<br />
Decide which one do you want.<br />
* Unpack tarball into drivers/net/wireless/acx directory.<br />
* Add a line to drivers/net/wireless/Makefile:<br />
obj-m += acx/<br />
* Build your modules as usual (perhaps "make modules modules_install").<br />
<br />
This will create acx module.<br />
<br />
Remove "acx-obj-y += usb.o" line in Makefile<br />
and "#define CONFIG_ACX_USB 1" line in acx_config.h<br />
if you want PCI-only driver. Ditto for USB-only one.<br />
<br />
USB snooping:<br />
<br />
If you are an USB driver developer and need to see USB traffic,<br />
http://benoit.papillault.free.fr/usbsnoop/ may be useful.<br />
Another very good way to snoop the USB frames is under Linux if your<br />
driver happens to run under ndiswrapper (which is often the case),<br />
either by savage printk's, or by using the USB snooping facilities from<br />
Pete Zaitcev.<br />
<br />
<br />
From: Per Bjornsson <perbj@stanford.edu><br />
To: ACX100 user mailing list <acx100-users@lists.sourceforge.net><br />
Date: Fri, 08 Jul 2005 13:44:26 -0700<br />
<br />
Hi,<br />
<br />
Just a note for those who, like me, prefer not to bother recompiling<br />
their whole kernel: It's not at all difficult to compile Denis's<br />
snapshots out of tree, despite what the readme file says! At least in<br />
somewhat recent 2.6.x kernels, there's a special syntax for compiling<br />
modules in a particular directory (as noted in the kernel docs in<br />
Documentation/kbuild/modules.txt):<br />
<br />
* Unpack Denis's tarball in a new directory (note that the<br />
tarballs currently don't contain a root directory, just the<br />
files, so you want to do the untarring in an empty directory)<br />
* If you're building for the currently running kernel, build the<br />
modules with the command<br />
make -C /lib/modules/`uname -r`/build M=`pwd`<br />
* Install the modules (must be root for this step, so use<br />
'su' if that's your preferred method of doing root stuff) with<br />
make -C /lib/modules/`uname -r`/build M=`pwd` modules_install<br />
<br />
I figured that the snapshots might get more testing if more people know<br />
that they don't have to muck around with the whole kernel source in<br />
order to build this. I tested this on Fedora Core 4; sane distributions<br />
should be using this setup for accessing the kernel build files (if they<br />
listened to Linus's suggestions anyways). The one trick is that you<br />
might need a special "kernel development files" package; on Fedora Core,<br />
the files are included in the regular kernel package for FC2 and 3 but<br />
you need the 'kernel-devel' package for FC4.<br />
<br />
And finally, the kernel won't figure out that the module has been<br />
installed until you run 'depmod -ae' as root. You can check that<br />
something useful got picked up with 'modinfo'. (Both of these commands<br />
are likely installed in /sbin so you might need the full path unless<br />
you're fully logged in as root.)<br />
<br />
The latest snapshot (acx-20050708.tar.bz2) generally seems to work well<br />
for me, except that it's somewhat noisy and reports a lot of DUPs in the<br />
system log. However, it appears to associate more consistently with my<br />
access point that the old versions (when I had those modprobed on boot<br />
and brought up by the system network scripts, the card would often just<br />
sit and scan around and never actually associate until I manually<br />
restarted the connection) - admittedly I've only tried a couple of times<br />
yet so I don't know just how consistent this is. My hardware is a<br />
Netgear WG311v2, using the firmware from the latest Netgear Windows<br />
driver. (Can't check the details right now since I'm not at that<br />
computer, sorry - it got too late when I was mucking with this and other<br />
stuff yesterday for me to get a message sent...)<br />
<br />
Cheers,<br />
Per<br />
--<br />
Per Bjornsson <perbj@stanford.edu><br />
Ph.D. Candidate, Department of Applied Physics, Stanford University</div>Erik