On Thu, Oct 6, 2016 at 10:25 AM, Arend Van Spriel <arend.vanspriel@xxxxxxxxxxxx> wrote: > On 6-10-2016 10:07, Gucea Doru wrote: >> On Wed, Oct 5, 2016 at 11:12 AM, Arend Van Spriel >> <arend.vanspriel@xxxxxxxxxxxx> wrote: >>> On 4-10-2016 13:39, Gucea Doru wrote: >>>> On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel >>>>> <arend.vanspriel@xxxxxxxxxxxx> wrote: >>>>>> >>>>>> >>>>>> On 29-09-16 13:32, Gucea Doru wrote: >>>>>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.doru@xxxxxxxxx> wrote: >>>>>>>> What is the decision triggering the exit from the PS mode immediately >>>>>>>> after the ping request? I am asking this because 802.11 PS legacy >>>>>>>> specifies that the client should wait for a beacon with TIM set in >>>>>>>> order to wake up: in my case, there is no beacon between the ping >>>>>>>> request message and the Null frame that announces the exit from the PS >>>>>>>> mode. >>>>>>> >>>>>>> >>>>>>> Any help would be highly appreciated :) >>>>>> >>>>>> Actually though I already sent you are reply, but alas here it is. >>>>>> >>>>>> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211 >>>>>> drivers. Regardless your question is more for firmware running on the >>>>>> device. So like the same behavior would be observed when using brcmfmac >>>>>> with same firmware. >>>>>> >>>>>>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA >>>>>>> detects that the bit corresponding to its AID is 1 i the TIM, the STA >>>>>>> shall issue a PS Poll". In my capture there are cases when the STA >>>>>>> exits the PS mode without waiting for a beacon. >>>>>> >>>>>> It is a bit tricky, but the standard does not explicitly say the STA >>>>>> should be in power-save at any other time. So it is difficult to say >>>>>> what event occurred on the STA side to exit PS mode. Also STA means >>>>>> P2P-Client as you say. That means that you have multiple interfaces: >>>>>> regular STA and P2P-Client. So is the STA connected to some other AP or >>>>>> just not connected. wpa_supplicant will do intermittent scan or initiate >>>>>> scheduled scan by which firmware will scan at a certain interval. That >>>>>> is just some things I can come up with and I am sure there are more. >>>> >>>> I agree that there may be some events belonging to the regular STA >>>> interface that could trigger the Null Frame (which includes the exit >>>> from PS Mode). However, I would expect to see some management frames >>>> in the air before/after the Null Packet (e.g.: a Probe request in case >>>> of a scheduled scan). But in my case the trigger for the Null frame >>>> seems to be the ping request packet, the scenario is the same every >>>> time: ping request -> Block ACK -> Null Frame (Wireshark trace >>>> confirms this behavior). >>>> >>>> I thought that you had a power save optimization algorithm that keeps >>>> the card on a few milliseconds just to see if we can have a fast reply >>>> from the peer. Does this ring a bell? :) >>> >>> It does not. That would be implemented in firmware. As said I am working >>> on brcmfmac/brcmsmac. So bcmdhd and firmware are not my expertise. >>> >> >> Arend, could you please redirect me to a Broadcom firmware maintainer? > > Can you please elaborate on your platform, broadcom chipset, and what > version of bcmdhd you are using. > Platform: Nexus 5 running CM13 (Android 6.0.1) Broadcom chipset: BCM4339 Wi-Fi Chipset bcmdhd version:Dongle Host Driver, version 1.88.45 (r) Do you need more information? Thank you, Doru
