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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html