[PATCH 4/7] P2P: Allow configuring ctwindow when working as GO
Peer, Ilan
ilan.peer
Tue Feb 24 11:38:17 PST 2015
Hi jouni,
> -----Original Message-----
> From: Jouni Malinen [mailto:j at w1.fi]
> Sent: Sunday, February 22, 2015 18:29
> To: Peer, Ilan
> Cc: Peller, EliadX; hostap at lists.shmoo.com
> Subject: Re: [PATCH 4/7] P2P: Allow configuring ctwindow when working as
> GO
>
> On Sun, Feb 22, 2015 at 03:22:55PM +0000, Peer, Ilan wrote:
> > > From: Jouni Malinen [mailto:j at w1.fi]
> > > > From: Eliad Peller <eliad at wizery.com> Read p2p_go_ctwindow from
> > > > the config file, and pass it to the driver on GO start.
> > > >
> > > > Use p2p_go_ctwindow=9 by default.
> > >
> > > Where does this value of 9 TU come from? The P2P spec states that
> > > CTWindow should be at least 10 TU for the GO to be discoverable, so
> > > making 9 as the default sounds quite strange. I'm replacing this
> > > with 0 (i.e., do not configure CTWindow) to maintain previous
> > > behavior and avoid any potential issues with drivers that might not
> > > be prepared for the value to be configured in the first place. If
> > > you want to use 9 TU for some reason, you can set that in the
> configuration.
> > >
> >
> > After discussing this with requirement owner, he did recommend changing
> to 10.
>
> Is there a specific reason for that value? I'm not planning on changing this
> from 0 (which matches the previous behavior) unless there is strong
> justification for enabling CTWindow configuration on GO by default. 10 TU
> would sound like a way too small default value, i.e., it would make the GO
> pretty difficult to discover since the GO could end up being 90% of the time
> away from the operating channel. That may be justifiable for some use cases
> (and that is now configurable, so that need is covered), but it does not sound
> like something I'd use as a default value.
>
The P2P GO ctwindow patches were introduced in order to better handle some Miracast adapters that did not handle periodic NOA well (multi-channel scenarios). As far as I understand, the CTWindows does not imply that the P2P GO disappears from the medium once the CTWindows ends (and it can't as long as there are active clients), but guarantees a period of time were clients can start a frame exchange (and override periodic NOA).
I'll further check about your concern that this is too small value. I think that this can stay zero for now.
Thanks again.,
Ilan.
More information about the Hostap
mailing list