Message ID | 1444665093-28063-1-git-send-email-greearb@candelatech.com |
---|---|
State | Changes Requested |
Headers | show |
On Mon, Oct 12, 2015 at 08:51:33AM -0700, greearb@candelatech.com wrote: > This is helpful when running multiple different vAP on the > same radio, in different modes. If a vap0 starts in /a mode on channel > 149, then a second vap1 in / mode cannot be switching around the primary > channel as it normally might try to do. I will not add configuration parameters that can be used to disable mandatory 20/40 MHz coexistence rules in the standard. The use case you describe here seems to be something very special where the "conflict" would be with another virtual interface of the same radio. I'm not sure why this type of combination would be used and why the primary channel could not be on the same channel as the 20 MHz channel. There would need to be significantly more justification for something like this to be acceptable and the changes would likely need to be constraint to apply only for the case of two local virtual interface instead of applying to any case where other devices in radio range need coexistence actions to be taken.
On 10/12/2015 01:48 PM, Jouni Malinen wrote: > On Mon, Oct 12, 2015 at 08:51:33AM -0700, greearb@candelatech.com wrote: >> This is helpful when running multiple different vAP on the >> same radio, in different modes. If a vap0 starts in /a mode on channel >> 149, then a second vap1 in / mode cannot be switching around the primary >> channel as it normally might try to do. > > I will not add configuration parameters that can be used to disable > mandatory 20/40 MHz coexistence rules in the standard. The use case you > describe here seems to be something very special where the "conflict" > would be with another virtual interface of the same radio. I'm not sure > why this type of combination would be used and why the primary channel > could not be on the same channel as the 20 MHz channel. There would need > to be significantly more justification for something like this to be > acceptable and the changes would likely need to be constraint to apply > only for the case of two local virtual interface instead of applying to > any case where other devices in radio range need coexistence actions to > be taken. > Ok, thanks for the feedback. In my case, it appears there must be an AP at the edge of our range because sometimes vAP want to switch channels, and sometimes not. I do not have any good way to automate configuring the vAP to work together well when some vAP may switch channels, as far as I can tell. I can understand why you would not want it upstream though. Thanks, Ben
diff --git a/hostapd/config_file.c b/hostapd/config_file.c index 82ac61d..42d3497 100644 --- a/hostapd/config_file.c +++ b/hostapd/config_file.c @@ -2667,6 +2667,14 @@ static int hostapd_config_fill(struct hostapd_config *conf, return 1; } conf->send_probe_response = val; + } else if (os_strcmp(buf, "no_pri_sec_switch") == 0) { + int val = atoi(pos); + if (val != 0 && val != 1) { + wpa_printf(MSG_ERROR, "Line %d: invalid no_pri_sec_switch %d (expected 0 or 1)", + line, val); + return 1; + } + conf->no_pri_sec_switch = val; } else if (os_strcmp(buf, "supported_rates") == 0) { if (hostapd_parse_intlist(&conf->supported_rates, pos)) { wpa_printf(MSG_ERROR, "Line %d: invalid rate list", diff --git a/hostapd/hostapd.conf b/hostapd/hostapd.conf index a0071f7..e683673 100644 --- a/hostapd/hostapd.conf +++ b/hostapd/hostapd.conf @@ -507,6 +507,13 @@ wmm_ac_vo_acm=0 # L-SIG TXOP protection support: [LSIG-TXOP-PROT] (disabled if not set) #ht_capab=[HT40-][SHORT-GI-20][SHORT-GI-40] +# Disable the automatic logic that may switch primary and secondary channel. +# This is useful if running multiple virtual AP on the same radio with different +# encodings (say, vap0 is /a mode, vap1 is /n mode). If vap1 tries to switch, +# it will not work because vap0 is already using the one and only channel it can +# use. +#no_pri_sec_switch=0|1 + # Require stations to support HT PHY (reject association if they do not) #require_ht=1