Recent patch somewhat breaking p2p

[Jouni Malinen]

On Tue, Aug 07, 2012 at 12:39:32PM +0300, Arik Nemtsov wrote:
> Standard android JB:
> Android: 4.1.1
> Build Number: JRO03C
> Kernel: 3.0.31-g6fb96c9

OK. I ran my tests using likely the same build (the JB factory image;
JRO03c).

> 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

I have my own set of repositories on top of both hostap.git and
wpa_supplicant_8.git to make more sense of what exactly is done in the
Android releases just to keep my sanity and not need to parse through
the big commits.. ;-)

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

Thanks! I was able to reproduce this both with and without a concurrent
AP connection. This is not exactly good as far as the P2P specification
if concerned and certainly not helpful with the commit
579a80982ad07619373876c09cdd60e2afcba5b5 in hostap.git. This resulted in
100% reproducible failure to complete GO Negotiation for the case where
Nexus was the device sending GO Negotiation Confirmation.

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

I'm not sure I follow. Not getting an ack would mean that we would not
stop at the 100 ms timeout.

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

If the peer does not receive GO Negotiation Response, I would assume it
will likely start new GO Negotiation attempt. What do you mean with
another try? Sending GO Negotiation Response again? It was already
retried at lower layer for multiple times..

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

It is obviously possible to start new GO Negotiation attempts and that
could be done without user interaction. However, I'm not sure whether
any additional transmissions of GO Negotiation Response or Confirmation
frames would really be useful.

As far as the 100 ms timeout is concerned, it looks like that would need
to be increased to 250 ms or so to work at least semi-reliably with
Galaxy Nexus (at least with JB build). This is actually not only for the
new enforced stop-GO-negotiation change, but even for the earlier
implementation of remain-on-channel (or offloaded offchannel TX) wait.
Those are using 200 ms timeout and would likely cause various issues
even without the new change when the peer takes 215 ms or so..

As an initial help for this, I increased the GO Negotiation timeouts in
commit 504a5839ea90cda48aaca69703995df427f060c4. This will hopefully
cover most cases. If someone can easily reproduce failures due to GO
Negotiation timeout (i.e., cases where the peer device would send a
valid next frame in the negotiation after we have stopped waiting), it
would be useful to collect wireless captures showing from such cases to
get better understanding on what kind of behavior is out there in
deployed devices.

-- 
Jouni Malinen                                            PGP id EFC895FA