(solved) ASUS WL-167g on Ubuntu Hardy iMac G3

zoof

07-12-2008 02:05:58

I've spend all day trying to get this USB wireless dongle to work but no luck. The onboard drivers can get me a WPA connection but it won't keep a connection for more than a few minutes. Using either NetworkManager or WICD, the tray icon will show that there is a connection but no data is actually transmitted.

Using the legacy rt73 driver, I can't even get a connection. Various AP's are found so there is some functionality but nothing beyond that. I've tried command line and using RutilT to get a connection but nothing worked. Attached is all the requested debug information.

Thanks!

Vern

07-12-2008 16:35:30

Hi zoof,

Thanks for the info. What does the sequence "ifconfig wlan0;iwconfig wlan0" (assuming the interface is named "wlan0") say?

Thanks,

zoof

07-12-2008 17:26:54

Hi Vern,

Here's the output

$ifconfig wlan0;iwconfig wlan0 wlan0 Link encapEthernet HWaddr 002354071bff BROADCAST MULTICAST MTU1500 Metric1 RX packets0 errors0 dropped0 overruns0 frame0 TX packets0 errors0 dropped0 overruns0 carrier0 collisions0 txqueuelen1000 RX bytes0 (0.0 B) TX bytes0 (0.0 B) wlan0 RT73 WLAN ESSID"TAZ0yLMt3GpsMJAKLXNh" ModeManaged Frequency=2.412 GHz Bit Rate=54 Mb/s RTS throff Fragment throff Link Quality=0/100 Signal level-121 dBm Noise level-111 dBm Rx invalid nwid0 Rx invalid crypt0 Rx invalid frag0 Tx excessive retries0 Invalid misc0 Missed beacon0 Vern 08-12-2008 01:39:26 Hi zoof, It looks like the device may not be "up". Has "ifconfig wlan0 up" been done somewhere along the line? What does "route -n" say" Thanks, zoof 08-12-2008 14:35:28 Hi Vern, Sorry I didn't think through exactly what it was that you wanted. Here's the new output as well as the result of "route -n". [code1ruztfht]$ ifconfig wlan0;iwconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:23:54:07:1b:ff
inet6 addr: fe80::223:54ff:fe07:1bff/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:317 errors:0 dropped:1 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:415819 (406.0 KB) TX bytes:17930 (17.5 KB)

wlan0 RT73 WLAN ESSID:"TAZ0yLMt3GpsMJAKLXNh"
Mode:Managed Frequency=2.412 GHz Bit Rate=54 Mb/s
RTS thr:off Fragment thr:off
Link Quality=0/100 Signal level:-30 dBm Noise level:-115 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
$route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 wlan0 0.0.0.0 0.0.0.0 0.0.0.0 U 1000 0 0 wlan0 [/code1ruztfht] Vern 08-12-2008 16:05:37 Hi zoof, Could you (sigh) try building and running with debug enabled, then attach a gzipped copy of /var/log/debug to a post here? Thanks, zoof 08-12-2008 16:27:34 Hi Vern, Here you go... Thanks, Vern 15-12-2008 17:23:21 Hi zoof, Sorry to keep you waiting so long. I finally got around to taking a look at your log. It doesn't look like you set the operating mode (adhoc vs. infra) anywhere. Could you double check to see if that's happening? Thanks and - again - sorry for the delay, zoof 18-12-2008 04:15:49 Hi Vern, Sorry if I didn't get quite what it was that you were looking for. I redid it and have also included the ifconfig and iwconfig output. Let me know if this is ok. Vern 20-12-2008 17:25:00 Hi zoof, Rechecked and found that indeed you are setting the mode - in both logs. My bad eyesight. Sorry. About all I've found so far is that although the adapter sees both APs in your network, its authentication request is timing out, for reasons I haven't yet determined. Are the adapter and APs configured compatibly? Will keep looking, zoof 20-12-2008 20:41:49 Hi Vern, I believe everything is configured correctly. The routers are WRT54Gs with tomato installed and configured as WDS with WPA1 and AES. To test that my network setup is correct, I booted up a Hardy live cd on an old 300Mhz x86 laptop, copied over the same source code I used on the G3 and the same /etc/network/interfaces file. I killed all network manager processes, rmmod'd the rt73usb, rt2x00usb and rt2x00lib modules and then modprobe'd rt73. Lastly 'sudo /etc/init.d/networking restart' and got a connection that was stable for as long as I left the computer on (about 5 minutes once I got a connection but I can leave it longer if it would be useful). Just to verify that I indeed configured the network correctly, here is /etc/network/interfaces [code23mxaime]auto wlan0 iface wlan0 inet dhcp pre-up ifconfig wlan0 up pre-up iwconfig wlan0 mode Managed pre-up iwconfig wlan0 essid "TAZ0yLMt3GpsMJAKLXNh" pre-up iwpriv wlan0 set AuthMode=WPAPSK pre-up iwpriv wlan0 set EncrypType=AES pre-up iwpriv wlan0 set WPAPSK="xxxxxxxxxxxxxxxxxx"[/code23mxaime] Pretty weird problem I guess but hopefully solvable. Actually, I'm a little surprised no one else has encountered it before as there must be tons of G3 iMacs out there, USB wireless devices are much cheaper than an Airport card and word is that the rt73 based dongles work, at least for x86 processors. Vern 21-12-2008 16:10:23 Hi zoof, Thanks for the effort and time in doing the cross check on an i386-type machine. Big endian capabilities for this driver have never been completely tested, and your results indicate that there's a problem with the driver - still - when in big endian mode. So that was a very useful effort. Could you do something like[codetmjkj533](touch /tmp/dummy_file.c; gcc -E -dM ~/tmp/dummy_file.c;\rm /tmp/dummy_file.c)|sort[/codetmjkj533](all on one line, though) and attach a gzipped file containing the output to a post here? This will help me verify if indeed I use the correct compiler constants to build for a big endian target environment. In the meantime, I need to go through the logic that generates an authentication request (in auth.c). It's pretty similar to that of the rt2570 driver, so the latter can be used as a baseline. Feel free to carry on a parallel effort (hint, hint). Thanks again, and hopefully, we'll have patch soon. Vern 22-12-2008 02:10:02 Hi zoof, Just for fun, could you try the attached patch? Thanks, zoof 22-12-2008 13:32:50 Hi Vern, I'll give it a try. And here is the output you requested. Thanks, zoof 22-12-2008 19:40:27 Hi Vern, I successfully applied the patch [code3lv3xozq]$ patch -p0 <fswap1.patch
patching file rtusb_data.c
[/code3lv3xozq]
but got a compilation error
[code3lv3xozq]\$ make
make[1]: Entering directory /usr/src/linux-headers-2.6.24-22-powerpc'
CC [M] /tmp/rt73-cvs-2008120513/Module/rtmp_main.o
CC [M] /tmp/rt73-cvs-2008120513/Module/mlme.o
CC [M] /tmp/rt73-cvs-2008120513/Module/connect.o
CC [M] /tmp/rt73-cvs-2008120513/Module/rtusb_bulk.o
CC [M] /tmp/rt73-cvs-2008120513/Module/rtusb_io.o
CC [M] /tmp/rt73-cvs-2008120513/Module/sync.o
CC [M] /tmp/rt73-cvs-2008120513/Module/assoc.o
CC [M] /tmp/rt73-cvs-2008120513/Module/auth.o
CC [M] /tmp/rt73-cvs-2008120513/Module/auth_rsp.o
CC [M] /tmp/rt73-cvs-2008120513/Module/rtusb_data.o
/tmp/rt73-cvs-2008120513/Module/rtusb_data.c: In function ‘RTUSBMlmeHardTransmit’:
/tmp/rt73-cvs-2008120513/Module/rtusb_data.c:1314: error: ‘pHeader80211’ undeclared (first use in this function)
/tmp/rt73-cvs-2008120513/Module/rtusb_data.c:1314: error: (Each undeclared identifier is reported only once
/tmp/rt73-cvs-2008120513/Module/rtusb_data.c:1314: error: for each function it appears in.)
make[2]: *** [/tmp/rt73-cvs-2008120513/Module/rtusb_data.o] Error 1
make[1]: *** [_module_/tmp/rt73-cvs-2008120513/Module] Error 2
make[1]: Leaving directory /usr/src/linux-headers-2.6.24-22-powerpc'
rt73.ko failed to build!
make: *** [module] Error 1[/code3lv3xozq]

I take your hint but unfortunately I know no C and wouldn't be much help coding but I'm happy to be of help any way that I can.

Thanks,

Vern

23-12-2008 17:18:46

Hi zoof,

Sorry to make you waste your time on a compile error I could have easily avoided. Haste and inattention. The attached modified patch should fix that. Please apply to an unmodified copy of the source.

The compiler constants you supplied did verify that the right values were being used for compilation, though.

Thanks,

zoof

23-12-2008 20:13:27

Hi Vern,

I tried the new patch and this time it compiled fine but still unable to connect with my AP. I'm not sure if it will be useful but here is the gzipped debug output.

Thanks,

Vern

29-12-2008 21:53:35

Hi zoof,

Looks like I've really left you hung out to dry. Anyway, hope you enjoyed your Christmas.

It looks like the driver wasn't always correctly flipping the content of a control structure it provides to the adapter. The attached patch hopefully fixes that. Could you apply it to a vanilla CVS tarball and see what happens? If it's still n/g, please attach a gzipped copy of /var/log/debug to a post here.

Thanks,

zoof

30-12-2008 03:46:56

Hi Vern,

Not at all -- I expected that you might be busy with the holidays and that it might take you some time to get around to it. I hope you enjoyed them!

In any case, I tried the new patch and it is still not working. Attached is the gzipped debug output.

Thanks,

Vern

02-01-2009 17:46:57

Hi zoof,

Hope you enjoyed your New Year.

It turns out that after we send the authentication request frame, the AP sends us some de-authentication frames - all with apparently the same sequence number.

The attached updated patch is intended to show what the reason code in the de-authentication frame is. Maybe that will provide me with a clue.

Could you try it and attach the resulting log to a post?

Thanks,

zoof

02-01-2009 18:23:29

Hi Vern,

Happy New Year to you!

Here is the debug output after applying the new patch.

Thanks,

Vern

06-01-2009 02:47:32

Hi zoof,

Thanks for the log info. It turns out the AP is accusing us of sending a class 2 frame before we're authenticated. I think *that* happened because the frame wasn't properly endianized prior to transmission.

I think the attached patch fixes that. Please try it and see what happens.

Thanks,

zoof

06-01-2009 15:19:59

Hi Vern,

Sorry to say but still no joy. Here is the new debug output.

Thanks,

Vern

08-01-2009 21:06:24

Hi zoof,

Well, we actually did make progress. The authentication frame exchange now succeeds, but we fail after responding to the third message in the EAPOL pair handshake sequence.

What may actually be the response from the AP is discarded due to a cipher error. It looks like we download an incorrect copy of the key data to the adapter, which would explain the error.

I've modified the patch to hopefully correct that problem and attached it as fwap6.patch.gz. Could you try it and see what happens?

Thanks,

zoof

08-01-2009 21:37:26

Hi Vern,

We're definitely making some progress here. One of the three times I tried to bring up the network resulted in an IP address! The connection was quickly lost but a address nevertheless. Anyway, here is the new debug output.

Thanks,

Vern

19-01-2009 17:16:02

Hi zoof,

Looks like progress is rapid, on a geological time scale. Thanks for your patience.

We now get as far as receiving the first group handshake message, but get de-authenticated due to EAPOL timeout some time later. It looks like the code uses an incorrect group key index internally. The attached patch is intended to fix that. Could you try it?

Thanks,

zoof

19-01-2009 20:10:01

Hi Vern,

I tried the new patch and unlike the previous one, never got an ip address (I think I tried it 5 times?). In any case, here is the debug output.

Thanks,

Vern

20-01-2009 17:51:55

Hi zoof,

I looked at your latest log. It seems we're not even getting thru authentication, which means the latest mod to the patch is not being executed.

There are also messages about invalid frame (sub)types and one de-authentication message with a Reason Code of 39011 - garbage.

I hate to ask, but could you apply the previous version (6) of the patch to a vanilla copy of the latest CVS and run that again? If you do not see the word "WpaGroupMsg1Action" in the debug log, then something has changed in the environment to make things go wrong.

If you do see the word "WpaGroupMsg1Action", then could you apply the latest version of the patch to a vanilla copy of the latest CVS and run that again?

Thanks (and sorry),

zoof

20-01-2009 20:41:08

Hi Vern,

Sorry, I must have made a mistake applying the latest patch. I redid patch 6 and found the message you were looking for. I then redid patch 7 and got a connection that seems to be stable -- at least so far. I'll report back if there are any issues. And in case you want to see it, here is also the debug log.

Thanks,

Vern

20-01-2009 21:12:16

I redid patch 6 and found the message you were looking for. I then redid patch 7 and got a connection that seems to be stable[/quote26lt80li](Whew!!) My Man! I'm impressed. The phrase "Above and beyond the call of duty" comes to mind.

The log looks good. Let's let things cook for a while and see how we do.

Thanks,

zoof

21-01-2009 04:19:22

Hi Vern,

I'm the one that should be impressed -- it has been a few weeks but I'm amazed that you managed to fix the problem this quickly on a machine that you can't even try the code yourself.

Anyway, it's looking pretty good -- up almost 6 hours with no interruptions so I guess we're probably done. I'll leave it on until morning just for good measure.

Thanks for all your help!

Vern

21-01-2009 15:50:27

Hi zoof,

Well, based on there being no problems reported overnight, I've gone ahead and pushed the latest version of the patch into CVS. The changes should start showing up in the hourly tarballs Real Soon Now.

Thanks again for your help,