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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/11/2018 02:23 PM, Jouni Malinen wrote:
On Mon, Jun 11, 2018 at 12:27:48PM -0700, Ben Greear wrote:
On 06/11/2018 11:51 AM, Jouni Malinen wrote:
This is not about center frequency, but about matching primary
channels. Switching pri/sec channels does not really change the
frequency range. I'd assume it would be possible for the AP interface to
go through channel switch when the STA interface needs to move (or
connect initially), but sure, it may be simpler to hardcode channels and
pri/sec assignment. That last part, though, is likely to be
non-compliant with the standard requirements for co-existence..

As far as I can tell, if a radio uses HT40- for an STA, it cannot simultaneously
run HT40+ in AP mode on the same radio.

That sounds quite likely for many radio designs.

In case you must connect an STA to an AP, that STA will negotiate a proper
center freq and primary channel.  If you then want to start an AP vdev on the same
radio, you must force it to not do pri/sec switch in order to have it reliably
work.

Sure, no issues here; there's obviously an existing AP with the specific
pri/sec selection in radio range, so the co-existence rules allow the
local AP to be started with same parameters. This should not need any
additional changes.

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?

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)?

Another use case we have for test equipment:  If you want to run one vdev in
HT20 mode and another in HT40 or HT80, then you must force the hostapds to all
use the same primary channel as the HT20 AP or it will fail to work.

For test tools, it may be acceptable to be non-compliant with the
standard.

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 :)

Thanks,
Ben


I don't know enough about mesh or Peter's use to usefully comment more on
this, but it sounds a lot like the issue I had with STA + AP.  I think you could,
for instance, run MESH on one vdev and an AP on another in the same radio
and end up with similar issues to what I had with STA + AP.

The commit messages certainly so not seem to point to any extra
constraints from virtual interfaces on the local device. What I really
want to see here is the exact use case that is being addressed so that I
can review whether it makes sense to provide exceptions to certain rules
or whether there are better ways of solving the issue (e.g., that STA+AP
example case using CSA on the AP).




--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux