[PATCH] P2P: Make P2P invitation flow less aggressive

[Jouni Malinen]

On Sun, Dec 04, 2022 at 08:02:28AM +0000, Otcheretianski, Andrei wrote:
> > > In order to not interfere with other channel activities, decrease the
> > > wait time to 200ms, or to 100ms in case of an active P2P GO on the
> > > system.
> > 
> > This sounds like a risky change to do at this point in time. Why would this be
> > needed now more than ten years after those earlier values had been
> > selected and having been tested for interoperability issues over years?
> 
> We got a relatively recent customer bug in a flow inviting a non-responding client with an active GO, which resulted in missing multiple beacon transmissions due to GO being too long out of its channel and eventual disconnection.
> I also wasn't confident about this change originally.. Would it be more acceptable to make these timeouts configurable, while keeping the original values as defaults?

I don't really like to force upper layer components or users to be
responsible for configuring this type of things to make something work
while potentially breaking something else..

Why is the wait time dropped for both cases of active GO (which I can
understand) and no other parallel operations (which seems quite separate
and unnecessary)? I don't think you can avoid missing a Beacon frame
transmission on another channels without low level synchronization
somewhere at the firmware/hardware level to jump between channels.. I
guess making the active P2P GO case use something like 1.5 times the
beacon interval might be justifiable so that it would hopefully not skip
more than two Beacon frames in a row.

-- 
Jouni Malinen                                            PGP id EFC895FA