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

Ben Greear greearb at candelatech.com
Mon Jun 11 12:27:48 PDT 2018

On 06/11/2018 11:51 AM, Jouni Malinen wrote:
> On Mon, Jun 11, 2018 at 11:23:32AM -0700, Ben Greear wrote:
>> I (and some customers) needed similar behaviour for STA + AP mode in the past, the reason is that
>> if you know for certain (due to user configuration typically) that a station
>> has to communicate with an AP on a certain bandwidth, and you want to run an
>> AP on the same radio, then you cannot have the AP interface using some different center
>> frequency.  Think police cruisers that need to provide hot-spot sometimes and also
>> use an STA vdev to connect to head-quarter's AP when in the parking-lot.
> 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.

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

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.

>> With MESH, if you are trying to join some existing mesh on a certain
>> frequency, it cannot physically work if somehow the hostapd/supplicant decides to use
>> a different frequency, right?
> Sure, but this is similarly sounding like trying to hide the real issue
> and go for something hardcoded rather than dynamically addressing needs
> when the peers changes. When starting up a mesh BSS in an environment
> where there is already an operating mesh BSS, matching pri/sec channels
> with that existing network is obviously the correct thing to do. If
> there is no mesh BSS in radio range, I find it much more difficult to
> understand why there would be an exception for co-existence
> requirements. The real issue comes when two originally disjoint segments
> of a mesh BSS move to be within radio range of each other. That said,
> pri/sec channel selection is not the only or even worse issue here since
> the devices may be using completely different frequency ranges.

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.


Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

More information about the Hostap mailing list