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.
With Ivo's help, we have a tested patch. Ivo will take care of
submitting it and extending it to all rt2x00 drivers.
I love it when things just work out!
Thank you,
Stefan.
2009/7/9 Ivo Van Doorn <[email protected]>:
> On Thu, Jul 9, 2009 at 7:30 AM, Stefan
> Steuerwald<[email protected]> wrote:
>>> > Sounds like a driver problem, it must not be reacting to set_tim()
>>> > properly.
>>> >
>>> > johannes
>>>
>>> Looking at rt73usb.c:2242, there isn't any initializer for .set_tim .
>>> Plausible explanation.
>>> It may be totally beyond me to just implement it. Let me find someone
>>> to ask nicely ;-) ...
>>
>> I have an experimental patch working (sent for review to the rt2x00
>> mailing list).
>> I will report back here.
>
> Are you sure you've send it already? Because I haven't seen anything yet.
>
> Ivo
>
On Thu, Jul 9, 2009 at 7:30 AM, Stefan
Steuerwald<[email protected]> wrote:
>> > Sounds like a driver problem, it must not be reacting to set_tim()
>> > properly.
>> >
>> > johannes
>>
>> Looking at rt73usb.c:2242, there isn't any initializer for .set_tim .
>> Plausible explanation.
>> It may be totally beyond me to just implement it. Let me find someone
>> to ask nicely ;-) ...
>
> I have an experimental patch working (sent for review to the rt2x00
> mailing list).
> I will report back here.
Are you sure you've send it already? Because I haven't seen anything yet.
Ivo
> > Sounds like a driver problem, it must not be reacting to set_tim()
> > properly.
> >
> > johannes
>
> Looking at rt73usb.c:2242, there isn't any initializer for .set_tim .
> Plausible explanation.
> It may be totally beyond me to just implement it. Let me find someone
> to ask nicely ;-) ...
I have an experimental patch working (sent for review to the rt2x00
mailing list).
I will report back here.
Stefan.
On Mon, 2009-07-06 at 19:06 +0200, Stefan Steuerwald wrote:
> 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.
Sounds like a driver problem, it must not be reacting to set_tim()
properly.
johannes
2009/7/6 Johannes Berg <[email protected]>
>
> On Mon, 2009-07-06 at 19:06 +0200, Stefan Steuerwald wrote:
> >
> > 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.
>
> Sounds like a driver problem, it must not be reacting to set_tim()
> properly.
>
> johannes
Looking at rt73usb.c:2242, there isn't any initializer for .set_tim .
Plausible explanation.
It may be totally beyond me to just implement it. Let me find someone
to ask nicely ;-) ...