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

[Johannes Berg <johannes@sipsolutions.net>]

On Sat, 2015-06-27 at 23:49 +0200, Janusz Dziedzic wrote:
> 
> I just check the mac80211/cfg80211 code, and I am not sure this 
> direct probe could work correctly.
> 
> Function ieee80211_rx_mgmt_probe_resp() is interesting.
> Seems we call
> ieee80211_rx_bss_info() -> ieee80211_bss_info_update ->
> cfg80211_inform_bss_width_frame() -> cfg80211_bss_update() -> this
> could set bss->proberesp_ies
> and after that check:
> 
>         if (ifmgd->auth_data && !ifmgd->auth_data->bss->proberesp_ies 
> &&
>             ether_addr_equal(mgmt->bssid, ifmgd->auth_data->bss
> ->bssid)) {
>                 /* got probe response, continue with auth */
>                 sdata_info(sdata, "direct probe responded\n");
> 
> So, ifmgd->auth_data->bss->proberesp_ies could be set before check?
> 
> BTW, During my tests (no matter which card used) I never saw this 
> msg:
> sdata_info(sdata, "direct probe responded\n");
> And always saw 3 failed direct probes.
> 
> @Johannes: Is that possible or I miss something.
> 

I agree that this looks like a bug, but I'm not sure it's really all
that relevant?

After all, ieee80211_probe_auth() takes ->proberesp_ies as its only
condition, so even if it doesn't get triggered immediately by the
"direct probe responded", it should send an auth frame the next round,
just the rounds counter wouldn't restart at 0 again.

Perhaps though the changes in cfg80211's BSS management broke this
whole logic? Then again, that's quite a while ago.

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

johannes