linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Jouni Malinen <j@w1.fi>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC] cfg80211: Advertise maximum associated STAs in AP mode
Date: Tue, 14 Jan 2014 17:32:28 +0100	[thread overview]
Message-ID: <1389717148.32635.18.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <20140107163834.GA9771@w1.fi>

On Tue, 2014-01-07 at 18:38 +0200, Jouni Malinen wrote:

> > > P2P has a P2P Group Limit field which the GO uses to
> > > advertise in Beacon/Probe Response frames to indicate that no more P2P
> > > Clients can join the group. wpa_supplicant supports this functionality,
> > > but currently, requires user (or well, whoever is building the system)
> > > to configure the maximum limit. This is an extra complexity that could
> > > be easily avoided for cases where the driver were able to advertise the
> > > maximum number of associated stations.
> > 
> > Right, indeed. That does indicate a need for such a limit. I wonder if a
> > more dynamic approach (such as an event saying 'I just ran out of
> > space') would be preferable? But it'd obviously be far more complex, so
> > may not be worth it.
> 
> That would allow the specific (and only clearly known today, I guess)
> use case of P2P GO to be addressed. Or well, this would actually require
> even more complexity, since there would also need to be another event to
> indicate that more space become available (another operation stopped)..

Yeah, too much complexity.

> While I'm not against adding this type of functionality, I'm not sure it
> really would be worth the effort and it would be yet another alternative
> since there is already support for maximum station count in
> hostapd/wpa_supplicant even if that currently happens to depend on
> manual configuration. The case of add-sta failing will obviously need to
> be supported cleanly, so we (or well, I at least ;-) are pretty much
> stuck with having at least those two.. Adding a third one sounds a bit
> much.

I agree. I think this patch is fine, but I'd like to see this documented
with the slightly relaxed semantics, i.e. documenting that it is fine in
practice to set this a bit too high where it can't be known or station
entries are shared. Given that is actually OK, of course, which I think
we said it would be.

johannes


      reply	other threads:[~2014-01-14 16:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-06  8:11 [RFC] cfg80211: Advertise maximum associated STAs in AP mode Jouni Malinen
2014-01-07 15:54 ` Johannes Berg
2014-01-07 16:12   ` Jouni Malinen
2014-01-07 16:29     ` Johannes Berg
2014-01-07 16:38       ` Jouni Malinen
2014-01-14 16:32         ` Johannes Berg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1389717148.32635.18.camel@jlt4.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=j@w1.fi \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).