Re: [PATCH RESEND] hostapd: add VHT tx power envelope IE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 23, 2015 at 06:22:14PM +0530, Rajkumar Manoharan wrote:
> Add VHT transmit power envelope element defined in IEEE std
> 802.11ac-2013 8.4.2.164 for VHT bandwidth channel switch.

Please note that this has been renamed to "Transmit Power Envelope
element" in REVmc (i.e., "VHT" removed from the name).

Why is this conditional on channel switch? The rules in the standard for
including this element in Beacon frames (and same for Probe Response
frames) is as follows:

"One Transmit Power Envelope element is present for each distinct value
of the Local Maximum Transmit Power Unit Interpretation subfield that is
supported for the BSS if both of the following conditions are met:
- dot11VHTOptionImplemented or
  dot11ExtendedSpectrumManagementImplemented is true;
- Either dot11SpectrumManagementRequired is true or
  dot11RadioMeasurementActivated is true.
Otherwise, this parameter is not present.

None of these seem to be a conditional on channel switch.

> diff --git a/src/ap/beacon.c b/src/ap/beacon.c
> @@ -330,7 +330,6 @@ static u8 * hostapd_eid_ecsa(struct hostapd_data *hapd, u8 *eid)
>  }
>  
> -
>  static u8 * hostapd_eid_supported_op_classes(struct hostapd_data *hapd, u8 *eid)

Please do not include unrelated whitespace changes especially when they
make this inconsistent with the expected style.

> @@ -482,6 +481,7 @@ static u8 * hostapd_gen_probe_resp(struct hostapd_data *hapd,
>  		pos = hostapd_eid_vht_capabilities(hapd, pos);
>  		pos = hostapd_eid_vht_operation(hapd, pos);
>  		pos = hostapd_eid_wb_chsw_wrapper(hapd, pos);
> +		pos = hostapd_eid_vht_txpwr_env(hapd, pos);
>  	}

That does not look like the correct location for the Transmit Power
Envelope element. This is supposed to be between the VHT Operation and
Channel Switch Wrapper elements in Probe Response frames.

> @@ -1086,6 +1086,7 @@ int ieee802_11_build_ap_params(struct hostapd_data *hapd,
>  		tailpos = hostapd_eid_vht_capabilities(hapd, tailpos);
>  		tailpos = hostapd_eid_vht_operation(hapd, tailpos);
>  		tailpos = hostapd_eid_wb_chsw_wrapper(hapd, tailpos);
> +		tailpos = hostapd_eid_vht_txpwr_env(hapd, tailpos);
>  	}

Same here for Beacon frames.

> diff --git a/src/ap/ieee802_11_vht.c b/src/ap/ieee802_11_vht.c
> @@ -184,6 +184,55 @@ u8 * hostapd_eid_wb_chsw_wrapper(struct hostapd_data *hapd, u8 *eid)
> +u8 * hostapd_eid_vht_txpwr_env(struct hostapd_data *hapd, u8 *eid)
> +{
> +	struct hostapd_freq_params *params = &hapd->cs_freq_params;
> +	struct hostapd_hw_modes *mode = hapd->iface->current_mode;
> +	struct hostapd_channel_data *chan;
> +	int i;
> +	u8 channel, max_tx_power;
> +
> +	if (hapd->cs_freq_params.bandwidth > 80 ||
> +	    !hapd->cs_freq_params.vht_enabled)
> +		return eid;

What is the purpose of that bandwidth > 80 check? Wouldn't Transmit
Power Envelope element be used with 80+80 and 160 MHz channels as well?

> +	*eid++ = WLAN_EID_VHT_TRANSMIT_POWER_ENVELOPE;
> +	*eid++ = 4;
> +	/*
> +	 * Max Transmit Power count = 2( 20,40 and 80MHz) and
> +	 * Max Transmit Power units = 0 (EIRP)
> +	 */
> +	*eid++ = 2;
> +

Same as above.. 160 MHz?

> +	/*
> +	 * Local Maximum Transmit power is encoded as 2's complement
> +	 * with a 0.5 dB step
> +	 */
> +	max_tx_power = ~(chan->max_tx_power * 2) + 1;
> +	*eid++ = max_tx_power;
> +	*eid++ = max_tx_power;
> +	*eid++ = max_tx_power;

Could you please clarify why all three values are set to the same value?
Would there be no case where the local maximum transmit power is
different for 20, 40, and 80 MHz channel cases?

-- 
Jouni Malinen                                            PGP id EFC895FA

_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux