Re: AP + P2P_GO multichan tests with intel7260 as a P2P_CLIENT - direct probe issue

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2015-07-02 at 17:20 +0530, Krishna Chaitanya wrote:
> On Thu, Jul 2, 2015 at 5:09 PM, Johannes Berg <
> johannes@sipsolutions.net> wrote:
> > On Thu, 2015-07-02 at 11:44 +0200, Janusz Dziedzic wrote:
> > > 
> > > > The issue above can probably easily fixed by doing the BSS 
> > > > update
> > > > after
> > > > the "direct probe responded" though, no? Like this:
> > > > https://p.sipsolutions.net/67f9212f0f9f3642.txt
> > > > 
> > > This was my first idea, but in such case I suspect we will send
> > > another direct probe while  bss->proberesp_ies will be not set 
> > > and
> > > ieee80211_probe_auth() will send second probe_req?
> Yes, if the seuqnce number is not set the second probe resp
> also gets dropped.
> 
> > But why would it not be set? We do rely on ieee80211_rx_bss_info()
> > setting it, after all.
> The probe resp is dropped early in the rx_path so this call is not 
> made.

Yeah but that way Janusz's patch makes the whole probe step pointless -
we *want* that information, if it doesn't show up we have another
problem

That said, the original patch introducing this was:

commit 9859b81eaeb8d48563b5fbd90215c0ae606455a3
Author: Ron Rindjunsky <ron.rindjunsky@intel.com>
Date:   Sat Aug 9 03:02:19 2008 +0300

    mac80211: add direct probe before association
    
    This patch adds a direct probe request as first step in the association
    flow if data we have is not up to date. Motivation of this step is to make
    sure that the bss information we have is correct, since last scan could
    have been done a while ago, and beacons do not fully answer this need as
    there are potential differences between them and probe responses (e.g.
    WMM parameter element)
    
    Signed-off-by: Ron Rindjunsky <ron.rindjunsky@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>


This addresses two things

1) potentially stale data (scan)
2) potential differences in IEs between beacons/probe responses

I think the stale data issue is not all that relevant, since it's
unlikely that the BSS actually got torn down and re-created with
entirely different parameters.

The differences in IEs are also debatable - in particular the one that
he gave as an example isn't all that relevant since we take it from the
association response (unless the AP is broken and not including it
there).

HT/VHT information we don't take from the assoc response since that's
also frequently broken, but we now (unlike at the time when that patch
was written) update HT/VHT operation when it changes in the beacon.

Overall I'm thus wondering if this direct probe step really buys us
much today?

johannes