On Thu, 2015-07-02 at 17:20 +0530, Krishna Chaitanya wrote: > On Thu, Jul 2, 2015 at 5:09 PM, Johannes Berg < > [email protected]> 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 <[email protected]> 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 <[email protected]> Signed-off-by: Tomas Winkler <[email protected]> Signed-off-by: John W. Linville <[email protected]> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
