Re: Connman WiFi p2p API evaluation

[Patrik Flykt <Patrik Flykt linux intel com>]

        Hi,

On Thu, 2015-01-08 at 16:04 -0600, Dan Williams wrote:

> Hi,
>
> Thomas asked me to look at the Connman P2P/Direct APIs to see if we can
> share some of the interfaces.  I think that's a worthwhile goal, so
> here's a short writeup of where the APIs stand WRT to NetworkManager's
> current D-Bus API.
>
> doc/wifi-p2p-overview.txt
> doc/technology-api.txt
> doc/peer-api.txt
>
> The largest issue is that all the interfaces start with "net.connman".
> If we're going to coordinate on API we should grab some neutral suffix
> to org.freedeskop.XXXX instead.

Yes.

> The second issue is that the APIs have some property-related things that
> aren't org.fdo.DBus.Properties conformant.  I think that's a legacy
> Connman thing, but eg I don't think we want to support the legacy
> net.connman.Peer.GetProperties() style functions or signals.

Yes.

> Summary  (the following from wifi-p2p-overview.txt)
> =======
>
> WiFi P2P is supported as follows:
> - if hardware and wpa_supplicant supports it, a "p2p" technology will
> appear in the technology list
>
> * this appears to refer to the Connman Manager object's
> GetTechnologies() method.  It looks like "Technologies" are somewhat
> like NM's devices, but I'm not sure whether you'll get two Technology
> objects for two separate wifi interfaces?  Patrik?

For any number of devices that are of the same device type there exists
exactly one Technology object in ConnMan. The Technology object is
responsible manipulating - in this case mostly enabling and disabling -
all devices of its type. Enabling or disabling a Technology also causes
other ConnMan D-Bus objects related to only that device type to appear
or disappear.

Thus there is only one Technology for a class of devices and/or
interfaces, e.g. P2P. P2P may end up using multiple WiFi cards but is
presented as having a single Technology object. Turning P2P Technology
on or off causes Peer objects to appear and disappear from D-Bus.

> Anyway, one issue is that even if p2p is supported on a specific wifi
> interface, that interface may have different capabilities that impact
> how p2p can be used.  I don't think we can divorce it entirely from the
> wifi interface it will be using, which the Connman interfaces appear to
> do.  Might be able to work something out here though (see way below).

That is true. But this problem is up to wpa_supplicant in how it deals
with conflicting requests for P2P and STA functionality. So if
wpa_supplicant notices that all WiFi devices are tied up in STA or AP
mode and no concurrent P2P is possible, no P2P D-Bus objects will
appear.

> - "p2p" technology, as for "wifi" technology, supports a Scan() method.
> Such method will trigger a P2P find process. The results will be
> available through the Manager interface, comparable to services being
> available through this same interface after a Scan() on "wifi"
> technology.
>
> * Scan() for p2p discovery sounds fine to me, but we'll have to figure
> out whether this should be on the WiFi device itself, or whether a
> global method is OK.  I can see arguments both ways, but I guess most
> client apps using P2P won't care about wifi at all really, just about
> P2P.

ConnMan lacks a 'device' concept when presenting objects through D-Bus.
Instead it provides all networking objects, Peer objects in case of P2P,
from all devices in response to a Scan(). This in order to decrease the
complexity presented for an application developer. The application can
then filter on the various other D-Bus properties if needed.

> - the result of a "p2p" Scan() consists into a list of "peer" objects
>
> * This we might be able to implement.  It looks like these are top-level
> objects in Connman instead, with no relation to their parent WiFi
> interface through which they will be reached.  But like I said above,
> perhaps most clients using P2P don't actually care how the peer is
> found?  and thus just care about P2P and not the parent wifi interface.

Yes.

> - it is then possible to access peer information, connecting and
> disconnecting it via the Peer API.
>
> * As above, the Peer API might be something we can mostly use as-is if
> we can get a namespace change.
>
>
> API Usage (also from wifi-p2p-overview.txt)
> =========
>
> The UI willing to access to WiFi P2P technology should proceed this way:
> - Request Manager.GetTechnologies() and figure out from the result if
> "p2p" technology is provided. What comes next implies this successful
> case.
>
> * I'd rather have a separate org.fdo.XXX.WiFiP2P interface on the
> top-level object that has a Capabilities properties with flags like
> "none", "client", "group owner".  That would be more generic and then NM
> wouldn't have to deal with technologies.  This interface would also have
> the Scan() method to find peers.

The role of a P2P device is volatile. Sometimes it ends up as the
client, sometimes as the group owner. The role is not really selectable
beforehand and needs to be set as necessary for the situation. As the
P2P role is independent on the upper layer application functionality, a
capability of client or group owner is not useful in this context.

> - Add a listener to signal Manager.PeersChanged(): this signal will
> provide the results of a "p2p" technology Scan().
>
> * I'd rather have this be signal on org.fdo.XXX.WiFiP2P instead, and
> coupled with an "ao" type Peers property that is an array of object
> paths to peers.  There would also be PropertiesChanged signals for
> Peers.

The PeersChanged and PropertiesChanged signals are only needed as D-Bus
ObjectManager is not supported by ConnMan. I'd propose to make the plans
such that ObjectManager provides the objects and that no specialized
signals are needed for these purposes.

> - From the "p2p" technology object, request a Technology.Scan() method.
> This will run for a while a P2P find process.
>
> * I'd rather have this on org.fdo.XXX.WiFiP2P, and it would emit changes
> to the Peers property as above.
>
> - If P2P peers are found, it will be signaled through
> Manager.PeersChanged(). Objects are "Peer" objects. UI might use
> Manager.GetPeers() instead, if listening to a signal is not the
> preferred way.
>
> * as above, I'd rather have a different dbus interface for these.

As above, name change and use of ObjectManager eliminates these problems.

> - Once selected the proper Peer object, request a Peer.Connect() method
> on it so it will connect to it. Peer.Disconnect() will disconnect.
>
> * this should be mostly fine.

Agree.

> The biggest question in my mind is whether the P2P operations can be (or
> should be) completely divorced from the WiFi interface they will be
> using.  Do clients care about the WiFi interface?  Quite possibly they
> don't; imagine a scenario in which you connect to a camera with P2P,
> where the Photos app doesn't care about wifi, it just wants to find some
> remote cameras it can connect to.

I don't think the application or application developer wants to deal
with any more complexity than the absolute minimum needed for getting a
task done. So if there exists a number of interfaces, the application
would anyway end up looking for Peers on each of them as it would be
close to impossible to select a specific one without detailed
environment and installation specific information. As we doubt even an
average user is capable of figuring it all out, all P2P operations are
therefore "global".

> I think there are restrictions in the drivers sometimes with whether
> they can be a Group Owner or client at the same time as a WiFi STA
> though, so clearly there would have to arbitration in some cases to warn
> the user they'd have to disconnect from their AP to do some of the P2P
> stuff.

That one goes to wpa_supplicant, it should deal with such matters.

> Assuming clients don't care about the parent WiFi interface at all, I
> could see this interface being usable:
>
> org.freedesktop.XXXX.WiFiP2P
>   - Scan(): starts a scan for new peers on all capable WiFi devices
>   - Peers: ao: array of object paths of Peer objects
>   - GetPeers()->ao: returns same results as Peers property
>   - PeersChanged(a(oa{sv}), ao): signal containing new peers and their
> properties, and removed peers
>   - standard D-Bus Properties API signals/methods too
>   - RegisterPeerService(a{sv}, bool) - registers local P2P service
>   - UnregisterPeerService(a{sv}) - unregisters local P2P service
>
> org.freedesktop.XXXX.WiFiP2P.Peer
>   - Connect()
>   - Disconnect()
>   - State
>   - Name
>   - IPv4 - ?  How about IPv6?

Only IPv4 has been specified for P2P. But as the kernel creates
link-local IPv6 adressing on all interfaces if not told otherwise, IPv6
might just work.

>   - Services

Cheers,

        Patrik