bcmdhd: Strange Power Save messages

bcmdhd: Strange Power Save messages

[Gucea Doru]

Hello,

I am analyzing the Power Save algorithm used on a pair of Nexus 5
devices. The devices use the bcmdhd Broadcom driver and are Wi-Fi
Direct connected.

My test is very simple: I send ping packets from the P2P client
towards the P2P GO. Before sending a ping packet the P2P client enters
PS mode (it sends a Null frame with the PWR MGT bit set). A few
miliseconds later, the P2P client sends the ping request message. Once
the ping request is ACKed the P2P client exits the PS mode (it sends a
Null frame with the PWR MGT bit unset) and the P2P GO decides to send
him the ping reply.

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.

For reference, the Wireshark trace can be found at [1].
SSID: DIRECT-35-Android_Intel
WPA pass: JYdrhZp3

[1] https://drive.google.com/file/d/0B5SBH08PU_ChQk95LWpzekh3VU0/view?usp=sharing

Thank you,
Doru

Re: bcmdhd: Strange Power Save messages

[Gucea Doru]

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 :)

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.

Thanks!

Re: bcmdhd: Strange Power Save messages

[Arend van Spriel]

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.

Regards,
Arend

Re: bcmdhd: Strange Power Save messages

[Krishna Chaitanya]

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.
Keeping the STA aside, as far as AP is concerned the STA is still in PS,
so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
Because the STA might be in power-off mode things seem to work.

Re: bcmdhd: Strange Power Save messages

[Gucea Doru]

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? :)

On Sat, Oct 1, 2016 at 3:02 PM, Krishna Chaitanya
<chaitanya.mgit@gmail.com> wrote:
> Keeping the STA aside, as far as AP is concerned the STA is still in PS,
> so it should set the TIM/DTIM bit to 1 before sending out data to the STA.

Not necessarily, see section 10.2.1.6/l from IEEE Std 802.11-2012:
"When an AP is informed that a STA has changed to the Active mode,
then the AP shall send buffered BUs (if any exist) to the STA without
waiting for a PS Poll...."

Re: bcmdhd: Strange Power Save messages

[Krishna Chaitanya]

On Tue, Oct 4, 2016 at 5:09 PM, Gucea Doru <gucea.doru@gmail.com> 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? :)
>
> On Sat, Oct 1, 2016 at 3:02 PM, Krishna Chaitanya
> <chaitanya.mgit@gmail.com> wrote:
>> Keeping the STA aside, as far as AP is concerned the STA is still in PS,
>> so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
>
> Not necessarily, see section 10.2.1.6/l from IEEE Std 802.11-2012:
> "When an AP is informed that a STA has changed to the Active mode,
> then the AP shall send buffered BUs (if any exist) to the STA without
> waiting for a PS Poll...."
Yes, but in this case the STA did not inform AP (as per sniffer captures)?
so AP should set TIM/DTIM...

Re: bcmdhd: Strange Power Save messages

[Gucea Doru]

On Tue, Oct 4, 2016 at 3:37 PM, Krishna Chaitanya
<chaitanya.mgit@gmail.com> wrote:
> On Tue, Oct 4, 2016 at 5:09 PM, Gucea Doru <gucea.doru@gmail.com> 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? :)
>>
>> On Sat, Oct 1, 2016 at 3:02 PM, Krishna Chaitanya
>> <chaitanya.mgit@gmail.com> wrote:
>>> Keeping the STA aside, as far as AP is concerned the STA is still in PS,
>>> so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
>>
>> Not necessarily, see section 10.2.1.6/l from IEEE Std 802.11-2012:
>> "When an AP is informed that a STA has changed to the Active mode,
>> then the AP shall send buffered BUs (if any exist) to the STA without
>> waiting for a PS Poll...."
> Yes, but in this case the STA did not inform AP (as per sniffer captures)?
> so AP should set TIM/DTIM...

The STA _did_ inform the AP.

If you take a look at the packet traces you'll see that the STA sends
a NULL frame saying that it will exit Power Save Mode. According to
the specification the AP can send the buffered frames.

Re: bcmdhd: Strange Power Save messages

[Krishna Chaitanya]

On Tue, Oct 4, 2016 at 11:57 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
> On Tue, Oct 4, 2016 at 3:37 PM, Krishna Chaitanya
> <chaitanya.mgit@gmail.com> wrote:
>> On Tue, Oct 4, 2016 at 5:09 PM, Gucea Doru <gucea.doru@gmail.com> 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? :)
>>>
>>> On Sat, Oct 1, 2016 at 3:02 PM, Krishna Chaitanya
>>> <chaitanya.mgit@gmail.com> wrote:
>>>> Keeping the STA aside, as far as AP is concerned the STA is still in PS,
>>>> so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
>>>
>>> Not necessarily, see section 10.2.1.6/l from IEEE Std 802.11-2012:
>>> "When an AP is informed that a STA has changed to the Active mode,
>>> then the AP shall send buffered BUs (if any exist) to the STA without
>>> waiting for a PS Poll...."
>> Yes, but in this case the STA did not inform AP (as per sniffer captures)?
>> so AP should set TIM/DTIM...
>
> The STA _did_ inform the AP.
>
> If you take a look at the packet traces you'll see that the STA sends
> a NULL frame saying that it will exit Power Save Mode. According to
> the specification the AP can send the buffered frames.
Yeah, sorry i thought AP is sending the ping request.
But still as STA is sending "ping request" with PM=0, the state at
AP should be updated treating STA as active, so sending NULL data +
PM=0 is redundant.





-- 
Thanks,
Regards,
Chaitanya T K.

Re: bcmdhd: Strange Power Save messages

[Arend Van Spriel]

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.

Regards,
Arend

> On Sat, Oct 1, 2016 at 3:02 PM, Krishna Chaitanya
> <chaitanya.mgit@gmail.com> wrote:
>> Keeping the STA aside, as far as AP is concerned the STA is still in PS,
>> so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
> 
> Not necessarily, see section 10.2.1.6/l from IEEE Std 802.11-2012:
> "When an AP is informed that a STA has changed to the Active mode,
> then the AP shall send buffered BUs (if any exist) to the STA without
> waiting for a PS Poll...."
> 

Re: bcmdhd: Strange Power Save messages

[Gucea Doru]

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?

Thank you,
Doru

Re: bcmdhd: Strange Power Save messages

[Arend Van Spriel]

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.

Regards,
Arend

Re: bcmdhd: Strange Power Save messages

[Gucea Doru]

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?

Thank you,
Doru

Re: bcmdhd: Strange Power Save messages

[Arend van Spriel]

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

Re: bcmdhd: Strange Power Save messages

[Gucea Doru]

On Tue, Oct 11, 2016 at 10:12 PM, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> 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.

Do you have a wpa-pwd entry "JYdrhZp3:DIRECT-35-Android_Intel" inside
Edit->Preferences->Protocols->IEEE 802.11->Decryption Keys? I use
Wireshark 2.0.4.

P2P-GO MAC: 66:89:9a:81:0d:95
P2P Client MAC: 66:89:9a:81:0f:20

Thanks,
Doru

Re: bcmdhd: Strange Power Save messages

[Arend van Spriel]

On 12-10-16 16:26, Gucea Doru wrote:
> On Tue, Oct 11, 2016 at 10:12 PM, Arend van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> 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.
> 
> Do you have a wpa-pwd entry "JYdrhZp3:DIRECT-35-Android_Intel" inside
> Edit->Preferences->Protocols->IEEE 802.11->Decryption Keys? I use
> Wireshark 2.0.4.

I see. I only entered the password but not the SSID. The examples showed
SSID was optional. Changed it, but still no luck using 2.2.0.

> P2P-GO MAC: 66:89:9a:81:0d:95
> P2P Client MAC: 66:89:9a:81:0f:20

Actually this was redundant question as it is clear which one sends the
beacon frames. Thanks anyway :-)

Regards,
Arend

> Thanks,
> Doru
>