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. 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? <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. Regards Marcel -- 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
