> 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)? Indeed, changing the wait time when there's no active GO is not critical. For an active GO it's really painful, since long offchannel activity will result in a notice of absence that can't be cancelled. However, even if there's no active go, there may be still concurrent channel activity which that can be affected by a long offchannel operation - but it is much less critical. I will drop this part. > 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. Since the exact beacon interval is not available in this flow, I'll change it to 150ms instead. Thanks, Andrei > > -- > Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
