rt73 in AP mode: PS frames buffered but missing TIM bit?

[Stefan Steuerwald <salsasepp@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 3107 bytes --]

Dear wireless wizards,

I'd like to ask your help, please.
Summary:
- I suspect a missing TIM bit when using rt73 in AP mode with my
powersaving iPod Touch.
- Despite frames being buffered no TIM bit is getting set (I thought
it should), station stays asleep.
- Symptom is app-level timeout on a TCP connection.

I had asked the list earlier for advice on which USB stick to try for
building an AP (see
http://marc.info/?l=linux-wireless&m=124453569425393&w=2).
I decided to try the rt73. I am aware AP support is broken in the
sense that the chip doesn't seem to know whether certain packets were
successfully transmitted (see patch
http://marc.info/?l=linux-wireless&m=124274853204411&w=2). However, I
am ignorant as to the symptoms of brokenness.

In case you're still reading ;-) ... :

I am using the latest wireless-testing, no further patches.
hostapd v0.6.9
My USB stick is this one (lsusb: ID 07d1:3c03 D-Link System DWL-G122
802.11g Adapter [ralink rt73]).
I am monitoring traffic using a second rt73 usb stick on another computer.

I have a http GET request with a 6 second timeout. The response is
guaranteed to happen after 5 seconds (and I can verify that my server
actually tries to send it in time).
I see the http client timeout after 6 seconds (killing the TCP
connection), with the server's response being sent shortly afterwards.
I suspect the response has actually been sitting there, buffered but
unannounced (see syslog below).
The beacons show no traffic indication, despite the log saying that
frames have been buffered.

Please see the attached capture:
Frame 750: iPod wakes up in preparation for http request
Frame 758: (time 17:40:21.4) http request, response is expected until 17:40:26.4
Frame 764: http request is done, iPod goes to sleep
Frame 822: iPod wakes up (after 6 seconds) because of app-level
timeout (no response received)
Frame 824: iPod kills TCP connection
Frame 826: AP sends http response (too late)

All the beacons in between have no data indicated in TIM (if I read
the TIM structure correctly).
PS debug output actually shows frames being buffered for the iPod at
the expected time (17:40:26) :

Jul  6 17:40:21 xthing kernel: [  133.355499] wlan0: STA
00:22:41:91:8e:96 aid 1 enters power save mode
Jul  6 17:40:26 xthing kernel: [  138.143862] STA 00:22:41:91:8e:96
aid 1: PS buffer (entries before 0)
Jul  6 17:40:26 xthing kernel: [  138.144122] STA 00:22:41:91:8e:96
aid 1: PS buffer (entries before 1)
Jul  6 17:40:26 xthing kernel: [  138.400307] STA 00:22:41:91:8e:96
aid 1: PS buffer (entries before 2)
Jul  6 17:40:27 xthing kernel: [  139.075028] wlan0: STA
00:22:41:91:8e:96 aid 1 exits power save mode
Jul  6 17:40:27 xthing kernel: [  139.075052] wlan0: STA
00:22:41:91:8e:96 aid 1 sending 0 filtered/3 PS frames since STA not
sleeping anymore
Jul  6 17:40:27 xthing kernel: [  139.294764] wlan0: STA
00:22:41:91:8e:96 aid 1 enters power save mode

Questions:
- Am I thinking into the right direction?
- Is this a symptom of the known broken AP support or may there be a fix?

I'd be happy to supply further debug info.

Thank you,
  Stefan.

[-- Attachment #2: ipod-cap-22.cap.bz2 --]
[-- Type: application/x-bzip2, Size: 45786 bytes --]