Wi-Fi Direct Group Ownership: Recover Persistent Peer Sessions Without Assuming a Router

A Wi-Fi Direct persistent group is retained configuration for a group relationship, not an always-running network. Recovery must establish which device is the Group Owner, whether the live group exists, whether both peers retain compatible state, and whether the application endpoint has returned. A remembered peer name or local network identifier answers only part of that chain.

This guide pins behavior to wpa_supplicant 2.11 with its optional P2P support and an appropriate Linux driver. It does not assume Android exposes every control command, nor that every radio supports the required concurrent interface combination. Infrastructure AP reconnection and DPP onboarding are separate workflows. All formation and recovery tests require an authorized peer pair and lawful channel operation.

Separate three identities and two lifetimes

Item	What it identifies	What must not be assumed
P2P device identity	The peer used for discovery and formation	That a display name authenticates the product
Persistent network identifier	A retained local supplicant configuration entry	That the same number means the same group on another device
Live group interface	The interface currently carrying the group	That its name remains valid after removal or recreation
Retained group state	Material available for reinvocation	That an active group or socket exists
Application session	The authenticated instrument/data exchange	That group formation completes application recovery

The 2.11 README documents list_networks as including stored persistent-group information, with its local identifier used by group-add or invitation operations. Keep that reference in a versioned local record and resolve it again after configuration changes. Do not hard-code an example network number into a product reconnect path. wpa_supplicant 2.11, README-P2P

Also verify actual persistence across a power cycle. A group marked persistent in current runtime state does not prove that the product’s configuration owner committed the state durably. The reference implementation’s configuration-write path is conditional. Treat storage ownership and reboot recovery as an acceptance case, not an implication of the word “persistent.”

Identify how the Group Owner is selected

The reference p2p_connect flow can include GO negotiation, interface setup, provisioning and data-connection establishment. Its join option instead joins an existing group and skips GO negotiation. p2p_group_add can create an autonomous GO without negotiating with a particular peer. These are different paths and need different expected events. wpa_supplicant 2.11 group-formation controls

GO intent ranges from zero through fifteen in this interface. Do not configure both peers to insist on being GO: the 2.11 negotiation code has an explicit incompatible-intent failure when both choose fifteen. A desired role is not evidence of the negotiated role. Record the actual group-start event and group-interface status before opening the application service.

A product can intentionally constrain one instrument to be GO, but it then owns that availability dependency. Losing that device can remove the network on which clients depended. Do not silently describe the remaining client as a replacement router or assume automatic role takeover without an implemented and qualified recovery policy.

Classify persistent-state disagreement

The 2.11 invitation interface distinguishes inviting a peer into a running group from reinvoking a persistent group. For a retained group, determine which peer is expected to be GO and which local entry represents that relationship. Preserve invitation status separately from final group-start status. The implementation has explicit unknown-group handling; an invitation response is more useful than a generic reconnect timeout. wpa_supplicant 2.11, README-P2P and p2p_supplicant.c

Build a two-sided matrix: both peers retain the group, only the GO retains it, only the client retains it, or neither retains it. A failed invitation in an asymmetric case may require an authorized fresh-formation workflow. It is not permission to erase all saved Wi-Fi configuration. Remove or replace only the intended relationship through the product’s approved ownership process.

Keep logs sanitized before exporting them. In the 2.11 source, the control-interface group-start message can include a PSK or passphrase, while the ordinary debug-log version deliberately omits those fields. Capturing raw control events into a support bundle can therefore expose credentials even when the console log looks safe.

Use the right teardown operation

p2p_cancel cancels formation and joining-related work. Its documented behavior removes a group interface still in the provisioning step, but does not terminate a group after that step has completed. p2p_group_remove terminates the specified live group and removes its dedicated virtual interface where one was created. Neither description should be confused with deleting a retained configuration entry. wpa_supplicant 2.11 cancellation and group-removal contracts

These are source-checked operation descriptions, not commands executed for this article. A product controller should serialize formation, cancellation and group removal, track the current group-interface lifetime, and reject late events from retired attempts. Verify the terminal state before starting a replacement operation.

Qualify owner loss and reinvocation

1. Baseline each intended role. Record the actual GO/client roles, persistent local references, group interface, address configuration and authenticated application service. Keep discovery success separate from all later stages.
2. Restart the client only. Verify whether retained state is durable and whether reinvocation or joining the still-running group follows the intended path.
3. Restart or remove the GO. Require explicit loss handling, bounded retries and a declared recovery policy. Check fresh addressing and socket reconstruction after the owner returns.
4. Create asymmetric retained state. On disposable test profiles, remove the intended group relationship on one side only. Verify a specific failure and authorized re-formation path without clearing unrelated profiles.
5. Cancel at two stages. Cancel during formation, then separately test stopping an established group. Confirm that the controller uses the operation matching the observed stage.
6. Repeat with the required concurrent roles. If infrastructure Wi-Fi must coexist, qualify the actual driver/firmware combination and legal channel constraints. A successful standalone P2P group does not prove concurrent support.

For a hypothetical camera and handheld controller, the camera is the fixed GO. After camera replacement, the handheld’s old persistent entry cannot establish that the new camera is authorized or has compatible group state. The recovery workflow must identify the replacement and perform the approved formation process, rather than trusting a reused product name.

Release evidence

No P2P discovery, group formation, credential change or radio test was executed here. The official 2.11 source and control documentation were inspected. Release with the role policy, two-sided persistence matrix, stage-correct teardown behavior and application-recovery evidence. That makes owner loss a defined product state rather than an unexplained absence of a router.