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.. > 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. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
