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).
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:
*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.