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
work.
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.
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
