On Fri, Jun 03, 2011 at 10:49:39PM +0200, thus spake Ignacy Gawedzki: > On Fri, Jun 03, 2011 at 10:16:44PM +0200, thus spake Ignacy Gawedzki: > > I can't confirm right now that this is indeed what's happening, but I'll post > > more information as soon as possible. > > I can now confirm that the state is MLME_SEARCH and that the ignored station > can't be added because of the following in ieee80211_ibss_add_sta(): > > if (ifibss->state == IEEE80211_IBSS_MLME_SEARCH) > return NULL; After looking more in details at the code, I think I'm getting closer to a proper diagnostic. The state is changed to MLME_SEARCH when ieee80211_ibss_join() is called from ieee80211_join_ibss() in cfg.c. I suppose this is what's called when an application asks the kernel to make the interface join an IBSS. Since in that state no new STA can be added to local->sta_list, if there were no STA at all, there's no last_rx to update and consequently ieee80211_sta_active_ibss() returns 0 and ieee80211_sta_find_ibss() may proceed. But apparently, if there are still some remaining STAs in local->sta_list, their last_rx is updated upon reception of a frame from them, so if they are transmitting frames often enough, ieee80211_sta_active_ibss() won't ever return 0 and ieee80211_sta_find_ibss() won't be able to proceed at all, which will keep the interface in the MLME_SEARCH state and hence the loop. So how comes there are remaining STAs in local->sta_list? When ieee80211_ibss_leave() is called from ieee80211_leave_ibss() in cfg.c, sta_info_flush() is called and there are no remaining STAs. But what if ieee80211_ibss_join() is called without prior call to ieee80211_ibss_leave()? I suppose this is when it goes wrong. Is flushing the local->sta_list in ieee80211_ibss_join() a good solution? Please just tell me and I'll happily post a patch. Thanks, Ignacy -- The groove will take you through times without money much better than money will take you through times without groove. -- 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
