Re: [PATCH] mac80211: Parse legacy and HT rate in injected frames

[Sven Eckelmann <sven@narfation.org>]

[-- Attachment #1: Type: text/plain, Size: 2236 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]