linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Stanislaw Gruszka <sgruszka@redhat.com>
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:37:41 +0200	[thread overview]
Message-ID: <1303990661.3558.3.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <20110428111011.GA6967@redhat.com>

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.

> -	/* 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?

johannes


  reply	other threads:[~2011-04-28 11:37 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 [this message]
2011-04-28 11:41   ` Johannes Berg
2011-04-28 11:59   ` Stanislaw Gruszka
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=1303990661.3558.3.camel@jlt3.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=ilw@linux.intel.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=sgruszka@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).