On Fri, 2008-11-21 at 09:37 +0100, Stefan Steuerwald wrote: > indeed I overlooked the AID bit in the relevant traffic sequences. > Knowing now what to look for, I can follow what is going on and find > it ok - except for the huge delay in between http request and reply. > Typically, the http request is sent, the iPod goes to sleep, and > several seconds pass (with numerous beacons without any AID bit set), > before we see one or two "traffic for you" beacons, then the iPod > wakes up and gets the reply. Most of the time my app already > timeouted. > > I have checked that my app indeed completes its TCP reply in almost no > time. Mysteriously, the data takes several seconds from boost::asio > write completion until it appears on the air. That's the problem. > > I will go back to square one and the fact that I see different > behaviour in the iPod and my other clients. I will work out the > differences. Will be back in case I come up with more wireless > questions. Well, there could a buffering error in mac80211/p54 too. You could enable verbose power save mode debugging (mac80211 debug kconfig, normally not recommended to turn on); that will then print to the kernel log whenever data for the station is being buffered and the AID bit will be set. Since multiple seconds pass, you should be able to correlate whether or not the AID bit is sent in the beacon right away after mac80211 requests that, or not. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
