Negotiation of a peer to GO client role

This is a creation in Article, where the information may have evolved or changed.

1-Peer GO client negotiation process

Negotiation process
The negotiation process for peer-to go/client requires just a few simple steps, such as:
Peer Connection Initiator: refers to a machine that initiates a peer-to-peer connection during a peer-to connection, with a representation;
Peer Connection Receiver: refers to the machine that accepts peer connection in the process of peer connection, with B;

Figure 1 Peer-to go/client negotiation process
As shown in the following:
1. First, a "GO negotiation Request" is sent to B after the initial preparation of the peer connection is completed;
2, and at this time, B is not ready, then B save the negotiation information of a, and then send a "GO negotiation Response" to a, the Response contains the negotiation information of B, but in the Response, B set the status state to P2p_ Sc_fail_info_currently_unavailable, indicates that the current peer-to connection is not available;
3, a after receiving the response, save the negotiation information of B, switch to the listen state, wait for the peer to the completion of B-connection initialization, and wait for B to send "GO negotiation Request". So the first consultation did not determine anything, mainly to inform the b,a need to connect with B;
4, b After sending the "Go negotiation Response", the peer to the connection to initialize, b after the peer-to connection initialization is complete, send a "go negotiation Request" to A;
5, and a after receiving the request of B, according to the request of the consultation information, you can determine their role in the peer-to connect. At this point a sends a "GO negotiation Response" to B, in the Response, the state is p2p_sc_success, indicating that it can be connected to the peer;
6, B after receiving the response of a, you can also determine their role in the peer connection;
7, the last B send a "GO negotiation Confirm" to a, one of the Confirm role is as a confirmation of the consultation, while determining the channel used by the back-to-peer connection;

After the peer-to go/client negotiation is complete, the device that acts as the go role switches itself to AP mode, and the device acting as the client role connects to the go AP.

Request/response content during negotiation
Content of Request:
* Dialog Token:1
Parsing WPS IE
Device Password Id:4
Parsing-Peer IE
Attribute 2 Length 2
* Device Capability Group Capability 2a
Attribute 4 Length 1
* GO intent:intent 6 Tie Breaker 0
Attribute 5 Length 2
* Configuration Timeout
Attribute 6 Length 5
* Listen channel:country XX (0x04) Regulatory Class Bayi Channel number 6
Attribute 9 Length 6
* Intended peer Interface address:96:bd:db:15:b9:38
Attribute Length 16
* Channel list:country String ' XX (0x04) '
Attribute Length 33
* Device INFO:ADDR 96:bd:db:15:b9:38 primary device type 10-0050F204-5 device name ' android_dd11 ' config methods 0x80
Attribute Length 5
* Operating channel:country XX (0x04) Regulatory Class Bayi Channel number one Peer country-hexdump (len=3): 58 58 04
where * GO intent:intent 6 Tie breaker 0 is used to determine the go/client role.

Response的部分内容：

* Dialog Token:2
Parsing WPS IE
Device Password id:0
Parsing-Peer IE
Attribute 0 Length 1
* Status:1
Attribute 2 Length 2
* Device Capability Group Capability 00
Attribute 4 Length 1
* GO intent:intent 6 Tie Breaker 0
Attribute 5 Length 2
* Configuration Timeout
Attribute Length 5
* Operating channel:country XX (0x04) Regulatory Class Bayi Channel number 11
Attribute 9 Length 6
* Intended peer Interface address:96:bd:db:15:b9:38
Attribute Length 16
* Channel list:country String ' XX (0x04) '
Attribute Length 33
* Device INFO:ADDR 96:bd:db:15:b9:38 primary device type 10-0050F204-5 device name ' android_dd11 ' config methods 0x188

Confirm的部分内容：

* Dialog Token:1
Parsing-Peer IE
Attribute 0 Length 1
* status:0
Attribute 2 Length 2
* Device Capability Group Capability 00
Attribute Length 5
* Operating channel:country XX (0x04) Regulatory Class Bayi Channel number 11
Attribute Length 16
* Channel list:country String ' XX (0x04) '

Peer-to-peer commands when connecting to peers
Connect to the Initiator command:
P2p-dev-wlan0:control interface Command ' P2p_find 120 '
P2p-dev-wlan0:control interface command ' P2p_stop_find '
P2p-dev-wlan0:control interface command ' P2p_peer 96:bd:db:15:b9:38 '
P2p-dev-wlan0:control interface command ' P2p_peer 96:bd:db:15:b9:38 '
P2p-dev-wlan0:control interface command ' P2p_prov_disc 96:bd:db:15:b9:38 PBC '
P2p-dev-wlan0:control interface command ' P2p_peer 96:bd:db:15:b9:38 '
P2p-dev-wlan0:control interface command ' p2p_connect 96:bd:db:15:b9:38 PBC persistent go_intent=6 '
P2p-dev-wlan0:control interface command ' List_networks '
P2p-dev-wlan0:control interface Command ' get_network 0 mode '
P2P-WLAN0-1: Control interface command ' SET p2p_group_idle 10 '
P2P-WLAN0-1: Control interface command ' SET p2p_group_idle 0 '
Different manufacturers to achieve the same way WLAN port, this is just a way to achieve, wherein the P2P-DEV-WLAN0 for the virtual network port, in peer scanning, negotiation phase is the use of the network port, p2p-wlan0-1 the core of the actual registration of the network port, the actual peer connection is the use of the network port, The P2P-WLAN0-1 network port is created when the P2p_connect command is received, and the manufacturer p2p-wlan0-1 the network port is created by the supplicant layer nl80211 driver The Add function calls the kernel for creation and eventually calls to the WiFi-powered wl_cfg80211_add_virtual_iface for the creation of the network port, which, although it appears to only increase the virtual network port, can also create the actual network port, Both the P2p-dev-wlan0 (virtual network port) and the P2p-wlan0-1 (actual gateway) are created by the function. The entire negotiation process here begins when the P2p_connect command is received.

Connect to the Initiator command:
P2p-dev-wlan0:control interface Command ' P2p_find 120 '
P2p-dev-wlan0:control interface command ' P2p_stop_find '
P2p-dev-wlan0:control interface command ' P2p_peer 96:bd:db:15:b9:38 '
P2p-dev-wlan0:control interface command ' p2p_connect 96:bd:db:15:b9:38 PBC persistent go_intent=6 '
P2p-dev-wlan0:control interface command ' List_networks '
P2p-dev-wlan0:control interface Command ' get_network 0 mode '
P2P-WLAN0-6: Control interface command ' SET p2p_group_idle 10 '
In the peer-to P2p_stop_find, when the upper layer confirms that the peer connection is allowed, first, then send the P2p_peer, P2p_connect, which will create the actual peer to face connection to the network Port p2p-wlan0-6, and then send a "GO Negotiation Request ".

2 negotiation process When a group has been saved

After the peer-to connect is complete, if the peer-to-peer connection disconnects, and then initiate a peer-to connect, does not necessarily need to peer-to go/client negotiation process, which depends on whether both sides have to save the peer-to information. The following first describes the information that is saved after the peer connection, as go or client, the information saved is not the same.
The information saved as Go is as follows:
network={
Ssid= "DIRECT-ZT-ANDROID_7AB3"
Bssid=6e:fa:a7:dc:14:d6
psk= "ZT32EQMT"
Proto=rsn
Key_mgmt=wpa-psk
pairwise=ccmp
Auth_alg=open
Mode=3
disabled=2
p2p_client_list=96:bd:db:15:b9:38
}
The name of the Ssid:go;
Bssid:go own MAC address;
Psk:go's password;
P2p_client_list: The MAC address of the connected client;
The information saved as a client is as follows:
network={
Ssid= "Direct-h0-android_dd11"
bssid=96:bd:db:15:b9:38
Psk=03e45fa923d8fbaf58920fdb484487bf19a98090d23278c72e326bfea44a9b50
Proto=rsn
Key_mgmt=wpa-psk
pairwise=ccmp
Auth_alg=open
disabled=2
}
SSID: The name of the connected go;
BSSID: The MAC address of the connected go;
PSK: The password of the connected go is encrypted;

Differences in peer-to-peer connectivity under different circumstances
1, both sides of the device do not have to save the connection information
The situation goes through the consultation process described in section I.
2, both sides of the device are saved with the peer-connected information
In this case, because the two sides are saved with the peer connection information, based on the last peer connection information connection can be, that is the last time to do go, or do go, do the same as the client, go name, MAC address, password, client MAC address are know, So there's no need to negotiate,
As long as the go/client at either end of the connection can be, but this time there is no need to send P2p_connect command, as long as the P2p_invite command to send, the command is as follows:
P2p-dev-wlan0:control interface command ' p2p_invite persistent=0 peer=96:bd:db:15:b9:38 '
3, the initiator does not save the peer-to-peer connection information, the recipient has to save the peer connection information
Because the initiator does not save the peer to the connection information, there is no choice, but also take the first section of the negotiation process described.
4, the initiator has the connection information, the recipient does not save the peer-to-peer connection information
Because the initiator has to save the peer to the connection information, so the initiator sends P2p_invite, but because the recipient does not have to save the peer-to information, this time the p2p_invite to fail, followed by the first section of the negotiation process introduced. The entire command process is as follows:
P2p-dev-wlan0:control interface Command ' P2p_find 120 '
P2p-dev-wlan0:control interface command ' P2p_stop_find '
P2p-dev-wlan0:control interface command ' P2p_peer 96:bd:db:15:b9:38 '
P2p-dev-wlan0:control interface command ' P2p_peer 96:bd:db:15:b9:38 '
P2p-dev-wlan0:control interface command ' p2p_invite persistent=0 peer=96:bd:db:15:b9:38 '
P2p-dev-wlan0:control interface Command ' get_network 0 p2p_client_list '
P2p-dev-wlan0:control interface Command ' remove_network 0 '
P2p-dev-wlan0:control interface command ' P2p_peer 96:bd:db:15:b9:38 '
P2p-dev-wlan0:control interface command ' p2p_connect 96:bd:db:15:b9:38 PBC persistent go_intent=6 '
P2p-dev-wlan0:control interface command ' List_networks '
P2p-dev-wlan0:control interface Command ' get_network 0 mode '
P2p-wlan0-13:control interface Command ' SET p2p_group_idle 10 '

3 The GO client role negotiation process

Negotiation parameters
During the negotiation process, the GO and client roles are determined by two parameters:
Intent: As the go priority;
Breaker: In intent the same is, used to determine who does go;
INTENT values range from: 0~1 (#define P2p_max_go_intent 15)
The intent is initialized at 0, and at each p2p_connect, it is passed down from the upper layer, and the Java layer defaults to 6 under the Android system, which is defined in:
/frameworks/opt/net/wifi/service/java/com/android/server/wifi/wifinative.java
private static final int default_group_owner_intent = 6;
In the negotiation, who INTENT value, who as go; if one end specifies a value of INTENT (p2p_max_go_intent) Then this end is go and if both ends are specified INTENT is 15, then this negotiation will fail. In the case where the values on both sides of the negotiation are not 15 and the values are equal, the value of breaker will be determined by who does go.
The value of breaker is only 0 or 1, which is randomly generated at initialization:
if (Os_get_random (&p2p->next_tie_breaker, 1) < 0)
P2p->next_tie_breaker = 0;
P2p->next_tie_breaker &= 0x01;

Dev->tie_breaker = p2p->next_tie_breaker;
P2p->next_tie_breaker =!p2p->next_tie_breaker; The
breaker value is reversed every time the p2p_connect is initiated, so that both sides have the opportunity to do go when the intent value is the same. And when the request is sent to fill in their own breaker value, in response to response, the other side of the breaker value is reversed and sent as a breaker value.
in the negotiation process, by the second request/response of the intent, breaker value determine who does go, which is the intent (not 15 of the case) value big who do go, when the intent value of the same time, At this point the breaker value of the send request side determines who does go, when sending the request side of the breaker value is 1 o'clock, send the request side as go, and vice versa as the client. Receiving the request side is just the opposite.

The role of parameters in the negotiation phase
This is illustrated in conjunction with Figure 1:
1, a Send request to B, the request contains a intent, breaker value;
2, B received the request, because B is not ready to respond to a response to a, the response contains the intent value of B, while the breaker value of a as breaker into response. When the WiFi is opened for the first time to accept peer-to connection, because the B layer has not been called p2p_connect, then the intent value is 0, but this time the intent value does not affect the final go, client judgment;
3, the above this round of request/response do not do go, client judgment;
4, B send request to A, the request contains a intent, breaker value;
5, a received request, respond to a response to B, the response contains a intent value, while the breaker value of B as breaker into response;
6, in this round of Request/response, decided who do go, who intent (not 15 of the case) value big who do go, in intent the same case, if B's breaker value is 1, then B do go, if B breaker value is 0, b The role of Client,a is just the opposite of B;

As you can see, the final go and client roles are determined in the second round of Request/response.