RE: [PATCH] P2P: Make P2P invitation flow less aggressive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux