Search Linux Wireless

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 23, 2015 at 4:41 PM, Peer, Ilan <ilan.peer@xxxxxxxxx> wrote:
>
>
>> -----Original Message-----
>> From: linux-wireless-owner@xxxxxxxxxxxxxxx [mailto:linux-wireless-
>> owner@xxxxxxxxxxxxxxx] On Behalf Of Janusz Dziedzic
>> Sent: Tuesday, June 23, 2015 11:51
>> To: linux-wireless@xxxxxxxxxxxxxxx
>> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux