On 01/25/2013 04:45 PM, Johannes Berg wrote: > On Thu, 2013-01-03 at 16:05 -0500, Will Hawkins wrote: >> Sorry for the delay responding! > > Haha, 1.5 days. I win at delaying ;-( > >>>> Anyway this part is really confusing. If userspace is handling >>>> auth frames, should the kernel really mark the station as >>>> authenticated? What then is the point in handling auth frames in >>>> userspace?? >>>> >>>> Will? >>> >>> Actually I don't know. Maybe Will can help us in understanding how >>> to handle this point. I simply kept the same behaviour: before this >>> (my) patch a station was marked as AUTHenticated in by the kernel, >>> even if userspace registered for AUTH frames, and the same I'm >>> doing here. >> >> It does *not* appear that Antonio's patch changes the logic that I put >> in place with my earlier patch. For me, the userspace application >> *authorizes* the station rather than *authenticates*. In other words, >> no matter whether or not the userspace application is registered for >> AUTH frames, the new station is assumed to be authenticated. Once the >> two stations are authenticated the key exchange begins (over AUTH >> frames) to determine if the stations are authorized. >> >> Johannes, what are your thoughts on the differences between the >> semantics of authenticated and authorized. I am definitely in over my >> head so please correct me where I've gone wrong. :-) > > That makes sense, you handle the SAE authentication and then mark the > station as authorized, which is perfectly fine. But that really mostly > means you don't care about the authenticated state at all, and there's > no real associated state anyway ... > >> I would be okay with this approach. I think that it would be fairly >> easy to essentially move the logic up a level and protect the >> transition to AUTH rather than AUTHORIZED. > > Well, you'd have to do both, and we also can't break the userspace API > now. > >>> This is a behaviour I introduced some time ago: >>> >>> 1153 sdata->u.ibss.control_port = params->control_port; >>> >>> which is set based on NL80211_ATTR_CONTROL_PORT and at the moment, >>> in IBSS, I think it is only set by wpa_supplicant when using >>> IBSS/RSN..you told me to use control_port instead of creating >>> another member..but maybe it is general and could be used for >>> something else? > > It could be used for something else. > >> The userspace application that I am writing does use the control port >> in IBSS. My goal is to integrate my userspace application with >> wpa_supplicant so eventually there will be convergence. In fact, >> Antonio's new message is critical to this integration. :-) > > That I don't understand? Why does it need the new event? Wouldn't > completing the SAE handshake be sufficient information? It does not need the new event, necessarily. I was just hoping to use that event to know when to kick off the SAE handshake with a new node. Something along the lines of NL80211_CMD_NEW_PEER_CANDIDATE in the world of 802.11s. With the code as it stands, I plan on using the NEW_STA event to start that process, but I was hoping for something that would indicate the station was authenticated (in case there was ever a time that we wanted to layer SAE on top of explicit authentication). Will > > 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
