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
problem happened.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
