(solved) ASUS WL-167g on Ubuntu Hardy iMac G3
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 for the info. What does the sequence "ifconfig wlan0;iwconfig wlan0" (assuming the interface is named "wlan0") say?
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
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
It looks like the device may not be "up". Has "ifconfig wlan0 up" been done somewhere along the line?
What does "route -n" say"
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
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
Could you (sigh) try building and running with debug enabled, then attach a gzipped copy of /var/log/debug to a post here?
Here you go...
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,
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.
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,
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
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.
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.
Just for fun, could you try the attached patch?
I'll give it a try. And here is the output you requested.
I successfully applied the patch
$ patch -p0 <fswap1.patch
patching file rtusb_data.c
but got a compilation error
make: 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: *** [/tmp/rt73-cvs-2008120513/Module/rtusb_data.o] Error 1
make: *** [_module_/tmp/rt73-cvs-2008120513/Module] Error 2
make: 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.
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.
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.
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.
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.
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?
Happy New Year to you!
Here is the debug output after applying the new patch.
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.
Sorry to say but still no joy. Here is the new debug output.
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?
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.
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?
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.
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),
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.
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.
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!
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,