dwl-520+ and linux (works!)

Wed Jan 22 09:41:42 PST 2003

So the + generation of dlink's products seems to finally work..?
I think i might have made dwl-520+ work under linux..
Even though dlink announced in last december that they would publish drivers 
(be it binary) for their TI - 22mbps products, such thing never happened..
Some point in November as i recall someone published a binary driver on 
behalf of a eusso company for a pPCI devicethat has the same chipset as the + 
generation by dlink (and others), the acx100 by Texas Instruments.. 
gryppas:~# cat /proc/pci
<snip>
Bus 0, device 12, function 0:
Network controller: PCI device 104c:8400 (Texas Instruments) (rev 0).
IRQ 11.
Master Capable. Latency=32.
I/O at 0xdc00 [0xdc1f].
Non-prefetchable 32 bit memory at 0xdc010000 [0xdc010fff].
Non-prefetchable 32 bit memory at 0xdc000000 [0xdc00ffff].
<snip> 
The driver was setup for a mandrake kernel, a 2.4.18-16mdk, see what the 
module has to say;
gryppas:/home/panxer# modinfo acx100_pci.o
filename: acx100_pci.o
description: "TI ACX100 WLAN 22Mbps driver"
author: "Lancelot Wang"
license: "GPL" 
Mentioning GPL makes me happy, maybe they finnaly _do_ plan to release the 
source code.

I noticed in the lwan mailing list that none had succeded in loading the 
driver and making it work.
I tried to load the driver in my 2.4.18 kernel yet it came oute with 5 or 6 
unresolved symbols, plus it was annoying telling me that it was made for a 
-16mdk..
Using hexeditor i erased every mention of -16mdk, and it stopped picking me 
about it. After contacting some guys from lkml i realised that  
CONFIG_DEBUG_KERNEL should be on, so i recompiled the kernel with this oprion 
and the driver came out with only one unresolved symbol which as i suspected 
it had to do with the fact that the built tree of the kernel was in 
/usr/src/whatever instead of the /usr/src/linux..(?)
So I mv /usr/src/whatever /usr/src/linux, placed the driver in /lib/modules 
and echo "alias wlan0 acx100_pci" >> /etc/modules.conf 
After a reboot the driver loaded properly!
gryppas:~# lsmod |grep a
Module Size Used by Tainted: GF
acx100_pci 181952 0 
I got the wlan0 up and 
gryppas:~# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:08:05:BF:66:50
inet addr:192.168.0.3 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::208:5ff:febf:6650/10 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:288 (288.0 b)
Interrupt:11 

iwconfig speaks:
gryppas:~# iwconfig wlan0
wlan0 v0.9.0.3a 11b+ ESSID:"Wesley2" Nickname:""
Mode:Ad-Hoc Channel:1 Cell: 59:51:5C:E6:3F:09 

Wesley2 is the default essid as seen in the driver...
gryppas:/etc/wireless/acx100# iwconfig wlan0 essid panxer
gryppas:/etc/wireless/acx100# iwconfig wlan0
wlan0 v0.9.0.3a 11b+ ESSID:"panxer" Nickname:""
Mode:Ad-Hoc Channel:1 Cell: 66:EE:E3:59:80:B6 
nice!
gryppas:~# uname -a &&lsmod
Linux gryppas 2.4.18 #5 ??? ??? 20 18:51:53 EET 2003 i686 unknown
Module Size Used by Tainted: GF
acx100_pci 181952 1 

Lets see if its functional
gryppas:~# ping 192.168.0.3
PING 192.168.0.3 (192.168.0.3): 56 data bytes
64 bytes from 192.168.0.3: icmp_seq=0 ttl=255 time=0.3 ms
<snip>
64 bytes from 192.168.0.3: icmp_seq=19 ttl=255 time=0.2 ms
--- 192.168.0.3 ping statistics ---
20 packets transmitted, 20 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.1/0.3 ms 

I borrowed a dw-900+ AP from a friend partner in the AWMN project ( 
www.athenswireless.net ) to do some testing..
It occured that the 900+ some how gets crazy when ping it hard, but it might 
be the driver or the 520+
--- 192.168.0.49 ping statistics ---
52 packets transmitted, 38 packets received, 26% packet loss
round-trip min/avg/max = 1.9/8374.0/32007.4 ms 

The strange thing is that;
gryppas:/etc/wireless/acx100# ping 192.168.0.49
PING 192.168.0.49 (192.168.0.49): 56 data bytes
64 bytes from 192.168.0.49: icmp_seq=13 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=14 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=15 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=16 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=17 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=18 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=19 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=20 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=21 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=22 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=23 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=24 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=25 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=26 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=27 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=28 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=29 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=30 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=31 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=32 ttl=127 time=4.3 ms
64 bytes from 192.168.0.49: icmp_seq=0 ttl=127 time=32007.4 ms
64 bytes from 192.168.0.49: icmp_seq=1 ttl=127 time=31008.6 ms
64 bytes from 192.168.0.49: icmp_seq=2 ttl=127 time=30010.6 ms
64 bytes from 192.168.0.49: icmp_seq=3 ttl=127 time=29011.3 ms
64 bytes from 192.168.0.49: icmp_seq=4 ttl=127 time=28012.2 ms
64 bytes from 192.168.0.49: icmp_seq=5 ttl=127 time=27013.3 ms
64 bytes from 192.168.0.49: icmp_seq=6 ttl=127 time=26014.0 ms
64 bytes from 192.168.0.49: icmp_seq=7 ttl=127 time=25015.1 ms
64 bytes from 192.168.0.49: icmp_seq=8 ttl=127 time=24016.4 ms
64 bytes from 192.168.0.49: icmp_seq=9 ttl=127 time=23017.2 ms
64 bytes from 192.168.0.49: icmp_seq=10 ttl=127 time=22018.0 ms
64 bytes from 192.168.0.49: icmp_seq=11 ttl=127 time=21018.6 ms
64 bytes from 192.168.0.49: icmp_seq=46 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=47 ttl=127 time=2.6 ms
64 bytes from 192.168.0.49: icmp_seq=48 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=49 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=50 ttl=127 time=1.9 ms
64 bytes from 192.168.0.49: icmp_seq=51 ttl=127 time=1.9 ms

Some icmp packets are delayed somehow (low basic Tx rate maybe?)..

I did some tweaks on the 900+ and it seems to be handling dwl-520+ better,
I still get some packetloss (few) and plenty of DUPs. I have to add that i 
can switch channel on the 520+ only after switching the AP to the desired 
channel and setting the same essid..
gryppas:/etc# iwconfig wlan0 mode managed channel 6 essid awmn
gryppas:/etc# iwconfig
lo no wireless extensions.

wlan0 v0.9.0.3a 11b+ ESSID:"awmn" Nickname:""
Mode:Managed Channel:6 Access Point: 00:40:05:CA:80:1E
Encryption key:off

eth0 no wireless extensions.

So, let us see what happens..
gryppas:~# ping -s 1024 192.168.0.202
PING 192.168.0.202 (192.168.0.202): 1024 data bytes
1032 bytes from 192.168.0.202: icmp_seq=0 ttl=128 time=4.8 ms
1032 bytes from 192.168.0.202: icmp_seq=1 ttl=128 time=5.9 ms
<snip>
--- 192.168.0.202 ping statistics ---
76 packets transmitted, 73 packets received, +9 duplicates, 3% packet loss
round-trip min/avg/max = 4.6/5.4/10.2 ms 
kinda nice i must say..

My logs are full of debugging stuff so maybe that suggests that the plan to 
release the driver someday..
Havent been able to get in contact with the guy who developed the driver..
In lwan-ng they imply that he used their code (which is under GPL) so we 
vould force him to publish the source..
Or else try to reverse eng. it. :P

After playing with the 900+ again i get better responces but lots of DUPs...

The fact is that dwl-520+ works under linux (at least in some point), i thing 
that all wifi NICs using acx100 might work also, check it out.. 

Regards,
Panagiotis Moustafellos 
(aka panXer)

www.athenswireless.net