* bcmdhd: Strange Power Save messages @ 2016-09-27 9:03 Gucea Doru 2016-09-29 11:32 ` Gucea Doru 0 siblings, 1 reply; 15+ messages in thread From: Gucea Doru @ 2016-09-27 9:03 UTC (permalink / raw) To: Arend van Spriel; +Cc: Andra Paraschiv, linux-wireless 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: bcmdhd: Strange Power Save messages 2016-09-27 9:03 bcmdhd: Strange Power Save messages Gucea Doru @ 2016-09-29 11:32 ` Gucea Doru 2016-10-01 9:22 ` Arend van Spriel 0 siblings, 1 reply; 15+ messages in thread From: Gucea Doru @ 2016-09-29 11:32 UTC (permalink / raw) To: Arend van Spriel; +Cc: Andra Paraschiv, linux-wireless 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! ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: bcmdhd: Strange Power Save messages 2016-09-29 11:32 ` Gucea Doru @ 2016-10-01 9:22 ` Arend van Spriel 2016-10-01 12:02 ` Krishna Chaitanya 0 siblings, 1 reply; 15+ messages in thread From: Arend van Spriel @ 2016-10-01 9:22 UTC (permalink / raw) To: Gucea Doru, Arend van Spriel; +Cc: Andra Paraschiv, linux-wireless 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: bcmdhd: Strange Power Save messages 2016-10-01 9:22 ` Arend van Spriel @ 2016-10-01 12:02 ` Krishna Chaitanya 2016-10-04 11:39 ` Gucea Doru 0 siblings, 1 reply; 15+ messages in thread From: Krishna Chaitanya @ 2016-10-01 12:02 UTC (permalink / raw) To: Arend van Spriel Cc: Gucea Doru, Arend van Spriel, Andra Paraschiv, linux-wireless 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: bcmdhd: Strange Power Save messages 2016-10-01 12:02 ` Krishna Chaitanya @ 2016-10-04 11:39 ` Gucea Doru 2016-10-04 12:37 ` Krishna Chaitanya 2016-10-05 9:12 ` Arend Van Spriel 0 siblings, 2 replies; 15+ messages in thread From: Gucea Doru @ 2016-10-04 11:39 UTC (permalink / raw) To: Krishna Chaitanya Cc: Arend van Spriel, Arend van Spriel, Andra Paraschiv, linux-wireless 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...." ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: bcmdhd: Strange Power Save messages 2016-10-04 11:39 ` Gucea Doru @ 2016-10-04 12:37 ` Krishna Chaitanya 2016-10-04 18:27 ` Gucea Doru 2016-10-05 9:12 ` Arend Van Spriel 1 sibling, 1 reply; 15+ messages in thread From: Krishna Chaitanya @ 2016-10-04 12:37 UTC (permalink / raw) To: Gucea Doru Cc: Arend van Spriel, Arend van Spriel, Andra Paraschiv, linux-wireless 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... ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: bcmdhd: Strange Power Save messages 2016-10-04 12:37 ` Krishna Chaitanya @ 2016-10-04 18:27 ` Gucea Doru 2016-10-04 18:54 ` Krishna Chaitanya 0 siblings, 1 reply; 15+ messages in thread From: Gucea Doru @ 2016-10-04 18:27 UTC (permalink / raw) To: Krishna Chaitanya Cc: Arend van Spriel, Arend van Spriel, Andra Paraschiv, linux-wireless 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: bcmdhd: Strange Power Save messages 2016-10-04 18:27 ` Gucea Doru @ 2016-10-04 18:54 ` Krishna Chaitanya 0 siblings, 0 replies; 15+ messages in thread From: Krishna Chaitanya @ 2016-10-04 18:54 UTC (permalink / raw) To: Gucea Doru Cc: Arend van Spriel, Arend van Spriel, Andra Paraschiv, linux-wireless 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: bcmdhd: Strange Power Save messages 2016-10-04 11:39 ` Gucea Doru 2016-10-04 12:37 ` Krishna Chaitanya @ 2016-10-05 9:12 ` Arend Van Spriel 2016-10-06 8:07 ` Gucea Doru 1 sibling, 1 reply; 15+ messages in thread From: Arend Van Spriel @ 2016-10-05 9:12 UTC (permalink / raw) To: Gucea Doru, Krishna Chaitanya Cc: Arend van Spriel, Andra Paraschiv, linux-wireless 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...." > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: bcmdhd: Strange Power Save messages 2016-10-05 9:12 ` Arend Van Spriel @ 2016-10-06 8:07 ` Gucea Doru 2016-10-06 8:25 ` Arend Van Spriel 0 siblings, 1 reply; 15+ messages in thread From: Gucea Doru @ 2016-10-06 8:07 UTC (permalink / raw) To: Arend Van Spriel Cc: Krishna Chaitanya, Arend van Spriel, Andra Paraschiv, linux-wireless 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: bcmdhd: Strange Power Save messages 2016-10-06 8:07 ` Gucea Doru @ 2016-10-06 8:25 ` Arend Van Spriel 2016-10-07 14:33 ` Gucea Doru 0 siblings, 1 reply; 15+ messages in thread From: Arend Van Spriel @ 2016-10-06 8:25 UTC (permalink / raw) To: Gucea Doru Cc: Krishna Chaitanya, Arend van Spriel, Andra Paraschiv, linux-wireless 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: bcmdhd: Strange Power Save messages 2016-10-06 8:25 ` Arend Van Spriel @ 2016-10-07 14:33 ` Gucea Doru 2016-10-11 19:12 ` Arend van Spriel 0 siblings, 1 reply; 15+ messages in thread From: Gucea Doru @ 2016-10-07 14:33 UTC (permalink / raw) To: Arend Van Spriel Cc: Krishna Chaitanya, Arend van Spriel, Andra Paraschiv, linux-wireless 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: bcmdhd: Strange Power Save messages 2016-10-07 14:33 ` Gucea Doru @ 2016-10-11 19:12 ` Arend van Spriel 2016-10-12 14:26 ` Gucea Doru 0 siblings, 1 reply; 15+ messages in thread From: Arend van Spriel @ 2016-10-11 19:12 UTC (permalink / raw) To: Gucea Doru Cc: Krishna Chaitanya, Arend van Spriel, Andra Paraschiv, linux-wireless 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: bcmdhd: Strange Power Save messages 2016-10-11 19:12 ` Arend van Spriel @ 2016-10-12 14:26 ` Gucea Doru 2016-10-12 18:48 ` Arend van Spriel 0 siblings, 1 reply; 15+ messages in thread From: Gucea Doru @ 2016-10-12 14:26 UTC (permalink / raw) To: Arend van Spriel Cc: Krishna Chaitanya, Arend van Spriel, Andra Paraschiv, linux-wireless 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: bcmdhd: Strange Power Save messages 2016-10-12 14:26 ` Gucea Doru @ 2016-10-12 18:48 ` Arend van Spriel 0 siblings, 0 replies; 15+ messages in thread From: Arend van Spriel @ 2016-10-12 18:48 UTC (permalink / raw) To: Gucea Doru Cc: Krishna Chaitanya, Arend van Spriel, Andra Paraschiv, linux-wireless 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 > ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2016-10-12 18:49 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-09-27 9:03 bcmdhd: Strange Power Save messages Gucea Doru 2016-09-29 11:32 ` Gucea Doru 2016-10-01 9:22 ` Arend van Spriel 2016-10-01 12:02 ` Krishna Chaitanya 2016-10-04 11:39 ` Gucea Doru 2016-10-04 12:37 ` Krishna Chaitanya 2016-10-04 18:27 ` Gucea Doru 2016-10-04 18:54 ` Krishna Chaitanya 2016-10-05 9:12 ` Arend Van Spriel 2016-10-06 8:07 ` Gucea Doru 2016-10-06 8:25 ` Arend Van Spriel 2016-10-07 14:33 ` Gucea Doru 2016-10-11 19:12 ` Arend van Spriel 2016-10-12 14:26 ` Gucea Doru 2016-10-12 18:48 ` Arend van Spriel
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.