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

[Andrei Emeltchenko <Andrei.Emeltchenko.news@gmail.com>]

Hi Marcel,

On Wed, Apr 18, 2012 at 01:51:19PM +0200, Marcel Holtmann wrote:
> Hi Andrei,
> 
> > > > > > >> I don't get this patch at all. Why am I reviewing some very very basic
> > > > > > >> skeleton code when we should be discussing userspace APIs (we have
> > > > > > >> already discussed them with a few people years ago), how the AMP is
> > > > > > >> going to be managed, how the security handshake is going to work, etc.
> > > > 
> > > > Do we have some outcome from that discussion?
> > > 
> > > This API-defining patch is probably the best we have:
> > > http://johannes.sipsolutions.net/patches/kernel/all/2010-10-13-15%
> > > 3a24/035-bt3-amp.patch
> > 
> > Thanks for the link. After looking to the patches I think that there are
> > some similarities with respect to interface type. As I understood the
> > basic idea is the same: create virtual interface. But in your case the
> > implementation is really difficult.
> > 
> > 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.

I think we can start with creating softAMP in advance.

> 
> 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.

A2MP might work without AMP present on the system. Do we need to create
AMP after "Discover AMP" requests? I believe we might be too smart here.
but this is possibly.

> 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?

IMO this shall be the case.

> 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?

If we create virtual interface then netdev is allocated and we can handle
it with common tools.

> <snip>
> 
> > > > > The whole AMP control goes via A2MP and L2CAP and both are fully
> > > > > implemented inside the kernel. In theory we do not even need to expose
> > > > > HCI AMP interfaces to userspace.
> > > > 
> > > > Johannes, you can think of SoftAMP as analog of SoftMAC (vs FullMAC).
> > > > SoftMAC is also possible to implement in user space but only
> > > > authentication is done this way.
> > > 
> > > Yeah, and we also implement roaming and crypto stuff in userspace, for
> > > softmac. Heck, we implement crypto in userspace even for fullmac, so
> > > really ...
> > 
> > Does crypto stuff mean getting symmetric key?
> > 
> > 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 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 do agree here with Marcel.

Best regards 
Andrei Emeltchenko