| Message ID | 391e68c7114385ed4cc14e85347b38e64e00ce4e.1527814610.git.peter.oh@bowerswilkins.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | mesh: enable DFS channels in mesh mode | expand |
On Thu, May 31, 2018 at 06:02:07PM -0700, peter.oh@bowerswilkins.com wrote: > Drivers don't allow mesh to use offchannel on management Tx, > otherwise it will fail and return error. This commit message is a bit confusing. The proposed change seems to change offchanok from 1 to 0 only if the channel on which the Action frame is supposed to be sent out requires DFS. I guess that's wrong as well.. Shouldn't this be based on the current operating channel of the mesh BSS rather than the channel where the Action frame might be sent at? > @@ -7190,6 +7194,13 @@ static int wpa_driver_nl80211_send_action(struct i802_bss *bss, > os_memset(bss->rand_addr, 0, ETH_ALEN); > } > > + if (is_mesh_interface(drv->nlmode)) { > + modes = nl80211_get_hw_feature_data(bss, &num_modes, > + &flags, &dfs_domain); > + if (ieee80211_is_dfs(freq, modes, num_modes)) > + offchanok = 0; This freq parameter to ieee80211_is_dfs() is the frequency for the next Action frame, not of the operating channel.. Isn't the constraint on not allowing offchannel operations based on the current operating channel requiring radar detection and as such, not allowing the radio to leave it?
On 06/11/2018 10:41 AM, Jouni Malinen wrote: > On Thu, May 31, 2018 at 06:02:07PM -0700, peter.oh@bowerswilkins.com wrote: >> Drivers don't allow mesh to use offchannel on management Tx, >> otherwise it will fail and return error. > This commit message is a bit confusing. The proposed change seems to > change offchanok from 1 to 0 only if the channel on which the Action > frame is supposed to be sent out requires DFS. I guess that's wrong as > well.. Shouldn't this be based on the current operating channel of the > mesh BSS rather than the channel where the Action frame might be sent > at? > >> @@ -7190,6 +7194,13 @@ static int wpa_driver_nl80211_send_action(struct i802_bss *bss, >> os_memset(bss->rand_addr, 0, ETH_ALEN); >> } >> >> + if (is_mesh_interface(drv->nlmode)) { >> + modes = nl80211_get_hw_feature_data(bss, &num_modes, >> + &flags, &dfs_domain); >> + if (ieee80211_is_dfs(freq, modes, num_modes)) >> + offchanok = 0; > This freq parameter to ieee80211_is_dfs() is the frequency for the next > Action frame, not of the operating channel.. Isn't the constraint on not > allowing offchannel operations based on the current operating channel > requiring radar detection and as such, not allowing the radio to leave > it? > I've updated the patch and commit message, so please review coming new patch.
diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c index 5cff47f..c1c641a 100644 --- a/src/drivers/driver_nl80211.c +++ b/src/drivers/driver_nl80211.c @@ -7166,6 +7166,10 @@ static int wpa_driver_nl80211_send_action(struct i802_bss *bss, int ret = -1; u8 *buf; struct ieee80211_hdr *hdr; + struct hostapd_hw_modes *modes; + int offchanok = 1; + u16 num_modes, flags; + u8 dfs_domain; wpa_printf(MSG_DEBUG, "nl80211: Send Action frame (ifindex=%d, " "freq=%u MHz wait=%d ms no_cck=%d)", @@ -7190,6 +7194,13 @@ static int wpa_driver_nl80211_send_action(struct i802_bss *bss, os_memset(bss->rand_addr, 0, ETH_ALEN); } + if (is_mesh_interface(drv->nlmode)) { + modes = nl80211_get_hw_feature_data(bss, &num_modes, + &flags, &dfs_domain); + if (ieee80211_is_dfs(freq, modes, num_modes)) + offchanok = 0; + } + if (is_ap_interface(drv->nlmode) && (!(drv->capa.flags & WPA_DRIVER_FLAGS_OFFCHANNEL_TX) || (int) freq == bss->freq || drv->device_ap_sme || @@ -7201,7 +7212,7 @@ static int wpa_driver_nl80211_send_action(struct i802_bss *bss, ret = nl80211_send_frame_cmd(bss, freq, wait_time, buf, 24 + data_len, &drv->send_action_cookie, - no_cck, 0, 1, NULL, 0); + no_cck, 0, offchanok, NULL, 0); os_free(buf); return ret;