[2/7] p2p: Add a utility function to retrieve local GO device address

Provided the given device address in the parameters belongs to a peer
device. This will be useful in wpa_supplicant part.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
---
 src/p2p/p2p.c | 18 ++++++++++++++++++
 src/p2p/p2p.h |  3 +++
 2 files changed, 21 insertions(+)

On Tue, May 20, 2014 at 02:51:09PM +0300, Tomasz Bursztyka wrote:
> Provided the given device address in the parameters belongs to a peer
> device. This will be useful in wpa_supplicant part.

> diff --git a/src/p2p/p2p.c b/src/p2p/p2p.c
> +const u8 *p2p_get_own_go_device_address(struct p2p_data *p2p,
> +					const u8 *peer_dev_addr)
> +{
> +	int i;
> +
> +	for (i = 0; i < p2p->num_groups; i++) {
> +		if (p2p_group_is_client_connected(p2p->groups[i],
> +						  peer_dev_addr))
> +			break;
> +	}
> +
> +	if (i >= p2p->num_groups)
> +		return NULL;
> +
> +	return p2p_group_get_interface_addr(p2p->groups[i]);

This function is named very confusingly. "device_address" seems to point
towards P2P Device Address, but this is clearly returning a P2P
Interface Address. In addition, it should be understood that more than a
single group may match, i.e., this function would return _a_ local P2P
Interface Address instead of _the_ address. This may still be useful,
but it would be better to rename the function and note that possibility
of multiple matches even if it is a bit unlikely to show up in practical
use cases.

Hi Jouni,

> This function is named very confusingly. "device_address" seems to point
> towards P2P Device Address, but this is clearly returning a P2P
> Interface Address.

That's a bug in the previous patch indeed.

>   In addition, it should be understood that more than a
> single group may match, i.e., this function would return_a_  local P2P
> Interface Address instead of_the_  address. This may still be useful,
> but it would be better to rename the function and note that possibility
> of multiple matches even if it is a bit unlikely to show up in practical
> use cases.

I see, I'll try to come with something that can iterate on all groups or 
some sort.

Basically, what I want is in DBus API part to retrieve all group the 
peer is part of (as a client or a GO)
for that I need the wpa_s the group is related to to be able to provide 
the object path of the group then.

This patch, returning the interface address makes is flawed anyway, and 
as you said I need to loop
on all possible groups due to the multi group case.

Tomasz

>> This function is named very confusingly. "device_address" seems to point
>> towards P2P Device Address, but this is clearly returning a P2P
>> Interface Address.
>
> That's a bug in the previous patch indeed. 

I am confused here, it is this actual patch which is bogus. Sorry

Tomasz

On Tue, May 27, 2014 at 01:32:32PM +0300, Tomasz Bursztyka wrote:
> Basically, what I want is in DBus API part to retrieve all group the
> peer is part of (as a client or a GO)
> for that I need the wpa_s the group is related to to be able to
> provide the object path of the group then.

Please note that wpa_supplicant does not track this type of information
now, so no matter what you'll do with the D-Bus interface, it is
unlikely to be able to give you this information reliably..

It is easy to find any specific peer from the groups where the local
device is the GO (though, there can be more than one matching group even
though that would be pretty unlikely in real world use cases).

For the groups where the local device is a P2P Client, there is no
existing data structure that would store reliably a list of all group
members. Getting an up to date list available would require sending a
Probe Request frame to the GO and then fetch the list from the Probe
Response frame. This is the part that is missing both in the sense of
that extra scan being triggered and that the results would be used to
generate a data structure with that information. If you want to make the
D-Bus interface work properly, the patch set would likely need to add
this new dynamic group data structure for groups where the local device
is a P2P Client and also some code to either trigger automatically
within wpa_supplicant or maybe more likely trigger by an external entity
a new scan for the GO(s) of such groups (p2p_find can specific a device
address to limit the results, but this would need to be run on the
operating channel(s), so may be useful to add a new wpa_supplicant
command to update the tables for P2P Client groups).

Hi Jouni,

> Please note that wpa_supplicant does not track this type of information
> now, so no matter what you'll do with the D-Bus interface, it is
> unlikely to be able to give you this information reliably..
>
> It is easy to find any specific peer from the groups where the local
> device is the GO (though, there can be more than one matching group even
> though that would be pretty unlikely in real world use cases).
>
> For the groups where the local device is a P2P Client, there is no
> existing data structure that would store reliably a list of all group
> members.

Sure! This is not my intention. I just want to make the local 
relationship so I can
reliably tell that the Peer I (with local device) connected to ended up 
in this
group and/or that one, no matter it is a client or GO.

Thus this Members property is not going to change, it will list peers if 
only the current
group is the GO.

Peer's Groups property will list the local relationship with groups, 
still in a local
scope. I am not interested to know any other distant relationships.

Tomasz