On Fri, 2011-09-16 at 13:27 +0200, Marek Lindner wrote: > > Right. So that means you shouldn't be rejecting the configuration when > > actually using it. You should be rejecting it when it's actually set. > > I'd like to remind you that it was not me who designed the original check (my > patch does not add anything new). If you are looking for somebody to beautify > your code you'll have to look somewhere else. If you're looking to fix a problem, I told you how to fix it. If you're just reporting a bug along with "this is what I think the fix might be" then maybe you shouldn't take rejection of the proposal so badly. I was, maybe erroneously, assuming that you wanted to fix the issue. > As I said: Feel free to propose an alternative patch. I certainly won't. Fair enough. I take it you're just reporting a bug then. > > Also, this patch is wrong -- at that point, checking for zero address serves > > a difference purpose I think, it means more something along the lines of > > "did we previously find an IBSS". > > Can't agree here. This check was conceived to hinder a fixed-bssid > configuration of 00:00:00:00:00:00. You just said that you didn't originally design it so how do you know the design intent? :-) FWIW, I think the check there pre-dates the current cfg80211/mac80211 design. The current assumption in mac80211 clearly is that ifibss->bssid is *always* valid since it's set to a random address when asked to join. Hence the only way it can be invalid is the bug case you reported (join fixed zeroes BSSID). Anyway. The right fix remains in cfg80211, and the is_zero_ether_addr() check in mac80211 can be deleted as it is completely pointless since it'll never be false. johannes -- 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
