(solved) rt2570 on a big endian machine

Live forum: http://rt2x00.serialmonkey.com/viewtopic.php?t=4429

asjo

11-11-2007 21:33:14

Hi.

I am trying to get an Asus WL-167g usb wireless card to work with an Apple Cube running Debian stable.

Here is what I did in response to http//sourceforge.net/mailarchive/mess ... global.net

asjo@gnalle/usr/src/rt2x00/source/rt2570/Module$ date
Sun Nov 11 220856 CET 2007
asjo@gnalle/usr/src/rt2x00/source/rt2570/Module$ cvs update -d
cvs update Updating .
asjo@gnalle/usr/src/rt2x00/source/rt2570/Module$ zcat /tmp/endian.patch.gz | patch
patching file rt2570.h
patching file rt2570sw.h
Hunk #2 succeeded at 1113 (offset -1 lines).
patching file rtusb_info.c
patching file rtusb_init.c
patching file rtusb_io.c
patching file rtusb_main.c
asjo@gnalle/usr/src/rt2x00/source/rt2570/Module$ make clean
asjo@gnalle/usr/src/rt2x00/source/rt2570/Module$ make debug
make[1] Entering directory `/usr/src/linux-headers-2.6.18-5-powerpc'
CC [M] /usr/src/rt2x00/source/rt2570/Module/rtusb_main.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/mlme.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/rtusb_bulk.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/connect.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/sync.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/rtusb_init.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/rtmp_tkip.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/wpa.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/rtmp_wep.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/rtusb_info.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/assoc.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/auth.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/auth_rsp.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/md5.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/rtusb_io.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/sanity.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/rtusb_data.o
CC [M] /usr/src/rt2x00/source/rt2570/Module/rt2x00debug.o
LD [M] /usr/src/rt2x00/source/rt2570/Module/rt2570.o
Building modules, stage 2.
MODPOST
CC /usr/src/rt2x00/source/rt2570/Module/rt2570.mod.o
LD [M] /usr/src/rt2x00/source/rt2570/Module/rt2570.ko
make[1] Leaving directory `/usr/src/linux-headers-2.6.18-5-powerpc'
asjo@gnalle/usr/src/rt2x00/source/rt2570/Module$ sudo modinfo rt2570.ko
filename rt2570.ko
description Ralink RT2570 usb 802.11g WLAN driver 1.0.0 - CVS CVS Release
author http//rt2x00.serialmonkey.com
license GPL
vermagic 2.6.18-5-powerpc mod_unload gcc-4.1
depends usbcore
alias usbv0B05p1706d*dc*dsc*dp*ic*isc*ip*
alias usbv0B05p1707d*dc*dsc*dp*ic*isc*ip*
alias usbv050Dp7050d*dc*dsc*dp*ic*isc*ip*
alias usbv050Dp7051d*dc*dsc*dp*ic*isc*ip*
alias usbv050Dp705Ad*dc*dsc*dp*ic*isc*ip*
alias usbv13B1p000Dd*dc*dsc*dp*ic*isc*ip*
alias usbv13B1p0011d*dc*dsc*dp*ic*isc*ip*
alias usbv13B1p001Ad*dc*dsc*dp*ic*isc*ip*
alias usbv14B2p3C02d*dc*dsc*dp*ic*isc*ip*
alias usbv2001p3C00d*dc*dsc*dp*ic*isc*ip*
alias usbv1044p8001d*dc*dsc*dp*ic*isc*ip*
alias usbv1044p8007d*dc*dsc*dp*ic*isc*ip*
alias usbv06F8pE000d*dc*dsc*dp*ic*isc*ip*
alias usbv0411p0066d*dc*dsc*dp*ic*isc*ip*
alias usbv0411p0067d*dc*dsc*dp*ic*isc*ip*
alias usbv0411p008Bd*dc*dsc*dp*ic*isc*ip*
alias usbv0411p0097d*dc*dsc*dp*ic*isc*ip*
alias usbv0DB0p6861d*dc*dsc*dp*ic*isc*ip*
alias usbv0DB0p6865d*dc*dsc*dp*ic*isc*ip*
alias usbv0DB0p6869d*dc*dsc*dp*ic*isc*ip*
alias usbv148Fp1706d*dc*dsc*dp*ic*isc*ip*
alias usbv148Fp2570d*dc*dsc*dp*ic*isc*ip*
alias usbv148Fp2573d*dc*dsc*dp*ic*isc*ip*
alias usbv148Fp9020d*dc*dsc*dp*ic*isc*ip*
alias usbv0681p3C06d*dc*dsc*dp*ic*isc*ip*
alias usbv0707pEE13d*dc*dsc*dp*ic*isc*ip*
alias usbv114Bp0110d*dc*dsc*dp*ic*isc*ip*
alias usbv0EB0p9020d*dc*dsc*dp*ic*isc*ip*
alias usbv5A57p0260d*dc*dsc*dp*ic*isc*ip*
parm ifnameNetwork device name (default rausb%d) (charp)
parm debugDebug mask n selects filter, 0 for none (int)
asjo@gnalle/usr/src/rt2x00/source/rt2570/Module$ uname -a
Linux gnalle 2.6.18-5-powerpc #1 Wed Oct 3 045619 UTC 2007 ppc GNU/Linux
asjo@gnalle/usr/src/rt2x00/source/rt2570/Module$ sudo ifconfig rausb0 down
rausb0 ERROR while getting interface flags No such device
asjo@gnalle/usr/src/rt2x00/source/rt2570/Module$ sudo rmmod rt2570
ERROR Module rt2570 does not exist in /proc/modules
asjo@gnalle/usr/src/rt2x00/source/rt2570/Module$ sudo insmod rt2570.ko debug=31

In the log I then get

Nov 11 221750 gnalle kernel rt2570 enter rtusb init( )
Nov 11 221750 gnalle kernel idVendor = 0xb05, idProduct = 0x1706
Nov 11 221750 gnalle kernel rt2570 usbdevice->name rausb0
Nov 11 221750 gnalle kernel rt2570 BulkOutMaxPacketSize 16384
Nov 11 221750 gnalle kernel rt2570 INIT bRadio=1
Nov 11 221750 gnalle kernel usbcore registered new driver rt2570

asjo@gnalle/usr/src/rt2x00/source/rt2570/Module$ sudo ifup rausb0
Error for wireless request "Set ESSID" (8B1A)
SET failed on device rausb0 ; Network is down.

In the log

Nov 11 221829 gnalle kernel rt2570 --->RTUSB_get_wireless_stats
Nov 11 221829 gnalle kernel RT25usb Driver version 1.0.0
Nov 11 221829 gnalle kernel rt2570 --> NICInitTransmit
Nov 11 221829 gnalle kernel rt2570 --> NICInitRecv
Nov 11 221829 gnalle kernel rt2570 <-- NICInitRecv
Nov 11 221829 gnalle kernel rt2570 --> NICInitializeAsic
Nov 11 221829 gnalle kernel rt2570 !!!!!set Rx control = 1
Nov 11 221830 gnalle kernel rt2570 Read BBP_Version Value = 0
Nov 11 221830 gnalle last message repeated 49 times
Nov 11 221830 gnalle kernel --->USB_ResetDevice
Nov 11 221830 gnalle kernel rt2570 !!!!!set Rx control = 1
Nov 11 221831 gnalle kernel rt2570 Read BBP_Version Value = 0
Nov 11 221832 gnalle last message repeated 49 times
Nov 11 221832 gnalle kernel --->USB_ResetDevice
Nov 11 221832 gnalle kernel rt2570 !!!!!set Rx control = 1
Nov 11 221833 gnalle kernel rt2570 Read BBP_Version Value = 0
Nov 11 221833 gnalle last message repeated 49 times

etc. etc.

ifconfig uses a lot of cpu and the machine starts to crawl

asjo@gnalle~$ top -n 1 | head -14
top - 221959 up 15 min, 3 users, load average 1.94, 0.67, 0.27
Tasks 49 total, 4 running, 45 sleeping, 0 stopped, 0 zombie
Cpu(s) 8.0%us, 8.9%sy, 0.0%ni, 82.0%id, 1.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem 578908k total, 65696k used, 513212k free, 284k buffers
Swap 1693672k total, 0k used, 1693672k free, 39496k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2588 root 19 0 1840 528 464 R 72.1 0.1 105.45 ifconfig
2593 asjo 15 0 2976 1164 920 R 0.8 0.2 000.02 top
1 root 15 0 2440 772 672 R 0.0 0.1 001.76 init
2 root 34 19 0 0 0 S 0.0 0.0 000.00 ksoftirqd/0
3 root 10 -5 0 0 0 S 0.0 0.0 000.56 events/0
4 root 10 -5 0 0 0 S 0.0 0.0 000.00 khelper
5 root 10 -5 0 0 0 S 0.0 0.0 000.00 kthread

Pulled out the usb card - machine froze.

The /etc/network/interfaces, this is the entry for rausb0

iface rausb0 inet static
address 192.168.1.193
netmask 255.255.255.0
gateway 192.168.1.1
wireless-essid koldfrontairportnet

Information on the adapter

asjo@gnalle/usr/src/rt2x00/source/rt2570/Module$ lsusb
Bus 001 Device 002 ID 0b051706 ASUSTek Computer, Inc.
Bus 001 Device 001 ID 00000000
Bus 002 Device 001 ID 00000000
asjo@gnalle/usr/src/rt2x00/source/rt2570/Module$ sudo lsusb -v

Bus 001 Device 002 ID 0b051706 ASUSTek Computer, Inc.
Device Descriptor
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0b05 ASUSTek Computer, Inc.
idProduct 0x1706
bcdDevice 0.01
iManufacturer 1 ASUS
iProduct 2 802.11g WLAN Drive
iSerial 0
bNumConfigurations 1
Configuration Descriptor
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 300mA
Interface Descriptor
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Qualifier (for other device speed)
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status 0x0000
(Bus Powered)

Best regards,
Adam

Vern

11-11-2007 22:45:11

Hi asjo,

Thanks for the quick response. Your log shows that we may need to lay out bit fields differently.

The attached modified version of the patch does that. It won't solve all the endian problems, but, if it proves out the hypothesis, the log will show us getting along a little further.

Please try it and post a gzipped copy of /var/log/debug here.

Thanks again,

asjo

11-11-2007 23:11:35

The attached modified version of the patch does that. It won't solve all the endian problems, but, if it proves out the hypothesis, the log will show us getting along a little further.

Please try it and post a gzipped copy of /var/log/debug here.[/quote31ecoio3]

Here you go.

Best regards,
Adam

Vern

13-11-2007 02:15:36

Hi asjo,

Well, that didn't seem to help us at all.

I've produced an update to the patch - attached as endian2.patch.gz - that packs some structure definitions based on the chance that your target may have alignment requirements that the x86 platform doesn't. It also has more debug info, and should also messages about compiling for a big- endian target - just to verify that that's really the case. Could you try it and attach a copy of your log here?

Are you set up to route debug messages to /var/log/debug? Using that will prune the amount of log data uploaded to the servers.

BTW, feel free to jump in and look for endian or alignment problems. The function I'm trundling along in is usb_rtusb_open() in rtusb_main.c, and I'm looking at what goes on inside RT2570InitializeAsic() when its called. If you come up with anything, do a patch and attach that to a posting here, too.

Thanks a lot for your work on this problem,

asjo

14-11-2007 14:17:04

Well, that didn't seem to help us at all.[/quotewrgydaas]

Well, that sucks -)

I've produced an update to the patch - attached as
endian2.patch.gz - that packs some structure definitions based on the
chance that your target may have alignment requirements that the x86
platform doesn't. It also has more debug info, and should also
messages about compiling for a big- endian target - just to verify
that that's really the case. Could you try it and attach a copy of
your log here?[/quotewrgydaas]

Sure, should be attached here.

I didn't get any output about compiling for a big endian target when running make debug. Was I supposed to?

file says
rt2570.ko ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (SYSV), not stripped

Are you set up to route debug messages to
/var/log/debug? Using that will prune the amount of log data uploaded
to the servers.[/quotewrgydaas]

I've set it up to log kern.=debug to /var/log/rt2570debug which I will
gzip and attach.

BTW, feel free to jump in and look for endian or
alignment problems. The function I'm trundling along in is
usb_rtusb_open() in rtusb_main.c, and I'm looking at what goes on
inside RT2570InitializeAsic() when its called. If you come up with
anything, do a patch and attach that to a posting here, too.[/quotewrgydaas]

I will see if I can get some time. I am not used to deal with these
kind of issues though.

Would it be of any help to you to get direct access to the machine in
question? (I am thinking ssh to a shared screen-session).

Thanks a lot for your work on this problem,[/quotewrgydaas]

Thank you for your work!

Best regards,
Adam

asjo

14-11-2007 14:45:47

I didn't get any output about compiling for a big endian target when running make debug. Was I supposed to?[/quote3n35j0xc]

I just added this to rtusb_init.c

@@ -1940,6 +1944,11 @@
pAdapter->PortCfg.bSwRadio = TRUE;
pAdapter->PortCfg.bRadio = TRUE;
DBGPRINT(RT_DEBUG_TRACE, "INIT bRadio=%d\n", pAdapter->PortCfg.bRadio);
+#ifdef BIG_ENDIAN
+ DBGPRINT(RT_DEBUG_TRACE, "INIT BIG_ENDIAN defined\n");
+#else
+ DBGPRINT(RT_DEBUG_TRACE, "INIT BIG_ENDIAN not defined\n");
+#endif
pAdapter->PortCfg.bHardwareRadio = FALSE; // Default is OFF
pAdapter->PortCfg.bAutoTxAgc = FALSE; // Default is OFF
pAdapter->PortCfg.bShowHiddenSSID = FALSE; // Default no show

and got

Nov 14 152304 gnalle kernel rt2570 INIT BIG_ENDIAN not defined

Which sounds wrong to me.

I guess the problem is in rt_config.h

#ifdef __BIG_ENDIAN // Propagate compiler environment asap - bb
#define BIG_ENDIAN
#warning "Compiling for big endian machine."
#endif /* __BIG_ENDIAN */

because the symbols defined by gcc are __BIG_ENDIAN__ and _BIG_ENDIAN

$ touch dummy_file.c; gcc -E -dM dummy_file.c | grep ENDIAN
#define __BIG_ENDIAN__ 1
#define _BIG_ENDIAN 1

This is with

$ gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

Attached is a new debug log with this applied

--- rt_config.h.orig 2007-11-14 153920.048992940 +0100
+++ rt_config.h 2007-11-14 153930.944989122 +0100
@@ -37,10 +37,10 @@
#ifndef __RT_CONFIG_H__
#define __RT_CONFIG_H__

-#ifdef __BIG_ENDIAN // Propagate compiler environment asap - bb
+#ifdef __BIG_ENDIAN__ // Propagate compiler environment asap - bb
#define BIG_ENDIAN
#warning "Compiling for big endian machine."
-#endif /* __BIG_ENDIAN */
+#endif /* __BIG_ENDIAN__ */

#define PROFILE_PATH "/etc/Wireless/RT2570STA/RT2570STA.dat"
#define NIC_DEVICE_NAME "RT2500USBSTA"

(compiling now gives a warning per file about compiling for big endian).

asjo

14-11-2007 15:01:26

With the change described above, ifconfig does not eat all the CPU any
more.

ifconfig shows

rausb0 Link encapEthernet HWaddr 0013D4F4C31B
inet addr192.168.1.193 Bcast192.168.1.255 Mask255.255.255.0
inet6 addr fe80213d4fffef4c31b/64 ScopeLink
UP BROADCAST RUNNING 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)

which is encouraging.

The card does not associate with the accesspoint, though - iwconfig
says

rausb0 RT2500USB WLAN ESSID""
ModeManaged Frequency=2.412 GHz Bit Rate11 Mb/s
RTS throff Fragment throff
Link Quality=0/100 Signal level-120 dBm Noise level-79 dBm
Rx invalid nwid0 Rx invalid crypt0 Rx invalid frag0
Tx excessive retries0 Invalid misc0 Missed beacon0

(I do not use encryption on my WLAN, only MAC-address filtering, and
the cards MAC is allowed).

In dmesg I get a lot of

<---RADIO OFF
<---RADIO OFF
<---RADIO OFF

lines.

If I do 'sudo ifdown rausb0' the command hangs.

Any ideas on where to from here?

Vern

14-11-2007 17:21:01

!!! ALL RIGHT, MY MAN !!!

Here's what the goal was
[codejmvkadqk]Read BBP_Version Value = 19[/codejmvkadqk]
and we got it. No cigar, but this is real progress.

I've downloaded your latest log, and need to look into it a little more.

Where did you go to get the info on what the compiler defines as BIG_ENDIAN?

Way to go, ah'll be bahk.

asjo

14-11-2007 17:38:40

Where did you go to get the info on what the compiler defines as BIG_ENDIAN?[/quotezgns90ee]

Google dug up this one liner for me

$ touch dummy_file.c; gcc -E -dM dummy_file.c

Looking forward to hearing what you find out from the logfile!

Vern

14-11-2007 19:50:56

Hi asjo,

Could you attach a copy of the results of
[coded2110wby]touch dummy_file.c; gcc -E -dM dummy_file.c[/coded2110wby]
to a posting here?

Unfortunately, doing it on my machine doesn't yield anything about endianess; so your results may be very informative and helpful.

Thanks,

asjo

14-11-2007 20:11:23

Could you attach a copy of the results of
[coderpnry6el]touch dummy_file.c; gcc -E -dM dummy_file.c[/coderpnry6el]
to a posting here?[/quoterpnry6el]

Sure. Attached is defines.txt with output from the different kinds of machines I had immediate access to.

I would imagine that it is documented somewhere, I just needed a quick result, so I turned to searching.

Unfortunately, doing it on my machine doesn't yield anything about endianess; so your results may be very informative and helpful.[/quoterpnry6el]

I guess your machine is little endian, then.

Vern

15-11-2007 18:26:26

Hi asjo,

The content of the compiler defines you posted shows that we've been incorrectly testing for the big endian machines. The fix has been commited to CVS for all the legacy drivers. Thanks.

Looking a little more at your last log give a little more info on the scope of what remains to be done.

The file rt2570.h has a bunch of structures that define CSRs in terms of bit fields every one of them has to be bit-flipped for big endian machines.

In the same file, the tx descriptor data structure fields have to be bit flipped. Also, since there are multi- byte numeric fields in that structure, they need to be byte flipped at run time for big endian machines.

This will take me a while to do - probably not before next week.

I've attached a slightly updated version of the driver patch if you're interested in looking into this some more in the meantime. It no longer issues big endian messages since the content of the log indicates whether it's correctly handled.

The upside is that we have a defined work scope, and taking care of these items may give us a driver that works in big endian mode.

Thanks,

asjo

15-11-2007 20:35:17

This will take me a while to do - probably not before next week.[/quote38d9pvok]

No worries. Meanwhile, attached is a log with the endian3 patch applied.

Vern

19-11-2007 01:00:04

Hi asjo,

Well, if we're really lucky, this thing might work. I'm not too sure I'm handling the initialization vectors of the tx descriptor properly (namely leaving them alone), but ...

At any rate, could you apply the attached patch to the very latest CVS and see what happens?

At the very least, we should get past the "radio off" stuff.

Thanks,

asjo

19-11-2007 18:40:53

Well, if we're really lucky, this thing might work. I'm not too sure I'm handling the initialization vectors of the tx descriptor properly (namely leaving them alone), but ...[/quoteje8tjq58]

Sounds great. In the meantime the harddisk in my Cube has died, so I need to replace it before I can test more. Will return when I get the right type of screwdriver (damn Apple, using torx).

Best regards,
Adam

asjo

03-12-2007 22:11:09

Sounds great. In the meantime the harddisk in my Cube has died, so I need to replace it before I can test more. Will return when I get the right type of screwdriver (damn Apple, using torx).[/quote13jm76bm]

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

asjo

04-12-2007 17:55:50

Well, if we're really lucky, this thing might work. I'm not too sure I'm handling the initialization vectors of the tx descriptor properly (namely leaving them alone), but ...

At any rate, could you apply the attached patch to the very latest CVS and see what happens?

At the very least, we should get past the "radio off" stuff.[/quote22vuxdy8]

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.

Vern

05-12-2007 01:47:35

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,

asjo

05-12-2007 19:04:04

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.[/quote333l1vve]

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.

Vern

07-12-2007 04:26:57

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,

asjo

08-12-2007 11:48:40

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.[/quote37by1g5z]

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

Vern

10-12-2007 01:30:31

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,

asjo

10-12-2007 17:47:09

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.[/quote1kavlkhb]

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 000F6651C715
ModeManaged
ESSID"koldfrontairportnet"
Encryption keyoff
Channel9
Cell 02 - Address 00173FB7C9D0
ModeManaged
ESSID"belkin54g"
Encryption keyon
Channel11

And the netcard associated to my accesspoint; ifwconfig said

rausb0 RT2500USB WLAN ESSID"koldfrontairportnet"
ModeManaged Frequency=2.412 GHz Bit Rate11 Mb/s
RTS throff Fragment throff
Encryption keyoff
Link Quality=0/100 Signal level-73 dBm Noise level-86 dBm
Rx invalid nwid0 Rx invalid crypt0 Rx invalid frag0
Tx excessive retries0 Invalid misc0 Missed beacon0

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

Vern

10-12-2007 21:36:17

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,

asjo

11-12-2007 18:37:58

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

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.c315 error ‚ undeclared (first use in this function)
/usr/src/source/rt2570/Module/assoc.c315 error (Each undeclared identifier is reported only once
/usr/src/source/rt2570/Module/assoc.c315 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 194042.589014026 +0100
+++ assoc.c 2007-12-11 193857.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.

Vern

13-12-2007 02:26:54

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,

asjo

13-12-2007 16:24:58

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[/quote10ylnts8]

Here is the log, hope it helps.

Best regards, Adam.

Vern

13-12-2007 18:24:37

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,

asjo

13-12-2007 19:12:14

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?[/quote3oojh2wc]

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.

Vern

15-12-2007 18:59:14

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,

asjo

16-12-2007 13:59:08

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.[/quote2lpd4xgv]

Your patch resulted in some warnings

CC [M] /usr/src/source/rt2570/Module/sanity.o
/usr/src/source/rt2570/Module/sanity.c In function ‚onAndProbeRspSanity‚
/usr/src/source/rt2570/Module/sanity.c607 warning passing argument 1 of ‚ from incompatible pointer type
/usr/src/source/rt2570/Module/sanity.c608 warning passing argument 1 of ‚ from incompatible pointer type
CC [M] /usr/src/source/rt2570/Module/rtusb_data.o

Attached is the log.

Best regards, Adam.

Vern

16-12-2007 21:50:40

Hi asjo,

Wrt. the warnings if you change lines 607, 608 of sanity.c to read [codelcbs73en]CfParm->CfpMaxDuration = le16_to_cpup((PUSHORT)&eid_ptr->Octet[2]);
CfParm->CfpDurRemaining = le16_to_cpup((PUSHORT)&eid_ptr->Octet[4]);[/codelcbs73en]do they go away? (I can't seem to get le16... etc. to actually compile on my machine. At any rate, I don't get any warning messages.)

This thing looks for all the world like it should work. Is your AP really set up to accept open authentication and no encryption? Does your Airport currently connect successfully to this AP (000f6651c715)? If so, is it configured the same as your Asus WL-167g?

I overlooked this on your Dec 10 post
[quotelcbs73en]I tried pinging the ip-address, and got answers. So I ssh'ed to it, ...[/quotelcbs73en]
That shouldn't have worked. Now I'm really confused. What did ping say?

This is turning into quite a siege, I know, but thanks,

asjo

16-12-2007 22:23:18


Wrt. the warnings if you change lines 607, 608 of sanity.c to read [code1zeq8j5k]CfParm->CfpMaxDuration = le16_to_cpup((PUSHORT)&eid_ptr->Octet[2]);
CfParm->CfpDurRemaining = le16_to_cpup((PUSHORT)&eid_ptr->Octet[4]);[/code1zeq8j5k]do they go away? (I can't seem to get le16... etc. to actually compile on my machine. At any rate, I don't get any warning messages.)
[/quote1zeq8j5k]

Yes, that removed the warning messages.


This thing looks for all the world like it should work. Is your AP really set up to accept open authentication and no encryption? Does your Airport currently connect successfully to this AP (000f6651c715)? If so, is it configured the same as your Asus WL-167g?
[/quote1zeq8j5k]

My accesspoint is set up to no encryption and mac-address filtering.

I used the Asus-card with an i386-machine previously against the same accesspoint - no change in its configuration.

The Airport card works against the access point with no encryption (I use that to access the machine).

The configurations are identical except for the IP-addresses.


I overlooked this on your Dec 10 post
[quote1zeq8j5k]I tried pinging the ip-address, and got answers. So I ssh'ed to it, ...[/quote1zeq8j5k]
That shouldn't have worked. Now I'm really confused. What did ping say?[/quote1zeq8j5k]

I think I was a little too quick there, sorry. I think the replies I got was probably through/due to the other interface - after your next patch I tried closing down the Airport-card and ping to the rt2570-card stopped getting replies.

(The Cube is headless, so I haven't tried closing networking completely off and then turning on the rt2570).

Let me know what you think I should try.

Best regards, Adam.

Vern

17-12-2007 21:32:00

Hi asjo,

It looks like I may have endianized a bridge too far (cleverly, so as not to be detected.)

I started to wonder why there were all these "flase alarm" messages in the log. Also I noticed that not only was there no response to authentication request frames, there was no response to probe requests, either.

It looks like what was happening was that the BBP tuning parameters read from EEPROM were screwed up enough (because of conflicting byte flipping logic) that we weren't transmitting with enough power to be detected.

The latest version of the patch now treats BBP tuning parameters as a byte array (which is what it is) instead of an array of shorts - thereby sidestepping the need for byte flipping. The driver still seems to work OK on my little endian machine. Could you try it on your Cube and see what happens?

The latest version of the patch is attached as "endian11.patch.gz" and should be applied to a vanilla version of the latest CVS.

Thanks,

asjo

18-12-2007 17:04:53

The latest version of the patch now treats BBP tuning parameters as a byte array (which is what it is) instead of an array of shorts - thereby sidestepping the need for byte flipping. The driver still seems to work OK on my little endian machine. Could you try it on your Cube and see what happens?[/quote2ckd6yq3]

Here is the log, hope it helps.

Best regards, Adam.

Vern

18-12-2007 19:10:08

asjo

Could you go to line #800 of the patched version of rtusb_init.c[code3bfu68gj]le16_to_cpus(&Power.word);[/code3bfu68gj]comment it out, then see what happens?

Thanks,

asjo

18-12-2007 21:44:31

Could you go to line #800 of the patched version of rtusb_init.c[codexejvjkga]le16_to_cpus(&Power.word);[/codexejvjkga]comment it out, then see what happens?[/quotexejvjkga]

Sure; log attached. Didn't seem to do the trick - I can't ping the IP of the rausb0 if I ifdown the eth2 (Airport).

Best regards, Adam.

Vern

22-12-2007 01:00:41

Hi asjo,

Two questions

1. Do other adapters see your RT2570 when they scan?
2. When you used it on your Pentium, was that USB 1.1 or 2.0? If the latter, is there any way you could try it on your Cube using USB 2.0?

Thanks, and Merry Christmas!

asjo

26-01-2008 16:39:32

1. Do other adapters see your RT2570 when they scan?[/quote21rr8ana]
How can I test this?

I think I usually only see accesspoints when I do an "iwlist [iface] scan", not other adapters?

2. When you used it on your Pentium, was that USB 1.1 or 2.0? If the latter, is there any way you could try it on your Cube using USB 2.0?[/quote21rr8ana]
I guess the old Compaq PII has USB 1.1 - it is quite old - but I don't know.

The Cube has two identical USB-ports, I don't think I can choose between 1.1 and 2.0 on the Cube?

Apple lists the two USB ports as being "12 Mbps each" http//support.apple.com/specs/powermac ... _Cube.html - I guess that means 1.1 at the most.

Best regards, Adam

Vern

26-01-2008 18:58:05

Hi asjo,

Nice to see you're back on the air. Hope you enjoyed your holidays.

Doesn't look like USB revision is a factor, so I think we can forget about that.

To see if this adapter is detectable, bring it up, then go to another PC in the area with a wireless adapter and do a scan. Doing this from an AP is something you need to consult the documentation for that specific AP on.

It turns out there's yet more endianization needed, which is included in the attached patch - endian12.patch.gz. Could you give that a try first and post the results here?

Thanks,

beren

26-02-2008 15:46:39

Has anyone tested this recently? I grabbed it but need to install the tools to build it still. All I need this driver for is injecting.

Vern

28-02-2008 17:16:05

Hi beren,

I'd been working with asjo on this, but he appears to have clapped out on me (after only three months! go figure).

Anyway, if you're interested in taking up the cudgel on this, I've regenerated the previous version of the patch against the latest CVS and attached it as "endian13.patch.gz".

Please apply, build and run with debug enabled, then post your results here.

Thanks,

asjo

28-02-2008 17:38:03

I'd been working with asjo on this, but he appears to have clapped out on me (after only three months! go figure).[/quote1if9jmba]

I am not totally AWAL, I have just been very busy. I tried the 12-patch, but got no debug messages in the logs, and had not the time to investigate and report.

I will try to make some time to try this latest patch.

Best regards,

Adam

asjo

09-03-2008 14:18:41

Anyway, if you're interested in taking up the cudgel on this, I've regenerated the previous version of the patch against the latest CVS and attached it as "endian13.patch.gz".

Please apply, build and run with debug enabled, then post your results here.[/quote2sfowk9r]

I've just done a test with this patch. Attached is the logfile. Here is some output from the xterm

gnalle/usr/src/source/rt2570/Module# ifup rausb0
Error for wireless request "Set ESSID" (8B1A)
SET failed on device rausb0 ; Network is down.
gnalle/usr/src/source/rt2570/Module# iwconfig
lo no wireless extensions.

eth1 no wireless extensions.

eth0 no wireless extensions.

eth2 IEEE 802.11b ESSID"koldfrontairportnet" Nickname"HERMES I"
ModeManaged Frequency2.452 GHz Access Point 000F6651C715
Bit Rate11 Mb/s Sensitivity1/3
Retry limit4 RTS throff Fragment throff
Encryption keyoff
Power Managementoff
Link Quality=14/92 Signal level=-80 dBm Noise level=-94 dBm
Rx invalid nwid0 Rx invalid crypt0 Rx invalid frag1
Tx excessive retries0 Invalid misc0 Missed beacon0

sit0 no wireless extensions.

rausb0 RT2500USB WLAN ESSID"koldfrontairportnet"
ModeManaged Frequency=2.412 GHz Bit Rate11 Mb/s
RTS throff Fragment throff
Encryption keyoff
Link Quality=0/100 Signal level-72 dBm Noise level-88 dBm
Rx invalid nwid0 Rx invalid crypt0 Rx invalid frag0
Tx excessive retries0 Invalid misc0 Missed beacon0

gnalle/usr/src/source/rt2570/Module# gnalle/usr/src/source/rt2570/Module# ifconfig
eth2 Link encapEthernet HWaddr 003065137614
inet addr192.168.1.193 Bcast192.168.1.255 Mask255.255.255.0
inet6 addr fe8023065fffe137614/64 ScopeLink
UP BROADCAST RUNNING MULTICAST MTU1500 Metric1
RX packets6200 errors0 dropped0 overruns0 frame0
TX packets4287 errors0 dropped0 overruns0 carrier0
collisions0 txqueuelen1000
RX bytes2137805 (2.0 MiB) TX bytes1427893 (1.3 MiB)
Interrupt57

lo Link encapLocal Loopback
inet addr127.0.0.1 Mask255.0.0.0
inet6 addr 1/128 ScopeHost
UP LOOPBACK RUNNING MTU16436 Metric1
RX packets0 errors0 dropped0 overruns0 frame0
TX packets0 errors0 dropped0 overruns0 carrier0
collisions0 txqueuelen0
RX bytes0 (0.0 b) TX bytes0 (0.0 b)

rausb0 Link encapEthernet HWaddr 0013D4F4C31B
inet addr192.168.1.194 Bcast192.168.1.255 Mask255.255.255.0
inet6 addr fe80213d4fffef4c31b/64 ScopeLink
UP BROADCAST RUNNING MULTICAST MTU1500 Metric1
RX packets0 errors0 dropped0 overruns0 frame0
TX packets0 errors0 dropped0 overruns0 carrier0
collisions0 txqueuelen1000
RX bytes39401 (38.4 KiB) TX bytes2740 (2.6 KiB)

I notice that Link Quality is reported as 0/100 for rausb0, while it is 14/92 for eth2 (the Apple Airport card).

Also, rausb0 does not report an Access Point, while eth2 does.

Let me know if there is something I should try / something I should check in the configuration, or otherwise.

Sorry for the very long turn-around time, this time.

Best regards, Adam.

asjo

09-03-2008 14:27:48

I forgot to mention The machine I am testing on runs mpd to play music through a USB soundcard. A while after doing the ifup rausb0 the sound dies.

I don't know if it is of significance, but now I've mentioned it.

Best regards, Adam

Vern

09-03-2008 23:34:15

Hi asjo,

Thanks for hanging in there.

Your observation about link quality may be on to something I see from your log that we're getting beacons, but no probe responses - implying probe requests may not be detected by the peer. We're getting authentication timeouts - implying that our authentication request frames may not be detected by the peer. The upshot of that is we may be transmitting with too low a power.

The current suspect is a guy called NICReadEEPROMParameters() in rtusb_init.c. The log output shows power setting values (e.g. BBPTuningThreshold & ff.) that do not correspond to what is displayed by my little endian machine. I suspect my change from an array of ushorts to uchars for the EEPROMBBPTuningParameters array may have introduced some alignment issues for PPC based big endian machines.

endian14.patch.gz (attached) adds a small change in the routine designed to show *exactly* what is being read into the array. That may provide some clues as to where things are going wrong. Please apply it to the latest CVS and feel free to plunge in.

A while after doing the ifup rausb0 the sound dies.[/quote3rclxt9s]Noted. There is at least one known problem with sharing devices downstream of the same (root) hub. Let's leave that for later.

Thanks again,

asjo

16-03-2008 18:06:05

endian14.patch.gz (attached) adds a small change in the routine designed to show *exactly* what is being read into the array. That may provide some clues as to where things are going wrong. Please apply it to the latest CVS and feel free to plunge in.[/quoteasvdn4po]

Attached is the log-output from endian14. Hope it helps.

Best regards, Adam.

Vern

16-03-2008 22:10:29

Hi asjo,

As it turns out, your log shows that the change designed to see what's coming in apparently has the side effect of making the data believable - I may also have inadvertently changed something else, but I can't find it.

Anyway, its beginning to seem that there are alignment requirements for USB input on the PPC that need to be addressed. So this latest version forces even alignment of all data structures read from EEPROM when running on a PPC machine.

Its attached as endian15.patch.gz. Could you give it at try and post your log here?

Thanks,

asjo

17-03-2008 12:47:39

Its attached as endian15.patch.gz. Could you give it at try and post your log here?[/quote2bsw2w08]

I still get the Link Quality=0/100

gnalle/usr/src/source/rt2570/Module# iwconfig rausb0
rausb0 RT2500USB WLAN ESSID"koldfrontairportnet"
ModeManaged Frequency=2.412 GHz Bit Rate11 Mb/s
RTS throff Fragment throff
Encryption keyoff
Link Quality=0/100 Signal level-71 dBm Noise level-89 dBm
Rx invalid nwid0 Rx invalid crypt0 Rx invalid frag0
Tx excessive retries0 Invalid misc0 Missed beacon0

gnalle/usr/src/source/rt2570/Module#

The log is attached.

Best regards, Adam.

Vern

22-03-2008 01:35:26

Hi asjo,

Well, this is turning into a real siege.

The basic problem continues to look like it's due to not getting any response to authentication request frames. The "link quality 0/100" may be consistent with that because because we have no partner to get a link quality from.

This latest version adds debug statements to try to see[list3lrcx9we]1. what's being reported up as link quality.
2. exactly what's sent via RTUSBWriteRFRegister() to set tx power and check my understanding of the four byte quantity that's being used.
3. the auth req frame exactly as seen by RTUSBBulkOutMLMEPacket() - again.[/listu3lrcx9we]The attached patch - endian16.patch.gz(!) - should be applied to the very latest version of the CVS. BTW, you can now do pre-up configuration under 2.6.24 with this version of the patch.

One more "Hail Mary!" question what happens if you're two feet away from the AP?

Thanks much again for hanging in there,

asjo

22-03-2008 20:10:19

The attached patch - endian16.patch.gz(!) - should be applied to the very latest version of the CVS. BTW, you can now do pre-up configuration under 2.6.24 with this version of the patch.[/quotepisl01tp]

Ok, the Cube is on 2.6.18 (Debian/stable; etch). Attached is the log with this patch.

One more "Hail Mary!" question what happens if you're two feet away from the AP?[/quotepisl01tp]

Currently it is less than 10m away from the access point. I will try to move it closer and send you another log of that later.

Best regards, Adam.

asjo

02-05-2008 21:30:32

One more "Hail Mary!" question what happens if you're two feet away from the AP?[/quote2foz7ufp]

Currently it is less than 10m away from the access point. I will try to move it closer and send you another log of that later.[/quote2foz7ufp]
Ok, so I have moved the Cube so it is less than 2 feet from the access point. From what I could see, it did not make any difference.

Attached is the log. Hope it helps.

Best regards, Adam

Vern

16-05-2008 18:58:24

Hi asjo,

Sorry to keep you swinging in the breeze so long, here.

Looking over your latest log, you're right. Its pretty much the same. What I do notice is that, after issuing the authentication request frame, a frame is received that I can't identify from the info available in the log, and which seems to be silently dropped. Maybe the AP is trying to tell us something?

I've modified the patch to show debug info on what all the received frame types are. Its attached as endian17.patch.gz. If you get a chance, could you apply it to the latest CVS and post the log here? It may provide some more info on what is going awry.

Thanks,

asjo

01-06-2008 17:39:45

Sorry to keep you swinging in the breeze so long, here.[/quote29j6x4dh]
No worries. It seems quite complicated?

I've modified the patch to show debug info on what all the received frame types are. Its attached as endian17.patch.gz. If you get a chance, could you apply it to the latest CVS and post the log here? It may provide some more info on what is going awry.[/quote29j6x4dh]
Sure, log-file attached.

Best regards, Adam

P.S. Here is the output of iwconfig after running ifup rausb0

[code29j6x4dh]lo no wireless extensions.

eth1 no wireless extensions.

eth0 no wireless extensions.

eth2 IEEE 802.11b ESSID:"koldfrontairportnet" Nickname:"HERMES I"
Mode:Managed Frequency:2.452 GHz Access Point: 00:0F:66:51:C7:15
Bit Rate:11 Mb/s Sensitivity:1/3
Retry limit:4 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=19/92 Signal level=-78 dBm Noise level=-97 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

sit0 no wireless extensions.

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:-79 dBm Noise level:-91 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0[/code29j6x4dh]

Vern

05-06-2008 00:59:37

Hi asjo,

Thanks for the log info. I've looked thru it and it turns out the mystery frames are data frames and probe requests, both of which could be broadcast - probably not of much interest after all.

I don't know if this is complicated I have a hunch that when this thing is finally resolved, it'll turn out to be something really obvious - and really stupid (I hope).

There're a couple of posts here[/url1s89kuzj] that indicate USB cable length may be a problem. What cable length are you using on your Apple Cube? On my system, I'm using about a four foot cable (@1.3m, I think). If your's is much over that, could you see if using a shorter cable helps? (Yet another Hail Mary question.)

Thanks,

asjo

05-06-2008 10:02:49

There're a couple of posts here[/url3bg80nr9] that indicate USB cable length may be a problem. What cable length are you using on your Apple Cube? On my system, I'm using about a four foot cable (@1.3m, I think). If your's is much over that, could you see if using a shorter cable helps? (Yet another Hail Mary question.)[/quote3bg80nr9]

I was actually using a long cable (3m) - I've changed it to a short one (~30cm) and created a new log.

I still got the same output from iwconfig, so I'm not sure it made any difference.

Best regards, Adam.

asjo

05-06-2008 10:23:14

There're a couple of posts here[/url30k9wyp0] that indicate USB cable length may be a problem.[/quote30k9wyp0]
I just read them and tried with no cable - the card inserted directly into the computer.

The log is attached, I could see no difference.

iwconfig still says

[code30k9wyp0]
eth2 IEEE 802.11b ESSID:"koldfrontairportnet" Nickname:"HERMES I"
Mode:Managed Frequency:2.452 GHz Access Point: 00:0F:66:51:C7:15
Bit Rate:5.5 Mb/s Sensitivity:1/3
Retry limit:4 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=23/92 Signal level=-74 dBm Noise level=-97 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:1
Tx excessive retries:72 Invalid misc:0 Missed beacon:0

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:-76 dBm Noise level:-85 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
[/code30k9wyp0]

Best regards, Adam

Vern

15-06-2008 17:55:32

Hi asjo,

You're right. Cable length doesn't seem to be an issue. No progress to report; just letting you know I haven't dropped this thing.

Would it be possible for you to apply the patch, then build and run on a standard PC? This would establish whether or not the patch breaks anything when running in a little endian environment.

If it turns out to be OK, I may just try to get the thing into CVS anyway so's to get exposure in other big endian configurations which may fail in a more informative way.

Thanks,

asjo

21-06-2008 23:03:06

Would it be possible for you to apply the patch, then build and run on a standard PC? This would establish whether or not the patch breaks anything when running in a little endian environment.[/quoteufnhhznv]
It worked fine on my little endian laptop (Transmeta Efficeon TM8000). I could ping the laptop and ssh into it via the Asus usb netcard. I did not do any extensive testing beyond that.

Attached is the output in the log, in case that might help.

Best regards, Adam.

Vern

09-07-2008 21:24:49

asjo

I *think* I may have found the problem. See how the attached patch - endian18.patch.gz modifies the function RTUSBWriteHWMACAddress() for details.

Could you try it and see what happens?

Thanks,

asjo

11-07-2008 16:00:29

I *think* I may have found the problem. See how the attached patch - endian18.patch.gz modifies the function RTUSBWriteHWMACAddress() for details.[/quote2uuak2hu]
You don't give up that easily! -)

Could you try it and see what happens?[/quote2uuak2hu]
Sure, attached is the log.

iwconfig said

[code2uuak2hu]
# /sbin/iwconfig
lo no wireless extensions.

eth1 no wireless extensions.

eth0 no wireless extensions.

eth2 IEEE 802.11b ESSID:"koldfront" Nickname:"HERMES I"
Mode:Managed Frequency:2.452 GHz Access Point: 00:0F:66:51:C7:15
Bit Rate:11 Mb/s Sensitivity:1/3
Retry limit:4 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=16/92 Signal level=-78 dBm Noise level=-94 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:1
Tx excessive retries:1 Invalid misc:0 Missed beacon:0

sit0 no wireless extensions.

rausb0 RT2500USB WLAN ESSID:"koldfront"
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:-81 dBm Noise level:-90 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
[/code2uuak2hu]

Best regards, Adam

Vern

11-07-2008 18:56:38

Hi asjo,

Thanks for slogging along, here.

We've definitely made progress. We now receive directed frames - e.g. probe responses and authentication frames - so we now get responses to our authentication requests.

Unfortunately, the internal routing logic fails to endianize the Sequence field of the authentication frame before evaluating it, which causes the frame to be dropped. So we still eventually time out.

The fix (I hope) for that is in the attached patch - endian19.patch.gz. See the mods for MsgTypeSubst() for details.

Could you try it? (We'll keep our fingers crossed.)

Thanks,

asjo

14-07-2008 15:49:48

We've definitely made progress.[/quote2twfnjzl]
Cool!

The fix (I hope) for that is in the attached patch - endian19.patch.gz. See the mods for MsgTypeSubst() for details.

Could you try it? (We'll keep our fingers crossed.)[/quote2twfnjzl]
Sure - attached is the log.

Compiling yields a single warning here

[code2twfnjzl]
CC [M] /usr/src/source/rt2570/Module/mlme.o
/usr/src/source/rt2570/Module/mlme.c: In function ‚:
/usr/src/source/rt2570/Module/mlme.c:3093: warning: passing argument 1 of ‚ from incompatible pointer type
CC [M] /usr/src/source/rt2570/Module/rtusb_bulk.o
[/code2twfnjzl]
Just so you know.

Progress? Yessirree! Here is what iwconfig says now

[code2twfnjzl]
rausb0 RT2500USB WLAN ESSID:"koldfront"
Mode:Managed Frequency=2.452 GHz Access Point: 00:0F:66:51:C7:15
Bit Rate:48 Mb/s
RTS thr:off Fragment thr:off
Encryption key:off
Link Quality=60/100 Signal level:-70 dBm Noise level:-85 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
[/code2twfnjzl]
Link quality check! Access Point check!

Let me check if I can ssh to the machine with only the rt2570 there...

Yes! It works now, I can access the machine via the Asus USB card using the endian19 patch! Looks like you have succeeded; congratulations - and thanks a lot!

Best regards, Adam

Vern

14-07-2008 16:48:35

Hi asjo,

Great! Do you realize this has taken about 10 1/2 months? Your efforts have really been above and beyond the call of duty, here.

Anyway, based on your results, I've corrected the compiler warning in mlme.c (reminder *always* compile against both 2.4 and 2.6), and submitted the patch to CVS. It's pretty big, and I see that I've just gotten a bounce message; but nevertheless, if all goes well, you should see it show up in the CVS tarballs Real Soon Now.

When it does show up, could you try it with AES encryption - just to wring out some more code paths? Both CCMP and TKIP now work with the driver in little endian mode, and should work in big endian mode.

Thanks again for your persistence,

(edit) OK, eight months. I better stick to programming. Counting on more than the fingers of one hand is apparently a little too much for me.

dossy

27-10-2008 04:05:10

I hate to resurrect an old thread, but I'm trying to get the rt2570 driver working on Linux 2.4.20 on MIPS (TiVo SA2, to be exact) with a Linksys WUSB54G adapter.

Starting with the latest CVS as of yesterday, I hacked a few things in order to get the driver to compile and recognize the device. However, after the few adjustments, once I ifconfig the rausb0 interface, the TiVo starts spewing lines like this non-stop

[code2uo4wusl]Unaligned Access to 0x80d43076 in kernel mode at 0xc021cd8c
Unaligned Access to 0x802d704a in kernel mode at 0xc021b3dc
Unaligned Access to 0x802d704a in kernel mode at 0xc021b408
Unaligned Access to 0x802d704a in kernel mode at 0xc021dc2c
Unaligned Access to 0x802d704a in kernel mode at 0xc021da50
Unaligned Access to 0x802d704a in kernel mode at 0xc021cd8c
Unaligned Access to 0x802d704a in kernel mode at 0xc021b5f0
Unaligned Access to 0x802d704a in kernel mode at 0xc021b68c
Unaligned Access to 0x80232c0b in kernel mode at 0xc0217be4
Unaligned Access to 0x80232c0d in kernel mode at 0xc0217c04
Unaligned Access to 0x8062e076 in kernel mode at 0xc021b3dc
Unaligned Access to 0x8062e076 in kernel mode at 0xc021b408
Unaligned Access to 0x8062e076 in kernel mode at 0xc021dc2c
Unaligned Access to 0x8062e076 in kernel mode at 0xc021dc08
Unaligned Access to 0x8062e076 in kernel mode at 0xc021cd8c[/code2uo4wusl]

There's a bunch of different addresses that show up as it scrolls by.

I made this change to rt_config.h --

[code2uo4wusl]#if defined(__BIG_ENDIAN) || defined(__BIG_ENDIAN__) || \
defined(_BIG_ENDIAN) || defined(__ARMEB__) || defined(__MIPSEB__)[/code2uo4wusl]

(added the "|| defined(__MIPSEB__)" to the end)

I made this change to rtusb_main.c --

[code2uo4wusl] for (i = 0; i < rtusb_usb_id_len; i++)
{
#ifdef __MIPSEB__
if (dev->descriptor.idVendor == rtusb_usb_id[i].idVendor &&
dev->descriptor.idProduct == rtusb_usb_id[i].idProduct)
#else
if (le16_to_cpu(dev->descriptor.idVendor) == rtusb_usb_id[i].idVendor &&
le16_to_cpu(dev->descriptor.idProduct) == rtusb_usb_id[i].idProduct)
#endif
{[/code2uo4wusl]

Without that change, it wouldn't detect the device (always saying "Device Descriptor not matching").

Any chance there's still interest in working on this driver to get it working on big-endian MIPS? I'm sure there will be many happy TiVo owners who would love to see this work done. -)

Vern

27-10-2008 16:01:56

Hi dossy,

Thanks for the work. I take it __MIPSEB__ is defined if the compile target is a MIPS machine in big endian mode?

The change you made to rtusb_main.c seems a little strange. le16_to_cpu is supposed to conditionally expand depending on the endianness of the target (independent of what's in rt_config.h). Using a current CVS tarball, could you see what happens with just your rt_config.h change?

Again, thanks for your efforts. Once we've dotted the i's and crossed the t's, we can update CVS as appropriate.

Thanks,

dossy

27-10-2008 16:56:43

Thanks for the response, Vern!

[iugk9b42f]Thanks for the work. I take it __MIPSEB__ is defined if the compile target is a MIPS machine in big endian mode?[/iugk9b42f]

Yes, which the TiVo is - NEC R5432 MIPS in big-endian mode.

[iugk9b42f]The change you made to rtusb_main.c seems a little strange. le16_to_cpu is supposed to conditionally expand depending on the endianness of the target (independent of what's in rt_config.h). Using a current CVS tarball, could you see what happens with just your rt_config.h change?[/iugk9b42f]

My change was made yesterday's CVS tarball. Without looking at the cvs log, were there relevant commits between yesterday and today?

It seems all of the places where the le16_to_cpu* macros are used are having problems. I wonder if I redefine the macros as no-op's, if things will "just work" ... ?

Vern

27-10-2008 17:44:40

It seems all of the places where the le16_to_cpu* macros are used are having problems. I wonder if I redefine the macros as no-op's, if things will "just work" ... ?[/quote1hy6bajb]No. If that's the problem, you have other problems. The compiler should generate the right expansion for the target environment.

May I suggest you drill down and see how those macros expand in your environment? I would expect for MIPS big endian, you would eventually end up with something like swap16(). (For little endian, you should end up with something like "nothing".)

As a pure SWAG, it *may* be possible that the TIVO environment endianizes little endian USB stuff - in which case, more thinking needs to be done.

Thanks,

dossy

27-10-2008 17:47:32

Sorry, I've created a separate thread for this - as this old thread is not exactly related to my issue

viewtopic.php?f=4&t=5057&start=0&st=0&sk=t&sd=a

Thanks for your help!