Recent patch somewhat breaking p2p

[Arik Nemtsov]

Reposting the message to the list with mentioned cap file uploaded
elsewhere (otherwise it bounces):

http://wizery.com/arik/galaxy-nexus-p2p-go-neg-confirm-delay.cap

On Tue, Aug 7, 2012 at 12:39 PM, Arik Nemtsov <arik at wizery.com> wrote:
> On Tue, Aug 7, 2012 at 11:29 AM, Jouni Malinen <j at w1.fi> wrote:
>>> 2. Some devices (namely the Galaxy Nexus device) find the 100ms
>>> timeout too harsh. Sometimes 200ms+ go by before a negotiation confirm
>>> is transmitted.
>>
>> This is not good.. It sounds a bit odd to get over 200 ms latency in
>> this and it would be interesting to know where it comes from (that
>> implementation is wpa_supplicant after all for processing and sending
>> the GO Neg frames). Which build was used on Galaxy Nexus?
>
> Standard android JB:
> Android: 4.1.1
> Build Number: JRO03C
> Kernel: 3.0.31-g6fb96c9
>
> The tree they are using is a bit odd, since they don't use upstream
> commits, but gather them up into big patches and push them. A clone of
> their tree is here:
> git://git.omapzoom.org/platform/external/wpa_supplicant_8.git
>
>>
>> Would you by any chance be able to get a debug log from such a device
>> (e.g., logcat with timestamps when wpa_supplicant debug level is set
>> more verbose)? Alternatively, a sniffer trace showing the GO Negotiation
>> frames could be useful. Anyway, I'll see if I can reproduce this with a
>> recent JB build on Galaxy Nexus.
>
> A cap is attached (courtesy of Eyal, also CCed). Note the delay
> between GO Neg Resp (Packet #132) to GO Neg Confirm (Packet #139).
> About 200ms.
>
>>
>>> When this patch is reverted, p2p works well.
>>
>> I don't really want to revert this, but the mechanism needs to be made
>> to take into account the ack frame. If it is also clear that some
>> common deployed devices take more than 100 ms to send to GO Neg Conf,
>> the timeout value may need to be adjusted.
>
> I don't think this will be good enough. We've seen situations where a
> peer switches the channels just after getting a GO Neg Resp. It
> receives the frame, but doesn't send an ack.
> Said peer will now send a GO Neg Confirm, and since the current code
> ignores the Tx status of the GO Neg Resp, everything will be fine. If
> we start considering the ack, and only giving the negotiation a single
> shot, the connection will fail.
>
> Of course there are situations where the peer doesn't send an ack
> since it didn't get the GO Neg Resp packet. So we should still give it
> another try in that case. No amount of delay can address this one.
>
> I don't think having multiple tries would violate the spec. I'm
> thinking about this as a higher layer trying the negotiation procedure
> multiple times. This is also what the deployed version in JB does, so
> at least some peers would cooperate.
>
> Arik