Hi Denis,
Btw, now I finally remembered what this also fixes - the whole bridging
mess :-) When we have this, we no longer need hostapd/wpas to be aware
of bridging and capturing frames beneath the bridge - something that's
actually a regression in Linux at some point.
> Do you have any thoughts on what the operations should look like or
> do you want me to take a stab in the dark at this?
Haven't really thought about it that much. I guess it should be similar
to mgmt_tx, quite possibly even just using that same operation?
Similarly, nl80211_register_mgmt() would have to be extended.
We already have NL80211_ATTR_CONTROL_PORT_ETHERTYPE, so perhaps this
should be used for some sort of filtering, i.e. perhaps
nl80211_register_mgmt() could be used with NL80211_ATTR_CONTROL_PORT or
something... Not really sure what the best plan is. Perhaps Jouni has
some other ideas.
It does seem like this shouldn't allow any other data frames to be
intercepted, since the control_port_protocol already requires special
handling in mac80211, but we don't really want to add even more than
that, i.e. I really don't want to see arbitrary ethertype interception
at this level.
> > That's actually not possible, since ordering set_key operations vs.
> > transmitted packets isn't something that's easily done by drivers.
>
> Fair enough, but at least the kernel can do its best to make sure
> that such races do not manifest themselves out into userspace. E.g.
> making sure that PAE events arrive after the connect events, etc.
Yes, having the events across a common path would actually solve that
particular race - not much more though, afaict.
> Makes sense. Should PAE packets always be sent unencrypted? Or
> should userspace be notified whether PAE was received unencrypted and
> send a response with the same flag?
No, they shouldn't always be sent unencrypted. They're specified to be
encrypted, e.g. for GTK rekeying that's required (though some non-IEEE
protocols require unencrypted, NL80211_ATTR_CONTROL_PORT_NO_ENCRYPT.)
Since we don't use the value of this attribute for anything but the TX
path, we can go two ways here:
1) with the new EAPOL-over-nl80211, require userspace to set the
unencrypted flag for every frame where it's needed, i.e. even for
rekeying frames on such non-IEEE protocols
2) if "do not encrypt" isn't specified, use control_port_no_encrypt as
the default value
I think I'd prefer (1), but only slightly, so perhaps it makes sense to
check what's better in the resulting code.
> Also, while we're on this subject. Should the kernel auto-manage
> the LINKMODE and OPERSTATE flags? It would seem that it already has
> the information to do so, and having userspace manage this just
> introduces another source of latency / possibility of race
> conditions, etc.
I'm not convinced that it does have that information in all cases, and
I don't see how that causes race conditions or much latency, since for
client mode userspace would probably just set that together with the
NL80211_STA_FLAG_AUTHORIZED flag?
Anyway - that really should be a separate discussion and project, and
I'd prefer not to take this thread away from the original subject too
much.
johannes
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
