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

Ben Greear greearb at candelatech.com
Mon Jun 11 15:31:07 PDT 2018


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 at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com




More information about the Hostap mailing list