From: Johannes Berg <johannes@sipsolutions.net>
To: Paul Stewart <pstew@chromium.org>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC] mac80211: Filter duplicate IE ids
Date: Fri, 24 Feb 2012 16:36:28 +0100 [thread overview]
Message-ID: <1330097788.3426.29.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <CAMcMvsihYU93DjdqKYHW2xKiNbFD1YBqESx6NAkgKARCf-FjDQ@mail.gmail.com> (sfid-20120224_162609_881741_F7CCCE9D)
On Fri, 2012-02-24 at 07:25 -0800, Paul Stewart wrote:
> >> > I suppose better to accept such service degradation than not connect,
> >> > but I wonder if we should log a warning when we actually try to use such
> >> > an AP?
> >>
> >> Let me know where you'd like it.
> >
> > How about having a flag in the BSS struct (ieee80211_bss) and printing a
> > message when we use that BSS struct for assoc? E.g. in
> > ieee80211_mgd_assoc()? I'm not sure I fully understand where this
> > actually has any effect.
>
> How do we clear this flag? Let's say we got one corrupted beacon and
> from then on, everything was ducky. We set the flag flag on the
> corrupted beacon. Do we clear it on an unblemished probe response?
> Are these really two flags, since beacons and probe responses
> sometimes have different subsets of info, or does a valid probe
> response clear both flags?
Huh, good questions. Which info do we end up using? Just the one that
was not corrupted? I think we always use the last IEs, no?
Hmm. You said in the bug that supported rates were really only affected,
and this caused an issue with the supported rates that we send, because
we restrict ourselves to the rates the AP advertises (due to other buggy
APs ...)
Maybe then it doesn't matter all that much.
OTOH, why should we ever reset the flag? Eventually the BSS entry will
be deleted anyway? And if we keep reconnecting to it, maybe there's some
other bug?
I'm not really sure -- open to suggestions. I just think that in order
to actually notice such things in the future we should print something
so we don't get confused.
johannes
next prev parent reply other threads:[~2012-02-24 15:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-24 1:59 [RFC] mac80211: Filter duplicate IE ids Paul Stewart
2012-02-24 7:34 ` Johannes Berg
2012-02-24 14:24 ` Paul Stewart
2012-02-24 14:29 ` Johannes Berg
2012-02-24 15:25 ` Paul Stewart
2012-02-24 15:36 ` Johannes Berg [this message]
2012-02-24 15:43 ` Paul Stewart
2012-02-24 15:48 ` Johannes Berg
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=1330097788.3426.29.camel@jlt3.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=pstew@chromium.org \
/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).