[PATCH v5 13/17] mesh: do not allow pri/sec channel switch

Jouni Malinen j at w1.fi
Tue Jun 12 02:31:39 PDT 2018


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



More information about the Hostap mailing list