P2P: Inviting a p2p device from already running persistent p2p go
Neeraj Kumar Garg
neerajkg at broadcom.com
Mon Dec 19 01:07:29 EST 2011
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.
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
Jouni Malinen PGP id EFC895FA
HostAP mailing list
HostAP at lists.shmoo.com
More information about the HostAP