After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 734073 - [enh] Add support for WiFi P2P (aka WiFi Direct)
[enh] Add support for WiFi P2P (aka WiFi Direct)
Product: NetworkManager
Classification: Platform
Component: Wi-Fi
Other Linux
: Normal normal
: ---
Assigned To: Alberto Fanjul
NetworkManager maintainer(s)
Depends on:
Blocks: nm-next
Reported: 2014-07-31 19:40 UTC by Dan Williams
Modified: 2019-02-15 07:29 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Dan Williams 2014-07-31 19:40:46 UTC
WiFi Direct is a WiFi feature that allows you to talk directly to consumer devices or other computer on a one-to-one basis.  For example, you could connect to your WiFi-enabled camera and transfer pictures instead of hooking up with a cable.  Or talk to a picture frame.  Or another laptop to exchange files.

It does this by virtualizing the wifi card and creating a second kernel wifi network interface that can be used to scan for the other device and connect to it.  It is based on AP+STA mode instead of Ad-Hoc and requires driver support due to the AP-mode requirement.

wpa_supplicant supports most of the functionality we'd want already.

The open issues are around constraints (eg driver/hardware capabilities) and UI design, such as:

1) if the driver is not capable of staying connected to the AP while talking to a device with P2P, we need to tell the user that this will break their network connection and let them allow/deny.  This could be due to driver limitations, or because the card doesn't have dual radios and the AP is on 2.4GHz but the device is on 5GHz.

2) What does the NM API look like?  These connections are temporary and shouldn't be saved anywhere.  It should probably be a new D-Bus interface that NMDeviceWifi implements.  There are two cases: (a) P2P Client (STA-like) and (b) P2P Group Owner (AP-like).  For the most part, both peers are visible ("listen" mode) you can just run a "connect" operation and they'll figure out who is the owner and who is the client automatically.

3) Once you've formed/joined a group and can talk to the peer, there's also Service Discovery to find out what you can actually do with the peer.  This is starting to get out of the realm of NetworkManager, but unfortunately the interface to do this is still via wpa_supplicant.  So should NetworkManager implement SD passthrough, or do we somehow need to tell clients the wpa_supplicant D-Bus path of the p2p network interface so they can do it themselves after talking to NM to set up the link?

Further reference:
Comment 1 Thomas Haller 2015-01-14 14:30:39 UTC
See also the thread on our mailing list from 08 Jan 2015, "Connman WiFi p2p API evaluation":
Comment 2 Alberto Fanjul 2017-03-06 12:32:08 UTC
I will try to migrate wifi p2p into network manager to resolve this
Comment 3 Thomas Haller 2018-10-19 15:26:50 UTC
Work in progress:
Comment 5 Thomas Haller 2019-02-15 07:29:01 UTC
Ah yes, should be fixed with upcoming 1.16.0 release of NetworkManager (which is not yet out).

All missing features and bugs beyond this deserve their own bugzilla/issues.

Thanks to Benjamin.

Maybe an interesting read is what Benjamin wrote about miracast (gnome-screencast):