wpa_supplicant support multiple WiFi Direct Groups [GO (2.4 GHz) + GO (5 GHz)]
Tue Sep 22 08:12:59 PDT 2015
My comments are below:
From: Peer, Ilan [mailto:ilan.peer at intel.com]
Sent: Sunday, September 20, 2015 12:35 PM
To: Shanbhag, Sandeep; hostap at lists.shmoo.com; j at w1.fi
Subject: RE: wpa_supplicant support multiple WiFi Direct Groups [GO (2.4 GHz) + GO (5 GHz)]
Tried to answer some of the questions below.
From: hostap-bounces at lists.shmoo.com<mailto: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<mailto:hostap at lists.shmoo.com>; j at w1.fi<mailto:j at w1.fi>
Subject: wpa_supplicant support multiple WiFi Direct Groups [GO (2.4 GHz) + GO (5 GHz)]
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.
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.
Understand this part, that was exactly my understanding of the supplicant design, that of a single P2P Device entity which can support multiple P2P-Groups with their own interfaces of course.
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.
This was more from the perspective that if each GO is supposed to have an associated unique Device entity.
Say if this single P2P Device entity does not suit the case of hosting multiple groups then there must be a way to add multiple P2P Device entity each being able to host its own group.
Below I will bring out the reason for such a need.
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.
Yes, what I meant was that P2P Device starts a new GO on a new interface.
WFD Spec also says that the P2P Device Address itself can be used as Interface Address provided it is either universally unique MAC or universally unique MAC with its locally administered bit set.
But I think with this design it is not possible as a separate Interface needs to be created for the GO which should have a different MAC address than the P2P Device Address.
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.
IMHO, this behavior beats the whole purpose of somebody trying to create multiple groups using a single supplicant. The reason somebody wants to create more than one group is so that the remote device sees these multiple groups as different groups and should be able to connect to whichever it chooses to connect. But with this single device entity it does not become possible due to the reasons mentioned above.
For Ex: If there are 2 groups created using a single supplicant say: Group-A (on 2.4 GHz Channel) and Group-B (on 5 GHz Channel).
Now a dual band mobile phone should be able to see both the groups in its WiFi Direct Discovery Screen and then should be able to make a choice of whether to connect to Group-A or Group-B.
But due to the same P2P-Device Address used by both the groups the remote device can at a time either see Group-A or Group-B.
Also consider a case when there are 2 WiFi chips and a single supplicant needs to create one group on each of the chip then at least 2 P2P Device Entities are required.
So this problem can be solved by either bringing P2P structure out of global and making it part of wpa_s structure or by changing the logic of peer addition based not only on Device Address but some also may be the group's interface address.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Hostap