| Message ID | 7d3d323f05a7627d073bcc69de94ef788e88f911.1527629631.git.peter.oh@bowerswilkins.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | mesh: enable DFS channels in mesh mode | expand |
On Tue, May 29, 2018 at 02:39:17PM -0700, peter.oh@bowerswilkins.com wrote: > We don't want mesh to switch the channel from primary to secondary, > since mesh points are not able to join each other in that case. > diff --git a/wpa_supplicant/mesh.c b/wpa_supplicant/mesh.c > @@ -336,7 +336,10 @@ static int wpa_supplicant_mesh_init(struct wpa_supplicant *wpa_s, > - > + /* Do not allow primary/secondary channel switch in mesh mode, > + * since mesh is not able to establish a physical link for it > + */ > + conf->no_pri_sec_switch = 1; What do you mean with "a physical link"? Physical?
On 05/31/2018 02:07 AM, Jouni Malinen wrote: > On Tue, May 29, 2018 at 02:39:17PM -0700, peter.oh@bowerswilkins.com wrote: >> We don't want mesh to switch the channel from primary to secondary, >> since mesh points are not able to join each other in that case. >> diff --git a/wpa_supplicant/mesh.c b/wpa_supplicant/mesh.c >> @@ -336,7 +336,10 @@ static int wpa_supplicant_mesh_init(struct wpa_supplicant *wpa_s, >> - >> + /* Do not allow primary/secondary channel switch in mesh mode, >> + * since mesh is not able to establish a physical link for it >> + */ >> + conf->no_pri_sec_switch = 1; > What do you mean with "a physical link"? Physical? > Yes, Physical. the comment will be updated like this in the next revision. + /* Do not allow primary/secondary channel switch in mesh mode, + * since mesh is only able to establish Physical link with peers + * on the same channel. + */
On Thu, May 31, 2018 at 04:19:21PM -0700, Peter Oh wrote: > > > On 05/31/2018 02:07 AM, Jouni Malinen wrote: > >On Tue, May 29, 2018 at 02:39:17PM -0700, peter.oh@bowerswilkins.com wrote: > >>We don't want mesh to switch the channel from primary to secondary, > >>since mesh points are not able to join each other in that case. > >>diff --git a/wpa_supplicant/mesh.c b/wpa_supplicant/mesh.c > >>@@ -336,7 +336,10 @@ static int wpa_supplicant_mesh_init(struct wpa_supplicant *wpa_s, > >>- > >>+ /* Do not allow primary/secondary channel switch in mesh mode, > >>+ * since mesh is not able to establish a physical link for it > >>+ */ > >>+ conf->no_pri_sec_switch = 1; > >What do you mean with "a physical link"? Physical? > > > Yes, Physical. the comment will be updated like this in the next revision. > + /* Do not allow primary/secondary channel switch in mesh mode, > + * since mesh is only able to establish Physical link with peers > + * on the same channel. > + */ What do you mean with "Physical" in this context? Where is physical link (or "Physical link"?!) defined? There is no such thing in the IEEE 802.11 standard and it would be better to use terms that people can understand easily. Maybe just delete "physical"? That said, this comment is still quite confusing even if "Physical" were removed. Are you trying to say that a link cannot be established if different primary channel is used? ".. only able to establishing a link with peers using the same primary channel"?
On 06/11/2018 09:55 AM, Jouni Malinen wrote: > On Thu, May 31, 2018 at 04:19:21PM -0700, Peter Oh wrote: >> >> >> On 05/31/2018 02:07 AM, Jouni Malinen wrote: >>> On Tue, May 29, 2018 at 02:39:17PM -0700, peter.oh@bowerswilkins.com wrote: >>>> We don't want mesh to switch the channel from primary to secondary, >>>> since mesh points are not able to join each other in that case. >>>> diff --git a/wpa_supplicant/mesh.c b/wpa_supplicant/mesh.c >>>> @@ -336,7 +336,10 @@ static int wpa_supplicant_mesh_init(struct wpa_supplicant *wpa_s, >>>> - >>>> + /* Do not allow primary/secondary channel switch in mesh mode, >>>> + * since mesh is not able to establish a physical link for it >>>> + */ >>>> + conf->no_pri_sec_switch = 1; >>> What do you mean with "a physical link"? Physical? >>> >> Yes, Physical. the comment will be updated like this in the next revision. >> + /* Do not allow primary/secondary channel switch in mesh mode, >> + * since mesh is only able to establish Physical link with peers >> + * on the same channel. >> + */ > > What do you mean with "Physical" in this context? Where is physical > link (or "Physical link"?!) defined? There is no such thing in the IEEE > 802.11 standard and it would be better to use terms that people can > understand easily. Maybe just delete "physical"? > > That said, this comment is still quite confusing even if "Physical" were > removed. Are you trying to say that a link cannot be established if > different primary channel is used? ".. only able to establishing a link > with peers using the same primary channel"? 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. 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? Thanks, Ben
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.
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
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. > 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. > 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).
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). > >
On Mon, Jun 11, 2018 at 03:31:07PM -0700, Ben Greear wrote: > 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? It shouldn't since the switch pri/sec channel requirement would apply only if there is no existing BSS using the same setting. If things are already inconsistent, there would not be much point to switch channels. > 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)? That parenthetical part is important, but sure, if there is a local or remote BSS with pri/sec selection that matches the new configuration, there should not be need to switch the new configuration even if other BSSs in range have different choice. This is not even limited to virtual interfaces of the same radio, but any local radio. > 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 :) I don't really justification for this in more common use cases since the default behavior should always work fine without needing such exceptions to allow hardcoded skipping of pri/sec channel switch. It is possible that something is missing from the current implementation on automatically doing this correctly and that can obviously be fixed, but this should work just fine as long as you start the virtual interfaces in the sequence that selects the 20 MHz channel to be used as the primary channel first.
On 06/12/2018 02:31 AM, Jouni Malinen wrote: > On Mon, Jun 11, 2018 at 03:31:07PM -0700, Ben Greear wrote: >> 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? > > It shouldn't since the switch pri/sec channel requirement would apply > only if there is no existing BSS using the same setting. If things are > already inconsistent, there would not be much point to switch channels. Part of it might be that sometimes a scan doesn't find all APs in range reliably, but that is just supposition on my part at this point. > >> 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)? > > That parenthetical part is important, but sure, if there is a local or > remote BSS with pri/sec selection that matches the new configuration, > there should not be need to switch the new configuration even if other > BSSs in range have different choice. This is not even limited to virtual > interfaces of the same radio, but any local radio. In case I find time and interest to code this up, would you like a patch that checks for any active vdev on any radio, and if it finds such vdev on the requested primary channel, it would disable the pri/sec switch? This feature could be disabled by default if you prefer. >> 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 :) > > I don't really justification for this in more common use cases since the > default behavior should always work fine without needing such exceptions > to allow hardcoded skipping of pri/sec channel switch. It is possible > that something is missing from the current implementation on > automatically doing this correctly and that can obviously be fixed, but > this should work just fine as long as you start the virtual interfaces > in the sequence that selects the 20 MHz channel to be used as the > primary channel first. Ok, maybe Peter can provide more details on why his case needs it. If I run into a case where someone needs this feature in a non-test-equipment setup I'll investigate the details and post my findings. Previously, they just described a problem and I told them about the pri/sec disable patch in my hostapd and that fixed the problem. I did not investigate exactly why the problem happened. Thanks, Ben
On 06/12/2018 02:31 AM, Jouni Malinen wrote: > I don't really justification for this in more common use cases since the > default behavior should always work fine without needing such exceptions > to allow hardcoded skipping of pri/sec channel switch. It is possible > that something is missing from the current implementation on > automatically doing this correctly and that can obviously be fixed, but > this should work just fine as long as you start the virtual interfaces > in the sequence that selects the 20 MHz channel to be used as the > primary channel first. I understood your opinion. This exception may be not the right approach and could hide an existing issue (or bug if exist). But my patch series is to make mesh point able to use DFS channels, not to fix existing issue, so I'll remove this patch from the series in next revision. We could discuss this exception later separately about why we need this exception and what to improve to avoid such exception. Thanks, Peter
diff --git a/wpa_supplicant/mesh.c b/wpa_supplicant/mesh.c index 4ff732b..90f3b1a 100644 --- a/wpa_supplicant/mesh.c +++ b/wpa_supplicant/mesh.c @@ -336,7 +336,10 @@ static int wpa_supplicant_mesh_init(struct wpa_supplicant *wpa_s, rate_len * sizeof(int)); conf->basic_rates[rate_len] = -1; } - + /* Do not allow primary/secondary channel switch in mesh mode, + * since mesh is not able to establish a physical link for it + */ + conf->no_pri_sec_switch = 1; wpa_supplicant_conf_ap_ht(wpa_s, ssid, conf); if (wpa_drv_init_mesh(wpa_s)) {