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