Add use_minrate param to ieee80211_tx_prepare_skb() function.
This is useful in case we would like to send frames
with lowest rates, eg. nullfunc, probe_resp.
Signed-off-by: Janusz Dziedzic <[email protected]>
---
drivers/net/wireless/ath/ath9k/channel.c | 5 +++--
include/net/mac80211.h | 4 +++-
net/mac80211/tx.c | 6 +++++-
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/channel.c b/drivers/net/wireless/ath/ath9k/channel.c
index b81f65c..ccb2d76 100644
--- a/drivers/net/wireless/ath/ath9k/channel.c
+++ b/drivers/net/wireless/ath/ath9k/channel.c
@@ -1040,7 +1040,7 @@ static void ath_scan_send_probe(struct ath_softc *sc,
skb_set_queue_mapping(skb, IEEE80211_AC_VO);
- if (!ieee80211_tx_prepare_skb(sc->hw, vif, skb, band, NULL))
+ if (!ieee80211_tx_prepare_skb(sc->hw, vif, skb, band, NULL, true))
goto error;
txctl.txq = sc->tx.txq_map[IEEE80211_AC_VO];
@@ -1155,7 +1155,8 @@ ath_chanctx_send_vif_ps_frame(struct ath_softc *sc, struct ath_vif *avp,
skb->priority = 7;
skb_set_queue_mapping(skb, IEEE80211_AC_VO);
- if (!ieee80211_tx_prepare_skb(sc->hw, vif, skb, band, &sta)) {
+ if (!ieee80211_tx_prepare_skb(sc->hw, vif, skb,
+ band, &sta, true)) {
dev_kfree_skb_any(skb);
return false;
}
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 0ea9b51..7269fca 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -5412,12 +5412,14 @@ void ieee80211_report_wowlan_wakeup(struct ieee80211_vif *vif,
* @skb: frame to be sent from within the driver
* @band: the band to transmit on
* @sta: optional pointer to get the station to send the frame to
+ * @use_minrate: use lowest rate
*
* Note: must be called under RCU lock
*/
bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw,
struct ieee80211_vif *vif, struct sk_buff *skb,
- int band, struct ieee80211_sta **sta);
+ int band, struct ieee80211_sta **sta,
+ bool use_minrate);
/**
* struct ieee80211_noa_data - holds temporary data for tracking P2P NoA state
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index a512c4b..ebe8268 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1526,7 +1526,8 @@ static int invoke_tx_handlers(struct ieee80211_tx_data *tx)
bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw,
struct ieee80211_vif *vif, struct sk_buff *skb,
- int band, struct ieee80211_sta **sta)
+ int band, struct ieee80211_sta **sta,
+ bool use_minrate)
{
struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
@@ -1540,6 +1541,9 @@ bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw,
info->control.vif = vif;
info->hw_queue = vif->hw_queue[skb_get_queue_mapping(skb)];
+ if (use_minrate)
+ info->flags |= IEEE80211_TX_CTL_USE_MINRATE;
+
if (invoke_tx_handlers(&tx))
return false;
--
1.9.1
On Tue, Jan 05, 2016 at 11:16:52AM +0100, Janusz Dziedzic wrote:
> I did it because most of devices I saw send probe_req using lowest rates?
> Anyway I can skip this for probe_res() frames in next patch if this is
> better idea.
Taken into account that there is strong desire to move towards the
opposite direction, yes, it would be good not to try to force Probe
Request frames use the minimal rate. We already force no-CCK policy for
P2P use cases and in the not too distant future, we'll probably need to
provide means for forcing at least 1 and 2 Mbps rates not being used for
any Probe Request frame..
--
Jouni Malinen PGP id EFC895FA
On 5 January 2016 at 10:45, Jouni Malinen <[email protected]> wrote:
> On Tue, Jan 05, 2016 at 10:00:19AM +0100, Janusz Dziedzic wrote:
>> Add use_minrate param to ieee80211_tx_prepare_skb() function.
>> This is useful in case we would like to send frames
>> with lowest rates, eg. nullfunc, probe_resp.
>
> I could kind of understand this for short frames like Data nullfunc and
> PS-Poll, but why would we like to hard code Probe Response frames to be
> sent at the lowest rate? Shouldn't the frames be sent at a rate that is
> most likely to get them through and do so in a manner that does not use
> excessive amount of air time?
>
This is used to get/send probe_req() frame, next used by ath9k
"hw_scan" when chanctx used.
> --
> Jouni Malinen PGP id EFC895FA
On Tue, 2016-01-05 at 11:18 +0100, Janusz Dziedzic wrote:
>
> BTW, should we export more params except minrate. I see also
> IEEE80211_TX_CTL_NO_CCK_RATE is used??
That would be required for P2P.
johannes
On Tue, Jan 05, 2016 at 10:00:19AM +0100, Janusz Dziedzic wrote:
> Add use_minrate param to ieee80211_tx_prepare_skb() function.
> This is useful in case we would like to send frames
> with lowest rates, eg. nullfunc, probe_resp.
I could kind of understand this for short frames like Data nullfunc and
PS-Poll, but why would we like to hard code Probe Response frames to be
sent at the lowest rate? Shouldn't the frames be sent at a rate that is
most likely to get them through and do so in a manner that does not use
excessive amount of air time?
--
Jouni Malinen PGP id EFC895FA
On 5 January 2016 at 11:16, Janusz Dziedzic <[email protected]> wrote:
> On 5 January 2016 at 11:06, Jouni Malinen <[email protected]> wrote:
>> On Tue, Jan 05, 2016 at 10:56:18AM +0100, Janusz Dziedzic wrote:
>>> On 5 January 2016 at 10:45, Jouni Malinen <[email protected]> wrote:
>>> > On Tue, Jan 05, 2016 at 10:00:19AM +0100, Janusz Dziedzic wrote:
>>> >> Add use_minrate param to ieee80211_tx_prepare_skb() function.
>>> >> This is useful in case we would like to send frames
>>> >> with lowest rates, eg. nullfunc, probe_resp.
>>> >
>>> > I could kind of understand this for short frames like Data nullfunc and
>>> > PS-Poll, but why would we like to hard code Probe Response frames to be
>>> > sent at the lowest rate? Shouldn't the frames be sent at a rate that is
>>> > most likely to get them through and do so in a manner that does not use
>>> > excessive amount of air time?
>>> >
>>> This is used to get/send probe_req() frame, next used by ath9k
>>> "hw_scan" when chanctx used.
>>
>> Sure, but that's not what I'm asking. I'm asking why would we want to
>> force Probe Response frames to use the lowest rate based on that commit
>> message above. If that's a typo and should have been Probe Request
>> frame, I'm going to ask the same question about Probe Request frames.
>> Why would we like to force the lowest rate to be used for them?
>>
> I did it because most of devices I saw send probe_req using lowest rates?
> Anyway I can skip this for probe_res() frames in next patch if this is
> better idea.
>
BTW, should we export more params except minrate. I see also
IEEE80211_TX_CTL_NO_CCK_RATE is used??
So, other implementation I see is to set
info->flags |= IEEE80211_TX_CTL_NO_CCK_RATE | IEEE80211_TX_CTL_USE_MINRATE;
In the driver and check this in ieee80211_tx_prepare_skb() before
memset(0) in ieee80211_tx_prepare()
I will send V2.
BR
Janusz
On Tue, Jan 05, 2016 at 10:56:18AM +0100, Janusz Dziedzic wrote:
> On 5 January 2016 at 10:45, Jouni Malinen <[email protected]> wrote:
> > On Tue, Jan 05, 2016 at 10:00:19AM +0100, Janusz Dziedzic wrote:
> >> Add use_minrate param to ieee80211_tx_prepare_skb() function.
> >> This is useful in case we would like to send frames
> >> with lowest rates, eg. nullfunc, probe_resp.
> >
> > I could kind of understand this for short frames like Data nullfunc and
> > PS-Poll, but why would we like to hard code Probe Response frames to be
> > sent at the lowest rate? Shouldn't the frames be sent at a rate that is
> > most likely to get them through and do so in a manner that does not use
> > excessive amount of air time?
> >
> This is used to get/send probe_req() frame, next used by ath9k
> "hw_scan" when chanctx used.
Sure, but that's not what I'm asking. I'm asking why would we want to
force Probe Response frames to use the lowest rate based on that commit
message above. If that's a typo and should have been Probe Request
frame, I'm going to ask the same question about Probe Request frames.
Why would we like to force the lowest rate to be used for them?
--
Jouni Malinen PGP id EFC895FA
On 5 January 2016 at 11:06, Jouni Malinen <[email protected]> wrote:
> On Tue, Jan 05, 2016 at 10:56:18AM +0100, Janusz Dziedzic wrote:
>> On 5 January 2016 at 10:45, Jouni Malinen <[email protected]> wrote:
>> > On Tue, Jan 05, 2016 at 10:00:19AM +0100, Janusz Dziedzic wrote:
>> >> Add use_minrate param to ieee80211_tx_prepare_skb() function.
>> >> This is useful in case we would like to send frames
>> >> with lowest rates, eg. nullfunc, probe_resp.
>> >
>> > I could kind of understand this for short frames like Data nullfunc and
>> > PS-Poll, but why would we like to hard code Probe Response frames to be
>> > sent at the lowest rate? Shouldn't the frames be sent at a rate that is
>> > most likely to get them through and do so in a manner that does not use
>> > excessive amount of air time?
>> >
>> This is used to get/send probe_req() frame, next used by ath9k
>> "hw_scan" when chanctx used.
>
> Sure, but that's not what I'm asking. I'm asking why would we want to
> force Probe Response frames to use the lowest rate based on that commit
> message above. If that's a typo and should have been Probe Request
> frame, I'm going to ask the same question about Probe Request frames.
> Why would we like to force the lowest rate to be used for them?
>
I did it because most of devices I saw send probe_req using lowest rates?
Anyway I can skip this for probe_res() frames in next patch if this is
better idea.
> --
> Jouni Malinen PGP id EFC895FA