Recent patch somewhat breaking p2p

Jouni Malinen j
Tue Aug 7 01:29:32 PDT 2012


On Thu, Jul 26, 2012 at 01:14:03PM +0300, Arik Nemtsov wrote:
> This commit seems to break p2p connections in certain situations:
> 
> commit 579a80982ad07619373876c09cdd60e2afcba5b5
>     P2P: Assume GO Negotiation failed if GO Neg Conf wait times out

> With this patch applied, the GO negotiation sequence effectively
> becomes a one-shot process. Once the GO neg response is transmitted,
> and a go neg confirm frame is not seen in 100ms, the negotiation
> fails.

That is by design and to follow the specification.. That said, the main
reason for the addition was from work on improving connections and
avoiding unnecessarily long waits.

> This is problematic in various scenarios:
> 1. The GO neg response might not have been acked by the peer. The Tx
> status of this frame is currently ignored. In general this is ok -
> since the peer maybe got it but switched the channel before the ack.
> Unfortunately if the peer didn't get it, the negotiation will fail.

This is not by design.. The 100 ms timeout should really be from the ack
frame. There is an assumption in the P2P protocol that GO Negotiation
will be completed as quickly as possible and without doing other
concurrent operations, so GO Negotiation Confirmation frame needs to be
there as soon as possible after GO Negotiation Response frames gets
acknowledged.

> 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?

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.

> 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.

-- 
Jouni Malinen                                            PGP id EFC895FA



More information about the Hostap mailing list