rt2x00.serialmonkey.com

Dear rt2x00 wizards,

I have an rt73 USB stick running with hostapd, latest wireless-testing, works almost OK.
I have reported missing beacon TIM bits with buffered frames during powersave with my iPod station here:
http://thread.gmane.org/gmane.linux.ker ... eral/35559

Digging around the source I seem to understand that the necessary infrastructure (i.e. the set_tim() function for rt73usb) is not implemented.
Being clueless about kernel/driver/wireless development, I thought I'd ask whether
a) somebody is working on it, or
b) someone can provide a clue, a code fragment or some starting point for me to do it myself

Thank you,
Stefan.

As far as I know, nobody is working on it.



Sorry, I don't know all steps which might be required to do this correctly.

_________________
Regards,
Ivo van Doorn
Project Administrator
http://rt2x00.serialmonkey.com

Thank you for this info.
Who might know?

I have considerable interest in helping to implement and test this, as rt2x00 based usb sticks seem to be about the only current hardware in this formfactor that can be used as an access point.

Thank you,
Stefan.

If I had time to look into this, I would/should know. But I fear that if you want to implement this you are on your own.
I can help a bit with the implementation details if you give me a clear description where the tim bit should be set (beacon, register, ..?)

_________________
Regards,
Ivo van Doorn
Project Administrator
http://rt2x00.serialmonkey.com

Ok, thanks, I might just try and learn something.

If I understand correctly, the following needs to be done:
- define rt73usb_set_tim(struct ieee80211_hw *hw, struct ieee80211_sta *sta,bool set) in rt73usb.c
- add it to rt73usb_mac80211_ops
- In there, iterate over all active interfaces
- Update beacon for each interface

mac80211 seems to take care of buffered frames accounting and assembling the TIM virtual bitmap for us. If that is true, I might get by with just calling rt2x00queue_update_beacon(), which is however not exported from rt2x00queue.c (and which may or may not be appropriate for this task at all).

Thats all of my wild guesses. Any of this makes the least bit of sense? If so, I'll give it a try.

This sounds like code which belongs in rt2x00lib rather then just the driver.



I think you will be forced to use the update_beacon callback function, since you can't modify a beacon on the fly with the USB drivers, once the beacon has been uploaded to the device it will keep sending that beacon until a new beacon was uploaded.

_________________
Regards,
Ivo van Doorn
Project Administrator
http://rt2x00.serialmonkey.com

Dear colleagues,

I'm also interested in setting up an rt73 usb stick as an AP.
Currently I have the same troubles with D-Link DWA-110 using vanilla kernel 2.6.30 with the patch from Alexandre Becholey (mentioned by Stefan) and hostapd 0.6.9.
Everything else looks working.

Could you please inform about your progress?

P.S. Many thanks to Stefan for identifying the cause of the problem.

Best regards,
Igor

The patch Stefan has produced will be submitted upstream in a couple of hours.

_________________
Regards,
Ivo van Doorn
Project Administrator
http://rt2x00.serialmonkey.com

Hi Ivo,

Unfortunately I don't see any patch at http://git.kernel.org/?p=linux/kernel/g ... ;a=summary.
Am I looking it at a wrong place? Or has something gone wrong with the patch?

Best Regards,
Igor

Ivo hast posted the patch here:
http://thread.gmane.org/gmane.linux.ker ... eral/35789

I've tested the patch on 2.6.30 kernel and have 4 issues.

My AP environment:
1. Linux kernel 2.6.30 with the patch from Alexandre Becholey (mentioned previously) and the set_tim patch.
2. Hostapd 0.6.9.
3. D-Link DWA-110 USB Wi-Fi stick (ID 07d1:3c07 D-Link System Wireless G DWA-110 Adapter).

Clients:
1. Dell notebook with Broadcom Wi-Fi card (Broadcom Corporation BCM4312 802.11b/g (rev 01)) under Ubuntu Linux 9.04.
I use Asus WL-167g USB Wi-Fi stick (ID 0b05:1706 ASUSTek Computer, Inc. WL-167G 802.11g Adapter [ralink]) as the monitor on it.
2. Toshiba G900 PDA under Windows Mobile 6.0.

After I've applied the set_tim patch, beacon frames contain correct TIM information and the notebook connects to the AP and exchanges traffic almost fine, but kernel oops happen from time to time (null pointer dereference) and significant delays (up to 3 seconds) took place.
PDA still encounters a difficulty.
A sniffer showed that the notebook uses "null function" frames to indicate power save transitions, whereas the PDA uses PS Poll frames, but the mac80211 code doesn't receive them (there is no "STA xxx aid y: PS Poll" messages in the log).

Issue 1. The rt73 usb stick is configured to filter out all control frames including the PS Poll one.

Who should configure the filter in a right way: the driver, the mac80211 stack or an application (hostapd)?

I'm not sure of that (I'm not a network programming guru ) and I've assumed that the driver should.
So, I've added following lines in rt2x00mac_configure_filter:
if (rt2x00dev->intf_ap_count)
*total_flags |= FIF_CONTROL;
Note, this is just my "RFC", I'd like to get your comments. Analogous approach I've seen in other wi-fi drivers.

After this step the PDA began exchange traffic, but kernel oops (null pointer dereference) and delays take place also.

Issue 2. Oops in rt73usb_write_beacon.
I've found that the oops are caused by two race conditions:
* In case of two near calls to set_tim: rt2x00lib_beacondone_iter is cleaning the beacon skb, whereas rt73usb_write_beacon is still using it.
* In case of two near updates of beacon: first as the result of set_tim and second as the result of a call from hostapd.

To avoid the race I've done the following:
* Moved cleanup of the beacon skb from rt2x00lib_beacondone_iter into the beginning of rt2x00queue_update_beacon.
* Added a mutex in struct rt2x00_intf, which guards the entire body of rt2x00queue_update_beacon.

Question 2: Should extra cleanup of the beacon skb be added somewhere else?
Or doing that in rt2x00queue_update_beacon is enough?

Issue 3. Delays in traffic exchange are caused by de-synchronization of beacon frames when beacon is being updated to refresh TIM (i.e. two neighbor beacon frames - before and after update - are being transmitted with a wrong time interval in this case).
I think, this is because rt73usb_write_beacon clears not only TXRX_CSR9_BEACON_GEN flags but also TXRX_CSR9_TSF_TICKING one (this is my guess, I have no Ralink documentation).
To keep beacon in sync I've commented out TXRX_CSR9_TSF_TICKING and TXRX_CSR9_TBTT_ENABLE clearing in rt73usb_write_beacon. I don't know, what the second flag is for, but I think, clearing TXRX_CSR9_BEACON_GEN is enough to prevent invalid beacon generation while new beacon is being uploaded.
So, we clear TXRX_CSR9_BEACON_GEN before uploading the beacon data and set it back further in rt73usb_kick_tx_queue.

Issue 4. It is related to the mac80211 implementation or hostapd (I'm not yet sure), but just for completeness of my report.
The station can't reconnect (e.g. the PDA can't reconnect after wake up).

Consider following step-by-step:
1. A station authenticates at AP and exchanges traffic.
2. The station indicates to the AP that it is going to sleep.
3. The station goes to the stand-by mode (not only the wi-fi card, but the device itself).
4. The station wakes up and begins authentication with an Authentication management frame.
This is the behavior of my PDA.

The problem is the mac80211 stack remembers that the station has gone to sleep. So, response frames from hostapd are buffered by mac80211.
The station indicates in the Authentication frame that it isn't sleeping anymore. But the mac80211 stack analyzes sleep/wake transitions in _data_ frames only, but not in management ones. See ieee80211_rx_h_sta_process in net/mac80211/rx.c. A comment there notes: "Ignore doze->wake transitions that are indicated by non-data frames, the standard is unclear here".
As the result, the station never receives the authentication response from the AP.

I think, there may be 2 alternative solutions:
A) In mac80211 implementation: improve ieee80211_rx_h_sta_process - analyze not only data frames, but also management ones. I've tried to add analysis of authentication frames there and it worked in my case. But I'm not sure if it is enough and if it doesn't brake some other functionality.
B) In hostapd: remove the station from the mac80211 stack just after receiving an authentication frame. In my case this approach also works.

I fixed these issues on the 2.6.30 kernel, but the code in Ivo's git repository seems containing these problems too.

What do you think about solutions of these issues, first of all issues 1 - 3?
If the proposed solutions have sense, I could supply a patch for further testing.

As for issue 4, may be you heard about that problem and/or its solution somewhere else?
Please let me know.

Best regards,
Igor

Not sure, I would say mac80211 should be in charge. But if you want to be really sure, you should
ask on the linux-wireless@vger.kernel.org mailinglist.



Will need to see a patch before I can judge that more clearly.
But it is too bad a mutex is needed while a spinlock was already present in the rt2x00_intf structure.



Sounds good, the current code is based on the legacy driver, but perhaps your solution works for the hardware as well.
Might even be applicable for all drivers.



This issue/question belongs on the linux-wireless@vger.kernel.org mailinglist as well, please send it there and you will get an answer from the mac80211 and hostapd developers.

_________________
Regards,
Ivo van Doorn
Project Administrator
http://rt2x00.serialmonkey.com

The patch is here:
http://rt2x00.serialmonkey.com/pipermai ... 00155.html
It is for the kernel 2.6.30, but can be applied to the rt2x00 git kernel tree as well.


The spinlock guards members of the structure. And the mutex guards rt2x00_intf->beacon->skb.
Unfortunately, a spinlock can't be used to serialize access to beacon->skb, because a thread can sleep when calling rt73usb_write_beacon (and perhaps analogous functions for other USB drivers) from rt2x00queue_update_beacon.


The patch for rt73usb is here:
http://rt2x00.serialmonkey.com/pipermai ... 00156.html
It is also for the kernel 2.6.30 and also can be applied to the rt2x00 git kernel tree as well.

The solution has been tested: when only TXRX_CSR9_BEACON_GEN is set to 0 in rt73usb_write_beacon and isn't set to 1 in rt73usb_kick_tx_queue, beacon frames aren't transmitted. And when this flag is set to 1 some time later, beacon frames are transmitted again in sync with previous sequence.

Thanks a lot Igor!

I'm still following this. I'd love to test these patches, but I haven't got my hardware at this time.
As to your Issue #1, I just re-checked that my iPod (firmware version 2.2) uses Null Function frames, not PS Poll ones, so I wouldn't have seen that. Same for all other wireless clients (notebooks) I have access to.
As to everything else, no opinion at this time.

Please continue updating this thread as your solution firms up, I plan on some more testing in about 10 days.

Thank you,
Stefan.

I see this Issue 3 in my capture logs as well.

Question please:
I understand that a station wakes up its receiver for a very short time span just to receive the beacon. So, when the beacon sequences before and after the PS buffering are out of sync relative to each other, the station will miss all beacons after the PS buffering and never wake up to receive the buffered frames, correct? This would explain the application-level timeouts on a TCP connection I am seeing.