rt2x00.serialmonkey.com

I finally got the torx-bit and a new harddisk in the Cube. I should have a log with the endian4-patch for you some time tomorrow. Sorry about the delay.

/Adam

Attached is the log with endian4.patch.gz applied. Besides what you see in the log, I got a lot of kernel: <-- RADIO OFF in the syslog.

The machine is up and running again, so turn-around time should be way better now.

Best regards, Adam.

Hi asjo,

Glad to see you're back on the air. Thanks for hanging in there.

Turns out we also need to byte flip selected fields of the EEPROM data that is read in during initialization. The attached updated patch "endian5.patch.gz" does that and also steers more debug messages to the debug file.

Please apply it to a vanilla copy of the latest CVS and see what happens.

Thanks again,

Done, attached is the log.

Well, actually the log created by the recipe in TESTING was empty. So I give you the output of multiple runs of dmesg, cut together.

When I ran ifup rausb0, I got this in the xterm:

# ifup rausb0
Error for wireless request "Set ESSID" (8B1A) :
SET failed on device rausb0 ; Network is down.
#

Which I think is new.

Running ifdown rausb0 gave the same output. Running rmmod rt2570 did not crash the machine.

Best regards, Adam.

Hi asjo,

You definitely went above and beyond the call of duty, here.

I've fixed a couple of minor items having to do with the xmit and recv descriptor data areas, and steered yet more debug messages to the debug log (attached as endian6.patch.gz); but I can't find anything that would account for an empty debug log.

Could you apply this version of the patch to the latest CVS and try it? If there's still no debug log, then could you do a run where you just do a modprobe followed by a rmmod? Basically, I'm trying to find out where the driver is stepping on itself.

Thanks again; and - again - thanks for the work,

I think the empty log was my fault, I didn't restart syslogd properly after truncating it or something. Sorry about the confusion.

Here is a new log with endian6 applied to a clean CVS; doing:

insmod rt2570.ko debug=31
ifup rausb0
ifconfig
iwconfig
iwlist rausb0 scan
ifdown rausb0
rmmod rt2570

Best regards, Adam

Hi asjo,

If i'm luckier than I've been so far, this latest version of the patch - attached as endian7.patch.gz - should endianize the needed frame data fields, and hopefully no others.

Please apply it to a vanilla version of the latest CVS and see what happens.

We'll keep our fingers crossed - who knows?

Thanks again for your work,

It looks like you have been quite succesfull. Attached is the log. After waiting a while, I got this output from a iwlist rausb0 scan:

rausb0 Scan completed :
Cell 01 - Address: 00:0F:66:51:C7:15
Mode:Managed
ESSID:"koldfrontairportnet"
Encryption key:off
Channel:9
Cell 02 - Address: 00:17:3F:B7:C9:D0
Mode:Managed
ESSID:"belkin54g"
Encryption key:on
Channel:11

And the netcard associated to my accesspoint; ifwconfig said:

rausb0 RT2500USB WLAN ESSID:"koldfrontairportnet"
Mode:Managed Frequency=2.412 GHz Bit Rate:11 Mb/s
RTS thr:off Fragment thr:off
Encryption key:off
Link Quality=0/100 Signal level:-73 dBm Noise level:-86 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

I tried pinging the ip-address, and got answers. So I ssh'ed to it, and that worked as well. I haven't done any stresstesting though (any suggestions?)

When I ran ifdown rausb0 I got this, though:

Error for wireless request "Set ESSID" (8B1A) :
SET failed on device rausb0 ; Network is down.

Looks very promising!!

Best regards, Adam

Hi asjo,

We've made progress, but according to the log, the authentication request keeps timing out. It turns out I omitted endianizing some 16 bit data fields in the authentication and association request frames, thus causing the AP to drop them (I think).

Anyway, this version of the patch - attached as endian8.patch.gz - does those operations now. Could you give it a try?

Thanks,

Failed to build:

asjo@gnalle:/usr/src/source/rt2570/Module$ make debug
make[1]: Entering directory `/usr/src/linux-headers-2.6.18-5-powerpc'
CC [M] /usr/src/source/rt2570/Module/rtusb_main.o
CC [M] /usr/src/source/rt2570/Module/mlme.o
CC [M] /usr/src/source/rt2570/Module/rtusb_bulk.o
CC [M] /usr/src/source/rt2570/Module/connect.o
CC [M] /usr/src/source/rt2570/Module/sync.o
CC [M] /usr/src/source/rt2570/Module/rtusb_init.o
CC [M] /usr/src/source/rt2570/Module/rtmp_tkip.o
CC [M] /usr/src/source/rt2570/Module/wpa.o
CC [M] /usr/src/source/rt2570/Module/rtmp_wep.o
CC [M] /usr/src/source/rt2570/Module/rtusb_info.o
CC [M] /usr/src/source/rt2570/Module/assoc.o
/usr/src/source/rt2570/Module/assoc.c: In function â:
/usr/src/source/rt2570/Module/assoc.c:315: error: â undeclared (first use in this function)
/usr/src/source/rt2570/Module/assoc.c:315: error: (Each undeclared identifier is reported only once
/usr/src/source/rt2570/Module/assoc.c:315: error: for each function it appears in.)
make[2]: *** [/usr/src/source/rt2570/Module/assoc.o] Error 1
make[1]: *** [_module_/usr/src/source/rt2570/Module] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.18-5-powerpc'
rt2570.ko failed to build!
make: *** [debug] Error 1

I think I've had this error before, but forgot the fix...

Ah, just a typo:

--- assoc.c.orig 2007-12-11 19:40:42.589014026 +0100
+++ assoc.c 2007-12-11 19:38:57.609994572 +0100
@@ -312,7 +312,7 @@
MgtMacHeaderInit(pAd, &AssocHdr, SUBTYPE_ASSOC_REQ, 0, &ApAddr, &ApAddr);

// Build basic frame first
- cpu_to_le16s(&CapablityInfo);
+ cpu_to_le16s(&CapabilityInfo);
cpu_to_le16s(&ListenIntv);
MakeOutgoingFrame(
OutBuffer, &FrameLen,

Log in a minute.

Attached is the log. Please note that my accesspoint (for legacy reasons) does not use WEP nor WPA. A lot of my neighbours have accesspoints with encryption turned on.

Best regards, Adam.

Hi asjo,

Well, the log shows that we're still timing out after sending the 1st authentication request frame. I haven't been able to see where exactly things are going wrong, so I've modified the patch yet again to get more information. The latest version - attached as endian9.patch.gz - does two things:

First, it applies the fix for the source code typo that you provided in your previous post.

Second, it prints out what is actually being sent down to the adapter when compiled and run with debug enabled; c.f. the function RTUSBBulkOutMLMEPacket.

Could you apply it to a vanilla copy of the latest CVS and see what happens?

Thanks,

Here is the log, hope it helps.

Best regards, Adam.

Hi asjo,

The frame of interest looks OK when we send it down to the adapter; so I need to dig some more.

Have you tried using the adapter on a little-endian machine running LInux to access the same AP? Does it work in that configuration?

... I had to ask. Thanks,

Yes, I have. It worked fine on the Compaq Pentium II-machine that the Apple Cube I am using now replaced.

(I have acquired an Airport-card for the Cube that I am using currently, so the incentive for me to get the rt2570-card to work is mainly larger bandwidth, now).

Best regards, Adam.

Hi asjo,

This latest version of the patch (attached as endian10.patch.gz) endianizes a little more frame data; transmitted deauthentication reason code, received CFP values from beacons and probe responses, and received ATIM window, beacon period, and capability info when in ad hoc mode. I doubt these are sufficient to get us past the authentication timeout problem, but they are needed for correct functioning on a big endian machine.

Could you apply it to a vanilla copy of the latest CVS and see what happens?

Thanks,