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:
ipod-cap-22.cap.bz2
Description: BZip2 compressed data
