| Message ID | 916392b0390a00f37d93a9dc00d89951534dbf1d.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:18PM -0700, peter.oh@bowerswilkins.com wrote: > Swapping between primary and secondary channel will break > mesh from joining, hence don't allow it. Could you please point to the location in the IEEE 802.11 standard that describes this exception in co-ex requirements?
On 05/31/2018 02:09 AM, Jouni Malinen wrote: > On Tue, May 29, 2018 at 02:39:18PM -0700, peter.oh@bowerswilkins.com wrote: >> Swapping between primary and secondary channel will break >> mesh from joining, hence don't allow it. > Could you please point to the location in the IEEE 802.11 standard that > describes this exception in co-ex requirements? > no direct exception addressed in co-ex requirement section, but in 802.11-2016 14.2.4 Mesh STA configuration it says Mesh STA configuration treats as identical if - For VHT mesh STAs, the Basic VHT-MCS and NSS fields in the VHT Operation element of the MLME-START.request are identical to the Basic VHT-MCS and NSS fields in the VHT Operation element received in the MLME-MESHPEERINGMANAGEMENT.indication. * center frequency is a part of VHT operation element, hence if channel is swap, then it won't be treated as identical anymore. - For HT mesh STAs, the Basic HT-MCS Set field of the HT Operation parameter of the MLMESTART. request is identical to the HT Operation element received in the MLMEMESHPEERINGMANAGEMENT. indication. * primary channel is part of HT operation parameter although standard addresses only Basic HT set here. in Table 9-365: Mesh Peering Open frame Action field format - 20/40 BSS Coexistence element in mesh is optional which current wpa_supplicant doesn't present in mesh action frame. Not sure if these sections are good enough to convince you, but there is drivers (not clearly remember if it's drivers or mac80211) limitation which needs this patch. However this single patch can be dropped, since it's a kind of improving reliability patch, not a functional patch. let me know if you want me to drop it. Thanks, Peter
On Thu, May 31, 2018 at 05:54:33PM -0700, Peter Oh wrote: > no direct exception addressed in co-ex requirement section, but in > 802.11-2016 14.2.4 Mesh STA configuration it says Mesh STA configuration > treats as identical if > - For VHT mesh STAs, the Basic VHT-MCS and NSS fields in the VHT Operation > element of the > MLME-START.request are identical to the Basic VHT-MCS and NSS fields in the > VHT Operation > element received in the MLME-MESHPEERINGMANAGEMENT.indication. > * center frequency is a part of VHT operation element, hence if channel is > swap, then it won't be treated as identical anymore. > > - For HT mesh STAs, the Basic HT-MCS Set field of the HT Operation parameter > of the MLMESTART. > request is identical to the HT Operation element received in the > MLMEMESHPEERINGMANAGEMENT. > indication. > * primary channel is part of HT operation parameter although standard > addresses only Basic HT set here. > > in Table 9-365: Mesh Peering Open frame Action field format > - 20/40 BSS Coexistence element in mesh is optional which current > wpa_supplicant doesn't present in mesh action frame. > > Not sure if these sections are good enough to convince you, but there is > drivers (not clearly remember if it's drivers or mac80211) limitation which > needs this patch. Could you please identify the exact limitations that "need this patch"? I'm trying to understand whether this is just trying to hide an issue that should really be fixed somewhere else. > However this single patch can be dropped, since it's a kind of improving > reliability patch, not a functional patch. let me know if you want me to > drop it. Huh? Improving reliability? That does not match the previous claim that there are limitation that need this patch. So no, I'm certainly not taking this without a clear description of why it is needed.
On 06/11/2018 09:58 AM, Jouni Malinen wrote: > On Thu, May 31, 2018 at 05:54:33PM -0700, Peter Oh wrote: > Could you please identify the exact limitations that "need this patch"? > I'm trying to understand whether this is just trying to hide an issue > that should really be fixed somewhere else. The purpose of this patch is to avoid peer link failure due to swapping primary and secondary channel. But as I replied in "mesh: do not allow pri/sec channel switch" patch, this exception may be not the right approach and could hide an existing issue. But again this patch series is to make mesh point use DFS channels, not to fix existing issue, so I'll remove this patch from the series in next revision. >> However this single patch can be dropped, since it's a kind of improving >> reliability patch, not a functional patch. let me know if you want me to >> drop it. > Huh? Improving reliability? That does not match the previous claim that > there are limitation that need this patch. So no, I'm certainly not > taking this without a clear description of why it is needed. > This is my commit message of this patch. "Swapping between primary and secondary channel will break mesh from joining, hence don't allow it." swapping pri/sec channel does not alway happen which means mesh could be still able to join each other without this patch if swapping pri/sec doesn't happen after scan. But there are chances that swapping is happening after scan due to neighbor environment. Improving reliability here means improve peer link reliability by avoid such swap happening which leads mesh peer link failure. But again I understood your concern and will remove this patch from the series and handle the swap pri/sec issue separately later. Thanks, Peter
diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c index df71b4f..b26e933 100644 --- a/wpa_supplicant/wpa_supplicant.c +++ b/wpa_supplicant/wpa_supplicant.c @@ -2185,7 +2185,7 @@ void ibss_mesh_setup_freq(struct wpa_supplicant *wpa_s, } freq->sec_channel_offset = ht40; - if (obss_scan) { + if (ssid->mode != WPAS_MODE_MESH && obss_scan) { struct wpa_scan_results *scan_res; scan_res = wpa_supplicant_get_scan_results(wpa_s, NULL, 0);