Return-path: Received: from mail-pa0-f43.google.com ([209.85.220.43]:35080 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750807AbcJEJMV (ORCPT ); Wed, 5 Oct 2016 05:12:21 -0400 Received: by mail-pa0-f43.google.com with SMTP id ik13so29462867pac.2 for ; Wed, 05 Oct 2016 02:12:21 -0700 (PDT) Subject: Re: bcmdhd: Strange Power Save messages To: Gucea Doru , Krishna Chaitanya References: Cc: Arend van Spriel , Andra Paraschiv , linux-wireless From: Arend Van Spriel Message-ID: (sfid-20161005_111226_222732_942ACBFF) Date: Wed, 5 Oct 2016 11:12:17 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 4-10-2016 13:39, Gucea Doru wrote: > On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel >> wrote: >>> >>> >>> On 29-09-16 13:32, Gucea Doru wrote: >>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru 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 > 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...." >