Table of Contents

What this is about

For an introduction see the slides for the “Wi-Fi Peer-to-Peer on Linux” talk given by Johannes Berg during the Linux Plumbers Conference 2010.

Basic P2P Architecture Stack

          |  <---------- D-Bus Application API
+--------------------+
| connection manager |
| or p2p control app |
+--------------------+
          |  <---------- D-Bus supplicant API
          |              or socket control interface
+--------------------+
| wpa_supplicant     |
+--------------------+
          |  <---------- nl80211
+--------------------+
| cfg80211           |
+--------------------+
          |  <---------- struct API
+--------------------+
| mac80211           |
+--------------------+
          |  <---------- mac80211's driver API
+--------------------+
| driver             |
+--------------------+

Interfaces

D-Bus Application API

NOTE: This doesn't exist yet! There's no integration
      with connection managers or any other control
      application yet!

We're currently working on seeing if this is at all feasible to define, but it would be good if applications could use a standard API that the connection manager offers. There are multiple reasons for having the connection manager offer this, like the need for a coordinator of all wifi usage.

Since there are multiple connections managers, a good approach to defining this would be a freedesktop.org standard.

supplicant API

D-Bus API

API has been posted for review: http://thread.gmane.org/gmane.linux.drivers.hostap/22469

socket control interface

This interface offers basic P2P primitives like p2p_find, p2p_stop_find, p2p_connect, etc.

Here's a full list:

Both D-Bus and socket interfaces (will) also have events indicating when new P2P devices were found, etc.

nl80211

Currently, the P2P-related extensions are:

cfg80211's struct API

This just mirrors nl80211 with function/method calls etc.

mac80211's driver API

Interface types

nl80211/cfg80211 currently define the P2P interface types P2P_CLIENT and P2P_GO, but wpa_supplicant doesn't use them, it still uses regular STA/AP interfaces. This is mostly because we haven't figured out a good way in the supplicant to distinguish between normal “STA” and P2P-client yet. The new P2P interface types will be needed later.

Driver considerations

Drivers must currently only support AP and STA modes, and must be able to function during off-channel periods. They must also be able to receive probe requests even while in station mode, as indicated by mac80211 by the FIF_PROBE_REQ filter flag.

With the patches that I'm working on, drivers may optionally implement the p2p_start_listen/stop_listen callback to allow offload to the device for these operations. Additionally, they will be able to implement off-channel TX callbacks (but this is still WIP).