# PATCH: rt73: probe of xxx failed with error -12

Vern

22-08-2007 17:28:31

Hi chris_ppc,

Thanks for the patch. It looks like idVendor and IdProduct are both really 16 bit fields in both 2.4.35 and 2.6.22, which would make the 'proper' fix just 'le16_to_cpu(...' in both statements.

Could you make that variation and see what happens?

Thanks,

chris_ppc

23-08-2007 11:47:49

Hi!

Yes that also works. Now when I plug in the stick it's recognized by the module.

When I want to "iwlist wlan0 scan" I get this

[code31c9int9]wlan0 Interface doesn't support scanning.[/code31c9int9]

When I unplug the stick after that my ibook hangs completely.

I attached the new patch and a debug.log which was made with debug=31. Seems there is a problem in the rt73_get_ether_sats funktion.

Any Ideas?

chris

Spy84464

23-08-2007 11:52:06

Hello,
The interface has to be up to perform a scan.

Regards,
Romain

chris_ppc

23-08-2007 11:53:15

Hi Again!

Don't ask me why, but I reloaded the module and now when I make iwlist scan I get "no scan results" immediately. But there should be scan results and not any of the leds (act, link) on the stick blink.

This new debug.log should be much more interesting.

chris

chris_ppc

23-08-2007 12:10:57

Hi Again!

Thanks for the tip to bring wlan0 up first. Well I think in the last debug log where I got "no scan results" this was the case.

Just to be sure I restarted the computer, inserted the module, brought down the interface and back up, and then performed a scan again. Still "no scan results". I also attach the new debug.log to this message.

lg, Chris

Vern

24-08-2007 17:01:23

Hi chris_ppc,

Your patch - with some mods - is in CVS. Could you try that?

Thanks,

chris_ppc

24-08-2007 19:37:53

Hi Vern!

Well the stick is recognized, but still no scan results. There are also non of the leds (act, link) blinking on the stick.

Of course I attached my debug.log again .

I am going on vacation tomorrow, so please be patient if you want me to do further testing. In the worst case I can test again two weeks from now. Depends if I can find a camping site with wlan at the Gardasee (Italy) or not.

chris

chris_ppc

14-09-2007 09:22:19

Hi!

So as I am back from vacation Any new developments on this problem. Anything you want me to test?

chris

Vern

17-09-2007 21:32:31

Hi chris_ppc,

Looking at your last debug log, the first problem area I observe is, starting at line #49, 100 lines of "BBP version = 0". The attached patch is intended to fix that, and maybe get us a little further along.

What it does is convert four-byte big endian register values to little- endian for the controller and vice versa.

Could you apply it to a vanilla version of the latest CVS, compile and run with debug=15, and attach a gzipped copy of the resulting debug log to a post here?

Thanks,

Vern

17-09-2007 21:47:11

Made a little slipsy-poo there (I think). Try this

seariver

22-10-2007 11:42:58

Hello,

I've a similar problem,.. were you able to solve this?
How can i help?

Vern

22-10-2007 17:34:39

Hi seariver,

Could you try the patch I attached to my previous post?

Thanks,

knaar

23-10-2007 03:45:09

Oh nice. I read somewhere that the rt2750 driver was better on ppc, so I did a diff and was looking through, but there's way more #ifdef BIG_ENDIAN stuff in this driver, so I think the person I read that from was mislead.

I am going to reboot into linux and post my debug log. I'm just going to

ifconfig wlan0 up
iwlist wlan0 scan

and hopefully that will get you the debugging info you need. I'm excited someone's helping us work on this issue.

knaar

23-10-2007 04:18:09

Here's the results. Here's exactly what I did

root@arthor~/Desktop/rt73-cvs-2007102113/Module# modprobe rt73 debug=31
*********************** PLUGGED IN RT73 DEVICE ************************
root@arthor~/Desktop/rt73-cvs-2007102113/Module# ifconfig wlan0 up
root@arthor~/Desktop/rt73-cvs-2007102113/Module# iwlist wlan0 scan
wlan0 No scan results
root@arthor~/Desktop/rt73-cvs-2007102113/Module# iwlist wlan0 scan
wlan0 No scan results
root@arthor~/Desktop/rt73-cvs-2007102113/Module# ifconfig wlan0 down
root@arthor~/Desktop/rt73-cvs-2007102113/Module# ifconfig wlan0 up
root@arthor~/Desktop/rt73-cvs-2007102113/Module# iwlist wlan0 scan
wlan0 No scan results
root@arthor~/Desktop/rt73-cvs-2007102113/Module# iwlist wlan0 scan
wlan0 No scan results
root@arthor~/Desktop/rt73-cvs-2007102113/Module# ifconfig wlan0 down
******************************* UNPLUGGED DEVICE *********************
root@arthor~/Desktop/rt73-cvs-2007102113/Module# rmmod rt73
root@arthor~/Desktop/rt73-cvs-2007102113/Module# cd ..
root@arthor~/Desktop/rt73-cvs-2007102113# cd ..
root@arthor~/Desktop# cat /var/log/debug | gzip > debug.txt.gz

EDIT BTW I did apply the patch first. Just so you know. I thought I mensioned that but I didn't.

Vern

24-10-2007 00:46:32

Hi knaar,

Thanks for the debug info. I've created another patch, attached as the file ppc2.patch.gz. It's intended to test a hypothesis about the interaction of how big- endian bit fields are layed out and byte- level endian conversion in the legacy rt73 driver.

If it is successful, it will still not cause the driver to operate entirely correctly in big- endian mode, but it should cause the messages saying "BBP version = 0" to no longer appear, and instead leave us with a single instance of a message saying that the BBP version is something other than 0.

Could you apply it to a vanilla CVS version of the driver, repeat your test procedure, and post a gzipped copy of the log here?

Thanks,

knaar

24-10-2007 01:58:59

Howdy Vern,

THANK YOU!!! so much for working on this. It is very appreciated.

The latest log is attached. I downloaded a newly downloaded CVS and applied the patch, compiled and installed it. This is what I did at the command line -- I got some interesting device busy messages

knaar@arthor~$sudo bash Password root@arthor~# modprobe rt73 debug=31 root@arthor~# ifconfig wlan0 up root@arthor~# iwlist wlan0 scan wlan0 No scan results root@arthor~# iwlist wlan0 scan wlan0 No scan results root@arthor~# ifconfig wlan0 down root@arthor~# ifconfig wlan0 up root@arthor~# iwlist wlan0 scan wlan0 Failed to read scan data Resource temporarily unavailable root@arthor~# iwlist wlan0 scan wlan0 Failed to read scan data Resource temporarily unavailable root@arthor~# iwlist wlan0 scan wlan0 Failed to read scan data Resource temporarily unavailable root@arthor~# iwconfig wlan0 wlan0 RT73 WLAN ESSID"" ModeManaged Frequency=2.412 GHz Bit Rate54 Mb/s RTS throff Fragment throff Encryption keyoff Link Quality=0/100 Signal level-121 dBm Noise level-143 dBm Rx invalid nwid0 Rx invalid crypt0 Rx invalid frag0 Tx excessive retries0 Invalid misc0 Missed beacon0 root@arthor~# ifconfig wlan0 wlan0 Link encapEthernet HWaddr 000E2ECE8FCE inet6 addr fe8020e2efffece8fce/64 ScopeLink UP BROADCAST RUNNING MULTICAST MTU1500 Metric1 RX packets0 errors0 dropped0 overruns0 frame0 TX packets27 errors0 dropped0 overruns0 carrier0 collisions0 txqueuelen1000 RX bytes0 (0.0 b) TX bytes3974 (3.8 KiB) root@arthor~# ifconfig wlan0 down root@arthor~# ifconfig wlan0 up root@arthor~# iwlist wlan0 scan wlan0 No scan results root@arthor~# iwlist wlan0 scan wlan0 No scan results root@arthor~# ifconfig wlan0 down root@arthor~# rmmod rt73 root@arthor~# cat /var/log/debug | gzip > debug.txt.gz Vern 24-10-2007 20:40:07 Hi knaar, Well, I screwed that up pretty thoroughly. Forget about ppc2.patch. Sorry to put you to all that work, and thanks for the effort. The current attempt, which I've attached as ppc3.patch.gz, reverts the PHY_CSR3 bit flipping to what is currently in CVS and replaces the previous MAC read/write byte flipping with in situ versions - taking a page from (I hope) the kernel's usb_control_msg() function. So maybe that will help matters. If it achieves its intended effect, we'll see a single message saying "BBP version = 22" in the log. When you get a chance, could you try it? Thanks, knaar 25-10-2007 07:06:44 Hey I'm a programmer too, I understand. Well I don't understand this code or how it works, but I understand the whole programming process. Alas I'd have to learn a lot about kernel programming and this device, etc to even know where to start and right now I really need to dump my mental effort towards web-based java and ruby code. But yeah, long story short I didn't get a chance today. Maybe tomorrow morning if all goes well. It's too bad I couldn't donate a power pc to the cause, it must be brutal to wait a whole day to see if your patch worked. Thanks again for your effort! Vern 25-10-2007 17:24:08 That'll be fine. Thanks again. knaar 26-10-2007 01:04:40 K, here it comes. I got something interesting, when I didn't have an ip specified for ifconfig wlan0 up, this time I created the wlan0ava interface. I believe ubuntu does this to get the dhcp config. I dunno, I don't know much about it. Anyway, here's what I did, and attached is the debug log. I downloaded a fresh copy of the cvs and applied ppc3.patch to it before starting. root@arthor~/Desktop# modprobe rt73 debug=31 root@arthor~/Desktop# ifconfig wlan0 up root@arthor~/Desktop# iwlist wlan0 scan wlan0 No scan results root@arthor~/Desktop# iwlist wlan0 scan wlan0 No scan results root@arthor~/Desktop# iwlist wlan0 scan wlan0 No scan results root@arthor~/Desktop# ifconfig eth0 Link encapEthernet HWaddr 001124356D10 inet addr192.168.1.103 Bcast192.168.1.255 Mask255.255.255.0 inet6 addr fe8021124fffe356d10/64 ScopeLink UP BROADCAST RUNNING MULTICAST MTU1500 Metric1 RX packets1370 errors0 dropped0 overruns0 frame0 TX packets917 errors0 dropped0 overruns0 carrier0 collisions0 txqueuelen1000 RX bytes1769928 (1.6 MiB) TX bytes89847 (87.7 KiB) Interrupt41 Base address0xd000 lo Link encapLocal Loopback inet addr127.0.0.1 Mask255.0.0.0 inet6 addr 1/128 ScopeHost UP LOOPBACK RUNNING MTU16436 Metric1 RX packets2 errors0 dropped0 overruns0 frame0 TX packets2 errors0 dropped0 overruns0 carrier0 collisions0 txqueuelen0 RX bytes100 (100.0 b) TX bytes100 (100.0 b) wlan0 Link encapEthernet HWaddr 000E2ECE8FCE inet6 addr fe8020e2efffece8fce/64 ScopeLink UP BROADCAST RUNNING MULTICAST MTU1500 Metric1 RX packets0 errors0 dropped0 overruns0 frame0 TX packets156 errors0 dropped0 overruns0 carrier0 collisions0 txqueuelen1000 RX bytes0 (0.0 b) TX bytes10140 (9.9 KiB) wlan0ava Link encapEthernet HWaddr 000E2ECE8FCE inet addr169.254.9.23 Bcast169.254.255.255 Mask255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU1500 Metric1 root@arthor~/Desktop# iwlist wlan0ava scan wlan0ava No scan results root@arthor~/Desktop# iwconfig lo no wireless extensions. eth0 no wireless extensions. wlan0 RT73 WLAN ESSID"" ModeManaged Frequency=2.412 GHz Bit Rate54 Mb/s RTS throff Fragment throff Encryption keyoff Link Quality=0/100 Signal level-121 dBm Noise level-143 dBm Rx invalid nwid0 Rx invalid crypt0 Rx invalid frag0 Tx excessive retries0 Invalid misc0 Missed beacon0 root@arthor~/Desktop# ifconfig wlan0 down root@arthor~/Desktop# root@arthor~/Desktop# ifconfig wlan0 192.168.1.12 netmask 255.255.255.0 up root@arthor~/Desktop# ifconfig eth0 Link encapEthernet HWaddr 001124356D10 inet addr192.168.1.103 Bcast192.168.1.255 Mask255.255.255.0 inet6 addr fe8021124fffe356d10/64 ScopeLink UP BROADCAST RUNNING MULTICAST MTU1500 Metric1 RX packets1372 errors0 dropped0 overruns0 frame0 TX packets918 errors0 dropped0 overruns0 carrier0 collisions0 txqueuelen1000 RX bytes1770254 (1.6 MiB) TX bytes89893 (87.7 KiB) Interrupt41 Base address0xd000 lo Link encapLocal Loopback inet addr127.0.0.1 Mask255.0.0.0 inet6 addr 1/128 ScopeHost UP LOOPBACK RUNNING MTU16436 Metric1 RX packets2 errors0 dropped0 overruns0 frame0 TX packets2 errors0 dropped0 overruns0 carrier0 collisions0 txqueuelen0 RX bytes100 (100.0 b) TX bytes100 (100.0 b) wlan0 Link encapEthernet HWaddr 000E2ECE8FCE inet addr192.168.1.12 Bcast192.168.1.255 Mask255.255.255.0 inet6 addr fe8020e2efffece8fce/64 ScopeLink UP BROADCAST RUNNING MULTICAST MTU1500 Metric1 RX packets0 errors0 dropped0 overruns0 frame0 TX packets27 errors0 dropped0 overruns0 carrier0 collisions0 txqueuelen1000 RX bytes0 (0.0 b) TX bytes21400 (20.8 KiB) root@arthor~/Desktop# iwlist wlan0 scan wlan0 No scan results root@arthor~/Desktop# iwlist wlan0 scan wlan0 No scan results root@arthor~/Desktop# iwlist wlan0 scan wlan0 No scan results root@arthor~/Desktop# ifconfig wlan0 down root@arthor~/Desktop# root@arthor~/Desktop# iwconfig wlan0 mode monitor Error for wireless request "Set Mode" (8B06) SET failed on device wlan0 ; Network is down. root@arthor~/Desktop# ifconfig wlan0 192.168.1.12 netmask 255.255.255.0 up root@arthor~/Desktop# iwconfig wlan0 mode monitor root@arthor~/Desktop# iwconfig lo no wireless extensions. eth0 no wireless extensions. wlan0 RT73 WLAN ESSID"" ModeMonitor Frequency=2.412 GHz Bit Rate54 Mb/s RTS throff Fragment throff Encryption keyoff Link Quality=0/100 Signal level-121 dBm Noise level-143 dBm Rx invalid nwid0 Rx invalid crypt0 Rx invalid frag0 Tx excessive retries0 Invalid misc0 Missed beacon0 root@arthor~/Desktop# airodump-ng wlan0 CH 13 ][ Elapsed 8 s ][ 2007-10-25 1858 BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID BSSID STATION PWR Lost Packets Probes root@arthor~/Desktop# ifconfig wlan0 down root@arthor~/Desktop# root@arthor~/Desktop# rmmod rt73 root@arthor~/Desktop# cat /var/log/debug | gzip > debug.txt.gz root@arthor~/Desktop# ls -l debug.txt.gz -rw-r--r-- 1 root root 155603 2007-10-25 1858 debug.txt.gz Vern 26-10-2007 19:04:53 Hi knaar, Well, I'm afraid I'm giving you a real workout, here. Sorry. Thanks again for your work. Things are still hosed the failure indicators (the BBP version messages) haven't changed. I looked at Ralink's version of the RT73 driver, and they seem to be avoiding the in-place byte flipping that I've been doing; so maybe that's the problem (I hope). Also, it looks like the kernel function usb_control_msg() byte flips from the stack by pointer, so I do that, too. The patch is attached in ppc4.patch.gz. As your schedule allows, could you try it? Thanks, Edit When you compile, do you get a warning message saying big endian support is still experimental? You should. knaar 27-10-2007 03:42:22 Howdy Vern, Yes, I get tons of those endian warning messages. I will try your patch in just a bit. I have my weekly stargate ritual to observe. Perhaps if I have time I may look through your patches and see what you're tinkering with here and see if I can poke through the code and get a version that gets at your goal of stopping the BBP messages or whatever. I know C very well, I just have no idea how the driver and/or kernel works. Again I wish I (or someone else, hint! hint!) could donate a power pc to you. Alas this is my first apple, and I doubt any of the junk at work would help you any. But who knows, maybe someone else wants this driver working bad enough to donate something? Anyway see ya in an hour or so. Stargate awaits! knaar 27-10-2007 04:46:04 Here's the latest debug log. I did much the same as last time. Ifconfig wlan0 up, and scanned three times, then took it down. After that I put it up and tried to put it into monitor mode and tried airodump-ng for a little while. Took it down and up and down and up and tried scanning. Nothing. No packets seen, no scan results. EDIT Oh, another thing this time when I compiled there **was NOT any warnings!** I see in the code the #warning tag is still there, so there SHOULD be warnings... hmmmm.... knaar 27-10-2007 05:28:49 Upon realizing the driver wasn't compiling in __BIG_ENDIAN support, I added -D__BIG_ENDIAN to the gcc flags in the makefile manually. I have no idea what changed to do that, but whatever, it spewed the warnings like it should this time. I attached two log files this time. Both were very similar processes. Just a lot of tinkering around. I blanked the log files and restarted the syslogd between captures, so the first few commands were a modprobe, I plugged in the device, I ifconfig wlan0 uped and then iwlist wlan0 scanned thrice. I keep seeing this sometimes [code3kvlgb3y] root@arthor:~/Desktop/rt73-cvs-2007102622/Module# ifconfig eth0 Link encap:Ethernet HWaddr 00:11:24:35:6D:10 inet addr:192.168.1.103 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::211:24ff:fe35:6d10/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1283 errors:0 dropped:0 overruns:0 frame:0 TX packets:1120 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1289256 (1.2 MiB) TX bytes:309597 (302.3 KiB) Interrupt:41 Base address:0xd000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:200 (200.0 b) TX bytes:200 (200.0 b) wlan0 Link encap:UNSPEC HWaddr 00-0E-2E-CE-8F-CE-48-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) [/code3kvlgb3y] Notice how the mac address is all screwed up. If I unplug the device and plug it back in, sometimes this is fixed. Sometimes I can ifconfig wlan0 down and when I bring it back up again it is fixed. knaar 27-10-2007 05:55:49 Oh and an interesting project here http//pearpc.sourceforge.net/ It does not have usb support, but you might be able to install linux inside it and at least check that the driver compiles? I dunno, maybe it'd be useless. Qemu can also emulate powerpc, and qemu does have preliminary usb support, but I don't know if it works when you're emulating a different cpu instead of virtualizing. Vern 27-10-2007 17:42:36 Hi knaar, Thanks for the pear link. As far as I understand, you shouldn't have to change the Makefile at all I think __BIG_ENDIAN is exported by the compiler; and I gather from your previous post that you were getting the warning messages without putting -D_BIG_ENDIAN in the Makefile. Is that right? Might bear further investigation. Thanks for the catch on the MAC address display. That's something else to look at. Anyway, let me put these logs in front of my navel and contemplate them. Thanks again, knaar 27-10-2007 19:12:56 Howdy Vern, I installed qemu on os x last night. It's very interesting. I can even emulate mipsel. Since I'd sort of like to compile these drivers on my asus mipsel router, I set up a mipsel debian box inside qemu. It's taking forever to compile, but hey, it has way more ram/hard drive than my router does. Mipsel is also little-endian, which leads me to believe I could get this driver working on my router with no modification.... here's hoping. But from what I read, if you install qemu on linux and use it to emulate a powerpc you *should* be able to get USB working. I also believe that if I install qemu in linux on my power pc, I should be able to emulate a little endian PC with usb support as well. It'd be slow as snot in winter, but it might work well enough to do some debugging... Just don't try to install X11 or anything fancy in qemu.... I've seen people running OS X in qemu but wow... this mipsel qemu box I have is around half the speed of my actual router, and it only has a 266 MHz CPU! But my project today is to try to compile the driver in mipsel and kick my router until it loads the driver and it works. Here's hoping! Vern 28-10-2007 00:45:55 Hi knaar, Looks like you're having fun. It may be that when our device is connected to a power pc (a real PPC, not an emulated one) that we're not allowing enough time for the adapter to respond when we access the BBP registers. In the function that gets the BBP version, I've pushed out the status loop to 50 iterations instead of 4 to see if this is the case, added more debug info to the error messages, and put the mods in ppc5.patch.gz. It might also be worth while to nail down the big endian anomaly why compiles stopped emitting the big-endian warning messages. Anyway, if (when) you get a chance, can you try the latest patch? Thanks again for your work, knaar 28-10-2007 02:10:32 Howdy Vern, Bombs away. Same commands as last time. This time no extra long mac address from ifconfig happened, however I still had to add -D__BIG_ENDIAN to the compiler flags. ubuntu wants me to upgrade to gutsy... I'm hesitant in case it will screw this up. I hear the driver has a few problems in gutsy. But I did tell it to auto upgrade some things, so something might have changed without me knowing. None of them are kernel or toolchain related, however. Vern 28-10-2007 17:27:40 Hi knaar, Thanks for the quick, consistent turnarounds. Having to manually specify -D__BIG_ENDIAN is troubling. From your earlier posts and logs, I gather that you were getting the expected results from make - i.e. the big endian warning message - without doing so. If that is the case, then I'd think something has changed in your compile environment. May be worth looking in to. [quote1jqf49qc]I hear the driver has a few problems in gutsy.[/quote1jqf49qc] As long as you're using either the hourly CVS tarball or CVS proper, that shouldn't be a problem. FYI, the log shows that a certain register we're interested in has the busy bit stuck on; so a little more digging is needed. If you've run ctags on the driver source, and view your log from the driver source directory, then you can use vim's tag capabity from the log file to view the various functions. e.g. [code1jqf49qc]- RTUSBReadBBPRegister: Pre-busy error=0x 10000 or device removed!!![/code1jqf49qc] Put the cursor on [code1jqf49qc]RTUSBReadBBPRegister[/code1jqf49qc], hit `^]', and you'll be looking at the source for that function. Anyway, I need to look into the stuck busy bit a little bit. Thanks again, knaar 29-10-2007 15:20:11 Hmmm... well I have no idea how to use vi or vim. I grew up being a windows guy and I've only been a linux user the last uh... 7 or so years, and during that time there's been lovely tools like gedit or kate, or even nano if I absolutely have to edit at the command line. Vi and Emacs seem backwards and awkward to me and I always mess up. Anyway I was thinking, perhaps a backwards command is being sent to the device and that's why the busy flag is stuck? If commands are an opcode for a cpu, or even an opcode for a small VM running on the device, if you give it an invalid opcode it is very likely not caught and instead just hangs the device.... here I use opcode and command interchangably. I mean, if the 2048 bytes of firmware sent to the device is actually a VM that runs on the device's cpu and interprets commands from the computer, then that's really not a lot of room to implement a complete vm, and it's likely that a lot of the error conditions just result in hangs or crashes. If it was busy when it hung or crashed, the busy flag would get stuck on. Or maybe I don't know anything about how it works and I should shut up now Vern 29-10-2007 17:41:36 Vi and Emacs seem backwards and awkward to me and I always mess up.[/quote9zgofmj0] Oh. [quote9zgofmj0]Or maybe I don't know anything about how it works ...[/quote9zgofmj0] Actually, you've got the right basic idea. And "backwards commands" (from a big- endian point of view) is the basic problem being addressed. The patch I've created seems to do much the same thing that Ralink's version, and the "Next Gen" version, of the driver does. I do have three questions 1. Are you compiling on the target machine? (Still gnawing away at the "-D" business.) 2. Have you tried Ralink's version of the driver? I'm not too sure what the state of play of anybody's driver version is in this regard. 3. I'm not too sure what the minimum kernel requirements for the "next gen" driver are, but you might try that. Thanks, knaar 30-10-2007 02:45:46 1. Yes I am, and until recently it did automatically figure out it was a big endian machine. I haven't downloaded the kernel source and tried with that, I'm currently just using the kernel headers. I suppose rolling my own kernel might be a thing to try. 2. I haven't tried Ralinks' driver. My main goal is to have injection working great, as this thing has a built in wifi card that happens to be a broadcom and doesn't do injection, but otherwise works fine for surfing the net. I have tried third party drivers that support fragmentation attacks, as well as the other goodies, but they require a few patches to compile, and then do exactly the same thing as this driver does -- can't hear any packets at all. 3. I've tried the next-gen drivers and they're slow and flaky. I read somewhere about a 5.5 Mbps max, and it doesn't capture nearly as many packets as the device does in KisMac in OSX in the same location with the same APs around (my APs). Plus there's no injection yet. The latest kernels support injection but the latest software (aircrack-ng) doesn't. That I know of. Plus ubuntu doesn't come stock with these kernels, not even gutsy, and there's probably a reason for that. I have made a bit of progress getting this driver to work on my mipsel router. I would really like it to work on my laptop but hey, my mipsel is little-endian, and while it currently has a 2.4 kernel, I'm going to try a 2.6 kernel on it and see if I can get it to boot. If I can, it should be a breeze to get this driver working on it. I hope. So anyway, if you're frustrated and you wanna call it quits, that's fine by me. It's obviously not a quick fix and you're probably not getting paid to do this, so meh. If someone wants to give you$500 and a free powerbook to do this project great, but otherwise the new apples are intel and this powerbook is obsolete (hence why I got it for free). (Although playstation 3s are power pcs too, and there might some day be someone that wants to run one of these devices on a playstation 3?? Naw...)

So yeah it's up to you. I'll sit down next weekend and see if I can understand the code enough to figure out what should be byte swapped and isn't already but I'm certainly not qualified. But this week I'm busy as hell and will be working 10-12 hour days to finish my project for monday.

Vern

31-10-2007 17:51:56

Hi knaar,
[quote1qq5d2v1]... until recently it did automatically figure out it was a big endian machine.[/quote1qq5d2v1]
I think it might be very worth while to figure out why that stopped and get things back to where endianism is automatically figured out. Things can be surprisingly sensitive to environment for the reason that many configuration options change the layout and format of structures in ways that have non- obvious dependencies e.g. I recently found that my rt2500 driver stopped working after configuring my kernel for tickless clock operation; and it stayed that way until I recompiled it against the reconfigured kernel source.
[quote1qq5d2v1]I've tried the next-gen drivers and they're slow and flaky.[/quote1qq5d2v1]
Almost sounds like your saying they work - i.e. transfer data; they're just slow. Do they work in that sense?
[quote1qq5d2v1]So anyway, if you're frustrated and you wanna call it quits, that's fine by me.[/quote1qq5d2v1]
We don't do that here. Getting this thing to work with your PPC means that it works with big- endian machines in general, which is a good thing.
[quote1qq5d2v1]it currently has a 2.4 kernel,[/quote1qq5d2v1]
All legacy drivers work - or should work - with 2.4 kernels as well as they do with 2.6 kernels. If not, that's a bug.

knaar

01-11-2007 00:12:11

Yes the next-gen driver works on my machine. Just the legacy driver does not.

If the build environment is that important I'm going to try downloading a vanilla kernel and rolling my own .config. I've never configured a kernel for a powerpc, but hopefully there's some hints and tips on the net somewhere for my model so I know what drivers it needs. I'd hate to have to take a screwdriver to it just to figure out which chips are inside, but it has no warantee so whatever. And then I'll try compiling this driver with the newly built kernel and see if it makes a difference. I hope so.

As for my router, I don't know why it won't load the driver. It only has insmod and not modprobe, and it won't allow you to set debug on the commandline, it just says "can't find module debug=15". Insmod is part of busybox. I did manage to compile the latest cvs and insert it but it said it couldn't find the firmware hooks, so obviously the kernel doesn't have firmware support compiled in. So I'm trying to compile an older version with hardcoded firmware but no go. Plus there's no errors. The module loads, but it doesn't associate with the usb module, and it doesn't grab usb devices when they're plugged in. It's weird. I think I'd have to compile it with openwrt's buildchain, but I could only find the amd64 version, and I didn't feel like rolling my own build environment. I'm just emulating a mipsel cpu with qemu as my build environment right now.

I'm thinking I'll just install debian on it so I have proper tools, not this busybox BS. Then maybe it'll give me an error I can use to track down the problem. I also haven't tried openwrt yet (using dd-wrt currently), and I might have more success with their kernel.

But that's for another day. I'll try the new kernel tonight and report back with any changes.

Vern

01-11-2007 17:51:40

Hi knaar,

If you can compile and run the next-gen driver on your Power PC machine, then the build environment should be good enough to compile and run the legacy driver.

What kernel are you running?

knaar

02-11-2007 03:25:27

Uh the next-gen driver came with ubuntu. I did not compile it, the ubuntu folks did. That's probably why it worked, some kernel genius probably tweaked it. I suppose I could try to compile the next-gen drivers and see if they work.

I'm using 2.6.20-16 with all the ubuntu patches and I believe it's also the -mm kernel. Hence why I wanted to try a vanilla kernel and see if it works. But alas I still haven't had time. I've been working really late every night. This weekend I should have time. I hope. If I don't get this project done tomorrow I'll be working saturday though -/ Oh well, it'll be worth it. My hard work will pay off, God willing.

Vern

02-11-2007 20:38:36

Hi knaar,

Just a thought, but it might be easier to figure out what changed in your environment to cause the big endian warnings to no longer be issued, then unchange it.

Sounds like you also have a day job. This stuff will all still be here after you take care of that.

knaar

04-11-2007 05:26:34

Howdy Vern,

Thought I'd give you a quick update before I go to bed. I found a tutorial on compiling a kernel on ubuntu, but I have never compiled a kernel on a powerpc before and I don't really trust myself to figure it out without wasting a ton of time. So I grabbed the config from ubuntu's current kernel and a vanilla kernel of a similar version (both 2.6.20 kernels) and ran a make oldconfig with the config file I found.

That said I suspect it will take bloody well forever, as everything is compiled as modules. I'll test that I can actually boot to this new kernel tomorrow morning and try compiling with it and see if it compiles with the proper endian warnings. Then I'll try various flavours of the driver and see if any of them work properly. I'm hoping one of them will.

knaar

04-11-2007 16:49:28

Oh this is interesting

vanilla 2.6.20.21 kernel, obtained direct from kernel.org, no patches of any kind.

My environment is fixed now, every module I tried to compile spews the endian warnings.

I tried the 2007101214 CVS tarball posted in another topic and applied your patch to it (ppc5.patch.gz). I got this debug log. I'm guessing that it's just because your patch wasn't designed for this version, but there's lots of kernel exceptions.

knaar

04-11-2007 17:16:50

I take that back. Every vanilla CVS module I've tried spews out the endian warnings. Every module I apply ppc5.patch to does NOT spew the endian warnings, and hence that's probably why that debug log was full of exceptions.

Attached is the log when I modified the makefile with -D__BIG_ENDIAN on the patched one from the previous post.

Vern

24-11-2007 05:00:38

Hi knaar,

Sorry for the delay.

Could you try the attached patch? If we (OK, I) am/are lucky, it will remove the "Pre busy" error, and get us somewhat further along.

Thanks,

osx424242

26-11-2007 00:57:22

Here's my output... I think I must have done something wrong compiling or running the driver, as the /var/log/debug output doesn't seem to have a lot of useful information.

Vern

26-11-2007 02:42:39

Hi osx424242,

I'm not too sure if the README file is helping or hurting. Try

'make clean debug'
'make modules_install'

Then do *modprobe* rt73 debug=31

and see what happens.

Thanks,

osx424242

26-11-2007 04:32:59

Hi Vern,

Yeah, I've _never_ seen out-of-date documentation that no longer matches the code

Okay I tried that but /var/log/debug still seems mostly empty, I'll attach my 'script' output as well as /var/log/debug. I'm still new to the linux way of doing things so I can't tell if there's something simple that I'm doing wrong. I'm sure you weren't expecting to help someone learn to properly build & install new code this weekend so I apologize for all the extra effort you have to put into this.

Oh, I'm also including /var/log/syslog which may have relevant messages. I also tried some more activities after breaking my script, so I will also include all the output from my terminal (not the full session, this was the reminder to increase my scrollback buffer size), just in case it is useful in concert with 'syslog'.

Vern

26-11-2007 17:53:16

Hi osx424242,

From the looks of your syslog, you may have the "next gen" driver in there somewhere, too.

Where is /etc/syslog.conf set up to send debug output to? There doesn't appear to be driver debug output in the copy of /var/log/debug you supplied.

Thanks,

osx424242

27-11-2007 06:17:54

I was unable to post a message earlier so I tried sending you a PM hopefully that worked... trying again now to post... I think I got the correct module loaded with debug symbols.

Vern

27-11-2007 18:02:20

Hi osx424242,

Thanks for the log info. I have to take care of some business, so it'll be awhile before I can delve into it; but I think there may be helpful info there.

Thanks again,

Vern

30-11-2007 19:03:26

Hi osx424242,

The attached patch adds some more byte flipping for big endian mode so that 512 bytes instead of 2 are used for the data block size. Also, it adds more debug statements to check byte flipping assumptions and for exception conditions.

It most probably won't make us fully operational, but we should get further along, and end up with more information.

So, could you give it a try?

Thanks,

osx424242

02-12-2007 08:39:50

grrr, spent 30 minutes trying to figure out why it didn't work... then remembered that I had unplugged my USB adapter okay, here is the output.

Vern

02-12-2007 19:25:46

You tryin'a tell me this is workin' boah?

osx424242

02-12-2007 20:19:28

Sorry, I should have been more specific 'ifconfig wlan1 up' wasn't working because the USB adapter was unplugged. When I plugged it in, 'ifconfig wlan1 up' started to work again (duh) and I saved /var/log/debug and attached it to my previous message. 'iwlist wlan1 scan' doesn't report anything (as shown in typescript from the previous attachment) and the adapter still does not show up in gnome-network-manager.

Vern

02-12-2007 22:26:19

Hi osx424242,

Well, basically, the thing is surfing through the channels and sending out probes. Two questions

1. After ifup wlan1, what does 'ifconfig (sic) wlan1' say?
2. Is it known that there is at least one beaconing a/b/g device in the vicinity?

Thanks,

osx424242

03-12-2007 00:16:03

I do, occasionally, see another access point. It has the name of a local (based in the next town over, about 3 miles from here) ISP with a '20' appended to it. I'm not sure what that means -- picking up a far-away access point; they have a nearby access point I can see; someone nearby has a household access point that is named or setup by the ISP -- but since I don't see it all the time it is either far from here (not a surprise, I can only see 2 houses from here, and I have to be standing in just the right place to see them) or not turned on all the time. Its signal is always very faint, so it could always be on but subject to interference. It must be b or g because that is what my laptop (wireless working system76) supports.
I have no idea if that access point was broadcasting this morning when I posted my previous message. It does not appear to be broadcasting right now.
SSID broadcast is disabled on my access point, FWIW. My access point only supports b/g.
Would enabling SSID broadcast, or undoing WAP security, be important for debugging this? I can do those for short periods, but my roommate (a) gets nervous (despite the fact that we are in a rural enough area to not be a target) and (b) I can't do it while my roommate is using my computer .

$ifconfig wlan1 wlan1 Link encapEthernet HWaddr 00173F72F5CE inet6 addr fe802173ffffe72f5ce/64 ScopeLink UP BROADCAST RUNNING MULTICAST MTU1500 Metric1 RX packets0 errors0 dropped0 overruns0 frame0 TX packets9 errors0 dropped0 overruns0 carrier0 collisions0 txqueuelen1000 RX bytes0 (0.0 b) TX bytes846 (846.0 b) I'm attaching the regular info in case it is useful (you can also see that ifconfig output there). From my "dumb user" standpoint, though, the wireless adapter still is not showing up as a choice in the network manager icon in the panel at the top of my screen. Vern 03-12-2007 00:26:57 Mama Mia! Atsa big log! SSID broadcast is disabled on my access point, ...[/quote27acnuzm] You might try using the AP's MAC address to associate. In the meantime, I'll take a look at your latest log. Thanks for the work, osx424242 03-12-2007 00:39:15 Wow, you're right, that is big. I didn't think to check the size before posting! Umm... to associate using the MAC address, do you mean by manually setting it up in /etc/network/interfaces, or a different technique? Vern 03-12-2007 02:33:55 e.g. [coden671omoq]iwconfig eth0 ap 00:60:1D:01:23:45[/coden671omoq] but never mind. It turns out we need to byte flip some of the EEPROM info we get from the adapter, too. Vern 03-12-2007 22:00:46 Hi osx424242, OK, here's another iteration of the patch - attached as ppc8.patch.gz. Basically does the following 1. Byte flip selected EEPROM values - hopefully only the right ones. 2. Remove warning about big endian compile. 3. Comment out a couple of no-longer-needed debug messages. Please apply it to a vanilla copy of the latest CVS tarball. Hopefully, this fixes the values the driver works with that they're not so out of whack that nothing happens. Thanks, osx424242 04-12-2007 07:39:23 Something went _very_ wrong. I sent a command (I am _fairly_certain_ that it was 'sudo ifconfig wlan1 up'; _possibly_ 'ifconfig wlan1'; _low_probability_ it was a different command, around there, from previous 'typescript' logs) and immediately lost my connection (no KVM attached to the PPC box, I just talk to it via remote desktop). A few minutes later, I was able to reconnect and got this [code28bquvwx]music@izzit:~$ uptime
22:56:02 up 3 min, 2 users, load average: 0.50, 0.81, 0.37[/code28bquvwx]
so apparently the lost connection was due to a reboot, presumably tied to the ifconfig wlan1 up command.
Oddly, typescript does _not_ show the last couple commands I sent -- is this a limitation in 'script'? I do not have any experience with script in crash situations to know more.
In addition to the incomplete typescript and /var/log/debug I'm including /var/log/syslog, which shows a 'reboot' near a jump in timestamps in /var/log/debug.
Unfortunately, "sudo find / -type f -name core" didn't find anything for me to include here.
Should I try again, or attach another log file, or ...?

osx424242

04-12-2007 07:44:39

okay, tried again, for shits & giggles
$sudo modprobe rt73 debug=31 - worked$ sudo ifconfig wlan1 up
- worked
$whoami - worked$ if
- in the middle of typing 'ifconfig', lost the connection
- says to me either 'modprobe' spawns a task that takes a while and then locks up, or else 'ifconfig' spawns a task that takes a while and then locks up, or else 'whoami' is terribly broken (not likely, given what I'm debugging ). I'd lay my money on 'ifconfig', since I wouldn't expect it to return at all if 'modprobe' was still working. But, you're the professional here... just let me know what you'd like me to try next.
(In my experience, obvious crashes always mean I'm on the right track and just a couple steps away from the correct solution, so I am _certainly_ encouraged by this result!)

panchofmx

06-01-2008 11:31:41

Hi im new
how do i apply the ppc8.patch to my rt73*/Module/

Vern

06-01-2008 18:40:34

Hi panchofmx,

Wellcome to the fray

2. After you log out, click on the Download tab at the top of the page, select the rt73 legacy driver, download it, and untar it.
3. cd rt73*/Module
5. make clean debug
6. make install (As root)

Then, also as root
1. echo -n >/var/log/debug (zaps log)
2. Run with "debug=31" as modprobe parameter
3. ifdown, then rmmod after encountering symptoms

Gzip a *copy* of /var/log/debug and attach it to a posting here.

Thanks,

panchofmx

06-01-2008 21:35:39

Hi vern

i did.

As root.
modprobe rt73 debug=31
ifconfig wlan0 down
rmmod rt73

i attach my debug

thanks

panchofmx

06-01-2008 22:48:44

ifconfig and iwconfig looks fine.
but

dosent found any APs or my own router.

Vern

06-01-2008 23:43:55

Sorry panchofmx. I should have been clearer By "run" (step 2), I meant "ifup ..., do stuff till you see that it's not working, then ifdown, rmmod ..." (step 3).

And that's probably what I should have said (You've heard the phrase DWIM, right?).

Could you try it again?

Thanks,

panchofmx

07-01-2008 00:26:42

root@ubuntu/home/panchofmx# echo -n >/var/log/debug
root@ubuntu/home/panchofmx# modprobe rt73 debug=31
root@ubuntu/home/panchofmx# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 RT73 WLAN
Link Quality0 Signal level0 Noise level113
Rx invalid nwid0 invalid crypt0 invalid misc0

root@ubuntu/home/panchofmx# ifup wlan0
There is already a pid file /var/run/dhclient.wlan0.pid with pid
805315536
Internet Systems Consortium DHCP Client V3.0.5

Listening on LPF/wlan0/00c0ca19dbbd
Sending on LPF/wlan0/00c0ca19dbbd
Sending on Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 16
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
No working leases in persistent database - sleeping.
root@ubuntu/home/panchofmx# ifdown wlan0
There is already a pid file /var/run/dhclient.wlan0.pid with pid 5096
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.0.5

Listening on LPF/wlan0/00c0ca19dbbd
Sending on LPF/wlan0/00c0ca19dbbd
Sending on Socket/fallback
DHCPRELEASE on wlan0 to 192.168.2.1 port 67
Error for wireless request "Set ESSID" (8B1A)
SET failed on device wlan0 ; Network is down.

root@ubuntu rmmod rt73

thank for you help Vern

panchofmx

07-01-2008 23:58:25

IM runing xubuntu 7.10 on my old Ibook 3g my Kernel is 2.6.22-14-powerpc and i also have 2.6.24-rc6

Im testing rt73 on 2.6.22-14-powerpc kernel.

using kitmet on monitor mode after a while the system locks up. same happen with airodomp-ng. i dont know if that help on anything
-
hope that osx424242 is correct about the crashes,
[quote2e2xwf84]
(In my experience, obvious crashes always mean I'm on the right track and just a couple steps away from the correct solution, so I am _certainly_ encouraged by this result!)[/quote2e2xwf84]

any luck with my debug vern?

panchofmx

12-01-2008 21:00:25

Any luck with the Driver under PPC?>

Vern

13-01-2008 04:08:30

Hi panchofmx,

Glad to see you're chomping at the bit and ready to go. Sorry for the delay I've been off picking lower hanging fruit.

One question does your AP - or other wireless equipment in the area - detect us when it does a scan?

Also, I've recently fixed up debug message routing in the driver. Could you grab the latest CVS, apply the attached patch (ppc9.patch.gz) to it, then compile and run with debug enabled?

There's something very small, but very critical, that we're missing here.

panchofmx

13-01-2008 07:16:33

Hello Vern,

i got kernel panic a few times doing ifup same happen trying to use airodump-ng and kismet
How can i attach my kernel panic Error msg to a debug? (the system locks up)

[quote1jnaqjf9]
One question does your AP - or other wireless equipment in the area - detect us when it does a scan? [/quote1jnaqjf9]
I cant find AP YET

attach my debug.
root@ubuntu/home/panchofmx# echo -n >/var/log/debug
root@ubuntu/home/panchofmx# modprobe rt73 debug=31
root@ubuntu/home/panchofmx# ifup wlan0

Internet Systems Consortium DHCP Client V3.0.5

Listening on LPF/wlan0/00c0ca19dbbd
Sending on LPF/wlan0/00c0ca19dbbd
Sending on Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 18
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
No working leases in persistent database - sleeping.

root@ubuntu/home/panchofmx# ifconfig wlan0

UP BROADCAST RUNNING MULTICAST MTU1500 Metric1
RX packets0 errors0 dropped0 overruns0 frame0
TX packets169 errors0 dropped0 overruns0 carrier0
collisions0 txqueuelen1000
RX bytes0 (0.0 b) TX bytes11154 (10.8 KB)

root@ubuntu/home/panchofmx# iwlist wlan0 scan
wlan0 No scan results

root@ubuntu/home/panchofmx# ifdown wlan0

Listening on LPF/wlan0/00c0ca19dbbd
Sending on LPF/wlan0/00c0ca19dbbd
Sending on Socket/fallback
DHCPRELEASE on wlan0 to 192.168.2.1 port 67
Error for wireless request "Set ESSID" (8B1A)
SET failed on device wlan0 ; Network is down.

root@ubuntu/home/panchofmx# rmmod rt73

Thanks

Vern

13-01-2008 18:52:17

Hi panchofmx,

If you like, see if you can find the Oops in /var/log/kern.log. If so, try grepping out the entries in the neighborhood of the time it happened, and attach a gzipped copy of the resulting extract to a posting here.
[quote25qqbu4y]I cant find AP YET[/quote25qqbu4y]
I meant does your AP see you when *it* scans?

In the meantime, I'll take a look at your log.

Thanks,

Vern

13-01-2008 23:58:50

Hi panchofmx,

Comparing your debug log output with that of a reference, I see that we're using very low trasmit power. I suspect this may be because I'm still incorrectly endianizing the EEPROM data used for tx power calculations.

The attached patch (ppc10.patch.gz) has even more debug statments in it to see if this is the case. Could you apply it to a vanilla copy of the latest CVS, build and run with debug enabled on your PPC machine; then (kick me if you wish) if you have a x86 based PC available, do the same on that? The reason is so we can factor out differences that may be introduced by different manufacturers.

Thanks,

panchofmx

14-01-2008 22:55:40

Hello vern.

attach my new debug with ppp10.patch
as root
modprobe rt73 debug=31
ifup
ifdown
rmmod rt73
.
testing the driver i found,
when rt73 find eny wireless signal the system crash. (kernel panic).
if I hide my wireless device form eny signals the system does not panic.

[quote9ffgkh3o] Could you apply it to a vanilla copy of the latest CVS, build and run with debug enabled on your PPC machine[/quote9ffgkh3o]

im installing the kernel linux-2.6.23-rc7-git4 now.
i will post the debug soon i get it working fine.

Which kernel from vanilla do you think is best for testing the rt73 on ppc??

Thanks

Vern

15-01-2008 02:20:07

Hi panchofmx,

Thanks for the debug info.
[quote23ichgbo]Which kernel from vanilla do you think is best for testing the rt73 on ppc??[/quote23ichgbo]
The vanilla CVS I'm referring to is the rt73 driver CVS. As far as the kernel is concerned, its best to continue using the one you've been using.

If you can extract the Oops info from /var/log/kern.log, that would be good, too.

Thanks,

panchofmx

15-01-2008 19:39:59

Hi Vern,

[quote1isvqqx8]If you can extract the Oops info from /var/log/kern.log, that would be good, too.[/quote1isvqqx8]

I Attach two kern.log files here, (they are on monitor mode)

also just before the system lock up i got a Error msg on the screen said something like.

RTMPcheckRxdescriptor+ox1fc/ox200 [rt73]
RTUSBRXpacket+oxda8/ox1254 [rt73]

Kernel panic
and the system automatic restart on 180sec

I cannot obtain the log file with it. ill try to find the whole message and post it here.

Thank.

Vern

15-01-2008 19:49:40

Hi panchofmx,

One quick observation I've found that whenever I change *any* driver source file, I need to do "make clean all", or "make clean debug" every time, or I sometimes get Oopses when I try to run the driver. Could you double check that you've done that?

Thanks,

panchofmx

15-01-2008 20:04:11

Yeah vern i make clean debug every time i install

panchofmx

15-01-2008 20:26:43

Fresh debug

panchofmx

18-01-2008 03:28:56

The latest rt73 CVS it appears that it find some packets and noise does not set any ESSID <No ESSID>. - looks like it hav low signal.
SYSTEM DOESN'T LOCK UP! Attach log of signal

i need to apply a new patch now?

Vern

18-01-2008 21:02:27

Hi panchofmx,

Do you have an x86-based PC available? If so, could you build the driver on that and attach a copy of the debug output to a posting here? The reason is that that - for reasons I don't understand - we seem to be using very low transmit power on the PPC machine, and I'd like to see what the results using the *same* adapter are on an x86 based machine that might give me a handle on what's missing with respect to big endian ops.

Thanks,

panchofmx

18-01-2008 21:25:02

[quote2b6xwibd]
Do you have an x86-based PC available?[/quote2b6xwibd]

No Sorry, i dont have one.

Vern

20-01-2008 21:17:26

Hi panchofmx,

I have two requests

First, could you post the manufacturer's name and model number of your adapter in the hope that some public spirited person with that model hooked up to an x86 PC will make the debug run to produce the reference log?

Second, could you get the gcc precompiled constants for your PPC machine and post them here? e.g. (assuming the file foo.c doesn't exist)

(touch foo.c; gcc -E -dM foo.c;\rm foo.c)|sort > gccconst.txt

and attach gccconst.txt to your post. That should give me a leg up on knowing what compile constants are available on the PPC target to help configure the build process a little better.

It turns out that the big endian definitions for the transmit and receive data structures (mailboxes of a kind for exchange of control info between driver and firmware) are pretty well hosed. The attached patch (ppc11.patch.gz) basically adds the following to what's been done so far

2. Fix big endian Tx, Rx Descriptor structure defs. Basically incorporate Ralink's changes.
3. Fix code for handling big endian Tx, Rx structures.

If we're *really* lucky, this should now work. If not, we're at least further down the road.

Thanks,

panchofmx

21-01-2008 12:27:07

Hi vern.

it find APs!! with airodump-ng a and kismet.

but iwlist wlan0 scan Does not find Nothing yet.

hav a look of my debug. also attach gccconst.txt

[quote27lcxn4v]
could you post the manufacturer's name and model number of your adapter[/quote27lcxn4v]
Alfa Network
ModelAWUS034s

GOOD WORK

Vern

21-01-2008 21:50:35

Hi panchofmx,

Thanks for the gcc constants and model info. That should help give us a leg up in hopefully getting more automation into the build process for various platforms.

While we don't have complete success, we've now moved on to actually receiving frames (I suspect probe response); which means what we send is detected, and deemed plausible by the recipient. However, the recieve handler fails with CipherErr 2 (MIC error) and 3 (bad key).

It looks like we end up undefining the big endian constant when we're not on a Win32 platform (I don't understand, either), with the result that we don't properly endianize the receive descriptor "mailbox", which is what's giving us the error.

The attached patch - in ppc12.patch.gz - incorporates everything in the previous version, and also changes the source code to not undefine the big endian constant. So, using the latest CVS, could you apply it and see what happens?

Thanks,

panchofmx

23-01-2008 07:25:40

great vern! it works better now.
iwlist wlan0 scan woRks!
Also RutilT
looking good.

one question vern, it normal that my Mac address on monitor mode change to HWaddr 00-C0-CA-19-DB-BD-48-00-00-00-00-00-00-00-00-00?

Attaching the usual debug.

thanks

Vern

23-01-2008 19:30:47

Hi panchofmx,

Thanks for the debug info. Your log shows that we're now receiving and processing beacons and probe responses (I think). The attached patch (ppc13.patch.gz) has some more debug statments to establish which is which. However, it does look like the thing may be working. Is it? Can you connect to an AP and do normal data transfers? If not what is the first thing that does fail?
[quote26qi0oip]one question vern, it normal that my Mac address on monitor mode change to HWaddr 00-C0-CA-19-DB-BD-48-00-00-00-00-00-00-00-00-00?[/quote26qi0oip]
No. But it doesn't look like the attached log includes an attempt to set monitor mode, which I would need to have. I've taken a swag at fixing that (suspect SIOCGIFHWADDR ioctl), so could you apply the attached patch to the latest CVS and and post that log with setting monitor mode included?

If things are still going wrong, also attaching the results of a script session would be good.

Thanks,

panchofmx

24-01-2008 19:38:28

Hi vern,

[quotez21oz81q]However, it does look like the thing may be working. Is it? [/quotez21oz81q]
yes it does, but things are abit mess up. I have not established a stable conecticion yet and i cant any injections. Also i still hav the funny MAC address on monitor.

here is my debugs info
modprobe rt73 debug=31
ifup wlan0
iwconfig wlan0 mode monitor
ifdown wlan0
rmmod rt73

thanks

panchofmx

24-01-2008 20:26:03

How can a attach the script session?

Vern

24-01-2008 20:29:04

Hi panchofmx,

Got your logs. Am perusing same.

Have you tried infrastructure mode? e.g.
[code3a9dnwnb]iwconfig wlan0 mode managed[/code3a9dnwnb]
Thanks,

(edit) Just saw your question re. script: you should be able to attach the script output file to a posting here. Try [quote3a9dnwnb]man script[/quote3a9dnwnb] for more info.

panchofmx

24-01-2008 20:55:08

Vern

25-01-2008 18:04:09

Hi panchofmx,

Thanks for the log info and script output. Unfortunately, I don't see anything going on there to indicate that a connection is being attempted.

Also, the driver doesn't take kindly to changing mode after the interface is brought up, like from monitor to infra. The only really safe way to change mode is to actually unload the module, then reload it.

First question is the funny looking MAC address display on monitor mode still happening?

Next, is there anything - say, in /etc/network/interfaces - to actually configure the device? I don't see anything in the log about setting a key value, encryption mode, etc. Basically, I'd like to see the result of standard bring-up procedures used with the intent of being able to browse, surf the net, etc.

Thanks,

itsbruce

26-01-2008 01:50:57

I'd love to contribute to this thread, because I bought an Ediamax EW7318USG last weekend to put into an old mac mini g4. I found this thread and I have experimented with patches 12 and 13 from this thread, on rt73-cvs-2008012312. The patches have allowed me to scan the nearby APs but I can't connect to them whether I use wpa_supplicant with the ralink driver, rutilt or just typing in iwconfig and iwpriv commands.

What I don't understand is that I have added "options rt73 debug=31" and a syslog line to specifically catch kernel debug messages, but *nothing* appears in the logs apart from the initial lines that always appear when the module loads or detects a card. Doesn't matter if I use insmod and pass the option that way. So I can't even attach debug output and contribute that way. If anybody could say what I might be doing wrong there, I'd be grateful.

Frankly, I'm really regretting the purchase. It took me a day to put mythtv on the mini but I've wasted most of a week on this damned card.

Vern

26-01-2008 19:24:26

itsbruce

26-01-2008 21:43:06

Bah. I was going to say "I read all of those, I'm not stupid." Then I realised I forgot to compile in debug support, so I'll shorten it to "I read all of those."

panchofmx

27-01-2008 23:47:28

Hi vern, Sorry for the late i hav being working lots...

[quote1zrmvxq3]First question is the funny looking MAC address display on monitor mode still happening?
[/quote1zrmvxq3]
Yes it does, i hav being trying to change it but not luck.

[quote1zrmvxq3]say, in /etc/network/interfaces - to actually configure the device? I don't see anything in the log about setting a key value, encryption mode, etc. Basically, I'd like to see the result of standard bring-up procedures used with the intent of being able to browse, surf the net, etc. [/quote1zrmvxq3]

I will attach a debug soon, trying to Connect to the net. ( just i need to find a open AP ) my router at home is not working at the moment...

i will do more testing now.
Thanks.

panchofmx

31-01-2008 22:21:30

Hi vern.

Here is a new debug with /etc/network/interfaces Config

i think im not receiving any beacons.

Let see what you think.
thank

Vern

12-02-2008 16:51:41

Hi panchofmx,

Sorry to leave you hung out to dry so long. Just letting you know this is still on the worklist.

Vern

15-02-2008 22:55:46

Hi panchofmx,

Your logs show that we actually are receiving frames and probe responses, but are not responding to them correctly. It turns out that I neglected to endianize some outgoing frame fields correctly, and have redundantly flipped at least one incoming field.

The attached patch - ppc14.patch.gz - hopefully addresses these. Could you apply it to the very latest CVS and see what happens? If we're lucky, we'll get a little further along.

Thanks for hanging in there, and hopefully we can start moving this along at a little better pace.

Thanks again,

Vern

19-05-2008 21:06:18

Hi panchofmx,

Hah! Thought you could just get back to having a life, eh?

Turns out I inadvertently fixed an endian bug in setting transmit gain, which is now in CVS. The attached patch - ppc15.patch.gz - is basically ppc14.patch.gz applied to the latest CVS with these additions
[list2fib1y8h]Show type and subtype of all received frames when debug is enabled.
Endianize generated probe response and beacon frame fields when running in adhoc mode.[/listu2fib1y8h]
I'm not entirely sure this will now work, so if it doesn't, please attach a copy of your debug log file to a post on this thread.

Thanks,

Vern

14-07-2008 21:28:57

panchofmx (or anybody else)

After getting big endian operations going on the rt2570 legacy driver, I reviewed what I was doing here and have found (hopefully fixed, too) a problem. I was redundantly endianizing some fixed frame fields, with the result that they ended up the wrong way.

So if anyone with a big endian machine cares to try this latest version of the patch, I'll greatly appreciate it.

Thanks,

Vern

23-07-2008 01:55:08

Well, enough is enough. I think the patch will work. Therefore I've put it into CVS.

If you have problems on big endian machines, read the "READ ME BEFORE POSTING" posting, and post your problem description to this thread.

Thanks,