- Compiled verbose and powersave debugging into the kernel - Using hostapd 0.6.6 with listen_interval fix - Moved my monitoring device to the machine acting as AP so timestamps are synced between the various logs I see "dropped TX filtered frame" messages in the syslog when at the same time I see wireless packet sequences as described below. Please see the attached logs. Capture: - frame 1158: my client does a http request - frame 1168: iPod goes to sleep - frame 1170: many beacons (with TIM bit set after some time) - frame 1199: iPod wakes up (presumably answering the "traffic for you" beacons) - ??? MISSING DATA ??? - frame 1201: beacons with no TIM bit set (so data got sent or dropped?) - frame 1204: iPod goes to sleep again In the syslog we find at the corresponding time: Nov 24 13:49:11 alix kernel: wlan0: STA 00:22:41:91:8e:96 aid 1 send PS frame since STA not sleeping anymore Nov 24 13:49:11 alix kernel: phy0: dropped TX filtered frame, queue_len=0 PS=0 @135594 Nov 24 13:49:11 alix kernel: wlan0: STA 00:22:41:91:8e:96 aid 1 enters power save mode which may explain why I don't see any data packet on the air. Also attached is hostapd log. This repeats several times until the final "http OK" which only succeeds because I have grossly extended the timeout of my app. However, the delay of several seconds between http request and server response is intended and normal. I have numerous occurrences of this sequence, easy to reproduce. Another thing is the fact that we see 24(!) consecutive beacons with TIM bit set until the iPod finally wakes up. It seems to be lying to the AP, as it advertises a listen_interval of only 10. May this cause the above? In case better debug output is needed or you need me to try out something, please shout. Best regards, Stefan. 2008/11/21 Stefan Steuerwald <salsasepp@xxxxxxxxxxxxxx>: > I got another one to lay out before you for comment: > > Setup: > - XG-601 card (ISL3880) with p54pci driver in AP mode > - iPod Touch 2G (firmware 2.1.1) as the only client > > The client does an http request and waits for an answer. In this case, > the web server answers, but the answer seemingly is never sent over > the air. > > Please see the attached pcap: > - frame 7: http request > - frame 13: iPod goes to sleep > - frame 23: AP beacon indicates traffic for iPod (AID 1 in TIM) > - frame 25: iPod wakes up > - in between: MISSING DATA ??? > - frame 27: AP beacon with no traffic indicated ??? > - frame 29: iPod goes to sleep again > - subsequent frames: repetitions of this, until the TCP connection is closed > > My understanding is that the AP would not indicate any traffic without > actually having some ready to send? Wrong assumption? > > Both the iPod and the monitoring device seem to agree the http reply > is not there. This would be a good reason for the application-level > timeouts I'm seeing. > > Best wishes, > Stefan. > > > See also: previous conversation about app-level timeouts and powersave: > http://article.gmane.org/gmane.linux.kernel.wireless.general/24278 >
Attachment:
ipod-patched-verbose.pcap.gz
Description: GNU Zip compressed data
Attachment:
ipod-patched-verbose-syslog.gz
Description: GNU Zip compressed data
Attachment:
ipod-patched-verbose-hostapd.log.gz
Description: GNU Zip compressed data
