On Tue, 2012-06-26 at 21:18 +0300, Arik Nemtsov wrote: > > And now this is just why it won't work even if we start from a clean > > slate -- I haven't even talked about the backward compatibility aspect, > > running an old supplicant on a driver that expects a ROC. Remember that > > the driver need not give the virtual interface *any* channel time on the > > right channel before needed, so if there's something going on on another > > channel with multi-channel, that vif would never be able to authenticate > > with an old supplicant. > > Well that's a given, if we're introducing new features into hostap to > support multi channel. No, not really -- I'm going to want to rely on this mechanism even for the single-channel case in our driver, everything else would be more like a collection of hacks :-) > > I could also mention how this is a stupid userspace API, you're now > > requiring to call one thing before another call is valid, but then the > > other call is only very briefly valid? If we really wanted ROC, we > > should embed the time for it into the auth/assoc request, I'd say. > > I think all these examples are because of our different definitions > for ROC. If ROC is a recommendation, then we just start the ROC before > starting the connection, and end it after the last EAPOL. > If channel management is implemented in SW, what you're saying is a > must. But the FW can abstract these details. Maybe we should do this > similar to SW/HW scan in mac80211? Well, I understand your point, but I don't think it's that simple. If, as you say, we define this to be a recommendation, then we will require device support for this. You may have that, but with what we're currently seeing from our firmware I don't think it's possible to implement it as a recommendation. Even if I could get it somehow implemented in our device and/or the driver, we'd still be making more assumptions than I'd want to make for this. > > Thinking about that though -- what for connect() calls? Whole new can of > > worms ... > > Not sure what you mean here. nl80211 connect call, where the driver is managing both auth/assoc, sometimes even BSS selection. > > Yes, but it would need this patch and a change to hostapd to add the > > station when it sends the first auth frame: > > http://johannes.sipsolutions.net/patches/kernel/all/LATEST/005-nl80211-full-sta-state.patch > > Ah this is useful on another level as well. Today we have a hack in > the driver to identify the auth-frame reply and add the STA to FW > temporarily :) Yes, I know. It's also useful to address a few other races, it just needs a hostapd implementation. Want to work on it? :-) 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
