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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
