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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
