Re: bcmdhd: Strange Power Save messages

[Arend van Spriel <arend.vanspriel@broadcom.com>]

On 07-10-16 16:33, Gucea Doru wrote:
> On Thu, Oct 6, 2016 at 10:25 AM, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 6-10-2016 10:07, Gucea Doru wrote:
>>> On Wed, Oct 5, 2016 at 11:12 AM, Arend Van Spriel
>>> <arend.vanspriel@broadcom.com> wrote:
>>>> On 4-10-2016 13:39, Gucea Doru wrote:
>>>>> On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
>>>>>> <arend.vanspriel@broadcom.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 29-09-16 13:32, Gucea Doru wrote:
>>>>>>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.doru@gmail.com> 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?

So can you indicate the mac addresses of the two nexus devices and which
one is P2P-GO. I entered the wpa key you mentioned in your initial
email, but my wireshark does not seem to be able to decrypt the packets,
which makes it a bit harder to analyze.

Regards,
Arend