Hello,
This is my setup:
t1-ath9k:
- AP (2412)
- P2P_GO - go_intent=15 (2462)
ref P2P - intel 7260
ref STA - t2-ath9k
Scenario:
1. setup AP t1-ath9k
2. connect STA (t2-ath9k) to AP
3. run ping STA->AP
4. t1-ath9k - p2p_connect <intel7260> go_intent=15
5. intel7260 - p2p_connect <t1-ath9k>
6. go_negotiation success
7. connect failed ...
8. ...
Sometimes I see such fail on intel7260:
[533519.009978] p2p-wlan3-0: authenticate with 02:03:7f:4e:a0:cd
[533519.009999] p2p-wlan3-0: Allocated STA 02:03:7f:4e:a0:cd
[533519.013667] p2p-wlan3-0: Inserted STA 02:03:7f:4e:a0:cd
[533519.014128] p2p-wlan3-0: direct probe to 02:03:7f:4e:a0:cd (try 1/3)
[533519.217270] p2p-wlan3-0: direct probe to 02:03:7f:4e:a0:cd (try 2/3)
[533519.421349] p2p-wlan3-0: direct probe to 02:03:7f:4e:a0:cd (try 3/3)
[533519.624329] p2p-wlan3-0: authentication with 02:03:7f:4e:a0:cd timed out
[533519.633084] p2p-wlan3-0: Removed STA 02:03:7f:4e:a0:cd
[533519.633325] p2p-wlan3-0: Destroyed STA 02:03:7f:4e:a0:cd
I suspect this is because of P2P_GO NoA?
Who should care about this direct probes tx when GO is not present?
In case we didn't send direct probes - there is no problem and TC
works correctly
BR
Janusz
On 24 June 2015 at 14:20, Peer, Ilan <[email protected]> wrote:
> Hi Janusz,
>
> Any chance you can check if the attached patch fixes the issue you reported?
>
> Thanks in advance,
>
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.
BR
Janusz
> Ilan.
>
>> -----Original Message-----
>> From: [email protected] [mailto:linux-wireless-
>> [email protected]] On Behalf Of Peer, Ilan
>> Sent: Tuesday, June 23, 2015 21:00
>> To: [email protected]
>> Cc: [email protected]; [email protected]
>> Subject: Re: AP + P2P_GO multichan tests with intel7260 as a P2P_CLIENT -
>> direct probe issue
>>
>> -----Original Message-----
>> From: Krishna Chaitanya
>> <[email protected]<mailto:Krishna%20Chaitanya%20%3cchaitanya.m
>> [email protected]%3e>>
>> To: "Peer, Ilan"
>> <[email protected]<mailto:%22Peer,%20Ilan%22%20%[email protected]
>> om%3e>>
>> Cc: Janusz Dziedzic
>> <[email protected]<mailto:Janusz%20Dziedzic%20%3cjanusz.dziedzic
>> @tieto.com%3e>>, [email protected] <linux-
>> [email protected]<mailto:%22linux-
>> [email protected]%22%20%[email protected]%3e>>
>> Subject: Re: AP + P2P_GO multichan tests with intel7260 as a P2P_CLIENT -
>> direct probe issue
>> Date: Tue, 23 Jun 2015 17:34:59 +0530
>>
>>
>>
>> On Tue, Jun 23, 2015 at 5:25 PM, Peer, Ilan
>> <[email protected]<mailto:[email protected]>> wrote:
>> >> >>
>> >> >> I suspect this is because of P2P_GO NoA?
>> >> >> Who should care about this direct probes tx when GO is not present?
>> >> >>
>> >> >> In case we didn't send direct probes - there is no problem and TC
>> >> >> works correctly
>> >> >>
>> >> >
>> >> > Interesting :)
>> >> >
>> >> > Any chance you can provide trace-cmd and sniffer capture?
>> >> >
>> >> > Normally, if we provided the FW with the BSSID information and TSF
>> >> > information for syncing, once the FW hears the 1st beacon with the
>> >> > NoA it should sync on it and not try to attempt to transmit any
>> >> > frames as long as the AP is absent. It might also be related to the
>> >> > fact that the probe requests are sent to broadcast address, but I
>> >> > need to further checks this. Anyway, having some data would help ;)
>> >> >
>> >> Thats exactly the point, if GO is in NoA FW will not transmit but
>> >> mac80211 timed-out for direct probe.
>> >>
>> >> So the question is should mac80211 even send the direct probe in this
>> >> case when GO is in NoA?
>> >
>> > I think that this should be the driver's/FW responsibility, as at this stage
>> mac80211 already configured all the information needed for the driver to
>> sync (assuming it heard a beacon/probe) and in addition mgd_prepare_tx() is
>> called to have the driver/FW prepare for a transmission of the mgmt. frame,
>> including synchronization with the P2P GO power state.
>> Agree, the actual transmission should definitely be in driver/FW but the
>> timeout for such frames are still at mac80211, so unless su it synchronizes the
>> timeouts to GO NoA period this "can" fail depending on the absence period of
>> GO. Default auth_timeout is 200ms.
>>
>>
>> I do not think that mac80211 should handle the synchronization, mostly since
>> it does not get the beacons from the AP we are associated with. As I
>> explained above, this should be the drivers/FW responsibility once they have
>> all the information they require. As such, I think that is expected from the
>> driver/FW to only send the frames when the P2P GO/AP is on the channel.
>>
>> Regards,
>>
>> Ilan.
>>
>>
>>
>> N r y b X ǧv ^ ){.n + { *ޕ , {ay ʇڙ ,j f h z w j:+v w j m zZ+
>> ݢj" ! i
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbGludXgtd2lyZWxlc3Mt
b3duZXJAdmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtd2lyZWxlc3MtDQo+IG93bmVyQHZn
ZXIua2VybmVsLm9yZ10gT24gQmVoYWxmIE9mIEphbnVzeiBEemllZHppYw0KPiBTZW50OiBUdWVz
ZGF5LCBKdW5lIDIzLCAyMDE1IDExOjUxDQo+IFRvOiBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5l
bC5vcmcNCj4gQ2M6IFBlZXIsIElsYW4NCj4gU3ViamVjdDogQVAgKyBQMlBfR08gbXVsdGljaGFu
IHRlc3RzIHdpdGggaW50ZWw3MjYwIGFzIGEgUDJQX0NMSUVOVCAtIGRpcmVjdA0KPiBwcm9iZSBp
c3N1ZQ0KPiANCj4gSGVsbG8sDQo+IA0KPiBUaGlzIGlzIG15IHNldHVwOg0KPiB0MS1hdGg5azoN
Cj4gLSBBUCAoMjQxMikNCj4gLSBQMlBfR08gLSBnb19pbnRlbnQ9MTUgKDI0NjIpDQo+IA0KPiBy
ZWYgUDJQIC0gaW50ZWwgNzI2MA0KPiByZWYgU1RBIC0gdDItYXRoOWsNCj4gDQo+IFNjZW5hcmlv
Og0KPiAxLiBzZXR1cCBBUCB0MS1hdGg5aw0KPiAyLiBjb25uZWN0IFNUQSAodDItYXRoOWspIHRv
IEFQDQo+IDMuIHJ1biBwaW5nIFNUQS0+QVANCj4gNC4gdDEtYXRoOWsgLSBwMnBfY29ubmVjdCA8
aW50ZWw3MjYwPiBnb19pbnRlbnQ9MTUgNS4gaW50ZWw3MjYwIC0NCj4gcDJwX2Nvbm5lY3QgPHQx
LWF0aDlrPiA2LiBnb19uZWdvdGlhdGlvbiBzdWNjZXNzIDcuIGNvbm5lY3QgZmFpbGVkIC4uLg0K
PiA4LiAuLi4NCj4gDQo+IFNvbWV0aW1lcyBJIHNlZSBzdWNoIGZhaWwgb24gaW50ZWw3MjYwOg0K
PiANCj4gWzUzMzUxOS4wMDk5NzhdIHAycC13bGFuMy0wOiBhdXRoZW50aWNhdGUgd2l0aCAwMjow
Mzo3Zjo0ZTphMDpjZA0KPiBbNTMzNTE5LjAwOTk5OV0gcDJwLXdsYW4zLTA6IEFsbG9jYXRlZCBT
VEEgMDI6MDM6N2Y6NGU6YTA6Y2QNCj4gWzUzMzUxOS4wMTM2NjddIHAycC13bGFuMy0wOiBJbnNl
cnRlZCBTVEEgMDI6MDM6N2Y6NGU6YTA6Y2QNCj4gWzUzMzUxOS4wMTQxMjhdIHAycC13bGFuMy0w
OiBkaXJlY3QgcHJvYmUgdG8gMDI6MDM6N2Y6NGU6YTA6Y2QgKHRyeSAxLzMpDQo+IFs1MzM1MTku
MjE3MjcwXSBwMnAtd2xhbjMtMDogZGlyZWN0IHByb2JlIHRvIDAyOjAzOjdmOjRlOmEwOmNkICh0
cnkgMi8zKQ0KPiBbNTMzNTE5LjQyMTM0OV0gcDJwLXdsYW4zLTA6IGRpcmVjdCBwcm9iZSB0byAw
MjowMzo3Zjo0ZTphMDpjZCAodHJ5IDMvMykNCj4gWzUzMzUxOS42MjQzMjldIHAycC13bGFuMy0w
OiBhdXRoZW50aWNhdGlvbiB3aXRoIDAyOjAzOjdmOjRlOmEwOmNkIHRpbWVkDQo+IG91dCBbNTMz
NTE5LjYzMzA4NF0gcDJwLXdsYW4zLTA6IFJlbW92ZWQgU1RBIDAyOjAzOjdmOjRlOmEwOmNkDQo+
IFs1MzM1MTkuNjMzMzI1XSBwMnAtd2xhbjMtMDogRGVzdHJveWVkIFNUQSAwMjowMzo3Zjo0ZTph
MDpjZA0KPiANCj4gSSBzdXNwZWN0IHRoaXMgaXMgYmVjYXVzZSBvZiBQMlBfR08gTm9BPw0KPiBX
aG8gc2hvdWxkIGNhcmUgYWJvdXQgdGhpcyBkaXJlY3QgcHJvYmVzIHR4IHdoZW4gR08gaXMgbm90
IHByZXNlbnQ/DQo+IA0KPiBJbiBjYXNlIHdlIGRpZG4ndCBzZW5kIGRpcmVjdCBwcm9iZXMgLSB0
aGVyZSBpcyBubyBwcm9ibGVtIGFuZCBUQyB3b3Jrcw0KPiBjb3JyZWN0bHkNCj4gDQoNCkludGVy
ZXN0aW5nIDopDQoNCkFueSBjaGFuY2UgeW91IGNhbiBwcm92aWRlIHRyYWNlLWNtZCBhbmQgc25p
ZmZlciBjYXB0dXJlPw0KDQpOb3JtYWxseSwgaWYgd2UgcHJvdmlkZWQgdGhlIEZXIHdpdGggdGhl
IEJTU0lEIGluZm9ybWF0aW9uIGFuZCBUU0YgaW5mb3JtYXRpb24gZm9yIHN5bmNpbmcsIG9uY2Ug
dGhlIEZXIGhlYXJzIHRoZSAxc3QgYmVhY29uIHdpdGggdGhlIE5vQSBpdCBzaG91bGQgc3luYyBv
biBpdCBhbmQgbm90IHRyeSB0byBhdHRlbXB0IHRvIHRyYW5zbWl0IGFueSBmcmFtZXMgYXMgbG9u
ZyBhcyB0aGUgQVAgaXMgYWJzZW50LiBJdCBtaWdodCBhbHNvIGJlIHJlbGF0ZWQgdG8gdGhlIGZh
Y3QgdGhhdCB0aGUgcHJvYmUgcmVxdWVzdHMgYXJlIHNlbnQgdG8gYnJvYWRjYXN0IGFkZHJlc3Ms
IGJ1dCBJIG5lZWQgdG8gZnVydGhlciBjaGVja3MgdGhpcy4gQW55d2F5LCBoYXZpbmcgc29tZSBk
YXRhIHdvdWxkIGhlbHAgOykNCg0KUmVnYXJkcywNCg0KSWxhbi4NCg==
On Tue, Jun 23, 2015 at 5:25 PM, Peer, Ilan <[email protected]> wrote:
>> >>
>> >> I suspect this is because of P2P_GO NoA?
>> >> Who should care about this direct probes tx when GO is not present?
>> >>
>> >> In case we didn't send direct probes - there is no problem and TC
>> >> works correctly
>> >>
>> >
>> > Interesting :)
>> >
>> > Any chance you can provide trace-cmd and sniffer capture?
>> >
>> > Normally, if we provided the FW with the BSSID information and TSF
>> > information for syncing, once the FW hears the 1st beacon with the NoA
>> > it should sync on it and not try to attempt to transmit any frames as
>> > long as the AP is absent. It might also be related to the fact that
>> > the probe requests are sent to broadcast address, but I need to
>> > further checks this. Anyway, having some data would help ;)
>> >
>> Thats exactly the point, if GO is in NoA FW will not transmit but mac80211
>> timed-out for direct probe.
>>
>> So the question is should mac80211 even send the direct probe in this case
>> when GO is in NoA?
>
> I think that this should be the driver's/FW responsibility, as at this stage mac80211 already configured all the information needed for the driver to sync (assuming it heard a beacon/probe) and in addition mgd_prepare_tx() is called to have the driver/FW prepare for a transmission of the mgmt. frame, including synchronization with the P2P GO power state.
Agree, the actual transmission should definitely be in driver/FW
but the timeout for such frames are still at mac80211, so unless
it synchronizes the timeouts to GO NoA period this "can" fail
depending on the absence period of GO. Default auth_timeout is 200ms.
On 27 June 2015 at 23:49, Janusz Dziedzic <[email protected]> wrote:
> On 24 June 2015 at 14:20, Peer, Ilan <[email protected]> wrote:
>> Hi Janusz,
>>
>> Any chance you can check if the attached patch fixes the issue you reported?
>>
>> Thanks in advance,
>>
> 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.
>
Simplest patch I made:
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index e9f36f7..8ceae3d 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -371,6 +371,7 @@ struct ieee80211_mgd_auth_data {
struct cfg80211_bss *bss;
unsigned long timeout;
int tries;
+ bool waiting_probe_resp;
u16 algorithm, expected_transaction;
u8 key[WLAN_KEY_LEN_WEP104];
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 3294666..6f4027e 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3212,13 +3212,14 @@ static void
ieee80211_rx_mgmt_probe_resp(struct ieee80211_sub_if_data *sdata,
ether_addr_equal(mgmt->bssid, ifmgd->associated->bssid))
ieee80211_reset_ap_probe(sdata);
- if (ifmgd->auth_data && !ifmgd->auth_data->bss->proberesp_ies &&
+ if (ifmgd->auth_data && ifmgd->auth_data->waiting_probe_resp &&
ether_addr_equal(mgmt->bssid, ifmgd->auth_data->bss->bssid)) {
/* got probe response, continue with auth */
sdata_info(sdata, "direct probe responded\n");
ifmgd->auth_data->tries = 0;
ifmgd->auth_data->timeout = jiffies;
ifmgd->auth_data->timeout_started = true;
+ ifmgd->auth_data->waiting_probe_resp = false;
run_again(sdata, ifmgd->auth_data->timeout);
}
}
@@ -3727,6 +3728,8 @@ static int ieee80211_probe_auth(struct
ieee80211_sub_if_data *sdata)
auth_data->bss->bssid, auth_data->tries,
IEEE80211_AUTH_MAX_TRIES);
+ auth_data->waiting_probe_resp = true;
+
rcu_read_lock();
ssidie = ieee80211_bss_get_ie(auth_data->bss, WLAN_EID_SSID);
if (!ssidie) {
BR
Janusz
Hi Janusz,
Any chance you can check if the attached patch fixes the issue you reported?
Thanks in advance,
Ilan.
> -----Original Message-----
> From: [email protected] [mailto:linux-wireless-
> [email protected]] On Behalf Of Peer, Ilan
> Sent: Tuesday, June 23, 2015 21:00
> To: [email protected]
> Cc: [email protected]; [email protected]
> Subject: Re: AP + P2P_GO multichan tests with intel7260 as a P2P_CLIENT -
> direct probe issue
>
> -----Original Message-----
> From: Krishna Chaitanya
> <[email protected]<mailto:Krishna%20Chaitanya%20%3cchaitanya.m
> [email protected]%3e>>
> To: "Peer, Ilan"
> <[email protected]<mailto:%22Peer,%20Ilan%22%20%[email protected]
> om%3e>>
> Cc: Janusz Dziedzic
> <[email protected]<mailto:Janusz%20Dziedzic%20%3cjanusz.dziedzic
> @tieto.com%3e>>, [email protected] <linux-
> [email protected]<mailto:%22linux-
> [email protected]%22%20%[email protected]%3e>>
> Subject: Re: AP + P2P_GO multichan tests with intel7260 as a P2P_CLIENT -
> direct probe issue
> Date: Tue, 23 Jun 2015 17:34:59 +0530
>
>
>
> On Tue, Jun 23, 2015 at 5:25 PM, Peer, Ilan
> <[email protected]<mailto:[email protected]>> wrote:
> >> >>
> >> >> I suspect this is because of P2P_GO NoA?
> >> >> Who should care about this direct probes tx when GO is not present?
> >> >>
> >> >> In case we didn't send direct probes - there is no problem and TC
> >> >> works correctly
> >> >>
> >> >
> >> > Interesting :)
> >> >
> >> > Any chance you can provide trace-cmd and sniffer capture?
> >> >
> >> > Normally, if we provided the FW with the BSSID information and TSF
> >> > information for syncing, once the FW hears the 1st beacon with the
> >> > NoA it should sync on it and not try to attempt to transmit any
> >> > frames as long as the AP is absent. It might also be related to the
> >> > fact that the probe requests are sent to broadcast address, but I
> >> > need to further checks this. Anyway, having some data would help ;)
> >> >
> >> Thats exactly the point, if GO is in NoA FW will not transmit but
> >> mac80211 timed-out for direct probe.
> >>
> >> So the question is should mac80211 even send the direct probe in this
> >> case when GO is in NoA?
> >
> > I think that this should be the driver's/FW responsibility, as at this stage
> mac80211 already configured all the information needed for the driver to
> sync (assuming it heard a beacon/probe) and in addition mgd_prepare_tx() is
> called to have the driver/FW prepare for a transmission of the mgmt. frame,
> including synchronization with the P2P GO power state.
> Agree, the actual transmission should definitely be in driver/FW but the
> timeout for such frames are still at mac80211, so unless su it synchronizes the
> timeouts to GO NoA period this "can" fail depending on the absence period of
> GO. Default auth_timeout is 200ms.
>
>
> I do not think that mac80211 should handle the synchronization, mostly since
> it does not get the beacons from the AP we are associated with. As I
> explained above, this should be the drivers/FW responsibility once they have
> all the information they require. As such, I think that is expected from the
> driver/FW to only send the frames when the P2P GO/AP is on the channel.
>
> Regards,
>
> Ilan.
>
>
>
> N r y b X ǧv ^ ){.n + { *ޕ , {ay ʇڙ ,j f h z w j:+v w j m zZ+
> ݢj" ! i
SGkgSmFudXN6LA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGxpbnV4
LXdpcmVsZXNzLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmxpbnV4LXdpcmVsZXNzLQ0K
PiBvd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uIEJlaGFsZiBPZiBKYW51c3ogRHppZWR6aWMNCj4g
U2VudDogU3VuZGF5LCBKdW5lIDI4LCAyMDE1IDAwOjQ5DQo+IFRvOiBQZWVyLCBJbGFuDQo+IENj
OiBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IGNoYWl0YW55YS5tZ2l0QGdtYWlsLmNv
bTsgSm9oYW5uZXMNCj4gQmVyZw0KPiBTdWJqZWN0OiBSZTogQVAgKyBQMlBfR08gbXVsdGljaGFu
IHRlc3RzIHdpdGggaW50ZWw3MjYwIGFzIGEgUDJQX0NMSUVOVCAtDQo+IGRpcmVjdCBwcm9iZSBp
c3N1ZQ0KPiANCj4gT24gMjQgSnVuZSAyMDE1IGF0IDE0OjIwLCBQZWVyLCBJbGFuIDxpbGFuLnBl
ZXJAaW50ZWwuY29tPiB3cm90ZToNCj4gPiBIaSBKYW51c3osDQo+ID4NCj4gPiBBbnkgY2hhbmNl
IHlvdSBjYW4gY2hlY2sgaWYgdGhlIGF0dGFjaGVkIHBhdGNoIGZpeGVzIHRoZSBpc3N1ZSB5b3UN
Cj4gcmVwb3J0ZWQ/DQo+ID4NCj4gPiBUaGFua3MgaW4gYWR2YW5jZSwNCj4gPg0KPiBJIGp1c3Qg
Y2hlY2sgdGhlIG1hYzgwMjExL2NmZzgwMjExIGNvZGUsIGFuZCBJIGFtIG5vdCBzdXJlIHRoaXMg
ZGlyZWN0IHByb2JlDQo+IGNvdWxkIHdvcmsgY29ycmVjdGx5Lg0KPiANCj4gRnVuY3Rpb24gaWVl
ZTgwMjExX3J4X21nbXRfcHJvYmVfcmVzcCgpIGlzIGludGVyZXN0aW5nLg0KPiBTZWVtcyB3ZSBj
YWxsDQo+IGllZWU4MDIxMV9yeF9ic3NfaW5mbygpIC0+IGllZWU4MDIxMV9ic3NfaW5mb191cGRh
dGUgLT4NCj4gY2ZnODAyMTFfaW5mb3JtX2Jzc193aWR0aF9mcmFtZSgpIC0+IGNmZzgwMjExX2Jz
c191cGRhdGUoKSAtPiB0aGlzIGNvdWxkDQo+IHNldCBic3MtPnByb2JlcmVzcF9pZXMgYW5kIGFm
dGVyIHRoYXQgY2hlY2s6DQo+IA0KPiAgICAgICAgIGlmIChpZm1nZC0+YXV0aF9kYXRhICYmICFp
Zm1nZC0+YXV0aF9kYXRhLT5ic3MtPnByb2JlcmVzcF9pZXMgJiYNCj4gICAgICAgICAgICAgZXRo
ZXJfYWRkcl9lcXVhbChtZ210LT5ic3NpZCwgaWZtZ2QtPmF1dGhfZGF0YS0+YnNzLT5ic3NpZCkp
IHsNCj4gICAgICAgICAgICAgICAgIC8qIGdvdCBwcm9iZSByZXNwb25zZSwgY29udGludWUgd2l0
aCBhdXRoICovDQo+ICAgICAgICAgICAgICAgICBzZGF0YV9pbmZvKHNkYXRhLCAiZGlyZWN0IHBy
b2JlIHJlc3BvbmRlZFxuIik7DQo+IA0KPiBTbywgaWZtZ2QtPmF1dGhfZGF0YS0+YnNzLT5wcm9i
ZXJlc3BfaWVzIGNvdWxkIGJlIHNldCBiZWZvcmUgY2hlY2s/DQo+IA0KPiBCVFcsIER1cmluZyBt
eSB0ZXN0cyAobm8gbWF0dGVyIHdoaWNoIGNhcmQgdXNlZCkgSSBuZXZlciBzYXcgdGhpcyBtc2c6
DQo+IHNkYXRhX2luZm8oc2RhdGEsICJkaXJlY3QgcHJvYmUgcmVzcG9uZGVkXG4iKTsgQW5kIGFs
d2F5cyBzYXcgMyBmYWlsZWQgZGlyZWN0DQo+IHByb2Jlcy4NCj4gDQoNCkkgdGhpbmsgdGhhdCB5
b3UgaGF2ZSBhIHBvaW50IGhlcmUuDQoNClJlZ2FyZGxlc3MsIGV2ZW4gd2l0aG91dCB0aGlzLCB0
aGUgYXV0aCB0aW1lciB3b3VsZCBleHBpcmUgYW5kIHdlIHNob3VsZCBiZSBhYmxlIHRvIGNvbnRp
bnVlIHRoZSBhdXRoIGZsb3cgYXMgd2Ugc2hvdWxkIGhhdmUgdGhlIHByb2JlIG5vdy4NCg0KSWxh
bi4NCg0K
PiA+Pg0KPiA+PiBJIHN1c3BlY3QgdGhpcyBpcyBiZWNhdXNlIG9mIFAyUF9HTyBOb0E/DQo+ID4+
IFdobyBzaG91bGQgY2FyZSBhYm91dCB0aGlzIGRpcmVjdCBwcm9iZXMgdHggd2hlbiBHTyBpcyBu
b3QgcHJlc2VudD8NCj4gPj4NCj4gPj4gSW4gY2FzZSB3ZSBkaWRuJ3Qgc2VuZCBkaXJlY3QgcHJv
YmVzIC0gdGhlcmUgaXMgbm8gcHJvYmxlbSBhbmQgVEMNCj4gPj4gd29ya3MgY29ycmVjdGx5DQo+
ID4+DQo+ID4NCj4gPiBJbnRlcmVzdGluZyA6KQ0KPiA+DQo+ID4gQW55IGNoYW5jZSB5b3UgY2Fu
IHByb3ZpZGUgdHJhY2UtY21kIGFuZCBzbmlmZmVyIGNhcHR1cmU/DQo+ID4NCj4gPiBOb3JtYWxs
eSwgaWYgd2UgcHJvdmlkZWQgdGhlIEZXIHdpdGggdGhlIEJTU0lEIGluZm9ybWF0aW9uIGFuZCBU
U0YNCj4gPiBpbmZvcm1hdGlvbiBmb3Igc3luY2luZywgb25jZSB0aGUgRlcgaGVhcnMgdGhlIDFz
dCBiZWFjb24gd2l0aCB0aGUgTm9BDQo+ID4gaXQgc2hvdWxkIHN5bmMgb24gaXQgYW5kIG5vdCB0
cnkgdG8gYXR0ZW1wdCB0byB0cmFuc21pdCBhbnkgZnJhbWVzIGFzDQo+ID4gbG9uZyBhcyB0aGUg
QVAgaXMgYWJzZW50LiBJdCBtaWdodCBhbHNvIGJlIHJlbGF0ZWQgdG8gdGhlIGZhY3QgdGhhdA0K
PiA+IHRoZSBwcm9iZSByZXF1ZXN0cyBhcmUgc2VudCB0byBicm9hZGNhc3QgYWRkcmVzcywgYnV0
IEkgbmVlZCB0bw0KPiA+IGZ1cnRoZXIgY2hlY2tzIHRoaXMuIEFueXdheSwgaGF2aW5nIHNvbWUg
ZGF0YSB3b3VsZCBoZWxwIDspDQo+ID4NCj4gVGhhdHMgZXhhY3RseSB0aGUgcG9pbnQsIGlmIEdP
IGlzIGluIE5vQSBGVyB3aWxsIG5vdCB0cmFuc21pdCBidXQgbWFjODAyMTENCj4gdGltZWQtb3V0
IGZvciBkaXJlY3QgcHJvYmUuDQo+IA0KPiBTbyB0aGUgcXVlc3Rpb24gaXMgc2hvdWxkIG1hYzgw
MjExIGV2ZW4gc2VuZCB0aGUgZGlyZWN0IHByb2JlIGluIHRoaXMgY2FzZQ0KPiB3aGVuIEdPIGlz
IGluIE5vQT8NCg0KSSB0aGluayB0aGF0IHRoaXMgc2hvdWxkIGJlIHRoZSBkcml2ZXIncy9GVyBy
ZXNwb25zaWJpbGl0eSwgYXMgYXQgdGhpcyBzdGFnZSBtYWM4MDIxMSBhbHJlYWR5IGNvbmZpZ3Vy
ZWQgYWxsIHRoZSBpbmZvcm1hdGlvbiBuZWVkZWQgZm9yIHRoZSBkcml2ZXIgdG8gc3luYyAoYXNz
dW1pbmcgaXQgaGVhcmQgYSBiZWFjb24vcHJvYmUpIGFuZCBpbiBhZGRpdGlvbiBtZ2RfcHJlcGFy
ZV90eCgpIGlzIGNhbGxlZCB0byBoYXZlIHRoZSBkcml2ZXIvRlcgcHJlcGFyZSBmb3IgYSB0cmFu
c21pc3Npb24gb2YgdGhlIG1nbXQuIGZyYW1lLCBpbmNsdWRpbmcgc3luY2hyb25pemF0aW9uIHdp
dGggdGhlIFAyUCBHTyBwb3dlciBzdGF0ZS4NCg0KUmVnYXJkcywNCg0KSWxhbi4NCg==
On Tue, Jun 23, 2015 at 4:41 PM, Peer, Ilan <[email protected]> wrote:
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:linux-wireless-
>> [email protected]] On Behalf Of Janusz Dziedzic
>> Sent: Tuesday, June 23, 2015 11:51
>> To: [email protected]
>> Cc: Peer, Ilan
>> Subject: AP + P2P_GO multichan tests with intel7260 as a P2P_CLIENT - direct
>> probe issue
>>
>> Hello,
>>
>> This is my setup:
>> t1-ath9k:
>> - AP (2412)
>> - P2P_GO - go_intent=15 (2462)
>>
>> ref P2P - intel 7260
>> ref STA - t2-ath9k
>>
>> Scenario:
>> 1. setup AP t1-ath9k
>> 2. connect STA (t2-ath9k) to AP
>> 3. run ping STA->AP
>> 4. t1-ath9k - p2p_connect <intel7260> go_intent=15 5. intel7260 -
>> p2p_connect <t1-ath9k> 6. go_negotiation success 7. connect failed ...
>> 8. ...
>>
>> Sometimes I see such fail on intel7260:
>>
>> [533519.009978] p2p-wlan3-0: authenticate with 02:03:7f:4e:a0:cd
>> [533519.009999] p2p-wlan3-0: Allocated STA 02:03:7f:4e:a0:cd
>> [533519.013667] p2p-wlan3-0: Inserted STA 02:03:7f:4e:a0:cd
>> [533519.014128] p2p-wlan3-0: direct probe to 02:03:7f:4e:a0:cd (try 1/3)
>> [533519.217270] p2p-wlan3-0: direct probe to 02:03:7f:4e:a0:cd (try 2/3)
>> [533519.421349] p2p-wlan3-0: direct probe to 02:03:7f:4e:a0:cd (try 3/3)
>> [533519.624329] p2p-wlan3-0: authentication with 02:03:7f:4e:a0:cd timed
>> out [533519.633084] p2p-wlan3-0: Removed STA 02:03:7f:4e:a0:cd
>> [533519.633325] p2p-wlan3-0: Destroyed STA 02:03:7f:4e:a0:cd
>>
>> I suspect this is because of P2P_GO NoA?
>> Who should care about this direct probes tx when GO is not present?
>>
>> In case we didn't send direct probes - there is no problem and TC works
>> correctly
>>
>
> Interesting :)
>
> Any chance you can provide trace-cmd and sniffer capture?
>
> Normally, if we provided the FW with the BSSID information and TSF information for syncing, once the FW hears the 1st beacon with the NoA it should sync on it and not try to attempt to transmit any frames as long as the AP is absent. It might also be related to the fact that the probe requests are sent to broadcast address, but I need to further checks this. Anyway, having some data would help ;)
>
Thats exactly the point, if GO is in NoA FW will not transmit
but mac80211 timed-out for direct probe.
So the question is should mac80211 even send the direct
probe in this case when GO is in NoA?
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEtyaXNobmEgQ2hhaXRhbnlhIDxjaGFp
dGFueWEubWdpdEBnbWFpbC5jb208bWFpbHRvOktyaXNobmElMjBDaGFpdGFueWElMjAlM2NjaGFp
dGFueWEubWdpdEBnbWFpbC5jb20lM2U+Pg0KVG86ICJQZWVyLCBJbGFuIiA8aWxhbi5wZWVyQGlu
dGVsLmNvbTxtYWlsdG86JTIyUGVlciwlMjBJbGFuJTIyJTIwJTNjaWxhbi5wZWVyQGludGVsLmNv
bSUzZT4+DQpDYzogSmFudXN6IER6aWVkemljIDxqYW51c3ouZHppZWR6aWNAdGlldG8uY29tPG1h
aWx0bzpKYW51c3olMjBEemllZHppYyUyMCUzY2phbnVzei5kemllZHppY0B0aWV0by5jb20lM2U+
PiwgbGludXgtd2lyZWxlc3NAdmdlci5rZXJuZWwub3JnIDxsaW51eC13aXJlbGVzc0B2Z2VyLmtl
cm5lbC5vcmc8bWFpbHRvOiUyMmxpbnV4LXdpcmVsZXNzQHZnZXIua2VybmVsLm9yZyUyMiUyMCUz
Y2xpbnV4LXdpcmVsZXNzQHZnZXIua2VybmVsLm9yZyUzZT4+DQpTdWJqZWN0OiBSZTogQVAgKyBQ
MlBfR08gbXVsdGljaGFuIHRlc3RzIHdpdGggaW50ZWw3MjYwIGFzIGEgUDJQX0NMSUVOVCAtIGRp
cmVjdCBwcm9iZSBpc3N1ZQ0KRGF0ZTogVHVlLCAyMyBKdW4gMjAxNSAxNzozNDo1OSArMDUzMA0K
DQoNCg0KT24gVHVlLCBKdW4gMjMsIDIwMTUgYXQgNToyNSBQTSwgUGVlciwgSWxhbiA8aWxhbi5w
ZWVyQGludGVsLmNvbTxtYWlsdG86aWxhbi5wZWVyQGludGVsLmNvbT4+IHdyb3RlOg0KPj4gPj4N
Cj4+ID4+IEkgc3VzcGVjdCB0aGlzIGlzIGJlY2F1c2Ugb2YgUDJQX0dPIE5vQT8NCj4+ID4+IFdo
byBzaG91bGQgY2FyZSBhYm91dCB0aGlzIGRpcmVjdCBwcm9iZXMgdHggd2hlbiBHTyBpcyBub3Qg
cHJlc2VudD8NCj4+ID4+DQo+PiA+PiBJbiBjYXNlIHdlIGRpZG4ndCBzZW5kIGRpcmVjdCBwcm9i
ZXMgLSB0aGVyZSBpcyBubyBwcm9ibGVtIGFuZCBUQw0KPj4gPj4gd29ya3MgY29ycmVjdGx5DQo+
PiA+Pg0KPj4gPg0KPj4gPiBJbnRlcmVzdGluZyA6KQ0KPj4gPg0KPj4gPiBBbnkgY2hhbmNlIHlv
dSBjYW4gcHJvdmlkZSB0cmFjZS1jbWQgYW5kIHNuaWZmZXIgY2FwdHVyZT8NCj4+ID4NCj4+ID4g
Tm9ybWFsbHksIGlmIHdlIHByb3ZpZGVkIHRoZSBGVyB3aXRoIHRoZSBCU1NJRCBpbmZvcm1hdGlv
biBhbmQgVFNGDQo+PiA+IGluZm9ybWF0aW9uIGZvciBzeW5jaW5nLCBvbmNlIHRoZSBGVyBoZWFy
cyB0aGUgMXN0IGJlYWNvbiB3aXRoIHRoZSBOb0ENCj4+ID4gaXQgc2hvdWxkIHN5bmMgb24gaXQg
YW5kIG5vdCB0cnkgdG8gYXR0ZW1wdCB0byB0cmFuc21pdCBhbnkgZnJhbWVzIGFzDQo+PiA+IGxv
bmcgYXMgdGhlIEFQIGlzIGFic2VudC4gSXQgbWlnaHQgYWxzbyBiZSByZWxhdGVkIHRvIHRoZSBm
YWN0IHRoYXQNCj4+ID4gdGhlIHByb2JlIHJlcXVlc3RzIGFyZSBzZW50IHRvIGJyb2FkY2FzdCBh
ZGRyZXNzLCBidXQgSSBuZWVkIHRvDQo+PiA+IGZ1cnRoZXIgY2hlY2tzIHRoaXMuIEFueXdheSwg
aGF2aW5nIHNvbWUgZGF0YSB3b3VsZCBoZWxwIDspDQo+PiA+DQo+PiBUaGF0cyBleGFjdGx5IHRo
ZSBwb2ludCwgaWYgR08gaXMgaW4gTm9BIEZXIHdpbGwgbm90IHRyYW5zbWl0IGJ1dCBtYWM4MDIx
MQ0KPj4gdGltZWQtb3V0IGZvciBkaXJlY3QgcHJvYmUuDQo+Pg0KPj4gU28gdGhlIHF1ZXN0aW9u
IGlzIHNob3VsZCBtYWM4MDIxMSBldmVuIHNlbmQgdGhlIGRpcmVjdCBwcm9iZSBpbiB0aGlzIGNh
c2UNCj4+IHdoZW4gR08gaXMgaW4gTm9BPw0KPg0KPiBJIHRoaW5rIHRoYXQgdGhpcyBzaG91bGQg
YmUgdGhlIGRyaXZlcidzL0ZXIHJlc3BvbnNpYmlsaXR5LCBhcyBhdCB0aGlzIHN0YWdlIG1hYzgw
MjExIGFscmVhZHkgY29uZmlndXJlZCBhbGwgdGhlIGluZm9ybWF0aW9uIG5lZWRlZCBmb3IgdGhl
IGRyaXZlciB0byBzeW5jIChhc3N1bWluZyBpdCBoZWFyZCBhIGJlYWNvbi9wcm9iZSkgYW5kIGlu
IGFkZGl0aW9uIG1nZF9wcmVwYXJlX3R4KCkgaXMgY2FsbGVkIHRvIGhhdmUgdGhlIGRyaXZlci9G
VyBwcmVwYXJlIGZvciBhIHRyYW5zbWlzc2lvbiBvZiB0aGUgbWdtdC4gZnJhbWUsIGluY2x1ZGlu
ZyBzeW5jaHJvbml6YXRpb24gd2l0aCB0aGUgUDJQIEdPIHBvd2VyIHN0YXRlLg0KQWdyZWUsIHRo
ZSBhY3R1YWwgdHJhbnNtaXNzaW9uIHNob3VsZCBkZWZpbml0ZWx5IGJlIGluIGRyaXZlci9GVw0K
YnV0IHRoZSB0aW1lb3V0IGZvciBzdWNoIGZyYW1lcyBhcmUgc3RpbGwgYXQgbWFjODAyMTEsIHNv
IHVubGVzcyBzdQ0KaXQgc3luY2hyb25pemVzIHRoZSB0aW1lb3V0cyB0byBHTyBOb0EgcGVyaW9k
IHRoaXMgImNhbiIgZmFpbA0KZGVwZW5kaW5nIG9uIHRoZSBhYnNlbmNlIHBlcmlvZCBvZiBHTy4g
RGVmYXVsdCBhdXRoX3RpbWVvdXQgaXMgMjAwbXMuDQoNCg0KSSBkbyBub3QgdGhpbmsgdGhhdCBt
YWM4MDIxMSBzaG91bGQgaGFuZGxlIHRoZSBzeW5jaHJvbml6YXRpb24sIG1vc3RseSBzaW5jZSBp
dCBkb2VzIG5vdCAgZ2V0IHRoZSBiZWFjb25zIGZyb20gdGhlIEFQIHdlIGFyZSBhc3NvY2lhdGVk
IHdpdGguICBBcyBJIGV4cGxhaW5lZCBhYm92ZSwgdGhpcyBzaG91bGQgYmUgdGhlIGRyaXZlcnMv
RlcgcmVzcG9uc2liaWxpdHkgb25jZSB0aGV5IGhhdmUgYWxsIHRoZSBpbmZvcm1hdGlvbiB0aGV5
IHJlcXVpcmUuIEFzIHN1Y2gsIEkgdGhpbmsgdGhhdCBpcyBleHBlY3RlZCBmcm9tIHRoZSBkcml2
ZXIvRlcgdG8gb25seSBzZW5kIHRoZSBmcmFtZXMgd2hlbiB0aGUgUDJQIEdPL0FQIGlzIG9uIHRo
ZSBjaGFubmVsLg0KDQpSZWdhcmRzLA0KDQpJbGFuLg0KDQoNCg0K
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.
On 2 July 2015 at 09:27, 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
>
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?
BR
Janusz
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.
On Thu, 2015-07-02 at 17:43 +0530, Krishna Chaitanya wrote:
>
> Thismight still be relevant, if you remember our discussion
> (
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/135533
> )
> a while ago, in a passive scan environment beacon might have
> the latest information than probe response but we end up using
> probe response, so in those cases direct probe helps to
> get the right capabilities.
>
> But i remember your argument about changing AP config is not
> much of a use case :-)
Yeah I still don't think this is much of an issue.
> In an environment where AP config is changed this might be helpful
> else not needed. Given the enterprise wifi deployments using
> controllers auto-changing of AP config based on the environemnt may
> not be far away
I can see the HT/VHT operation changing, and perhaps even channel
jumping, but staying on the channel and changing parameters that can't
actually be updated on the fly seems a bit strange. I'm not even sure
what parameters those would be.
That said, I found at least one issue with removing the direct probe:
If the beacon only has WMM info and not WMM parameters (as permitted by
the WMM spec) then we would disable WMM in ieee80211_mgd_assoc() if we
don't have a probe response. We'd thus have to move validation to after
having received the association response, but at that point it's not
clear to me what we should do if we don't receive good WMM parameters,
then we can't connect without WMM any more.
johannes
On Thu, Jul 2, 2015 at 5:31 PM, Johannes Berg <[email protected]> wrote:
> 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
If the probe response is valid then Janusz's patch make sense.
> 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.
Thismight still be relevant, if you remember our discussion
(http://permalink.gmane.org/gmane.linux.kernel.wireless.general/135533)
a while ago, in a passive scan environment beacon might have
the latest information than probe response but we end up using
probe response, so in those cases direct probe helps to
get the right capabilities.
But i remember your argument about changing AP config is not
much of a use case :-)
> 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?
In an environment where AP config is changed this might be helpful
else not needed. Given the enterprise wifi deployments using controllers
auto-changing of AP config based on the environemnt may not be far away
On Thu, 2015-07-02 at 14:32 +0530, Krishna Chaitanya wrote:
>
> 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.
I don't quite see how that can be an issue, since the RETRY bit
shouldn't be set??
johannes
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
On Thu, Jul 2, 2015 at 5:08 PM, Johannes Berg <[email protected]> wrote:
> On Thu, 2015-07-02 at 14:32 +0530, Krishna Chaitanya wrote:
>>
>> 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.
>
> I don't quite see how that can be an issue, since the RETRY bit
> shouldn't be set??
If retry bit is not set, then it works, but in a noisy channel 2.4GHz
we are seeing high retries causing direct probes to fail 90% of the
time.
The AP in case is Marvel AP RD88W8787 (WFA Testbed).
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
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?
>
But why would it not be set? We do rely on ieee80211_rx_bss_info()
setting it, after all.
johannes