Re: [PATCH] mac80211: Parse legacy and HT rate in injected frames
On Mon, 2016-01-25 at 13:59 +0100, Sven Eckelmann wrote: > > The flag itself has to be set when the radiotap information is > available+parsed and when the actual rate information calculation > should > happen. > > Afaik the ieee80211_tx_data is always a local variable on the stack. > Either > from ieee80211_tx_prepare_skb, ieee80211_tx, ieee80211_xmit_fast or > ieee80211_get_buffered_bc. But the parsing of the radiotap header > happens > before that in ieee80211_monitor_start_xmit. And after that it calls > ieee80211_xmit -> ieee80211_tx. So tx_data is definitely not > available when > the radiotap header is parsed. Fair enough. We could put that data elsewhere, but it's probably not worth it for a simple flag. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: Parse legacy and HT rate in injected frames
On Thursday 26 November 2015 18:25:26 Johannes Berg wrote: > > We have required the support for rate parsing (legacy + HT) for some > > tests. > > It is already known that this may not be the best place to set this > > flag > > (IEEE80211_TX_CTRL_RATE_INJECT) but the main flags field is already > > full. > > It seems you could perhaps put that into struct > ieee80211_tx_data::flags? Or is it required somewhere outside the > mac80211 processing? The flag itself has to be set when the radiotap information is available+parsed and when the actual rate information calculation should happen. Afaik the ieee80211_tx_data is always a local variable on the stack. Either from ieee80211_tx_prepare_skb, ieee80211_tx, ieee80211_xmit_fast or ieee80211_get_buffered_bc. But the parsing of the radiotap header happens before that in ieee80211_monitor_start_xmit. And after that it calls ieee80211_xmit -> ieee80211_tx. So tx_data is definitely not available when the radiotap header is parsed. > Otherwise I think the place is fine? What issue do you have with it? > > > There is also the problem that powersave could overwrite the rate > > control > > fields - so either we disable powersave queueing or find a different > > solution. > > I have no idea what you mean? The flag - as you have it now - should be > preserved, no? Perhaps if you moved the flag into tx_data then it > wouldn't be, and that's a good argument for not moving it? I was under the impression that the PS could write in part of the ieee80211_tx_info union which would be in conflict with the control part. But I've just rechecked the source and could not find anything like that. > > But maybe this feature is also not wanted anymore in the mac80211 > > driver. > > Well, I'm open to adding the code if you need it. Could consider VHT as > well, I guess. I personally don't have VHT hardware which would support injected frames with self chosen rates. So I cannot test VHT rate injection. > Adding the check to the fast-xmit path seems neither right nor > necessary though, since that shouldn't get invoked for injection to > start with? Ok, will be removed and I resent it as v2. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
Re: [PATCH] mac80211: Parse legacy and HT rate in injected frames
On Tue, 2015-10-13 at 16:36 +0200, Sven Eckelmann wrote: > > The removal of this feature heavily reduced the usefulness of frame > injection when wanting to simulate specific transmission behavior. > Having > rate parsing together with MCS rates and retry support allows a fine > grained selection of the tx behavior of injected frames for these > kind of > tests. Assuming you have hardware to do it, but that requirement seems fair. > We have required the support for rate parsing (legacy + HT) for some > tests. > It is already known that this may not be the best place to set this > flag > (IEEE80211_TX_CTRL_RATE_INJECT) but the main flags field is already > full. It seems you could perhaps put that into struct ieee80211_tx_data::flags? Or is it required somewhere outside the mac80211 processing? Otherwise I think the place is fine? What issue do you have with it? > There is also the problem that powersave could overwrite the rate > control > fields - so either we disable powersave queueing or find a different > solution. I have no idea what you mean? The flag - as you have it now - should be preserved, no? Perhaps if you moved the flag into tx_data then it wouldn't be, and that's a good argument for not moving it? > But maybe this feature is also not wanted anymore in the mac80211 > driver. Well, I'm open to adding the code if you need it. Could consider VHT as well, I guess. Adding the check to the fast-xmit path seems neither right nor necessary though, since that shouldn't get invoked for injection to start with? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mac80211: Parse legacy and HT rate in injected frames
Drivers/devices without their own rate control algorithm can get the
information what rates they should use from either the radiotap header of
injected frames or from the rate control algorithm. But the parsing of the
legacy rate information from the radiotap header was removed in commit
e6a9854b05c1 ("mac80211/drivers: rewrite the rate control API").
The removal of this feature heavily reduced the usefulness of frame
injection when wanting to simulate specific transmission behavior. Having
rate parsing together with MCS rates and retry support allows a fine
grained selection of the tx behavior of injected frames for these kind of
tests.
Signed-off-by: Sven Eckelmann
Cc: Simon Wunderlich
Cc: Johannes Berg
---
We have required the support for rate parsing (legacy + HT) for some tests.
It is already known that this may not be the best place to set this flag
(IEEE80211_TX_CTRL_RATE_INJECT) but the main flags field is already full.
There is also the problem that powersave could overwrite the rate control
fields - so either we disable powersave queueing or find a different
solution.
But maybe this feature is also not wanted anymore in the mac80211 driver.
Thanks,
Sven
---
Documentation/networking/mac80211-injection.txt | 17 ++
include/net/mac80211.h | 2 +
net/mac80211/tx.c | 76 +++--
3 files changed, 91 insertions(+), 4 deletions(-)
diff --git a/Documentation/networking/mac80211-injection.txt
b/Documentation/networking/mac80211-injection.txt
index 3a93007..ec8f934 100644
--- a/Documentation/networking/mac80211-injection.txt
+++ b/Documentation/networking/mac80211-injection.txt
@@ -28,6 +28,23 @@ radiotap headers and used to control injection:
IEEE80211_RADIOTAP_F_TX_NOACK: frame should be sent without waiting for
an ACK even if it is a unicast frame
+ * IEEE80211_RADIOTAP_RATE
+
+ legacy rate for the transmission (only for devices without own rate control)
+
+ * IEEE80211_RADIOTAP_MCS
+
+ HT rate for the transmission (only for devices without own rate control).
+ Also some flags are parsed
+
+ IEEE80211_TX_RC_SHORT_GI: use short guard interval
+ IEEE80211_TX_RC_40_MHZ_WIDTH: send in HT40 mode
+
+ * IEEE80211_RADIOTAP_DATA_RETRIES
+
+ number of retries when either IEEE80211_RADIOTAP_RATE or
+ IEEE80211_RADIOTAP_MCS was used
+
The injection code can also skip all other currently defined radiotap fields
facilitating replay of captured radiotap headers directly.
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 4ec6fed..e1bf37d 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -689,12 +689,14 @@ enum mac80211_tx_info_flags {
* protocol frame (e.g. EAP)
* @IEEE80211_TX_CTRL_PS_RESPONSE: This frame is a response to a poll
* frame (PS-Poll or uAPSD).
+ * @IEEE80211_TX_CTRL_RATE_INJECT: This frame is injected with rate information
*
* These flags are used in tx_info->control.flags.
*/
enum mac80211_tx_control_flags {
IEEE80211_TX_CTRL_PORT_CTRL_PROTO = BIT(0),
IEEE80211_TX_CTRL_PS_RESPONSE = BIT(1),
+ IEEE80211_TX_CTRL_RATE_INJECT = BIT(2),
};
/*
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 464ba1a..58298c4 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1474,7 +1474,8 @@ static int invoke_tx_handlers(struct ieee80211_tx_data
*tx)
CALL_TXH(ieee80211_tx_h_ps_buf);
CALL_TXH(ieee80211_tx_h_check_control_port_protocol);
CALL_TXH(ieee80211_tx_h_select_key);
- if (!ieee80211_hw_check(>local->hw, HAS_RATE_CONTROL))
+ if (!ieee80211_hw_check(>local->hw, HAS_RATE_CONTROL) &&
+ !(info->control.flags & IEEE80211_TX_CTRL_RATE_INJECT))
CALL_TXH(ieee80211_tx_h_rate_ctrl);
if (unlikely(info->flags & IEEE80211_TX_INTFL_RETRANSMISSION)) {
@@ -1663,15 +1664,24 @@ void ieee80211_xmit(struct ieee80211_sub_if_data *sdata,
ieee80211_tx(sdata, sta, skb, false);
}
-static bool ieee80211_parse_tx_radiotap(struct sk_buff *skb)
+static bool ieee80211_parse_tx_radiotap(struct sk_buff *skb,
+ struct ieee80211_local *local)
{
struct ieee80211_radiotap_iterator iterator;
struct ieee80211_radiotap_header *rthdr =
(struct ieee80211_radiotap_header *) skb->data;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ struct ieee80211_supported_band *sband =
+ local->hw.wiphy->bands[info->band];
int ret = ieee80211_radiotap_iterator_init(, rthdr, skb->len,
NULL);
u16 txflags;
+ u16 rate = 0;
+ bool rate_found = false;
+ u8 rate_retries = 0;
+ u16 rate_flags = 0;
+ u8 mcs_known, mcs_flags;
+ int i;
