[PATCH v5 13/17] mesh: do not allow pri/sec channel switch
greearb at candelatech.com
Tue Jun 12 10:42:14 PDT 2018
On 06/12/2018 02:31 AM, Jouni Malinen wrote:
> 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.
Part of it might be that sometimes a scan doesn't find all APs in range
reliably, but that is just supposition on my part at this point.
>> 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.
In case I find time and interest to code this up, would you like a patch
that checks for any active vdev on any radio, and if it finds such vdev on
the requested primary channel, it would disable the pri/sec switch?
This feature could be disabled by default if you prefer.
>> 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.
Ok, maybe Peter can provide more details on why his case needs it.
If I run into a case where someone needs this feature in a non-test-equipment
setup I'll investigate the details and post my findings. Previously, they
just described a problem and I told them about the pri/sec disable patch in
my hostapd and that fixed the problem. I did not investigate exactly why the
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
More information about the Hostap