| Message ID | 1341809468-1089-1-git-send-email-rmanohar@qca.qualcomm.com |
|---|---|
| State | Superseded |
| Headers | show |
On Mon, Jul 09, 2012 at 10:21:08AM +0530, Rajkumar Manoharan wrote: > Right now HT40 mode is not enabled for AP/P2P GO mode in wpa_supplicant. > If the HW is capable of 40MHz channel width and user specifies the > secondary channel posision, lets enable the HT40 mode in wpa_s. This > patch also enables HT40 support for P2P mode. > > ap_ht40_mode : -1 -> HT40MINUS, 1 -> HT40PLUS what about HT20? This would be useful for IBSS mode too..what about extending this option to IBSS as well? Cheers, > > Signed-hostap: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> > --- > wpa_supplicant/ap.c | 3 +++ > wpa_supplicant/config.c | 5 ++++- > wpa_supplicant/config.h | 7 +++++++ > wpa_supplicant/config_file.c | 4 ++++ > wpa_supplicant/p2p_supplicant.c | 2 -- > wpa_supplicant/wpa_supplicant.c | 2 ++ > wpa_supplicant/wpa_supplicant_i.h | 1 + > 7 files changed, 21 insertions(+), 3 deletions(-) > > diff --git a/wpa_supplicant/ap.c b/wpa_supplicant/ap.c > index f9e0045..25a07d5 100644 > --- a/wpa_supplicant/ap.c > +++ b/wpa_supplicant/ap.c > @@ -99,6 +99,9 @@ static int wpa_supplicant_conf_ap(struct wpa_supplicant *wpa_s, > > if (!no_ht && mode && mode->ht_capab) { > conf->ieee80211n = 1; > + if (mode->ht_capab & HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET) > + conf->secondary_channel = > + wpa_s->global->ap_ht40_mode; > > /* > * white-list capabilities that won't cause issues > diff --git a/wpa_supplicant/config.c b/wpa_supplicant/config.c > index a68b31e..31a5d39 100644 > --- a/wpa_supplicant/config.c > +++ b/wpa_supplicant/config.c > @@ -2921,7 +2921,10 @@ static const struct global_parse_data global_fields[] = { > { INT_RANGE(wps_nfc_dev_pw_id, 0x10, 0xffff), 0 }, > { BIN(wps_nfc_dh_pubkey), 0 }, > { BIN(wps_nfc_dh_privkey), 0 }, > - { BIN(wps_nfc_dev_pw), 0 } > + { BIN(wps_nfc_dev_pw), 0 }, > +#ifdef CONFIG_IEEE80211N > + { INT(ap_ht40_mode), 0 }, > +#endif > }; > > #undef FUNC > diff --git a/wpa_supplicant/config.h b/wpa_supplicant/config.h > index 46c4da2..7bb326d 100644 > --- a/wpa_supplicant/config.h > +++ b/wpa_supplicant/config.h > @@ -661,6 +661,13 @@ struct wpa_config { > * wps_nfc_dh_pubkey - NFC Device Password for password token > */ > struct wpabuf *wps_nfc_dev_pw; > +#ifdef CONFIG_IEEE80211N > + /** > + * ap_ht40_mode - Specify HT40 mode secondary channel position > + * HT40+/- mainly for AP mode > + */ > + int ap_ht40_mode; > +#endif > }; > > > diff --git a/wpa_supplicant/config_file.c b/wpa_supplicant/config_file.c > index 8badc7b..3182d29 100644 > --- a/wpa_supplicant/config_file.c > +++ b/wpa_supplicant/config_file.c > @@ -875,6 +875,10 @@ static void wpa_config_write_global(FILE *f, struct wpa_config *config) > write_global_bin(f, "wps_nfc_dh_pubkey", config->wps_nfc_dh_pubkey); > write_global_bin(f, "wps_nfc_dh_privkey", config->wps_nfc_dh_privkey); > write_global_bin(f, "wps_nfc_dev_pw", config->wps_nfc_dev_pw); > +#ifdef CONFIG_IEEE80211N > + if (config->ap_ht40_mode) > + fprintf(f, "ap_ht40_mode=%d\n", config->ap_ht40_mode); > +#endif > } > > #endif /* CONFIG_NO_CONFIG_WRITE */ > diff --git a/wpa_supplicant/p2p_supplicant.c b/wpa_supplicant/p2p_supplicant.c > index 218ed2f..0a9fc1f 100644 > --- a/wpa_supplicant/p2p_supplicant.c > +++ b/wpa_supplicant/p2p_supplicant.c > @@ -2231,10 +2231,8 @@ static int wpas_p2p_setup_channels(struct wpa_supplicant *wpa_s, > struct p2p_oper_class_map op_class[] = { > { HOSTAPD_MODE_IEEE80211G, 81, 1, 13, 1, BW20 }, > { HOSTAPD_MODE_IEEE80211G, 82, 14, 14, 1, BW20 }, > -#if 0 /* Do not enable HT40 on 2 GHz for now */ > { HOSTAPD_MODE_IEEE80211G, 83, 1, 9, 1, BW40PLUS }, > { HOSTAPD_MODE_IEEE80211G, 84, 5, 13, 1, BW40MINUS }, > -#endif > { HOSTAPD_MODE_IEEE80211A, 115, 36, 48, 4, BW20 }, > { HOSTAPD_MODE_IEEE80211A, 124, 149, 161, 4, BW20 }, > { HOSTAPD_MODE_IEEE80211A, 116, 36, 44, 8, BW40PLUS }, > diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c > index c65dc3c..22b063b 100644 > --- a/wpa_supplicant/wpa_supplicant.c > +++ b/wpa_supplicant/wpa_supplicant.c > @@ -2534,6 +2534,8 @@ static int wpa_supplicant_init_iface(struct wpa_supplicant *wpa_s, > return -1; > } > > + wpa_s->global->ap_ht40_mode = wpa_s->conf->ap_ht40_mode; > + > /* > * Override ctrl_interface and driver_param if set on command > * line. > diff --git a/wpa_supplicant/wpa_supplicant_i.h b/wpa_supplicant/wpa_supplicant_i.h > index b608f29..6c4c507 100644 > --- a/wpa_supplicant/wpa_supplicant_i.h > +++ b/wpa_supplicant/wpa_supplicant_i.h > @@ -239,6 +239,7 @@ struct wpa_global { > WPA_CONC_PREF_STA, > WPA_CONC_PREF_P2P > } conc_pref; > + int ap_ht40_mode; > }; > > > -- > 1.7.11.1 > > _______________________________________________ > HostAP mailing list > HostAP@lists.shmoo.com > http://lists.shmoo.com/mailman/listinfo/hostap
On Mon, Jul 09, 2012 at 10:21:08AM +0530, Rajkumar Manoharan wrote: > Right now HT40 mode is not enabled for AP/P2P GO mode in wpa_supplicant. > If the HW is capable of 40MHz channel width and user specifies the > secondary channel posision, lets enable the HT40 mode in wpa_s. This > patch also enables HT40 support for P2P mode. > > ap_ht40_mode : -1 -> HT40MINUS, 1 -> HT40PLUS This looks quite confusing to use as a global parameter. The selection between HT40- and HT40+ should really be based on the channel that ends up getting used (e.g., cannot use HT40- on channel 36). The preferred way of specifying plus vs. minus would be with the operation that selects the channel (say, p2p_connect command). For a global parameter, I would rather have just enable_ht40 0/1 and have the plus/minus part figured out automatically based on which channel is going to be used. > diff --git a/wpa_supplicant/p2p_supplicant.c b/wpa_supplicant/p2p_supplicant.c > @@ -2231,10 +2231,8 @@ static int wpas_p2p_setup_channels(struct wpa_supplicant *wpa_s, > struct p2p_oper_class_map op_class[] = { > { HOSTAPD_MODE_IEEE80211G, 81, 1, 13, 1, BW20 }, > { HOSTAPD_MODE_IEEE80211G, 82, 14, 14, 1, BW20 }, > -#if 0 /* Do not enable HT40 on 2 GHz for now */ > { HOSTAPD_MODE_IEEE80211G, 83, 1, 9, 1, BW40PLUS }, > { HOSTAPD_MODE_IEEE80211G, 84, 5, 13, 1, BW40MINUS }, > -#endif Why? 40 MHz channels on 2 GHz band were disabled on purpose and I would like to keep this separate from the possibility of using 40 MHz channels on 5 GHz.
On Mon, Jul 09, 2012 at 09:07:53AM +0200, Antonio Quartulli wrote: > On Mon, Jul 09, 2012 at 10:21:08AM +0530, Rajkumar Manoharan wrote: > > Right now HT40 mode is not enabled for AP/P2P GO mode in wpa_supplicant. > > If the HW is capable of 40MHz channel width and user specifies the > > secondary channel posision, lets enable the HT40 mode in wpa_s. This > > patch also enables HT40 support for P2P mode. > > > > ap_ht40_mode : -1 -> HT40MINUS, 1 -> HT40PLUS > > what about HT20? As of now if CONFIG_IEEE80211N=y and driver supports it, AP interface is configured in HT20 mode. If ap_ht40_mode is not configured or ap_ht40_mode == 0, AP is started in HT20 mode. > This would be useful for IBSS mode too..what about extending this option to IBSS > as well? > wpa_supplicant_create_ap only be called for AP or P2P GO mode. -Rajkumar
On Mon, Jul 09, 2012 at 11:56:14AM +0300, Jouni Malinen wrote: > On Mon, Jul 09, 2012 at 10:21:08AM +0530, Rajkumar Manoharan wrote: > > Right now HT40 mode is not enabled for AP/P2P GO mode in wpa_supplicant. > > If the HW is capable of 40MHz channel width and user specifies the > > secondary channel posision, lets enable the HT40 mode in wpa_s. This > > patch also enables HT40 support for P2P mode. > > > > ap_ht40_mode : -1 -> HT40MINUS, 1 -> HT40PLUS > > This looks quite confusing to use as a global parameter. The selection > between HT40- and HT40+ should really be based on the channel that ends > up getting used (e.g., cannot use HT40- on channel 36). The preferred > way of specifying plus vs. minus would be with the operation that > selects the channel (say, p2p_connect command). For a global parameter, > I would rather have just enable_ht40 0/1 and have the plus/minus part > figured out automatically based on which channel is going to be used. > I thought of that too. But how about the channels that can operate in HT40+ and HT40- like channel 6. How can we determine that on which mode AP should start with? So I followed the existing hostap approach. > > diff --git a/wpa_supplicant/p2p_supplicant.c b/wpa_supplicant/p2p_supplicant.c > > @@ -2231,10 +2231,8 @@ static int wpas_p2p_setup_channels(struct wpa_supplicant *wpa_s, > > struct p2p_oper_class_map op_class[] = { > > { HOSTAPD_MODE_IEEE80211G, 81, 1, 13, 1, BW20 }, > > { HOSTAPD_MODE_IEEE80211G, 82, 14, 14, 1, BW20 }, > > -#if 0 /* Do not enable HT40 on 2 GHz for now */ > > { HOSTAPD_MODE_IEEE80211G, 83, 1, 9, 1, BW40PLUS }, > > { HOSTAPD_MODE_IEEE80211G, 84, 5, 13, 1, BW40MINUS }, > > -#endif > > Why? 40 MHz channels on 2 GHz band were disabled on purpose and I would > like to keep this separate from the possibility of using 40 MHz channels > on 5 GHz. If so, for 2GHz band alone cards we are not supporting HT40 in P2P mode. Before starting in HT40 mode, we are already going though OBSS process. Then why do we have to disable HT40 mode? -Rajkumar
On Mon, Jul 9, 2012 at 7:51 AM, Rajkumar Manoharan <rmanohar@qca.qualcomm.com> wrote: > Right now HT40 mode is not enabled for AP/P2P GO mode in wpa_supplicant. > If the HW is capable of 40MHz channel width and user specifies the > secondary channel posision, lets enable the HT40 mode in wpa_s. This > patch also enables HT40 support for P2P mode. > > ap_ht40_mode : -1 -> HT40MINUS, 1 -> HT40PLUS > > Signed-hostap: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> > --- > wpa_supplicant/ap.c | 3 +++ > wpa_supplicant/config.c | 5 ++++- > wpa_supplicant/config.h | 7 +++++++ > wpa_supplicant/config_file.c | 4 ++++ > wpa_supplicant/p2p_supplicant.c | 2 -- > wpa_supplicant/wpa_supplicant.c | 2 ++ > wpa_supplicant/wpa_supplicant_i.h | 1 + > 7 files changed, 21 insertions(+), 3 deletions(-) > > diff --git a/wpa_supplicant/ap.c b/wpa_supplicant/ap.c > index f9e0045..25a07d5 100644 > --- a/wpa_supplicant/ap.c > +++ b/wpa_supplicant/ap.c > @@ -99,6 +99,9 @@ static int wpa_supplicant_conf_ap(struct wpa_supplicant *wpa_s, > > if (!no_ht && mode && mode->ht_capab) { > conf->ieee80211n = 1; > + if (mode->ht_capab & HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET) > + conf->secondary_channel = > + wpa_s->global->ap_ht40_mode; Can you tell me why HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET is not enabled in the capabilities white-list? (just below this code). I must be missing something, otherwise I'm not sure how this works.. Thanks, Arik
On Mon, Jul 09, 2012 at 06:50:04PM +0300, Arik Nemtsov wrote: > On Mon, Jul 9, 2012 at 7:51 AM, Rajkumar Manoharan > <rmanohar@qca.qualcomm.com> wrote: > > Right now HT40 mode is not enabled for AP/P2P GO mode in wpa_supplicant. > > If the HW is capable of 40MHz channel width and user specifies the > > secondary channel posision, lets enable the HT40 mode in wpa_s. This > > patch also enables HT40 support for P2P mode. > > > > ap_ht40_mode : -1 -> HT40MINUS, 1 -> HT40PLUS > > > > Signed-hostap: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> > > --- > > wpa_supplicant/ap.c | 3 +++ > > wpa_supplicant/config.c | 5 ++++- > > wpa_supplicant/config.h | 7 +++++++ > > wpa_supplicant/config_file.c | 4 ++++ > > wpa_supplicant/p2p_supplicant.c | 2 -- > > wpa_supplicant/wpa_supplicant.c | 2 ++ > > wpa_supplicant/wpa_supplicant_i.h | 1 + > > 7 files changed, 21 insertions(+), 3 deletions(-) > > > > diff --git a/wpa_supplicant/ap.c b/wpa_supplicant/ap.c > > index f9e0045..25a07d5 100644 > > --- a/wpa_supplicant/ap.c > > +++ b/wpa_supplicant/ap.c > > @@ -99,6 +99,9 @@ static int wpa_supplicant_conf_ap(struct wpa_supplicant *wpa_s, > > > > if (!no_ht && mode && mode->ht_capab) { > > conf->ieee80211n = 1; > > + if (mode->ht_capab & HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET) > > + conf->secondary_channel = > > + wpa_s->global->ap_ht40_mode; > > Can you tell me why HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET is not enabled > in the capabilities white-list? > (just below this code). > > I must be missing something, otherwise I'm not sure how this works.. > The HT40 mode should be enabled if and only if the hw has IEEE80211_HT_CAP_SUP_WIDTH_20_40 capability. This info was exported by wpa_driver_nl80211_get_hw_feature_data. I don't understand why it has be added in white-list? Jouni, Please correct me if wrong. -Rajkumar
On Mon, Jul 9, 2012 at 7:15 PM, Rajkumar Manoharan <rmanohar@qca.qualcomm.com> wrote: > On Mon, Jul 09, 2012 at 06:50:04PM +0300, Arik Nemtsov wrote: >> On Mon, Jul 9, 2012 at 7:51 AM, Rajkumar Manoharan >> <rmanohar@qca.qualcomm.com> wrote: >> > Right now HT40 mode is not enabled for AP/P2P GO mode in wpa_supplicant. >> > If the HW is capable of 40MHz channel width and user specifies the >> > secondary channel posision, lets enable the HT40 mode in wpa_s. This >> > patch also enables HT40 support for P2P mode. >> > >> > ap_ht40_mode : -1 -> HT40MINUS, 1 -> HT40PLUS >> > >> > Signed-hostap: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> >> > --- >> > wpa_supplicant/ap.c | 3 +++ >> > wpa_supplicant/config.c | 5 ++++- >> > wpa_supplicant/config.h | 7 +++++++ >> > wpa_supplicant/config_file.c | 4 ++++ >> > wpa_supplicant/p2p_supplicant.c | 2 -- >> > wpa_supplicant/wpa_supplicant.c | 2 ++ >> > wpa_supplicant/wpa_supplicant_i.h | 1 + >> > 7 files changed, 21 insertions(+), 3 deletions(-) >> > >> > diff --git a/wpa_supplicant/ap.c b/wpa_supplicant/ap.c >> > index f9e0045..25a07d5 100644 >> > --- a/wpa_supplicant/ap.c >> > +++ b/wpa_supplicant/ap.c >> > @@ -99,6 +99,9 @@ static int wpa_supplicant_conf_ap(struct wpa_supplicant *wpa_s, >> > >> > if (!no_ht && mode && mode->ht_capab) { >> > conf->ieee80211n = 1; >> > + if (mode->ht_capab & HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET) >> > + conf->secondary_channel = >> > + wpa_s->global->ap_ht40_mode; >> >> Can you tell me why HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET is not enabled >> in the capabilities white-list? >> (just below this code). >> >> I must be missing something, otherwise I'm not sure how this works.. >> > The HT40 mode should be enabled if and only if the hw has IEEE80211_HT_CAP_SUP_WIDTH_20_40 > capability. This info was exported by wpa_driver_nl80211_get_hw_feature_data. > I don't understand why it has be added in white-list? > The capabilities enabled for p2p are only a subset of all the capabilities the HW supports. See this in the code: /* * white-list capabilities that won't cause issues * to connecting stations, while leaving the current * capabilities intact (currently disabled SMPS). */ conf->ht_capab |= mode->ht_capab & (HT_CAP_INFO_GREEN_FIELD | HT_CAP_INFO_SHORT_GI20MHZ | HT_CAP_INFO_SHORT_GI40MHZ | HT_CAP_INFO_RX_STBC_MASK | HT_CAP_INFO_MAX_AMSDU_SIZE); Arik
On Mon, Jul 09, 2012 at 07:33:23PM +0300, Arik Nemtsov wrote: > On Mon, Jul 9, 2012 at 7:15 PM, Rajkumar Manoharan > <rmanohar@qca.qualcomm.com> wrote: > > On Mon, Jul 09, 2012 at 06:50:04PM +0300, Arik Nemtsov wrote: > >> On Mon, Jul 9, 2012 at 7:51 AM, Rajkumar Manoharan > >> <rmanohar@qca.qualcomm.com> wrote: > >> > Right now HT40 mode is not enabled for AP/P2P GO mode in wpa_supplicant. > >> > If the HW is capable of 40MHz channel width and user specifies the > >> > secondary channel posision, lets enable the HT40 mode in wpa_s. This > >> > patch also enables HT40 support for P2P mode. > >> > > >> > ap_ht40_mode : -1 -> HT40MINUS, 1 -> HT40PLUS > >> > > >> > Signed-hostap: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> > >> > --- > >> > wpa_supplicant/ap.c | 3 +++ > >> > wpa_supplicant/config.c | 5 ++++- > >> > wpa_supplicant/config.h | 7 +++++++ > >> > wpa_supplicant/config_file.c | 4 ++++ > >> > wpa_supplicant/p2p_supplicant.c | 2 -- > >> > wpa_supplicant/wpa_supplicant.c | 2 ++ > >> > wpa_supplicant/wpa_supplicant_i.h | 1 + > >> > 7 files changed, 21 insertions(+), 3 deletions(-) > >> > > >> > diff --git a/wpa_supplicant/ap.c b/wpa_supplicant/ap.c > >> > index f9e0045..25a07d5 100644 > >> > --- a/wpa_supplicant/ap.c > >> > +++ b/wpa_supplicant/ap.c > >> > @@ -99,6 +99,9 @@ static int wpa_supplicant_conf_ap(struct wpa_supplicant *wpa_s, > >> > > >> > if (!no_ht && mode && mode->ht_capab) { > >> > conf->ieee80211n = 1; > >> > + if (mode->ht_capab & HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET) > >> > + conf->secondary_channel = > >> > + wpa_s->global->ap_ht40_mode; > >> > >> Can you tell me why HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET is not enabled > >> in the capabilities white-list? > >> (just below this code). > >> > >> I must be missing something, otherwise I'm not sure how this works.. > >> > > The HT40 mode should be enabled if and only if the hw has IEEE80211_HT_CAP_SUP_WIDTH_20_40 > > capability. This info was exported by wpa_driver_nl80211_get_hw_feature_data. > > I don't understand why it has be added in white-list? > > > > The capabilities enabled for p2p are only a subset of all the > capabilities the HW supports. See this in the code: > Oops. I understood. forgive my ignorance. -Rajkumar
On Mon, Jul 09, 2012 at 10:41:39PM +0530, Rajkumar Manoharan wrote: > On Mon, Jul 09, 2012 at 07:33:23PM +0300, Arik Nemtsov wrote: > > On Mon, Jul 9, 2012 at 7:15 PM, Rajkumar Manoharan > > <rmanohar@qca.qualcomm.com> wrote: > > > On Mon, Jul 09, 2012 at 06:50:04PM +0300, Arik Nemtsov wrote: > > >> On Mon, Jul 9, 2012 at 7:51 AM, Rajkumar Manoharan > > >> <rmanohar@qca.qualcomm.com> wrote: > > >> > Right now HT40 mode is not enabled for AP/P2P GO mode in wpa_supplicant. > > >> > If the HW is capable of 40MHz channel width and user specifies the > > >> > secondary channel posision, lets enable the HT40 mode in wpa_s. This > > >> > patch also enables HT40 support for P2P mode. > > >> > > > >> > ap_ht40_mode : -1 -> HT40MINUS, 1 -> HT40PLUS > > >> > > > >> > Signed-hostap: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> > > >> > --- > > >> > wpa_supplicant/ap.c | 3 +++ > > >> > wpa_supplicant/config.c | 5 ++++- > > >> > wpa_supplicant/config.h | 7 +++++++ > > >> > wpa_supplicant/config_file.c | 4 ++++ > > >> > wpa_supplicant/p2p_supplicant.c | 2 -- > > >> > wpa_supplicant/wpa_supplicant.c | 2 ++ > > >> > wpa_supplicant/wpa_supplicant_i.h | 1 + > > >> > 7 files changed, 21 insertions(+), 3 deletions(-) > > >> > > > >> > diff --git a/wpa_supplicant/ap.c b/wpa_supplicant/ap.c > > >> > index f9e0045..25a07d5 100644 > > >> > --- a/wpa_supplicant/ap.c > > >> > +++ b/wpa_supplicant/ap.c > > >> > @@ -99,6 +99,9 @@ static int wpa_supplicant_conf_ap(struct wpa_supplicant *wpa_s, > > >> > > > >> > if (!no_ht && mode && mode->ht_capab) { > > >> > conf->ieee80211n = 1; > > >> > + if (mode->ht_capab & HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET) > > >> > + conf->secondary_channel = > > >> > + wpa_s->global->ap_ht40_mode; > > >> > > >> Can you tell me why HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET is not enabled > > >> in the capabilities white-list? > > >> (just below this code). > > >> > > >> I must be missing something, otherwise I'm not sure how this works.. > > >> > > > The HT40 mode should be enabled if and only if the hw has IEEE80211_HT_CAP_SUP_WIDTH_20_40 > > > capability. This info was exported by wpa_driver_nl80211_get_hw_feature_data. > > > I don't understand why it has be added in white-list? > > > > > > > The capabilities enabled for p2p are only a subset of all the > > capabilities the HW supports. See this in the code: > > > Oops. I understood. forgive my ignorance. > Thanks Arik. Forgot to amend the changes. Such a poor guy. -Rajkumar
On Mon, Jul 9, 2012 at 8:15 PM, Rajkumar Manoharan <rmanohar@qca.qualcomm.com> wrote: > On Mon, Jul 09, 2012 at 10:41:39PM +0530, Rajkumar Manoharan wrote: >> On Mon, Jul 09, 2012 at 07:33:23PM +0300, Arik Nemtsov wrote: >> > On Mon, Jul 9, 2012 at 7:15 PM, Rajkumar Manoharan >> > <rmanohar@qca.qualcomm.com> wrote: >> > > On Mon, Jul 09, 2012 at 06:50:04PM +0300, Arik Nemtsov wrote: >> > >> On Mon, Jul 9, 2012 at 7:51 AM, Rajkumar Manoharan >> > >> <rmanohar@qca.qualcomm.com> wrote: >> > >> > Right now HT40 mode is not enabled for AP/P2P GO mode in wpa_supplicant. >> > >> > If the HW is capable of 40MHz channel width and user specifies the >> > >> > secondary channel posision, lets enable the HT40 mode in wpa_s. This >> > >> > patch also enables HT40 support for P2P mode. >> > >> > >> > >> > ap_ht40_mode : -1 -> HT40MINUS, 1 -> HT40PLUS >> > >> > >> > >> > Signed-hostap: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> >> > >> > --- >> > >> > wpa_supplicant/ap.c | 3 +++ >> > >> > wpa_supplicant/config.c | 5 ++++- >> > >> > wpa_supplicant/config.h | 7 +++++++ >> > >> > wpa_supplicant/config_file.c | 4 ++++ >> > >> > wpa_supplicant/p2p_supplicant.c | 2 -- >> > >> > wpa_supplicant/wpa_supplicant.c | 2 ++ >> > >> > wpa_supplicant/wpa_supplicant_i.h | 1 + >> > >> > 7 files changed, 21 insertions(+), 3 deletions(-) >> > >> > >> > >> > diff --git a/wpa_supplicant/ap.c b/wpa_supplicant/ap.c >> > >> > index f9e0045..25a07d5 100644 >> > >> > --- a/wpa_supplicant/ap.c >> > >> > +++ b/wpa_supplicant/ap.c >> > >> > @@ -99,6 +99,9 @@ static int wpa_supplicant_conf_ap(struct wpa_supplicant *wpa_s, >> > >> > >> > >> > if (!no_ht && mode && mode->ht_capab) { >> > >> > conf->ieee80211n = 1; >> > >> > + if (mode->ht_capab & HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET) >> > >> > + conf->secondary_channel = >> > >> > + wpa_s->global->ap_ht40_mode; >> > >> >> > >> Can you tell me why HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET is not enabled >> > >> in the capabilities white-list? >> > >> (just below this code). >> > >> >> > >> I must be missing something, otherwise I'm not sure how this works.. >> > >> >> > > The HT40 mode should be enabled if and only if the hw has IEEE80211_HT_CAP_SUP_WIDTH_20_40 >> > > capability. This info was exported by wpa_driver_nl80211_get_hw_feature_data. >> > > I don't understand why it has be added in white-list? >> > > >> > >> > The capabilities enabled for p2p are only a subset of all the >> > capabilities the HW supports. See this in the code: >> > >> Oops. I understood. forgive my ignorance. >> > Thanks Arik. Forgot to amend the changes. Such a poor guy. That's ok. No harm done :) A question for Jouni - are you against enabling 2.4Ghz 40mhz support for STA (CLI) only as well? I understand the AP OBSS scan is currently not implemented, and it is also discouraged by the spec, but everything seems supported for STA. This will require a different trick because we don't know what we are yet. How about enabling the 2Ghz operating classes and disabling the HT40 support just before starting the GO (if it's in 2Ghz)? Arik
On Mon, Jul 09, 2012 at 03:13:23PM +0530, Rajkumar Manoharan wrote: > I thought of that too. But how about the channels that can operate in HT40+ > and HT40- like channel 6. How can we determine that on which mode AP should > start with? So I followed the existing hostap approach. Deciding something like this based on a global configuration parameter does not make much sense to me. If you need to specify HT40+ vs. HT40- (which would only be the case on some 2.4 GHz band channels), it should really be done as part of p2p_connect/p2p_group_add command parameters or as a network block parameter rather than global parameter. > > > diff --git a/wpa_supplicant/p2p_supplicant.c b/wpa_supplicant/p2p_supplicant.c > > > @@ -2231,10 +2231,8 @@ static int wpas_p2p_setup_channels(struct wpa_supplicant *wpa_s, > > > struct p2p_oper_class_map op_class[] = { > > > { HOSTAPD_MODE_IEEE80211G, 81, 1, 13, 1, BW20 }, > > > { HOSTAPD_MODE_IEEE80211G, 82, 14, 14, 1, BW20 }, > > > -#if 0 /* Do not enable HT40 on 2 GHz for now */ > > > { HOSTAPD_MODE_IEEE80211G, 83, 1, 9, 1, BW40PLUS }, > > > { HOSTAPD_MODE_IEEE80211G, 84, 5, 13, 1, BW40MINUS }, > > > -#endif > > > > Why? 40 MHz channels on 2 GHz band were disabled on purpose and I would > > like to keep this separate from the possibility of using 40 MHz channels > > on 5 GHz. > If so, for 2GHz band alone cards we are not supporting HT40 in P2P mode. > Before starting in HT40 mode, we are already going though OBSS process. > Then why do we have to disable HT40 mode? I would like to keep this change separate from the rest of the patch to keep these topics independent of each other. I have nothing against enabling 40 MHz channels on 5 GHz band for P2P use cases, but I'm not sure I would really like to see that as the default behavior for 2.4 GHz band. And even if ever enabled for 2.4 GHz, a more robust mechanism would be to first initiate the GO with 20 MHz channel and then switch to 40 MHz channel based on the co-existence procedure defined in 802.11n afterwards.
On Mon, Jul 09, 2012 at 08:30:23PM +0300, Arik Nemtsov wrote: > On Mon, Jul 9, 2012 at 8:15 PM, Rajkumar Manoharan > <rmanohar@qca.qualcomm.com> wrote: > > On Mon, Jul 09, 2012 at 10:41:39PM +0530, Rajkumar Manoharan wrote: > >> On Mon, Jul 09, 2012 at 07:33:23PM +0300, Arik Nemtsov wrote: > >> > On Mon, Jul 9, 2012 at 7:15 PM, Rajkumar Manoharan > >> > <rmanohar@qca.qualcomm.com> wrote: > >> > > On Mon, Jul 09, 2012 at 06:50:04PM +0300, Arik Nemtsov wrote: > >> > >> Can you tell me why HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET is not enabled > >> > >> in the capabilities white-list? > >> > >> (just below this code). It does not sound like a good idea to enable 40 MHz channels unconditionally especially for 2.4 GHz band. I guess it could be considered for 5 GHz, but even there, I would rather have this configurable or even better, set with p2p_connect/p2p_group_add commands on the GO. > A question for Jouni - are you against enabling 2.4Ghz 40mhz support > for STA (CLI) only as well? No. I thought we already enabled that (and probably do with some drivers). Does this get somehow disabled with mac80211-based drivers? I'm only concerned about unconditionally (or even by default) enabling 40 MHz channels on the AP/GO. The P2P client should follow whatever parameters the GO has set for the network. > This will require a different trick because we don't know what we are > yet. How about enabling the 2Ghz operating classes and disabling the > HT40 support just before starting the GO (if it's in 2Ghz)? The GO can switch to 40 MHz channel even after having negotiated group with the 20 MHz operating class. I don't see why the operating class table would need to be modified for this to work.
On Mon, Jul 9, 2012 at 9:42 PM, Jouni Malinen <j@w1.fi> wrote: > On Mon, Jul 09, 2012 at 08:30:23PM +0300, Arik Nemtsov wrote: >> On Mon, Jul 9, 2012 at 8:15 PM, Rajkumar Manoharan >> <rmanohar@qca.qualcomm.com> wrote: >> > On Mon, Jul 09, 2012 at 10:41:39PM +0530, Rajkumar Manoharan wrote: >> >> On Mon, Jul 09, 2012 at 07:33:23PM +0300, Arik Nemtsov wrote: >> >> > On Mon, Jul 9, 2012 at 7:15 PM, Rajkumar Manoharan >> >> > <rmanohar@qca.qualcomm.com> wrote: >> >> > > On Mon, Jul 09, 2012 at 06:50:04PM +0300, Arik Nemtsov wrote: >> >> > >> Can you tell me why HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET is not enabled >> >> > >> in the capabilities white-list? >> >> > >> (just below this code). > > It does not sound like a good idea to enable 40 MHz channels > unconditionally especially for 2.4 GHz band. I guess it could be > considered for 5 GHz, but even there, I would rather have this > configurable or even better, set with p2p_connect/p2p_group_add commands > on the GO. The p2p_connect/p2p_group_add approach sounds reasonable. > >> A question for Jouni - are you against enabling 2.4Ghz 40mhz support >> for STA (CLI) only as well? > > No. I thought we already enabled that (and probably do with some > drivers). Does this get somehow disabled with mac80211-based drivers? > I'm only concerned about unconditionally (or even by default) enabling > 40 MHz channels on the AP/GO. The P2P client should follow whatever > parameters the GO has set for the network. I haven't tested it, only assumed the table was used by both sides for channel type. What you're saying makes sense. I'll be testing this in the following days (and will report). > >> This will require a different trick because we don't know what we are >> yet. How about enabling the 2Ghz operating classes and disabling the >> HT40 support just before starting the GO (if it's in 2Ghz)? > > The GO can switch to 40 MHz channel even after having negotiated group > with the 20 MHz operating class. I don't see why the operating class > table would need to be modified for this to work. Well extended channel switch is not really tested in today's certification tests, so it's likely to cause interoperability issues. Probably negotiating an HT40 channel in the first place would work better. But if 2.4g 40mhz CLI can be enabled without touching these operating classes, it would be great. I agree 2.4g 40mhz GO is problematic. Arik
On Mon, Jul 09, 2012 at 09:36:22PM +0300, Jouni Malinen wrote: > On Mon, Jul 09, 2012 at 03:13:23PM +0530, Rajkumar Manoharan wrote: > > I thought of that too. But how about the channels that can operate in HT40+ > > and HT40- like channel 6. How can we determine that on which mode AP should > > start with? So I followed the existing hostap approach. > > Deciding something like this based on a global configuration parameter > does not make much sense to me. If you need to specify HT40+ vs. HT40- > (which would only be the case on some 2.4 GHz band channels), it should > really be done as part of p2p_connect/p2p_group_add command parameters > or as a network block parameter rather than global parameter. > Fine. I assume that ieee80211n_check_40mhz_2g4 always validates the scan results before starting AP interface in HT40. Thats why i enabled it for both the bands. For GO mode, we can use the p2p commands to enable 40MHz. But How about regular (non-P2P) AP mode? Are we supporting traditional AP mode in wpa_s? > > > > diff --git a/wpa_supplicant/p2p_supplicant.c b/wpa_supplicant/p2p_supplicant.c > > > > @@ -2231,10 +2231,8 @@ static int wpas_p2p_setup_channels(struct wpa_supplicant *wpa_s, > > > > struct p2p_oper_class_map op_class[] = { > > > > { HOSTAPD_MODE_IEEE80211G, 81, 1, 13, 1, BW20 }, > > > > { HOSTAPD_MODE_IEEE80211G, 82, 14, 14, 1, BW20 }, > > > > -#if 0 /* Do not enable HT40 on 2 GHz for now */ > > > > { HOSTAPD_MODE_IEEE80211G, 83, 1, 9, 1, BW40PLUS }, > > > > { HOSTAPD_MODE_IEEE80211G, 84, 5, 13, 1, BW40MINUS }, > > > > -#endif > > > > > > Why? 40 MHz channels on 2 GHz band were disabled on purpose and I would > > > like to keep this separate from the possibility of using 40 MHz channels > > > on 5 GHz. > > If so, for 2GHz band alone cards we are not supporting HT40 in P2P mode. > > Before starting in HT40 mode, we are already going though OBSS process. > > Then why do we have to disable HT40 mode? > > I would like to keep this change separate from the rest of the patch to > keep these topics independent of each other. I have nothing against > enabling 40 MHz channels on 5 GHz band for P2P use cases, but I'm not > sure I would really like to see that as the default behavior for 2.4 GHz > band. And even if ever enabled for 2.4 GHz, a more robust mechanism > would be to first initiate the GO with 20 MHz channel and then switch to > 40 MHz channel based on the co-existence procedure defined in 802.11n > afterwards. Fine. -Rajkumar
diff --git a/wpa_supplicant/ap.c b/wpa_supplicant/ap.c index f9e0045..25a07d5 100644 --- a/wpa_supplicant/ap.c +++ b/wpa_supplicant/ap.c @@ -99,6 +99,9 @@ static int wpa_supplicant_conf_ap(struct wpa_supplicant *wpa_s, if (!no_ht && mode && mode->ht_capab) { conf->ieee80211n = 1; + if (mode->ht_capab & HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET) + conf->secondary_channel = + wpa_s->global->ap_ht40_mode; /* * white-list capabilities that won't cause issues diff --git a/wpa_supplicant/config.c b/wpa_supplicant/config.c index a68b31e..31a5d39 100644 --- a/wpa_supplicant/config.c +++ b/wpa_supplicant/config.c @@ -2921,7 +2921,10 @@ static const struct global_parse_data global_fields[] = { { INT_RANGE(wps_nfc_dev_pw_id, 0x10, 0xffff), 0 }, { BIN(wps_nfc_dh_pubkey), 0 }, { BIN(wps_nfc_dh_privkey), 0 }, - { BIN(wps_nfc_dev_pw), 0 } + { BIN(wps_nfc_dev_pw), 0 }, +#ifdef CONFIG_IEEE80211N + { INT(ap_ht40_mode), 0 }, +#endif }; #undef FUNC diff --git a/wpa_supplicant/config.h b/wpa_supplicant/config.h index 46c4da2..7bb326d 100644 --- a/wpa_supplicant/config.h +++ b/wpa_supplicant/config.h @@ -661,6 +661,13 @@ struct wpa_config { * wps_nfc_dh_pubkey - NFC Device Password for password token */ struct wpabuf *wps_nfc_dev_pw; +#ifdef CONFIG_IEEE80211N + /** + * ap_ht40_mode - Specify HT40 mode secondary channel position + * HT40+/- mainly for AP mode + */ + int ap_ht40_mode; +#endif }; diff --git a/wpa_supplicant/config_file.c b/wpa_supplicant/config_file.c index 8badc7b..3182d29 100644 --- a/wpa_supplicant/config_file.c +++ b/wpa_supplicant/config_file.c @@ -875,6 +875,10 @@ static void wpa_config_write_global(FILE *f, struct wpa_config *config) write_global_bin(f, "wps_nfc_dh_pubkey", config->wps_nfc_dh_pubkey); write_global_bin(f, "wps_nfc_dh_privkey", config->wps_nfc_dh_privkey); write_global_bin(f, "wps_nfc_dev_pw", config->wps_nfc_dev_pw); +#ifdef CONFIG_IEEE80211N + if (config->ap_ht40_mode) + fprintf(f, "ap_ht40_mode=%d\n", config->ap_ht40_mode); +#endif } #endif /* CONFIG_NO_CONFIG_WRITE */ diff --git a/wpa_supplicant/p2p_supplicant.c b/wpa_supplicant/p2p_supplicant.c index 218ed2f..0a9fc1f 100644 --- a/wpa_supplicant/p2p_supplicant.c +++ b/wpa_supplicant/p2p_supplicant.c @@ -2231,10 +2231,8 @@ static int wpas_p2p_setup_channels(struct wpa_supplicant *wpa_s, struct p2p_oper_class_map op_class[] = { { HOSTAPD_MODE_IEEE80211G, 81, 1, 13, 1, BW20 }, { HOSTAPD_MODE_IEEE80211G, 82, 14, 14, 1, BW20 }, -#if 0 /* Do not enable HT40 on 2 GHz for now */ { HOSTAPD_MODE_IEEE80211G, 83, 1, 9, 1, BW40PLUS }, { HOSTAPD_MODE_IEEE80211G, 84, 5, 13, 1, BW40MINUS }, -#endif { HOSTAPD_MODE_IEEE80211A, 115, 36, 48, 4, BW20 }, { HOSTAPD_MODE_IEEE80211A, 124, 149, 161, 4, BW20 }, { HOSTAPD_MODE_IEEE80211A, 116, 36, 44, 8, BW40PLUS }, diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c index c65dc3c..22b063b 100644 --- a/wpa_supplicant/wpa_supplicant.c +++ b/wpa_supplicant/wpa_supplicant.c @@ -2534,6 +2534,8 @@ static int wpa_supplicant_init_iface(struct wpa_supplicant *wpa_s, return -1; } + wpa_s->global->ap_ht40_mode = wpa_s->conf->ap_ht40_mode; + /* * Override ctrl_interface and driver_param if set on command * line. diff --git a/wpa_supplicant/wpa_supplicant_i.h b/wpa_supplicant/wpa_supplicant_i.h index b608f29..6c4c507 100644 --- a/wpa_supplicant/wpa_supplicant_i.h +++ b/wpa_supplicant/wpa_supplicant_i.h @@ -239,6 +239,7 @@ struct wpa_global { WPA_CONC_PREF_STA, WPA_CONC_PREF_P2P } conc_pref; + int ap_ht40_mode; };