rt73usb in AP(master) mode

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

mgc8

12-02-2009 16:03:39

Hello,

I am posting this question here because I got conflicting information from various parts of the Net while searching for an answer and it confused me profoundly )

So, what I want is to use a USB dongle with a Ralink chipset to form an Access Point (for example, the Edimax 7318USg which is cheap and easily available).

From what I see, that dongle (and countless others) should be supported with the rt73usb module in the rewritten drivers. Here comes the problem
In the wiki -- http//rt2x00.serialmonkey.com/wiki/ind ... mode_Howto -- it says "Note that this will not work with Ralink's USB chips because we don't know how to get status messages (ACK/FAIL) for sent packets." so I take it AP does not and will not work on that dongle; on the other hand, here -- viewtopic.php?f=5&t=5053&hilit=rt73usb -- there is talk about using hostap on that specific dongle.

So which is it? Is the wiki outdated and the newest drivers have overcome the issue or am I misunderstanding the discussion?

In any case, what is the status of AP support with the USB Ralink dongles? Is it stable enough for use or still in testing? And if so, which chip would offer the best support?

Thank you in advance for any replies and best regards,
Mihnea

IvD

12-02-2009 18:11:23

Both are correct actually, earlier versions of rt2x00 reported always success for all USB frames regardless if they were send or not.
Since that is incorrect behavior it was changed to reporting status unknown. Unfortunately, hostapd doesn't like that and complains about failed frames (and results in the behavior as described in the wiki).

mgc8

12-02-2009 18:41:07

Then I take it AP mode does not work "properly" on rt73usb or any other Ralink chipset for that matter? I mean it works but with errors in transmission? Is this what the lacking ACK/FAIL support means? So if hostapd is patched to work with the current version of the driver, will it work up to a point (slow speed, dropped connections) or will it fail entirely?

Thanks again and sorry if I ask too many questions but I want to understand the situation completely...

IvD

12-02-2009 19:07:43

Then I take it AP mode does not work "properly" on rt73usb or any other Ralink chipset for that matter?[/quote1hdcb3ta]

Only the USB drivers are a problem (same for some drivers for USB hardware from other manufacturers)


I mean it works but with errors in transmission? Is this what the lacking ACK/FAIL support means?
[/quote1hdcb3ta]

What is happening is this
hostapd sends packet to mac80211
mac80211 sends packet to rt73usb
rt73usb uploads packet to device
device reports success for the [b1hdcb3ta]upload[/b1hdcb3ta] and starts transmitting the frame
rt73usb knows the frame was uploaded correctly, but doesn't know the status of the transmission
rt73usb returns status unknown to mac80211
mac80211 returns status unknown to hostapd
hostapd reports error that the packet has failed and denies association.


So if hostapd is patched to work with the current version of the driver, will it work up to a point (slow speed, dropped connections) or will it fail entirely?
[/quote1hdcb3ta]

Hostapd will refuse connections since it thinks the association response has failed.
hostapd developers indicated the problem is with the driver, so there is no patch for hostapd.

The driver developers (not only the rt2x00 developers) have discussed this issue, and there is a plan for a possible fix, but so far nobody implemented it due to lack of time (and the solution is quite complex to get it right).

mgc8

13-02-2009 09:20:32

Thank you for the clarification, I understand the issue now.
Hostapd will refuse connections since it thinks the association response has failed.
hostapd developers indicated the problem is with the driver, so there is no patch for hostapd.[/quote3m73cs6u]
Ok, then talking hypothetically here, if one were to privately patch a copy of r2x00 to revert to the old and incorrect behaviour, would that result in hostapd working (at least partially) or just to more crashes/transmission errors/unusability?
The driver developers (not only the rt2x00 developers) have discussed this issue, and there is a plan for a possible fix, but so far nobody implemented it due to lack of time (and the solution is quite complex to get it right).[/quote3m73cs6u]
Would it be possible to link to an archive of that discussion? I'd be interested in the information... Thanks!

IvD

13-02-2009 15:03:36

Thank you for the clarification, I understand the issue now.
Hostapd will refuse connections since it thinks the association response has failed.
hostapd developers indicated the problem is with the driver, so there is no patch for hostapd.[/quote37medic0]
Ok, then talking hypothetically here, if one were to privately patch a copy of r2x00 to revert to the old and incorrect behaviour, would that result in hostapd working (at least partially) or just to more crashes/transmission errors/unusability?
[/quote37medic0]

You can do that, only you have to keep in mind that the link quality must be good in order to keep the number of failed transmissions from rt73usb low (remember, hostapd will not know if the frame failed or not).


The driver developers (not only the rt2x00 developers) have discussed this issue, and there is a plan for a possible fix, but so far nobody implemented it due to lack of time (and the solution is quite complex to get it right).[/quote37medic0]
Would it be possible to link to an archive of that discussion? I'd be interested in the information... Thanks![/quote37medic0]

You have to check the linux-wireless mailinglist archives.

scifi

14-02-2009 21:43:13

You have to check the linux-wireless mailinglist archives.[/quoteimoteqg3]
I am trying to follow this situation too. I searched the linux-wireless mailinglist archives, and this is what I came up with
[urlimoteqg3]http://thread.gmane.org/gmane.linux.kernel.wireless.general/20675[/urlimoteqg3]
While searching, I saw a post that might indicate that the rate control bug (stuck at lowest rate) might be related to TX status reporting too
[urlimoteqg3]http://article.gmane.org/gmane.linux.kernel.wireless.general/5654[/urlimoteqg3]

n_petr

16-02-2009 23:32:35

I have found one patch too [url275r300t]http://eznemegy.blog.hu/2008/12/14/using_rt2x00_wireless_driver_with_hostapd[/url275r300t], but I was not successful with my rt2500pci [url275r300t]http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=5150[/url275r300t]. May be it helps to you because of rt73-base usb wifi dongle.

IvD

17-02-2009 09:29:04

To quote myself


Only the USB drivers are a problem (same for some drivers for USB hardware from other manufacturers)
[/quote3ds7qy8c]

But as far as I know, rt2500pci doesn't even work in managed mode, so that would explain why it fails in master mode as well.

mgc8

17-02-2009 11:24:02

Ok, thanks to everyone who replied now I have a clear picture of the situation... Seems like implementing the "ACK queue" would certainly be an improvement, however as I see it it's not here yet. I am not going to ask when it will be implemented since I know there are no clear deadlines, however I'll ask this which do you think will be finished faster -- this or rt2800pci support? Thanks again and keep up the nice work!

IvD

17-02-2009 11:46:22

Well I am not working on that ACK issue, I'm not sure who is working on it.
I am working on rt2800pci (actually rt2800usb gets all attention, because if that works, I only need to sort out the PCI specific details for the chipset to get rt2800pci going).
So it is hard to say which will be delivered first.

witukind

15-03-2009 01:19:47

Any updates on this issue?

After reading the relevant discussions on the LKML it seems that this issue is hardly fixable at the driver/kernel level. Someone mentioned that it might be fixable at the firmware level. IvD then said he would email RaLink to ask what they think about it. Any news from RaLink?

IvD

15-03-2009 08:51:23

Well you seem to have midunderstood a few things in this topic.

a) it _is_ fixable in kernel-level but it should be done in mac80211 and not the driver
b) it isn't fixable by changing the firmware
c) I wouldn't contact Ralink about this

The only news is that Alexandre is working on the fix for mac80211.

witukind

15-03-2009 12:40:45

Sorry, I read so much threads that I might have mixed up things. In any event this is *really* good news D Thanks for the update.

Rafaello

12-04-2009 15:15:23

I have set up a rt73 USB dongle in AP mode using kernel 2.6.29 and hostapd 0.6.9. The hostapd is compiled with patch described here[/url27bk8bvv]. It works, but only when I specify MTU no longer than 450.
I have performed some tests with UDP messages sent on MTU 1500. UDP messages up to 422 bytes are delivered successfully. 423-byte messages aren't delivered.
Below is my output of rt2x00_regdump.sh.

kernel 2.6.29
driver rt2500pci
version 2.2.3
compiled Apr 12 2009 164109
dev_flags 0x00000a03
rt chip 0201
rf chip 0003
revision00000004

csr length 93
eeprom length 256
bbp length 64
rf length 5


kernel 2.6.29
driver rt73usb
version 2.2.3
compiled Apr 12 2009 164109
dev_flags 0x000064af
rt chip 1300
rf chip 0002
revision0002573a

csr length 300
eeprom length 128
bbp length 128
rf length 5

Rafaello

14-04-2009 05:38:37

Hmm... It seems to be a problem with hardware. I have checked the USB wireless stick with the same hostapd and the same kernel version on a different machine, and it works correctly. It seems to be a problem with USB device on this machine.

Rafaello

14-04-2009 11:32:30

Hmm... I have found the problem reason. It seems the USB controller does not send the packet data to device when
1. the data is at least 512 byte long and
2. it is not 4-byte aligned

unfortunately the rt73usb driver sends a not 4-byte aligned data, hence the problem appears.
The problematic device is WMU-6000FS router with R8610 SoC. I'm wondering whether other controllers have similar problem.

IvD

14-04-2009 13:01:35

Could you try this patch?
This should fix the 4-byte alignment issue.

Rafaello

15-04-2009 09:38:48

No, the fix does not work at all.
As I understand the fix meaning, it ensures 4-byte alignment of payload in message. But the problem is not with message payload. The problem has nothing to do with message contents at all. The problem is associated with alignment of the whole message in memory, with the value assigned to urb->transfer_buffer, which is not at 4-byte boundary.

One more thing, the rt2x00queue_payload_align seems strange for me. As I understand, it should add/remove space between header and payload. The first memmove (remove L2 padding) is
[code1ykqb3lq] memmove(skb->data, skb->data + align, header_length);[/code1ykqb3lq]
Shouldn't it be
[code1ykqb3lq] memmove(skb->data + align, skb->data, header_length);[/code1ykqb3lq]
? Second memmove (add L2 padding) is
[code1ykqb3lq] memmove(skb->data, skb->data + header_length + align, header_length);[/code1ykqb3lq]
Shouldn't it be
[code1ykqb3lq] memmove(skb->data, skb->data + align, header_length);[/code1ykqb3lq]
?

Rafaello

15-04-2009 12:05:27

One more thing. Program hostapd (0.6.9) with kernel 2.6.29-wl cannot associate encrypted connection (WPA), although with 2.6.29 vanilla kernel works fine. I have noticed also that it complains about extra bytes when running with the "wl" kernel
[quotevfdlci31]IEEE 802.1X 101 bytes from 001b7765fbd2
IEEE 802.1X version=1 type=3 length=95
[bvfdlci31]ignoring 2 extra octets[/bvfdlci31] after IEEE 802.1X packet[/quotevfdlci31]
Maybe this is because of unnecessary invoke of the rt2x00queue_payload_align function in rt2x00lib_rxdone function when l2pad is set to false? When I did remove the function call, the hostapd stopped to complain and has associated the connection.

IvD

15-04-2009 13:25:58

Interesting I'll recheck to code to come up with a smart answer on those memmove suggestions. ;)

About the association bug, that might be caused because the driver expected the 2 bytes padding were present, but it should check the RXDONE flags to see if those bytes are indeed present (rt73usb never sets the flag that those bytes are there).

IvD

15-04-2009 18:17:17

Ok here comes my "smart" answer. ;)

No, the fix does not work at all.
As I understand the fix meaning, it ensures 4-byte alignment of payload in message. But the problem is not with message payload. The problem has nothing to do with message contents at all. The problem is associated with alignment of the whole message in memory, with the value assigned to urb->transfer_buffer, which is not at 4-byte boundary.
[/quoteashs5uvc]

And transfer_buffer aligment comes from the actual skb->data pointer and thus the frame alignment itself.
Perhaps the alignment should not be between the header and payload but should the entire thing be padded (to make sure the TX descriptor is aligned as well).


One more thing, the rt2x00queue_payload_align seems strange for me. As I understand, it should add/remove space between header and payload. The first memmove (remove L2 padding) is
[codeashs5uvc] memmove(skb->data, skb->data + align, header_length);[/codeashs5uvc]
Shouldn't it be
[codeashs5uvc] memmove(skb->data + align, skb->data, header_length);[/codeashs5uvc]
? Second memmove (add L2 padding) is
[codeashs5uvc] memmove(skb->data, skb->data + header_length + align, header_length);[/codeashs5uvc]
Shouldn't it be
[codeashs5uvc] memmove(skb->data, skb->data + align, header_length);[/codeashs5uvc]
?[/quoteashs5uvc]

Both are good catches, could you use the attached patch to see if that works better (I'll also commit it to git)?

Rafaello

16-04-2009 07:31:45

No, it doesn't work better. I think you can forget about the first patch (hw.diff.txt). It causes that device stops to work. Without this, device can at least establish a connection.

Let's forget about the problem. This is a problem with USB device driver rather than the rt73 driver. The USB driver needs a patch against buggy USB controller. Accidentally the problem started to appear in communication with the wireless device.