[RFC 2/3] wpa_supplicant: Add 2040 BSS intolerance support in station mode

Rajkumar Manoharan rmanohar at qca.qualcomm.com
Mon Apr 23 07:28:07 EDT 2012


On Mon, Apr 23, 2012 at 04:41:49PM +0530, Rajkumar Manoharan wrote:
> On Mon, Apr 23, 2012 at 12:01:07PM +0300, Jouni Malinen wrote:
> > On Wed, Apr 18, 2012 at 07:14:09PM +0530, Rajkumar Manoharan wrote:
> > > Add support for HT STA to report 40MHz intolerance to the associated AP.
> > > A HT station generates a report (2040 BSS coexistence) of channel list
> > > if it finds a non-HT capable AP or a HT AP which prohibits 40MHz
> > > transmission (i.e 40MHz intolerant bit is set in HT capabilities IE)
> > > from the scan results.
> > 
> > This looks SME-specific, so it would be cleaner to keep the
> > implementation within sme.c until some other uses show up for it. The
> > below version does that and adds couple of TODO/FIX comments that should
> > be addressed. The OBSS scan one could be left as a separate one for now,
> > but the other comments should be addressed for the initial commit (well,
> > apart from the special Country element cases with operating class
> > triplets).
> > 
> > 
> Thanks a lot for the cleanup patch.
> 
> > diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
> > index da9cf2b..f6e1622 100644
> > --- a/wpa_supplicant/events.c
> > +++ b/wpa_supplicant/events.c
> > @@ -1096,6 +1096,12 @@ static int _wpa_supplicant_event_scan_results(struct wpa_supplicant *wpa_s,
> >  
> >  	selected = wpa_supplicant_pick_network(wpa_s, scan_res, &ssid);
> >  
> > +	/*
> > +	 * TODO: This should be done at the completion of OBSS scan operations
> > +	 * which may or may not be identical to other scans..
> > +	 */
> > +	sme_proc_40mhz_intolerant(wpa_s);
> > +
> >  	if (selected) {
> >  		int skip;
> >  		skip = !wpa_supplicant_need_to_roam(wpa_s, selected, ssid,
> > diff --git a/wpa_supplicant/sme.c b/wpa_supplicant/sme.c
> > index b366847..f4aa006 100644
> > --- a/wpa_supplicant/sme.c
> > +++ b/wpa_supplicant/sme.c
> > @@ -609,6 +609,160 @@ void sme_deinit(struct wpa_supplicant *wpa_s)
> >  }
> >  
> >  
> > +static void sme_send_2040_bss_coex(struct wpa_supplicant *wpa_s,
> > +				   const u8 *chan_list, u8 num_channels)
> > +{
> > +	struct ieee80211_2040_bss_coex_ie *bc_ie;
> > +	struct ieee80211_2040_intol_chan_report *ic_report;
> > +	struct wpabuf *buf;
> > +
> > +	wpa_printf(MSG_DEBUG, "SME: Send 20/40 BSS Coexistence to " MACSTR,
> > +		   MAC2STR(wpa_s->bssid));
> > +
> > +	buf = wpabuf_alloc(2 + /* action.category + action_code */
> > +			   sizeof(struct ieee80211_2040_bss_coex_ie) +
> > +			   sizeof(struct ieee80211_2040_intol_chan_report) +
> > +			   num_channels);
> > +	if (buf == NULL)
> > +		return;
> > +
> > +	wpabuf_put_u8(buf, WLAN_ACTION_PUBLIC);
> > +	wpabuf_put_u8(buf, WLAN_PA_20_40_BSS_COEX);
> > +
> > +	bc_ie = wpabuf_put(buf, sizeof(*bc_ie));
> > +	bc_ie->element_id = WLAN_EID_20_40_BSS_COEXISTENCE;
> > +	bc_ie->length = 1;
> > +	/* TODO: is this flag really supposed to be added uncontionally?
> > +	 * Shouldn't this be added onyl if a trigger event TE-B has been
> > +	 * detected?
> > +	 */
> > +	bc_ie->coex_info = WLAN_20_40_BSS_COEX_20MHZ_WIDTH_REQ;
> > +
> > +	ic_report = wpabuf_put(buf, sizeof(*ic_report));
> > +	ic_report->element_id = WLAN_EID_20_40_BSS_INTOLERANT;
> > +	ic_report->length = num_channels + 1;
> > +	/* FIX: set ic_report->op_class */
> > +
> As mentioned in TODO, op_class is set as "unknown" as regulatory triplet is not
> handled. So that ic_report->op_class is 0 and it is not explicitly mentioned.
> 
> > +	os_memcpy(wpabuf_put(buf, num_channels), chan_list, num_channels);
> > +
> > +	if (wpa_drv_send_action(wpa_s, wpa_s->assoc_freq, 0, wpa_s->bssid,
> > +				wpa_s->own_addr, wpa_s->bssid,
> > +				wpabuf_head(buf), wpabuf_len(buf), 0) < 0) {
> > +		wpa_msg(wpa_s, MSG_INFO, "SME: Failed to send 20/40 BSS "
> > +			"Coexistence frame");
> > +	}
> > +
> > +	wpabuf_free(buf);
> > +}
> > +
> > +
> > +	/*
> > +	 * Check whether AP uses regulatory triplet or channel triplet in
> > +	 * country info. Right now the operating class of the BSS channel
> > +	 * width trigger event is "unknown" (IEEE Std 802.11-2012 10.15.12),
> > +	 * based on the assumption that operating class triplet is not used in
> > +	 * beacon frame. If the First Channel Number/Operating Extension
> > +	 * Identifier octet has a positive integer value of 201 or greater,
> > +	 * then its operating class triplet.
> > +	 *
> > +	 * TODO: If Supported Operating Classes element is present in Beacon
> > +	 * frame, have to lookup operating class in Annex E and fill them in
> > +	 * 20/40 coex frame.
> > +	 *
> > +	 * TODO: Is it fine to skip this report if Country element is not
> > +	 * included?
> > +	 */
> It is only be ignored if first channel number in country IE is >= 201. 
> If so, then the triplet comprises operating class set that we are not taking
> care right now. Do you still want to consider those IEs?
> 
correction. I should change the condition as well.
> > +	ie = wpa_bss_get_ie(wpa_s->current_bss, WLAN_EID_COUNTRY);
> > +	if (!ie || ie[1] < 6 || (ie[5] > 201))
> > +		return;
> > +
-Rajkumar


More information about the HostAP mailing list