On 4/18/2012 4:51 AM, Marcel Holtmann wrote:
Why do we need netlink commands like NL80211_CMD_HCI_AMP_ADD and
NL80211_CMD_HCI_AMP_DELETE if what we need is to create/delete virtual
interface which can be done with standard tools with a several lines
patch to iw:
if we put the crypto piece aside for a minute, then we need to decide
who is creating the actual AMP virtual interface on mac80211.
And here the problem starts. That part is actually not triggered from
userspace via wpa_supplicant. It is triggered over the A2MP (AMP manager
protocol) that runs inside the Bluetooth stack in the kernel.
Or is the idea to always keep the AMP virtual interface around? Meaning
that as soon as we have a mac80211 card, we have an AMP virtual
interface if the driver supports it?
This is also a little bit of confusing since FullMac cards will not
create an AMP virtual interface. With them you just see the HCI AMP
controller on the Bluetooth side. Can an AMP virtual interface be just
virtual inside mac80211 or does it have to have a netdev attached to it?
It shouldn't have a netdev, hence the separate commands (though I'll
admit it's also possible to use the same commands, if a bit confusing).
However, wpa_s would probably keep it around for use by BT whenever it
didn't conflict with other wifi usage, e.g. when a device like ours has
a limited number of MAC contexts you can create and use.
I see that all commands by default are sent via netlink to wpa_supplicant.
I think that we can send those command which cannot be handled by us
directly but I believe most command might be handled directly.
The crypto itself is done either in hardware or with the kernel crypto
framework. Just the EAP part is done inside wpa_supplicant.
With the changes that we did for Bluetooth and its management interface,
all the link keys are present in the kernel. And these are used as the
WPA2 PSK. I don't think it is a good idea to push these around into
userspace to wpa_supplicant one more time. And we would need to do that
since bluetoothd has no option to hand them out.
I don't see that as a problem, since they're just HCI commands and the
kernel just has to sort them into "for management" and "for data path",
the former going to userspace.
I still think that WPA2 PSK only EAP implementation for Bluetooth AMP
controllers would be a good idea in the kernel. It has nothing to do
with policy or user input in this specific case. The roundtrip into
userspace for doing EAP 4-way handshake and some HMAC-SHA1 where the PSK
is already present in kernel space seems really pointless.
I disagree -- I think rewriting crypto code is almost always a bad idea,
and code reuse is good.
Beside this though, we need wpa_s managing the concurrency aspect
anyway, so even if we had it in the kernel it wouldn't really change much.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
