Centrino power save problem with HostAP

[Motoyuki OHMORI]

Hi Larry,

I'm newbie of this list, but I'd like to post because 
I have experienced same situation as you mentioned.

When I was using PRISM2 based card with primary firmware 0.3.0 and
station firmware 0.8.0, Ack for Null function was not sent by the
card. Instead, host AP driver seemed to send it in kernel.
However, the Ack was too late for Centrino clients to receive it.

After all, I upgraded station firmware to 1.7.1, then my problem
was fixed.

P.S.
I think that some *BSD_-current_s support power save mode.

Regards,
---
Motoyuki OHMORI <ohmori at dontaku.csce.kyushu-u.ac.jp>
Araki Laboratory, Department of C.S.C.E.,
Graduate School of I.S.E.E., Kyushu University, Japan

On Sun, 14 Sep 2003 18:07:34 -0700
larry.leblanc at shaw.ca wrote:

> This is a follow up to my earlier post...
> 
> I've been having some problems with the interaction between a Centrino laptop and my hostap access point (HostAP 0.0.4, Linksys WPC11 ver 3 card with STA firmware 1.4.9). In particular I am having a problem with power save mode, in which TCP communication seems to grind to a halt. I would expect throughput to drop considerably in power save mode due to the polling nature of the data transfer. However I would not expect everything to grind to a halt unless packets/frames were being lost, and since I am in a lab environment (good signal, close proximity, no interference) that shouldn't happen.
> 
> I am in the process of acquiring an 802.11 sniffer so I can see exactly what is going on but in the meantime I have made use of a demo version to look at what happens when the Centrino tries to negotiate power save mode with the AP. The scenario I tested was:
> 
> - Set Centrino driver to max performance setting so it won't try to go into power save mode.
> - set the sniffer to filter out beacons
> - start tracing - observe the link is idle (other than the filtered beacons)
> - switch the Centrino driver to max battery life mode so it attempts to go into power save mode.
> 
> The resulting trace looks something like this (C = Centrino, A = AP):
> 
> Time (microsec)  Event
> ---------------  ------------------------
>         0        C->A: empty data packet with PS=1
>       888        C->A: empty data packet with PS=1, Retransmit=1
>      1640        C->A: RTS
>      1959        A->C: CTS
>      2383        C->A: empty data packet with PS=1, Retransmit=1
>      3155        A->C: Ack with PS=0
>      4315        A->C: Ack with PS=0, Retransmit=1
>      4975        A->C: Ack with PS=0, Retransmit=1
>      9405        A->C: Ack with PS=0, Retransmit=1
>     14796        A->C: Ack with PS=0, Retransmit=1
>     16311        A->C: Ack with PS=0, Retransmit=1
>     20018        A->C: Ack with PS=0, Retransmit=1
>     20662        A->C: Ack with PS=0, Retransmit=1
>     33221        C->A: empty packet with PS=1
>     34030        C->A: empty packet with PS=1, Retransmit=1
>     34802        C->A: RTS
>     35121        A->C: CTS
>     35546        C->A: empty packet with PS=1, Retransmit=1
>     36254        A->C: Ack with PS=0, Retransmit=1
>     ...<the sequence repeats indefinitely>...
> 
> So, what I take from this is that the Centrino attempts to tell the AP that it is going into power save mode and doesn't get an ack so it retransmits the request. It still doesn't get an ack, so it sends an RTS, gets a CTS and sends its request yet again. Finally an ack comes back, but the PS bit is 0. I'm not sure if this is a problem or not. I'm also not sure why the AP retransmits its Ack 7 times.
> 
> So is this normal? It seems to me that there should be a single packet sent from the Centrino to the AP and one Ack back. Then everything should be quiet until the Centrino decides to poll for data. Based on what I've heard from Intel, the Centrino won't poll for data until it receives a DTIM indicating there is data waiting, so in my test case the link should just go quiet.
> 
> Any help would be greatly appreciated.
> 
> Thanks,
> 
> Larry LeBlanc
> 
> _______________________________________________
> HostAP mailing list
> HostAP at shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>