* [RFC v3] mac80211: Send nullfunc frames at lower rate
@ 2011-09-26 12:23 Rajkumar Manoharan
2011-09-26 13:34 ` Felix Fietkau
0 siblings, 1 reply; 6+ messages in thread
From: Rajkumar Manoharan @ 2011-09-26 12:23 UTC (permalink / raw)
To: johannes; +Cc: linville, linux-wireless, Rajkumar Manoharan, stable
Recently mac80211 was changed to use nullfunc instead of probe
request for connection monitoring for tx ack status reporting
hardwares. These nullfunc data frames are being sent at higer
rates and also as aggregated ones. This could probably delays
the nullfunc ack so the connection is more frequently getting
disconnected as max retries are reached. In order to improve
the connectivity send the nullfunc at lower rate.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
---
v2: update commit log
v3: rename rc_no_data_or_no_ack & Ccd stable
net/mac80211/rate.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index f61244c..240a24d 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -199,7 +199,7 @@ static void rate_control_release(struct kref *kref)
kfree(ctrl_ref);
}
-static bool rc_no_data_or_no_ack(struct ieee80211_tx_rate_control *txrc)
+static bool rc_no_non_nulldata_or_no_ack(struct ieee80211_tx_rate_control *txrc)
{
struct sk_buff *skb = txrc->skb;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
@@ -208,7 +208,8 @@ static bool rc_no_data_or_no_ack(struct ieee80211_tx_rate_control *txrc)
fc = hdr->frame_control;
- return (info->flags & IEEE80211_TX_CTL_NO_ACK) || !ieee80211_is_data(fc);
+ return (info->flags & IEEE80211_TX_CTL_NO_ACK) ||
+ !ieee80211_is_data(fc) || ieee80211_is_nullfunc(fc);
}
static void rc_send_low_broadcast(s8 *idx, u32 basic_rates,
@@ -262,7 +263,7 @@ bool rate_control_send_low(struct ieee80211_sta *sta,
struct ieee80211_supported_band *sband = txrc->sband;
int mcast_rate;
- if (!sta || !priv_sta || rc_no_data_or_no_ack(txrc)) {
+ if (!sta || !priv_sta || rc_no_non_nulldata_or_no_ack(txrc)) {
if ((sband->band != IEEE80211_BAND_2GHZ) ||
!(info->flags & IEEE80211_TX_CTL_NO_CCK_RATE))
info->control.rates[0].idx =
--
1.7.6.4
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [RFC v3] mac80211: Send nullfunc frames at lower rate
2011-09-26 12:23 [RFC v3] mac80211: Send nullfunc frames at lower rate Rajkumar Manoharan
@ 2011-09-26 13:34 ` Felix Fietkau
2011-09-26 13:45 ` Stanislaw Gruszka
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Felix Fietkau @ 2011-09-26 13:34 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: johannes, linville, linux-wireless
On 2011-09-26 6:23 AM, Rajkumar Manoharan wrote:
> Recently mac80211 was changed to use nullfunc instead of probe
> request for connection monitoring for tx ack status reporting
> hardwares. These nullfunc data frames are being sent at higer
> rates and also as aggregated ones. This could probably delays
> the nullfunc ack so the connection is more frequently getting
> disconnected as max retries are reached. In order to improve
> the connectivity send the nullfunc at lower rate.
I don't think nullfunc frames should be sent at the lowest rate. If they
fail frequently, then the rate control module is doing something crappy
and should be fixed. So far I haven't seen any nullfunc reliablity
issues with minstrel_ht.
Also, as far as I know, mac80211 sends non-QoS nullfunc frames, so they
cannot get aggregated either.
- Felix
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [RFC v3] mac80211: Send nullfunc frames at lower rate
2011-09-26 13:34 ` Felix Fietkau
@ 2011-09-26 13:45 ` Stanislaw Gruszka
2011-09-26 15:09 ` Rajkumar Manoharan
2011-09-26 15:07 ` Rajkumar Manoharan
2011-09-27 13:54 ` Rajkumar Manoharan
2 siblings, 1 reply; 6+ messages in thread
From: Stanislaw Gruszka @ 2011-09-26 13:45 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Rajkumar Manoharan, johannes, linville, linux-wireless
On Mon, Sep 26, 2011 at 07:34:41AM -0600, Felix Fietkau wrote:
> On 2011-09-26 6:23 AM, Rajkumar Manoharan wrote:
> >Recently mac80211 was changed to use nullfunc instead of probe
> >request for connection monitoring for tx ack status reporting
> >hardwares. These nullfunc data frames are being sent at higer
> >rates and also as aggregated ones. This could probably delays
> >the nullfunc ack so the connection is more frequently getting
> >disconnected as max retries are reached. In order to improve
> >the connectivity send the nullfunc at lower rate.
> I don't think nullfunc frames should be sent at the lowest rate. If
> they fail frequently, then the rate control module is doing
> something crappy and should be fixed. So far I haven't seen any
> nullfunc reliablity issues with minstrel_ht.
> Also, as far as I know, mac80211 sends non-QoS nullfunc frames, so
> they cannot get aggregated either.
Perhaps nullfunc should be send at lowest rate only when it is
used for connection monitoring, but I'm not sure if we can easily
distinguish that.
Stanislaw
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC v3] mac80211: Send nullfunc frames at lower rate
2011-09-26 13:45 ` Stanislaw Gruszka
@ 2011-09-26 15:09 ` Rajkumar Manoharan
0 siblings, 0 replies; 6+ messages in thread
From: Rajkumar Manoharan @ 2011-09-26 15:09 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Felix Fietkau, johannes, linville, linux-wireless
On Mon, Sep 26, 2011 at 03:45:53PM +0200, Stanislaw Gruszka wrote:
> On Mon, Sep 26, 2011 at 07:34:41AM -0600, Felix Fietkau wrote:
> > On 2011-09-26 6:23 AM, Rajkumar Manoharan wrote:
> > >Recently mac80211 was changed to use nullfunc instead of probe
> > >request for connection monitoring for tx ack status reporting
> > >hardwares. These nullfunc data frames are being sent at higer
> > >rates and also as aggregated ones. This could probably delays
> > >the nullfunc ack so the connection is more frequently getting
> > >disconnected as max retries are reached. In order to improve
> > >the connectivity send the nullfunc at lower rate.
> > I don't think nullfunc frames should be sent at the lowest rate. If
> > they fail frequently, then the rate control module is doing
> > something crappy and should be fixed. So far I haven't seen any
> > nullfunc reliablity issues with minstrel_ht.
> > Also, as far as I know, mac80211 sends non-QoS nullfunc frames, so
> > they cannot get aggregated either.
>
> Perhaps nullfunc should be send at lowest rate only when it is
> used for connection monitoring, but I'm not sure if we can easily
> distinguish that.
>
I completely agree with you. If there are options to do that in simpler
way, that could be the better solution :)
--
Rajkumar
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC v3] mac80211: Send nullfunc frames at lower rate
2011-09-26 13:34 ` Felix Fietkau
2011-09-26 13:45 ` Stanislaw Gruszka
@ 2011-09-26 15:07 ` Rajkumar Manoharan
2011-09-27 13:54 ` Rajkumar Manoharan
2 siblings, 0 replies; 6+ messages in thread
From: Rajkumar Manoharan @ 2011-09-26 15:07 UTC (permalink / raw)
To: Felix Fietkau; +Cc: johannes, linville, linux-wireless
On Mon, Sep 26, 2011 at 07:34:41AM -0600, Felix Fietkau wrote:
> On 2011-09-26 6:23 AM, Rajkumar Manoharan wrote:
> >Recently mac80211 was changed to use nullfunc instead of probe
> >request for connection monitoring for tx ack status reporting
> >hardwares. These nullfunc data frames are being sent at higer
> >rates and also as aggregated ones. This could probably delays
> >the nullfunc ack so the connection is more frequently getting
> >disconnected as max retries are reached. In order to improve
> >the connectivity send the nullfunc at lower rate.
> I don't think nullfunc frames should be sent at the lowest rate. If
> they fail frequently, then the rate control module is doing
> something crappy and should be fixed. So far I haven't seen any
> nullfunc reliablity issues with minstrel_ht.
> Also, as far as I know, mac80211 sends non-QoS nullfunc frames, so
> they cannot get aggregated either.
>
Whatever you mentioned is completely fine, if nullfunc is not used for
monitoring purpose. Otherwise the nullfunc can be aggregated and on worst
case it will be retried to max and BAR will be exchange. By the time
the connection was terminated. As we are using nulldata for controlling
the connection, IMHO it is not wrong to send it at min rate. So we can
avoid unnecessary disconnections.
--
Rajkumar
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC v3] mac80211: Send nullfunc frames at lower rate
2011-09-26 13:34 ` Felix Fietkau
2011-09-26 13:45 ` Stanislaw Gruszka
2011-09-26 15:07 ` Rajkumar Manoharan
@ 2011-09-27 13:54 ` Rajkumar Manoharan
2 siblings, 0 replies; 6+ messages in thread
From: Rajkumar Manoharan @ 2011-09-27 13:54 UTC (permalink / raw)
To: Felix Fietkau; +Cc: johannes, linville, linux-wireless
On Mon, Sep 26, 2011 at 07:34:41AM -0600, Felix Fietkau wrote:
> On 2011-09-26 6:23 AM, Rajkumar Manoharan wrote:
> >Recently mac80211 was changed to use nullfunc instead of probe
> >request for connection monitoring for tx ack status reporting
> >hardwares. These nullfunc data frames are being sent at higer
> >rates and also as aggregated ones. This could probably delays
> >the nullfunc ack so the connection is more frequently getting
> >disconnected as max retries are reached. In order to improve
> >the connectivity send the nullfunc at lower rate.
> I don't think nullfunc frames should be sent at the lowest rate. If
> they fail frequently, then the rate control module is doing
> something crappy and should be fixed. So far I haven't seen any
> nullfunc reliablity issues with minstrel_ht.
> Also, as far as I know, mac80211 sends non-QoS nullfunc frames, so
> they cannot get aggregated either.
>
Yes. you are right. it is not aggregated. An issue was observed when
the STA is roaming so frequesntly and it is on idle state without any
transmission. In such case the rate control is not learned completely.
By the time the connection was terminated so offenly due to not
receiving ack for null frames. On the same situaltion, sending probe
requests instead of nullfunc helps to retain the connection.
--
Rajkumar
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-09-27 13:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-26 12:23 [RFC v3] mac80211: Send nullfunc frames at lower rate Rajkumar Manoharan
2011-09-26 13:34 ` Felix Fietkau
2011-09-26 13:45 ` Stanislaw Gruszka
2011-09-26 15:09 ` Rajkumar Manoharan
2011-09-26 15:07 ` Rajkumar Manoharan
2011-09-27 13:54 ` Rajkumar Manoharan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.