We have already learnt about the P2P Group Formation using Negotiation Method and Autonomous Method , Now we will learn about the P2P Group Formation using Persistent Method. In the Persistent method devices will store the credentials that were being sent in the M8 Message , and the GO or GC will use these credentials to invoke the P2P Device to form a group. Please go through the previous posts to learn about the P2P Group Formation using Negotiation Method and Autonomous Method. Checkout the below links so that it will help you understand the Group Formation using persistent method.
Here we will learn briefly about the Group Formation Procedures. And Observe the below diagrams. And observe the differences between the each group formation procedure. If you want to learn more, you can read above the links. I have written detailed explanation about these procedures.
The Above diagram shows the P2P Group Formation Procedure using Negotiation Method. And this method consists of the phase “Go Negotiation” phase to decide which device will become group owner. Based on the handshake messages one device will become GO and other will become GC.
ProvisioningTo allow for P2P Device configuration, P2P Devices may delay starting the Provisioning phase until the expiration of the maximum of the P2P Group Owners GO Configuration Time and the P2P Clients Client Configuration Time from the respective Configuration Timeout attributes exchanged during Group Owner Negotiation.
Observe the below capture to see the GO Configuration Time out, this is basically the time the device need to become the GO. Observe the below screen capture.
We have the Phase 1 and Phase 2 of WPS Provisioning. Phase 1 will have the M1 to M8 Message sequence and in M8 GO will deliver the credentials to the GC. In Phase 2 we have a 4-way handshake, and key will be the one that got delivered to the GC in the M8 Message.
Observe the below frame exchanges that will happen while forming the Group.
Autonomous Group Formation Method
In Autonomous GO method once device declares itself as a group owner or any device will be joining in a already operational group, and there will not be any Negotiation Method happening. We don’t have negotiation phase because we already have a Group owner.
See the below flow to know about the Autonomous Group Formation Flow.
The only difference that we see in Negotiation and Autonomous group methods are the Negotiation Phase. We don’t see the Negotiation phase in autonomous phase , and all the procedure is same. We will see Phase 1 and Phase 2 here as well.
Now we will learn about the P2P Persistent Group Formation Method. And we will learn how it is different from the Negotiation and Autonomous Group Methods.
P2P Persistent Group Formation Method
At the time time of initial group formation we will see Phase-1 and Phase-2 of the group formation procedure. And Phase-1 will be used by GO to deliver the credentials to GC. So at the time of initial group formation we will see the Phase-1 and Phase-2 of the group formation procedure.
In P2P Persistent Group Formation , there will not be any Phase 1 in persistent group formation. Because Devices will store the credentials at the time of initial group formation. So there will not be any Phase 1 , which will be used to generate the credentials. If any device wants to connect to that previously connected device it will use the same credentials stored, so there will not be any phase-1 and group formation will happen faster, because we have removed few frame exchanges between GO and GC.
In this Persistent method we don’t see the Negotiation Phase as well, because the Group owner already been decided based when the group was created initially.
A P2P Device that successfully obtains Credentials for a Persistent P2P Group shall store the Credentials for that P2P Group. This enables the P2P Device that is P2P Group Owner to recreate the P2P Group for additional sessions after initial formation. Even P2P Clients can also store the credentials so that P2P Clients also can use these credentials to invite the Group Owner to form a group.
In 2 ways persistent group formation will happen:
- Invoking from GO
- GO will send P2P INVITATION REQUEST request to the GC, and GC replies back with P2P INVITATION RESPONSE.
- Invoking from GC
- GC will send P2P INVITATION REQUEST request to the GO, and GO replies back with P2P INVITATION RESPONSE.
Before we learn about the Invitation Procedure , we will first learn about the frame exchanges that are involved in the Persistent group formation method. And we will see the frame captures involved.
Observe the below figure to know about P2P Persistent group formation Method.
Check the below message flow to understand the message exchange between GO and GC.
In Persistent method we will have Invitation Procedure. Which will be used by the GO to invite the GC or GC to invite the GO to form a group.
Device Discovery happening using Active Scanning in the P2P Persistent Group. It is also possible that it happens through passive scanning, when group is already started (Autonomous GO) and the GO will be beaconing. In the above diagram it is shown that discovery is happening through the Probe Request and Probe Response frame. Check out the below link to know more about discovery procedure.
If the GO is capable of doing persistent Group Formation. Then the Persistent P2P Group bit in the Group Capability Bitmap field in the P2P Capability attribute shall be set in the Beacon and Probe Response frames transmitted by the P2P Group Owner. Observe the below capture to check this.
See the below capture to check the Persistent reconnect set as 0, as the GO doesn’t have support for Persistent reconnect. Capture is taken from the beacon.
A P2P Group Owner may advertise that it supports P2P Client reconnection without user intervention for a Persistent P2P Group by setting the Persistent Reconnect bit to 1 in the Group Capabilities Bitmap field that it sends describing the P2P Group capabilities. See the below capture from beacon. We can see the same info from probe response as well.
We will see the phase-1 and phase-2 of the group formation at the initial group formation. So, see the below capture to check the initial group formation flow. When we want to invoke the group after the initial group formation, then we don’t see the Phase-1 we see only the phase-2.
Observe the below supplicant log if there any Persistent Group is created.
Persistent Group creation Supplicant Log<3>P2P-GROUP-STARTED p2p-wlan0-13 GO ssid=”DIRECT-X7″ freq=2462 passphrase=”11W0
ozWN” go_dev_addr=xx:xx:xx:74:c0:a0 [PERSISTENT]
Now observe the below capture and see the frame exchanges that have been done in persistent reconnect method, and observe that we don’t see phase-1.
P2P Invitation Procedure
Before we learn about the Group Formation procedure , we will have to learn about the P2P Invitation Procedures. In Invitation procedure GO invokes a GC to form a group or GC invokes a GO to form a group. We will first learn about the invitation procedure and then we will see the frame captures involved in the invitation procedure.
P2P Invitation procedure is an optional procedure that used for the following:
- A P2P Group Owner inviting a P2P Device to become a P2P Client in its P2P Group.
- A P2P Client inviting another P2P Device to join the P2P Group of which the P2P Client is a member because it wishes to use some service of the P2P Device.
- Requesting to invoke a Persistent P2P Group for which both P2P Devices have previously been provisioned and one of the Devices is P2P Group Owner for the Persistent P2P Group.
Now we will see the invitation procedure which we can use to invoke the group that was created earlier. Now we will reconnect the group using persistent method by using P2P INVITATION procedure.
Now lets see the P2P invitation request that has been sent from one device to other device and check the sniffer capture for this and observe the fields that I have marked in the sniffer capture that have been sent in the invitation request. Observe the capture that has P2P Invitation flag set to 1 to when persistent group is revoked.
If the Invitation request is simply being sent to the other P2P Device (Not a persistent) then the P2P invitation flag will be set to 0. Observe the below capture for Normal P2P Invitation request.
Now we will see the P2P Invitation Response from the GC. And observe that GO Configuration time out is set 0 ms in the P2P Invitation response.
The GO Configuration Timeout field in the Configuration Timeout attribute shall be set to 0 in the P2P Invitation Response.
We can see the same frame exchange whether the GO invokes group or GC invoke the group.
P2P INVITATION RESPONSE CODES
Here we will have Different INVITATION Response codes and I tried to get few INVITATION Response codes. Check the below response codes. We can see the few other response codes from the post P2P GO Negotiation.
Observe the few Invitation Response codes below. When Peer Device does not respond to the Invitation Request.
Observe the below response code when the P2P devices tries to connect to the unknown P2P Device.
After Invitation Procedure
After the Group Formation is successful, GO device will send a beacon with Persistent P2P Group and Persistent reconnect set to 1.
We will have only the phase-2 of the group formation, in persistent group formation, Because both the devices will store the credentials that were generated during Phase-1. And they will use same credentials again when the group is getting created again. So we will see only Phase-2. You can have a look at the Phase-2 from the below link.
Now the Data Transfer Between the GO and GC happens using AES-CCMP Encryption.
In the next Post we will learn about the P2P Power Management Operation.