P2P: Inviting a p2p device from already running persistent p2p go

Neeraj Kumar Garg neerajkg
Sun Dec 18 22:07:29 PST 2011

Hello Jouni,
Thanks for your comments. Before I generate a new patch (to check the already running persistent group in group= command), I want to discuss few more things:
1. In the receive path of persistent invitation, supplicant code already checks for an already running group. So in that way, it makes more sense to check already running group in persistent= command for transmit case too.
2. We have to use either group= or persistent= command to find out if we are already running a persistent group. Lets say we use p2p_invite peer=xx group=xxx persistent=x command. [Doing automatically without persistent= will be difficult as we might have multiple entries in conf file with same go_dev_addr but different ssid]. For this we have to add the complete code of persistent verification from persistent invite to group invite.
3. Logic is since an application want to do a persistent invite, we can make persistent invite to find out if the group is already running or not. The other logic is since group is already running, should the application do a persistent invite or a normal invite. I think both weighs equal in this aspect.

Plz let me know. With my limited knowledge, the other patch [adding a persistent invite in group= command] is looking more unclean as far as implementation is concerned. 


-----Original Message-----
From: hostap-bounces at lists.shmoo.com [mailto:hostap-bounces at lists.shmoo.com] On Behalf Of Jouni Malinen
Sent: Sunday, December 18, 2011 11:52 PM
To: hostap at lists.shmoo.com
Subject: Re: P2P: Inviting a p2p device from already running persistent p2p go

On Sun, Dec 11, 2011 at 10:43:28PM -0800, Neeraj Kumar Garg wrote:
> The patch is still needed as the command p2p_invite group=<ifname> always sends a non-persistent invitation but we want to do a persistent invitation. We want to avoid WPS negotiation as P2 already have WPS credentials of P1.

Well, a fix may be needed, but that does not mean that this patch is the
correct fix. It would sound better to fix p2p_invite to indicate
persistent group if the group selected with group=<ifname> is indeed

> If you are worried what would be the use case of above command sequence, then:
> A. 3 devices were connected and this was a persistent connection and then disconnected. Now 2 of them (one of them is earlier GO) re-invoked the persistent connection. And now GO wants to do a persistent invite to the third device.
> B. To avoid excessive entries in the conf file, we decided that whenever application will ask to create autonomous GO, we will reinvoke a persistent GO entry from the Conf file. This will also increase our hit ratio of persistent connection from the clients as we will be running same credentials. And then later invitation to a client device has to be a persistent one.
> C. An application on GO may decide to store the connected client information for a persistent connection. In that case, it very well knows to whom it has to send persistent invitation and to whom it has to send a normal invitation.

This is all fine and I have no problems understanding the use case; I'm
just pointing out that the approach used in this patch is trying to
misuse the ctrl_iface commands and the correct fix is something else
(most likely a fix to that p2p_invite group=<ifname> to make it aware of
persistent groups).

Jouni Malinen                                            PGP id EFC895FA
HostAP mailing list
HostAP at lists.shmoo.com

More information about the Hostap mailing list