wpa_supplicant support multiple WiFi Direct Groups [GO (2.4 GHz) + GO (5 GHz)]

[Peer, Ilan]

Hi,

Tried to answer some of the questions below.

Regards,

Ilan.

From: hostap-bounces at lists.shmoo.com [mailto:hostap-bounces at lists.shmoo.com] On Behalf Of Shanbhag, Sandeep
Sent: Saturday, September 19, 2015 07:43
To: hostap at lists.shmoo.com; j at w1.fi
Subject: wpa_supplicant support multiple WiFi Direct Groups [GO (2.4 GHz) + GO (5 GHz)]

Hello,

We have a requirement to support 2 P2P Autonomous Group Owner instances: GO (2.4 GHz) + GO (5 GHz) with a single chip.
So we were considering using a single wpa_supplicant instance running on the 2 P2P interfaces and while analyzing this option we found the below limitation in supplicant:

The P2P data structure sits inside the global data structure and not directly inside the wpa_s structure which is per interface.

wpas_p2p_init()
{
                if (global->p2p)
                                return 0;

                global->p2p = p2p_init(&p2p);
}

P2P architecture defines a single P2P Device entity that is responsible for managing the P2P Device operations/flows, and one or more entities that can be used to manage P2P GOs and/or P2P clients. The above function is used to initialize a P2P Device context and not the P2P GOs/Clients, i.e., if you have a HW that can support several P2P GOs then the wpa_supplicant is already designed to support operating several P2P groups, each managed by its own wpa_supplicant interface instance.

Due to this if we want to add multiple p2p interfaces representing multiple P2P Device Discovery Interface then it does not become possible as it gets returned from this function.

Adding a P2P group interface should not call this function.

Is there any particular reason why p2p structure was part of global structure and not part of interface specific wpa_s structure?
Do you have any plans to extend this to move inside wpa_s structure in order to support multiple P2P interfaces?

As explain above, multiple P2P Group interfaces are already supported.

Our requirement is to start 2 Autonomous Group Owners and on analysis we find that the P2P Device Address is not of much relevance once a P2P Device assumes the role of P2P-Group Owner as all frames use P2P-Interface Address for communication.

P2P Device does not assume the role of a P2P GO. However, it is possible that the same wpa_supplicant interface that is used to managed the P2P Device operations is also used for managing the P2P GO operations.

Is the rationale behind having p2p structure inside global is thinking that a single unique P2P Device Address is sufficient to create multiple groups with their own unique interface addresses?

Please let us know if our understanding matches with yours and if this is the reason why a single instance of p2p structure is allowed by making it part of the global structure.

If this was indeed the reason then we have one issue that the peer devices (based on wpa_supplicant) keeps overwriting the this device during discovery as the Supplicant's logic to add a peer is based on device address from within the P2P-IE and not based on Interface Address. So the peer devices will either see the 2.4 GHz GO or 5 GHz GO and not both.

Not sure I fully understand, but this is the expected behavior, as the both P2P GOs are tied to the same P2P Device context, so eventually in the P2P Device list you should have only a single entry representing the remote P2P Device. There might be an issue with the P2P Device structure that does not handle the possibility that that a single P2P Device can be a client in several P2P groups, but this can clearly be extended if needed.

I know that the device address stays same across multiple persistency sessions but the interface addresses of devices can change, this could be one of the reasons to base peer entry on device address.

If you think that it makes sense for a single device to host 2 groups with a single device address and if this was one of the reasons to have a single P2P Discovery Interface then please consider also changing the logic of peer entry to also consider Interface address and not only device address.

Regards,
Sandeep D.S

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20150920/962e3113/attachment.htm>