Re: [RFCv1] mac80211: Adds Software / Virtual AMP 80211

[Johannes Berg <johannes@sipsolutions.net>]

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