lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87k1hazo6r.fsf@purkki.adurom.net>
Date:   Thu, 07 Mar 2019 17:42:04 +0200
From:   Kalle Valo <kvalo@...eaurora.org>
To:     Julius Niedworok <julius.n@....net>
Cc:     linux-wireless@...r.kernel.org, ga58taw@...um.de, david@...hat.com,
        nc@....in.tum.de, Johannes Berg <johannes@...solutions.net>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC v2] mac80211: debugfs option to force TX status frames

Julius Niedworok <julius.n@....net> writes:

> At Technical University of Munich we use MAC 802.11 TX status frames to
> perform several measurements in MAC 802.11 setups.
>
> With ath based drivers this was possible until commit d94a461d7a7df6
> ("ath9k: use ieee80211_tx_status_noskb where possible") as the driver
> ignored the IEEE80211_TX_CTL_REQ_TX_STATUS flag and always delivered
> tx_status frames. Since that commit, this behavior was changed and the
> driver now adheres to IEEE80211_TX_CTL_REQ_TX_STATUS.
>
> Due to performance reasons, IEEE80211_TX_CTL_REQ_TX_STATUS is not set for
> data frames from interfaces in managed mode. Hence, frames that are sent
> from a managed mode interface do never deliver tx_status frames. This
> remains true even if a monitor mode interface (the measurement interface)
> is added to the same ieee80211 physical device. Thus, there is no
> possibility for receiving tx_status frames for frames sent on an interface
> in managed mode, if the driver adheres to IEEE80211_TX_CTL_REQ_TX_STATUS.
>
> In order to force delivery of tx_status frames for research and debugging
> purposes, implement a debugfs option force_tx_status for ieee80211 physical
> devices. When this option is set for a physical device,
> IEEE80211_TX_CTL_REQ_TX_STATUS is enabled in all packets sent from that
> device. This option can be set via
> /sys/kernel/debug/ieee80211/<dev>/force_tx_status. The default is disabled.
>
> Co-developed-by: Charlie Groh <ga58taw@...um.de>
> Signed-off-by: Charlie Groh <ga58taw@...um.de>
> Signed-off-by: Julius Niedworok <julius.n@....net>

[...]

> +	len = scnprintf(buf, sizeof(buf), "%d\n", (int)local->force_tx_status);

I wonder about the cast, is it guaranteed that a bool is always of the
same size as an int?

> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -1367,6 +1367,7 @@ struct ieee80211_local {
>  		struct dentry *rcdir;
>  		struct dentry *keys;
>  	} debugfs;
> +	bool force_tx_status;

[...]

>  #endif
>  
>  	/*
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 928f13a..717fa71 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -2463,6 +2463,11 @@ static struct sk_buff *ieee80211_build_hdr(struct ieee80211_sub_if_data *sdata,
>  	if (IS_ERR(sta))
>  		sta = NULL;
>  
> +#ifdef CONFIG_MAC80211_DEBUGFS
> +		if (local->force_tx_status)
> +			info_flags |= IEEE80211_TX_CTL_REQ_TX_STATUS;
> +#endif
> +
>  	/* convert Ethernet header to proper 802.11 header (based on
>  	 * operation mode) */
>  	ethertype = (skb->data[12] << 8) | skb->data[13];
> @@ -3468,6 +3473,11 @@ static bool ieee80211_xmit_fast(struct ieee80211_sub_if_data *sdata,
>  		      (tid_tx ? IEEE80211_TX_CTL_AMPDU : 0);
>  	info->control.flags = IEEE80211_TX_CTRL_FAST_XMIT;
>  
> +#ifdef CONFIG_MAC80211_DEBUGFS
> +		if (local->force_tx_status)
> +			info->flags |= IEEE80211_TX_CTL_REQ_TX_STATUS;
> +#endif

IMHO the ifdefs look pointless just to save four bytes. I would move
force_tx_status outside of ifdef in the struct so that the actual code
doesn't have ugly ifdefs.

-- 
Kalle Valo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ