In the previous posts we have learnt about the P2P Discovery procedures, P2P Group formation procedures , and P2P power saving mechanism. And in this posts we will learn about the communication in a P2P group after the Group is formed. Before we go further, look at the Group Formation procedures below.
In the group formation procedures we have learnt that in Phase-1 , GO will deliver the credentials to the client in the M8 Message.
The Credentials for a P2P Group issued to a P2P Device shall:
- Use WPA2-PSK as Authentication Type.
- Use AES as Encryption Type.
- Use a Network Key Type of 64 Hex characters.
- Use a different SSID for each group to assure that all P2P Groups are unique.
The PSK is derived from the pass-phrase and SSID. Each SSID shall begin with the ASCII characters “DIRECT-“. Following “DIRECT-“ the SSID shall contain two ASCII characters “xy”, randomly selected with a uniform distribution from the following character set: upper case letters, lower case letters and numbers. Observe the below SSID in the wireshark.

Communication in a P2P Group
Observe the below figure and check that we have a P2P group formation procedure.

Communication within a P2P Group shall employ WPA2-Personal security with AES-CCMP as the encryption cipher. Immediately after a successful association, the P2P Group Owner and the newly connected P2P Client shall execute the 4-way handshake in which the P2P Group Owner shall act as the authenticator and the P2P Client shall act as the supplicant. The resulting temporal encryption keys shall be installed and used to encrypt unicast and broadcast/multicast frames exchanged between the P2P Group Owner and the Client.
Higher-layer data services may use IP. The P2P Group Owner shall act as a DHCP server to provide IP addresses to the connected P2P Clients that use IP. The DHCP Server shall at a minimum support Internet Protocol version 4 (IPv4) and assignment of an IP address. A P2P Client that uses IP shall be capable of acting as a DHCP Client.
Observe the below sniffer capture and see the frame exchanges. And we can see that the DHCP data is encrypted using WPA2+AES encryption. Observe the Encrypted DHCP frames i.e 12349, 13041,13046,13061 and it is shown as QoS Data below.

If we have to decrypt the data , then we should have the Network key with 64 Hex characters i.e PSK. The PSK is derived from the pass-phrase and SSID. Pass-phrase will be a randomly generated in GO and it will be delivered to Client.
In the above example our PSK is
e013e5953993f0e48867be633273664c31f4cf507fad9295f048c4915d61682d.
We will use the wireshark to decrypt the data. We can give the PSK in the wireshark and we can see the decrypted DHCP data in the below figure. Observe the Decrypted DHCP frames i.e 12349, 13041,13046,13061.

You can observe the below ICMP traffic between between GO and GC when pinged from GO to GC. Observe the below encrypted sniffer capture of PING traffic. We can see the QoS data here.

Now we will see the decrypted PING traffic from GO to GC. Observe the below capture.

P2P DISCONNECTION
CLIENT Disconnecting from a P2P Group
A P2P Client shall, when possible, indicate intent to disconnect from a P2P Group by using either:
- Deauthentication procedure
- Disassociation procedure
Observe the below capture and see that when the client is disconnected from P2P group, it sends disassociation frame to the GO. GO sends deauthentication frame to the GC.
Observe the below capture i.e GC sends disassociation to the GO. And GO sends Deauthentication to the GC.

See the below disassociation frame that is being sent from GC to GO.

See the below disassociation frame that is being sent from GO to GC.

GROUP OWNER Disconnecting a P2P CLIENT
A P2P Group Owner may disconnect a Client from a P2P Group. In order to disconnect a Client, a P2P Group Owner shall use either:
- Deauthentication procedure
- Disassociation procedure
Ending a P2P Group session
Unexpected departure of a P2P Group Owner shall terminate the P2P Group session. A P2P Group Owner indicating intent to terminate a P2P Group session shall use the deauthentication procedure to send a Deauthentication frame to the broadcast address, or to all connected Clients.
The reason code in the deauthentication frame shall take the value 3 (Deauthenticated because sending STA is leaving (or has left) IBSS, or ESS). If there are no connected P2P Clients the P2P Group Owner may end the P2P Group session.
observe the below capture for this scenario. GO simply sends the Deauthentication frame.
