]>
Commit | Line | Data |
---|---|---|
f765701f JM |
1 | /** |
2 | \page p2p Wi-Fi Direct - P2P module | |
3 | ||
4 | Wi-Fi Direct functionality is implemented any many levels in the WLAN | |
5 | stack from low-level driver operations to high-level GUI design. This | |
5eb513c3 | 6 | document covers the parts that can be user by wpa_supplicant. However, |
f765701f JM |
7 | it should be noted that alternative designs are also possible, so some |
8 | of the functionality may reside in other components in the system. | |
9 | ||
10 | The driver (or WLAN firmware/hardware) is expected to handle low-level | |
11 | operations related to P2P Power Management and channel scheduling. In | |
12 | addition, support for virtual network interface and data frame | |
13 | processing is done inside the driver. Configuration for these | |
14 | low-level operations is defined in the driver interface: | |
15 | src/drivers/driver.h. This defines both the commands and events used to | |
16 | interact with the driver. | |
17 | ||
18 | P2P module implements higher layer functionality for management P2P | |
19 | groups. It takes care of Device Discovery, Service Discovery, Group | |
20 | Owner Negotiation, P2P Invitation. In addition, it maintains | |
21 | information about neighboring P2P Devices. This module could be used | |
5eb513c3 | 22 | in designs that do not use wpa_supplicant and it could also reside |
f765701f | 23 | inside the driver/firmware component. P2P module API is defined in |
5eb513c3 | 24 | \ref src/p2p/p2p.h. |
f765701f JM |
25 | |
26 | Provisioning step of Group Formation is implemented using WPS | |
5eb513c3 | 27 | (\ref src/wps/wps.h). |
f765701f | 28 | |
5eb513c3 JM |
29 | wpa_supplicant includes code in interact with both the P2P module |
30 | (\ref wpa_supplicant/p2p_supplicant.c) and WPS | |
31 | (\ref wpa_supplicant/wps_supplicant.c). The driver operations are passed | |
f765701f JM |
32 | through these files, i.e., core P2P or WPS code does not interact |
33 | directly with the driver interface. | |
34 | ||
35 | ||
36 | \section p2p_arch P2P architecture | |
37 | ||
38 | P2P functionality affects many areas of the system architecture. This | |
39 | section shows couple of examples on the location of main P2P | |
40 | components. In the diagrams below, green arrows are used to show | |
41 | communication paths from the P2P module to upper layer management | |
42 | functionality and all the way to a GUI that user could use to manage | |
43 | P2P connections. Blue arrows show the path taken for lower layer | |
44 | operations. Glue code is used to bind the P2P module API to the rest | |
45 | of the system to provide access both towards upper and lower layer | |
46 | functionality. | |
47 | ||
48 | \subsection p2p_arch_mac80211 P2P architecture with Linux/mac80211/ath9k | |
49 | ||
50 | An architecture where the P2P module resides inside the | |
5eb513c3 | 51 | wpa_supplicant process is used with Linux mac80211-based drivers, |
f765701f JM |
52 | e.g., ath9k. The following diagram shows the main components related |
53 | to P2P functionality in such an architecture. | |
54 | ||
55 | \image html p2p_arch.png "P2P module within wpa_supplicant" | |
56 | \image latex p2p_arch.eps "P2P module within wpa_supplicant" width=15cm | |
57 | ||
58 | \subsection p2p_arch_umac P2P architecture with UMAC | |
59 | ||
60 | The following diagram shows the main components related to P2P | |
61 | functionality in an architecture where the P2P module resides inside | |
62 | the kernel IEEE 802.11 stack (UMAC in the figure). | |
63 | ||
64 | \image html p2p_arch2.png "P2P module in kernel | |
65 | \image latex p2p_arch2.eps "P2P module in kernel" width=15cm | |
66 | ||
67 | ||
68 | \section p2p_module P2P module | |
69 | ||
70 | P2P module manages discovery and group formation with a single state | |
71 | machine, i.e., only a single operation per device can be in progress | |
72 | at any given time. The following diagram describes the P2P state | |
73 | machine. For clarity, it does not include state transitions on | |
74 | operation timeouts to the IDLE state. The states that are marked with | |
75 | dotted ellipse are listed for clarity to describe the protocol | |
76 | functionality for Device Discovery phase, but are not used in the | |
77 | implementation (the SEARCH state is used to manage the initial Scan | |
78 | and the alternating Listen and Search states within Find). | |
79 | ||
80 | \image html p2p_sm.png "P2P module state machine" | |
81 | \image latex p2p_sm.eps "P2P module state machine" width=15cm | |
82 | ||
83 | \subsection p2p_module_api P2P module API | |
84 | ||
5eb513c3 | 85 | P2P module API is defined in \ref src/p2p/p2p.h. The API consists of |
f765701f JM |
86 | functions for requesting operations and for providing event |
87 | notifications. Similar set of callback functions are configured with | |
88 | struct p2p_config to provide callback functions that P2P module can | |
89 | use to request operations and to provide event notifications. In | |
90 | addition, there are number of generic helper functions that can be | |
91 | used for P2P related operations. | |
92 | ||
93 | These are the main functions for an upper layer management entity to | |
94 | request P2P operations: | |
5eb513c3 JM |
95 | - \ref p2p_find() |
96 | - \ref p2p_stop_find() | |
97 | - \ref p2p_listen() | |
98 | - \ref p2p_connect() | |
99 | - \ref p2p_reject() | |
100 | - \ref p2p_prov_disc_req() | |
101 | - \ref p2p_sd_request() | |
102 | - \ref p2p_sd_cancel_request() | |
103 | - \ref p2p_sd_response() | |
104 | - \ref p2p_sd_service_update() | |
105 | - \ref p2p_invite() | |
f765701f JM |
106 | |
107 | These are the main callback functions for P2P module to provide event | |
108 | notifications to the upper layer management entity: | |
109 | ||
5eb513c3 JM |
110 | - \ref p2p_config::dev_found() |
111 | - \ref p2p_config::go_neg_req_rx() | |
112 | - \ref p2p_config::go_neg_completed() | |
113 | - \ref p2p_config::sd_request() | |
114 | - \ref p2p_config::sd_response() | |
115 | - \ref p2p_config::prov_disc_req() | |
116 | - \ref p2p_config::prov_disc_resp() | |
117 | - \ref p2p_config::invitation_process() | |
118 | - \ref p2p_config::invitation_received() | |
119 | - \ref p2p_config::invitation_result() | |
f765701f JM |
120 | |
121 | The P2P module uses following functions to request lower layer driver | |
122 | operations: | |
123 | ||
5eb513c3 JM |
124 | - \ref p2p_config::p2p_scan() |
125 | - \ref p2p_config::send_probe_resp() | |
126 | - \ref p2p_config::send_action() | |
127 | - \ref p2p_config::send_action_done() | |
128 | - \ref p2p_config::start_listen() | |
129 | - \ref p2p_config::stop_listen() | |
f765701f JM |
130 | |
131 | Events from lower layer driver operations are delivered to the P2P | |
132 | module with following functions: | |
133 | ||
5eb513c3 JM |
134 | - \ref p2p_probe_req_rx() |
135 | - \ref p2p_rx_action() | |
136 | - \ref p2p_scan_res_handler() | |
137 | - \ref p2p_scan_res_handled() | |
138 | - \ref p2p_send_action_cb() | |
139 | - \ref p2p_listen_cb() | |
f765701f JM |
140 | |
141 | In addition to the per-device state, the P2P module maintains | |
142 | per-group state for group owners. This is initialized with a call to | |
143 | p2p_group_init() when a group is created and deinitialized with | |
144 | p2p_group_deinit(). The upper layer GO management entity uses | |
145 | following functions to interact with the P2P per-group state: | |
146 | ||
5eb513c3 JM |
147 | - \ref p2p_group_notif_assoc() |
148 | - \ref p2p_group_notif_disassoc() | |
149 | - \ref p2p_group_notif_formation_done() | |
150 | - \ref p2p_group_match_dev_type() | |
f765701f JM |
151 | |
152 | The P2P module will use following callback function to update P2P IE | |
153 | for GO Beacon and Probe Response frames: | |
154 | ||
5eb513c3 | 155 | - \ref p2p_group_config::ie_update() |
f765701f JM |
156 | |
157 | ||
158 | \section p2p_driver P2P driver operations (low-level interface) | |
159 | ||
160 | The following driver wrapper functions are needed for P2P in addition | |
161 | to the standard station/AP mode operations when the P2P module resides | |
5eb513c3 JM |
162 | within wpa_supplicant: |
163 | - \ref wpa_driver_ops::if_add() | |
164 | - \ref wpa_driver_ops::if_remove() | |
165 | - \ref wpa_driver_ops::remain_on_channel() | |
166 | - \ref wpa_driver_ops::cancel_remain_on_channel() | |
167 | - \ref wpa_driver_ops::send_action() | |
168 | - \ref wpa_driver_ops::probe_req_report() | |
f765701f JM |
169 | |
170 | The following driver wrapper events are needed for P2P in addition to | |
171 | the standard station/AP mode events when the P2P module resides within | |
5eb513c3 JM |
172 | wpa_supplicant: |
173 | - \ref wpa_event_type::EVENT_RX_MGMT | |
174 | - \ref wpa_event_type::EVENT_REMAIN_ON_CHANNEL | |
175 | - \ref wpa_event_type::EVENT_CANCEL_REMAIN_ON_CHANNEL | |
176 | - \ref wpa_event_type::EVENT_RX_PROBE_REQ | |
f765701f | 177 | |
f765701f JM |
178 | |
179 | \section p2p_go_neg P2P device discovery and group formation | |
180 | ||
181 | This section shows an example sequence of operations that can be used | |
182 | to implement P2P device discovery and group formation. The function | |
183 | calls are described based on the P2P module API. The exact design for | |
184 | the glue code outside the P2P module depends on the architecture used | |
185 | in the system. | |
186 | ||
187 | An upper layer management entity starts P2P device discovery by | |
5eb513c3 JM |
188 | calling \ref p2p_find(). The P2P module start the discovery by requesting a |
189 | full scan to be completed by calling \ref p2p_config::p2p_scan(). Results | |
190 | from the scan will be reported by calling \ref p2p_scan_res_handler() and | |
f765701f | 191 | after last result, the scan result processing is terminated with a |
5eb513c3 JM |
192 | call to \ref p2p_scan_res_handled(). The P2P peers that are found during |
193 | the full scan are reported with the \ref p2p_config::dev_found() callback. | |
f765701f JM |
194 | |
195 | After the full scan, P2P module start alternating between Listen and | |
196 | Search states until the device discovery operation times out or | |
5eb513c3 | 197 | terminated, e.g., with a call to \ref p2p_stop_find(). |
f765701f JM |
198 | |
199 | When going into the Listen state, the P2P module requests the driver | |
200 | to be configured to be awake on the listen channel with a call to | |
5eb513c3 | 201 | \ref p2p_config::start_listen(). The glue code using the P2P module may |
f765701f JM |
202 | implement this, e.g., by using remain-on-channel low-level driver |
203 | functionality for off-channel operation. Once the driver is available | |
204 | on the requested channel, notification of this is delivered by calling | |
5eb513c3 | 205 | \ref p2p_listen_cb(). The Probe Request frames that are received during the |
f765701f | 206 | Listen period are delivered to the P2P module by calling |
5eb513c3 JM |
207 | \ref p2p_config::p2p_probe_req_rx() and P2P module request a response to |
208 | these to be sent by using \ref p2p_config::send_probe_resp() callback | |
f765701f JM |
209 | function. If a group owner negotiation from another P2P device is |
210 | received during the device discovery phase, that is indicated to the | |
5eb513c3 | 211 | upper layer code with the \ref p2p_config::go_neg_req_tx() callback. |
f765701f JM |
212 | |
213 | The Search state is implemented by using the normal scan interface, | |
5eb513c3 | 214 | i.e., the P2P module will call \ref p2p_config::p2p_scan() just like in the |
f765701f JM |
215 | full scan phase described. Similarly, scan results from the search |
216 | operation will be delivered to the P2P module using the | |
5eb513c3 | 217 | \ref p2p_scan_res_handler() and \ref p2p_scan_res_handled() functions. |
f765701f JM |
218 | |
219 | Once the upper layer management entity has found a peer with which it | |
220 | wants to connect by forming a new group, it initiates group owner | |
5eb513c3 | 221 | negotiation by calling \ref p2p_connect(). Before doing this, the upper |
f765701f JM |
222 | layer code is responsible for asking the user to provide the PIN to be |
223 | used during the provisioning step with the peer or the push button | |
224 | press for PBC mode. The glue code will need to figure out the intended | |
225 | interface address for the group before group owner negotiation can be | |
226 | started. | |
227 | ||
228 | Optional Provision Discovery mechanism can be used to request the peer | |
229 | to display a PIN for the local device to enter (and vice versa). Upper | |
230 | layer management entity can request the specific mechanism by calling | |
5eb513c3 JM |
231 | \ref p2p_prov_disc_req(). The response to this will be reported with the |
232 | \ref p2p_config::prov_disc_resp() callback. If the peer device started | |
f765701f | 233 | Provision Discovery, an accepted request will be reported with the |
5eb513c3 | 234 | \ref p2p_config::prov_disc_req() callback. The P2P module will |
f765701f JM |
235 | automatically accept the Provision Discovery for display and keypad |
236 | methods, but it is up to the upper layer manegement entity to actually | |
5eb513c3 | 237 | generate the PIN and to configure it with following \ref p2p_connect() call |
f765701f JM |
238 | to actually authorize the connection. |
239 | ||
5eb513c3 | 240 | The P2P module will use \ref p2p_config::send_action() callback to request |
f765701f | 241 | lower layer code to transmit an Action frame during group owner |
5eb513c3 | 242 | negotiation. \ref p2p_send_action_cb() is used to report the result of |
f765701f JM |
243 | transmission. If the peer is not reachable, the P2P module will try to |
244 | find it by alternating between Action frame send and Listen | |
245 | states. The Listen state for this phase will be used similarly to the | |
246 | Listen state during device discovery as described above. | |
247 | ||
248 | Once the group owner negotiation has been completed, its results will | |
5eb513c3 | 249 | be reported with the \ref p2p_config::go_neg_completed() callback. The |
f765701f JM |
250 | upper layer management code or the glue code using the P2P module API |
251 | is responsible for creating a new group interface and starting | |
252 | provisioning step at this point by configuring WPS Registrar or | |
253 | Enrollee functionality based on the reported group owner negotiation | |
254 | results. The upper layer code is also responsible for timing out WPS | |
255 | provisioning if it cannot be completed in 15 seconds. | |
256 | ||
257 | Successful completion of the WPS provisioning is reported with a call | |
5eb513c3 | 258 | to \ref p2p_wps_success_cb(). The P2P module will clear its group formation |
f765701f JM |
259 | state at this point and allows new group formation attempts to be |
260 | started. The upper layer management code is responsible for configuring | |
261 | the GO to accept associations from devices and the client to connect to | |
262 | the GO with the provisioned credentials. GO is also responsible for | |
5eb513c3 | 263 | calling \ref p2p_group_notif_formation_done() as described below. |
f765701f JM |
264 | |
265 | If the WPS provisioning step fails or times out, this is reported with | |
5eb513c3 | 266 | a call to \ref p2p_group_formation_failed(). The P2P module will clear its |
f765701f JM |
267 | group formation state at this point and allows new group formation |
268 | attempts to be started. The upper layer management code is responsible | |
269 | for removing the group interface for the failed group. | |
270 | ||
271 | ||
272 | \section p2p_sd P2P service discovery | |
273 | ||
274 | P2P protocol includes service discovery functionality that can be used | |
275 | to discover which services are provided by the peers before forming a | |
276 | group. This leverages the Generic Advertisement Service (GAS) protocol | |
277 | from IEEE 802.11u and P2P vendor-specific contents inside the Native | |
278 | GAS messages. | |
279 | ||
280 | The P2P module takes care of GAS encapsulation, fragmentation, and | |
281 | actual transmission and reception of the Action frames needed for | |
282 | service discovery. The user of the P2P module is responsible for | |
283 | providing P2P specific Service Request TLV(s) for queries and Service | |
284 | Response TLV(s) for responses. | |
285 | ||
286 | \subsection p2p_sd_query Quering services of peers | |
287 | ||
288 | Service discovery is implemented by processing pending queries as a | |
5eb513c3 | 289 | part of the device discovery phase. \ref p2p_sd_request() function is used |
f765701f | 290 | to schedule service discovery queries to a specific peer or to all |
5eb513c3 | 291 | discovered peers. \ref p2p_sd_cancel_request() can be used to cancel a |
f765701f JM |
292 | scheduled query. Queries that are specific to a single peer will be |
293 | removed automatically after the response has been received. | |
294 | ||
295 | After the service discovery queries have been queued, device discovery | |
5eb513c3 | 296 | is started with a call to \ref p2p_find(). The pending service discovery |
f765701f JM |
297 | queries are then sent whenever a peer is discovered during the find |
298 | operation. Responses to the queries will be reported with the | |
5eb513c3 | 299 | \ref p2p_config::sd_response() callback. |
f765701f JM |
300 | |
301 | \subsection p2p_sd_response Replying to service discovery queries from peers | |
302 | ||
303 | The received service discovery requests will be indicated with the | |
5eb513c3 JM |
304 | \ref p2p_config::sd_request() callback. The response to the query is sent |
305 | by calling \ref p2p_sd_response(). | |
f765701f JM |
306 | |
307 | \subsection p2p_sd_indicator Service update indicator | |
308 | ||
309 | P2P service discovery provides a mechanism to notify peers about | |
310 | changes in available services. This works by incrementing Service | |
311 | Update Indicator value whenever there is a change in the | |
312 | services. This value is included in all SD request and response | |
313 | frames. The value received from the peers will be included in the | |
5eb513c3 | 314 | \ref p2p_config::sd_request() and \ref p2p_config::sd_response() callbacks. The |
f765701f | 315 | value to be sent to the peers is incremented with a call to |
5eb513c3 | 316 | \ref p2p_sd_service_update() whenever availibility of the local services |
f765701f JM |
317 | changes. |
318 | ||
319 | ||
320 | \section p2p_go P2P group owner | |
321 | ||
322 | This section describes how P2P module can be used for managing | |
323 | per-group information in a group owner. The function calls are | |
324 | described based on the P2P module API. The exact design for the glue | |
325 | code outside the P2P module depends on the architecture used in the | |
326 | system. | |
327 | ||
328 | When a P2P group interface is created in group owner role, per-group | |
5eb513c3 | 329 | data is initialized with \ref p2p_group_init(). This call provides a |
f765701f | 330 | pointer to the per-device P2P module context and configures the |
5eb513c3 | 331 | per-group operation. The configured \ref p2p_group_config::ie_update() |
f765701f JM |
332 | callback is used to set the initial P2P IE for Beacon and Probe |
333 | Response frames in the group owner. The AP mode implementation may use | |
334 | this information to add IEs into the frames. | |
335 | ||
336 | Once the group formation has been completed (or if it is skipped in | |
5eb513c3 | 337 | case of manual group setup), \ref p2p_group_notif_formation_done() is |
f765701f JM |
338 | called. This will allow the P2P module to update the P2P IE for |
339 | Beacon and Probe Response frames. | |
340 | ||
341 | The SME/MLME code that managements IEEE 802.11 association processing | |
342 | needs to inform P2P module whenever a P2P client associates or | |
343 | disassociates with the group. This is done by calling | |
5eb513c3 | 344 | \ref p2p_group_notif_assoc() and \ref p2p_group_notif_disassoc(). The P2P module |
f765701f JM |
345 | manages a list of group members and updates the P2P Group Information |
346 | subelement in the P2P IE based on the information from the P2P | |
5eb513c3 | 347 | clients. The \ref p2p_group_config::ie_update() callback is used whenever |
f765701f JM |
348 | the P2P IE in Probe Response frames needs to be changed. |
349 | ||
350 | The SME/MLME code that takes care of replying to Probe Request frames | |
5eb513c3 | 351 | can use \ref p2p_group_match_dev_type() to check whether the Probe Request |
f765701f JM |
352 | frame request a reply only from groups that include a specific device |
353 | type in one of the clients or GO. A match will be reported if the | |
354 | Probe Request does not request a specific device type, so this | |
355 | function can be used to filter or received Probe Request frames and | |
356 | only the ones that result in non-zero return value need to be replied. | |
357 | ||
358 | When the P2P group interface for GO role is removed, | |
5eb513c3 | 359 | \ref p2p_group_deinit() is used to deinitialize the per-group P2P module |
f765701f JM |
360 | state. |
361 | ||
362 | ||
363 | \section p2p_ctrl_iface P2P control interface | |
364 | ||
5eb513c3 | 365 | wpa_supplicant \ref ctrl_iface_page "control interface" can be used |
f765701f JM |
366 | to manage P2P functionality from an external program (e.g., a GUI or a |
367 | system configuration manager). This interface can be used directly | |
368 | through the control interface backend mechanism (e.g., local domain | |
369 | sockets on Linux) or with help of wpa_cli (e.g., from a script). | |
370 | ||
371 | The following P2P-related commands are available: | |
372 | - \ref ctrl_iface_P2P_FIND P2P_FIND | |
373 | - \ref ctrl_iface_P2P_STOP_FIND P2P_STOP_FIND | |
374 | - \ref ctrl_iface_P2P_CONNECT P2P_CONNECT | |
375 | - \ref ctrl_iface_P2P_LISTEN P2P_LISTEN | |
376 | - \ref ctrl_iface_P2P_GROUP_REMOVE P2P_GROUP_REMOVE | |
377 | - \ref ctrl_iface_P2P_GROUP_ADD P2P_GROUP_ADD | |
378 | - \ref ctrl_iface_P2P_PROV_DISC P2P_PROV_DISC | |
379 | - \ref ctrl_iface_P2P_SERV_DISC_REQ P2P_SERV_DISC_REQ | |
380 | - \ref ctrl_iface_P2P_SERV_DISC_CANCEL_REQ P2P_SERV_DISC_CANCEL_REQ | |
381 | - \ref ctrl_iface_P2P_SERV_DISC_RESP P2P_SERV_DISC_RESP | |
382 | - \ref ctrl_iface_P2P_SERVICE_UPDATE P2P_SERVICE_UPDATE | |
383 | - \ref ctrl_iface_P2P_SERV_DISC_EXTERNAL P2P_SERV_DISC_EXTERNAL | |
384 | - \ref ctrl_iface_P2P_REJECT P2P_REJECT | |
385 | - \ref ctrl_iface_P2P_INVITE P2P_INVITE | |
386 | ||
387 | The following P2P-related events are used: | |
388 | - \ref ctrl_iface_event_P2P_EVENT_DEVICE_FOUND P2P-DEVICE-FOUND | |
389 | - \ref ctrl_iface_event_P2P_EVENT_GO_NEG_REQUEST P2P-GO-NEG-REQUEST | |
390 | - \ref ctrl_iface_event_P2P_EVENT_GO_NEG_SUCCESS P2P-GO-NEG-SUCCESS | |
391 | - \ref ctrl_iface_event_P2P_EVENT_GO_NEG_FAILURE P2P-GO-NEG-FAILURE | |
392 | - \ref ctrl_iface_event_P2P_EVENT_GROUP_FORMATION_SUCCESS P2P-GROUP-FORMATION-SUCCESS | |
393 | - \ref ctrl_iface_event_P2P_EVENT_GROUP_FORMATION_FAILURE P2P-GROUP-FORMATION-FAILURE | |
394 | - \ref ctrl_iface_event_P2P_EVENT_GROUP_STARTED P2P-GROUP-STARTED | |
395 | - \ref ctrl_iface_event_P2P_EVENT_GROUP_REMOVED P2P-GROUP-REMOVED | |
396 | - \ref ctrl_iface_event_P2P_EVENT_PROV_DISC_SHOW_PIN P2P-PROV-DISC-SHOW-PIN | |
397 | - \ref ctrl_iface_event_P2P_EVENT_PROV_DISC_ENTER_PIN P2P-PROV-DISC-ENTER-PIN | |
398 | - \ref ctrl_iface_event_P2P_EVENT_SERV_DISC_REQ P2P-SERV-DISC-REQ | |
399 | - \ref ctrl_iface_event_P2P_EVENT_SERV_DISC_RESP P2P-SERV-DISC-RESP | |
400 | - \ref ctrl_iface_event_P2P_EVENT_INVITATION_RECEIVED P2P-INVITATION-RECEIVED | |
401 | - \ref ctrl_iface_event_P2P_EVENT_INVITATION_RESULT P2P-INVITATION-RESULT | |
402 | ||
403 | ||
404 | \subsection p2p_wpa_gui GUI example (wpa_gui) | |
405 | ||
406 | wpa_gui has an example implementation of a GUI that could be used to | |
407 | manage P2P operations. The P2P related functionality is contained | |
408 | mostly in wpa_supplicant/wpa_gui-qt4/peers.cpp and it shows how the | |
409 | control interface commands and events can be used. | |
410 | ||
411 | ||
412 | \subsection p2p_wpa_cli wpa_cli example | |
413 | ||
5eb513c3 | 414 | wpa_cli can be used to control wpa_supplicant in interactive |
f765701f JM |
415 | mode. The following sessions show examples of commands used for |
416 | device discovery and group formation. The lines starting with "> " are | |
417 | commands from the user (followed by command result indication) and | |
5eb513c3 | 418 | lines starting with "<2>" are event messages from wpa_supplicant. |
f765701f JM |
419 | |
420 | P2P device "Wireless Client": | |
421 | ||
422 | \verbatim | |
423 | > p2p_find | |
424 | OK | |
425 | > <2>P2P-DEVICE-FOUND 02:40:61:c2:f3:b7 p2p_dev_addr=02:40:61:c2:f3:b7 | |
426 | pri_dev_type=1-0050F204-1 name='Wireless Client 2' config_methods=0x18c | |
427 | dev_capab=0x1 group_capab=0x0 | |
428 | <2>P2P-GO-NEG-REQUEST 02:40:61:c2:f3:b7 | |
429 | <2>P2P-GO-NEG-REQUEST 02:40:61:c2:f3:b7 | |
430 | > p2p_connect 02:40:61:c2:f3:b7 pbc | |
431 | OK | |
432 | <2>P2P-GO-NEG-SUCCESS | |
433 | <2>P2P-GROUP-FORMATION-SUCCESS | |
434 | <2>P2P-GROUP-STARTED sta0-p2p-0 client DIRECT-vM | |
435 | > interface | |
436 | Available interfaces: | |
437 | sta0-p2p-0 | |
438 | sta0 | |
439 | > p2p_group_remove sta0-p2p-0 | |
440 | <2>P2P-GROUP-REMOVED sta0-p2p-0 client | |
441 | OK | |
442 | > term | |
443 | OK | |
444 | \endverbatim | |
445 | ||
446 | ||
447 | P2P device "Wireless Client2" (which ended up operating in GO role): | |
448 | ||
449 | \verbatim | |
450 | > p2p_find | |
451 | OK | |
452 | <2>P2P-DEVICE-FOUND 02:f0:bc:44:87:62 p2p_dev_addr=02:f0:bc:44:87:62 | |
453 | pri_dev_type=1-0050F204-1 name='Wireless Client' config_methods=0x18c | |
454 | dev_capab=0x1 group_capab=0x0 | |
455 | > p2p_connect 02:f0:bc:44:87:62 pbc | |
456 | OK | |
457 | <2>P2P-GO-NEG-SUCCESS | |
458 | <2>P2P-GROUP-FORMATION-SUCCESS | |
459 | <2>P2P-GROUP-STARTED sta1-p2p-0 GO DIRECT-vM | |
460 | > interface | |
461 | Available interfaces: | |
462 | sta1-p2p-0 | |
463 | sta1 | |
464 | > p2p_group_remove sta1-p2p-0 | |
465 | <2>P2P-GROUP-REMOVED sta1-p2p-0 GO | |
466 | OK | |
467 | > term | |
468 | OK | |
469 | \endverbatim | |
470 | ||
471 | */ |