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