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