On Tue, Jan 07, 2014 at 05:29:39PM +0100, Johannes Berg wrote: > Is such a limit advertised anywhere? Yes, below.. > I can't think of a reason why a > static limit would be superior to a dynamic one? Maybe if we'd want to > restrict it to 8 to have enough station entries for the other use cases, > but then we could do that in the code as well? It is not really that much of a static vs. dynamic, but more so about being able to advertise this before a station tries to start association (which, for some P2P devices, may mean having to drop another connection). > Anyway, I'm not really objecting much to this, I'm just not convinced > it's sufficient, and if we need a more dynamic mechanism anyway I'm not > sure it really buys us much. Like I said, I think both will be needed. > > 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).. 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. -- Jouni Malinen PGP id EFC895FA -- 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
