From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com>,
Intel Linux Wireless <ilw@linux.intel.com>,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH wireless-2.6] iwlagn: fix "Received BA when not expected"
Date: Thu, 28 Apr 2011 13:59:48 +0200 [thread overview]
Message-ID: <20110428115947.GB7030@redhat.com> (raw)
In-Reply-To: <1303990661.3558.3.camel@jlt3.sipsolutions.net>
On Thu, Apr 28, 2011 at 01:37:41PM +0200, Johannes Berg wrote:
> On Thu, 2011-04-28 at 13:10 +0200, Stanislaw Gruszka wrote:
> > Need to use broadcast sta_id for management and multicast frames,
> > otherwise we broke BA session and get messages like that:
> >
> > "Received BA when not expected"
> >
> > or (on older kernels):
> >
> > "BA scd_flow 0 does not match txq_id 10"
>
> Hmm. Interesting. I believe you, but it's hard.
To be honest, I expected to get explanations from you (perhaps
with better fix) :-) However this one is intended to work on older
kernels, and is tested by me and one other user.
> > - /* Find index into station table for destination station */
> > - sta_id = iwl_sta_id_or_broadcast(priv, ctx, info->control.sta);
>
> info->control.sta should be NULL here, at least for multicast frames
> (which never really happen in practise unless you use AP mode). And then
> this should return ctx->bcast_sta_id, just like you use below:
>
> > + /* If this frame is broadcast or management, use broadcast station id */
> > + if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1))
> > + sta_id = ctx->bcast_sta_id;
>
> So the reason has to be management frames. But why would those be
> affecting it? They aren't QoS frames, so there should be no influence on
> BA handling at all. This is a bit odd.
>
>
> Maybe we should make it clear here that it's about non-data frames and
> remove the multicast check since that ought to be handled in the other
> path?
We call iwl_sta_modify_sleep_tx_count(priv, sta_id, 1); for any frame
as long as some other conditions are true.
Also multicast frames are important. When we send data and multicast
frame we probably modify
priv->stations[sta_id].tid[tid]
with wrong sta_id (other station with unicast address), what make related
aggregation data wrong for that other station.
Stanislaw
next prev parent reply other threads:[~2011-04-28 12:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-28 11:10 [PATCH wireless-2.6] iwlagn: fix "Received BA when not expected" Stanislaw Gruszka
2011-04-28 11:37 ` Johannes Berg
2011-04-28 11:41 ` Johannes Berg
2011-04-28 11:59 ` Stanislaw Gruszka [this message]
2011-04-28 12:09 ` Johannes Berg
2011-04-29 13:57 ` Stanislaw Gruszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110428115947.GB7030@redhat.com \
--to=sgruszka@redhat.com \
--cc=ilw@linux.intel.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=wey-yi.w.guy@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.