On Mon, Jun 11, 2018 at 03:31:07PM -0700, Ben Greear wrote: > Other random APs could be in range which the user has no control over, > and those might be on conflicting primary channels. Couldn't that cause > a chance that the pri/sec logic would chose the wrong primary channel? It shouldn't since the switch pri/sec channel requirement would apply only if there is no existing BSS using the same setting. If things are already inconsistent, there would not be much point to switch channels. > Maybe hostapd should query to find vdevs on the radio and dynamically > disable pri/sec selection if another vdev is active (and use the primary > channel that the active vdev is using)? That parenthetical part is important, but sure, if there is a local or remote BSS with pri/sec selection that matches the new configuration, there should not be need to switch the new configuration even if other BSSs in range have different choice. This is not even limited to virtual interfaces of the same radio, but any local radio. > If there is a legit case to get the patch upstream, that makes my life > a small bit simpler, but I cannot think of a real use case for having multiple > vdev APs on different frequencies, so I'm hoping there are other use cases :) I don't really justification for this in more common use cases since the default behavior should always work fine without needing such exceptions to allow hardcoded skipping of pri/sec channel switch. It is possible that something is missing from the current implementation on automatically doing this correctly and that can obviously be fixed, but this should work just fine as long as you start the virtual interfaces in the sequence that selects the 20 MHz channel to be used as the primary channel first. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
