From: Ben Greear <greearb@candelatech.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: mac80211: 3.9.0+: Invalid WDS/flush state and non-connecting station.
Date: Thu, 02 May 2013 13:45:44 -0700 [thread overview]
Message-ID: <5182D078.4020605@candelatech.com> (raw)
In-Reply-To: <1367526288.11375.2.camel@jlt4.sipsolutions.net>
On 05/02/2013 01:24 PM, Johannes Berg wrote:
> On Thu, 2013-05-02 at 12:50 -0700, Ben Greear wrote:
>> Kernel is hacked 3.9.0+
>
> Clearly :)
>
>> I've been seeing this problem for a while (and posted about it previously). The problem
>> is that a station appears to associate fine, but never actually 'connects'. This problem
>> is not easy to reproduce...
>
> It would be useful to know what you added ... the message you point to
> (invalid wds/flush whatever) doesn't exist upstream.
Gobs of stuff, as usual. Thought I had that WDS thing pushed upstream,
but I guess not.
http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.9.dev.y/.git;a=summary
That message comes from:
/*
* Remove all stations associated with this interface.
*
* This must be done before calling ops->remove_interface()
* because otherwise we can later invoke ops->sta_notify()
* whenever the STAs are removed, and that invalidates driver
* assumptions about always getting a vif pointer that is valid
* (because if we remove a STA after ops->remove_interface()
* the driver will have removed the vif info already!)
*
* This is relevant only in WDS mode, in all other modes we've
* already removed all stations when disconnecting or similar,
* so warn otherwise.
*
* We call sta_info_flush_cleanup() later, to combine RCU waits.
*/
flushed = sta_info_flush_defer(sdata);
if ((sdata->vif.type != NL80211_IFTYPE_WDS && flushed > 0) ||
(sdata->vif.type == NL80211_IFTYPE_WDS && flushed != 1)) {
sdata_info(sdata,
"Invalid WDS/flush state, type: %i WDS: %i flushed: %i\n",
sdata->vif.type, NL80211_IFTYPE_WDS, flushed);
WARN_ON_ONCE(1);
}
I notice __cfg80211_connect_result checks the wdev state, so I added some
printouts there to see if it is bailing due to some funny state, but will
probably be a while before I reproduce it again and know for sure.
Thanks,
Ben
>
> johannes
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2013-05-02 20:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-02 19:50 mac80211: 3.9.0+: Invalid WDS/flush state and non-connecting station Ben Greear
2013-05-02 20:24 ` Johannes Berg
2013-05-02 20:45 ` Ben Greear [this message]
2013-05-08 16:18 ` Ben Greear
2013-05-08 17:58 ` Johannes Berg
2013-05-08 18:14 ` Ben Greear
2013-05-10 21:21 ` Ben Greear
2013-05-10 21:25 ` Johannes Berg
2013-05-10 21:33 ` Ben Greear
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=5182D078.4020605@candelatech.com \
--to=greearb@candelatech.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.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 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.