On Thu, Jul 2, 2015 at 12:57 PM, Johannes Berg
<[email protected]> wrote:
> 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
>
We have also found another issue with direct probe.
Some of the AP's are not setting sequence number in the probe responses
so in case of a retry they are dropped as duplicate by rx_h_check
causing direct probe to fail.
--
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
