Virtual Interface for P2P operations

[Jithu Jance]

Hi Jouni,

Thanks for your comments. You are right. In my below description, I will refer PMA as primary MAC address and P2PDA as P2P device address.  
 
Our patch is primarily useful for embedded MAC [full dongle] architectures where dongle has separate interfaces for p2p(P2PDA) and legacySTA(PMA) operations,even before any p2p connection is made. In this case, we will use a P2PDA different from PMA (which is reserved for eth0) for P2P connections.

In our approach, we do not want to create a specific linux network interface for P2P Device address  [as this interface is supposed to be used only during the discovery & connection process]. However on establishing a connection, we create a linux network interface with P2P interface address [not P2PDA].   P2PDA is a logical entity in the  Wifi- Dongle used for sending out probe req/resp and other action frames. As per WiFi-Direct specification, a device can either use PMA or PMA with locally administered bit as P2PDA. Suggested patch wants to use PMA for LegacySTA operations and P2PDA for P2P operations to support concurrency in dongle. 
 
So the supplicant will still use the PMA for sending the P2P frames down to dongle and Hence NL80211_CMD_FRAME does not face any issues.  

Suggested patch will require the supplicant to be advertising P2PDA while doing a p2p find [in P2P IEs].  Subsequently, supplicant need to know about the  P2PDA interface even before the supplicant has created an interface for p2p connection.

Kindly share your thoughts on this. 

Thanks,
 
Jithu.

-----Original Message-----
From: Jouni Malinen [mailto:j at w1.fi] 
Sent: Tuesday, July 05, 2011 8:41 PM
To: Jithu Jance
Cc: Greg Goldman; Henry Ptasinski; hostap at lists.shmoo.com; Neeraj Kumar Garg
Subject: Re: Virtual Interface for P2P operations

On Tue, Jul 05, 2011 at 03:26:14AM -0700, Jithu Jance wrote:
> Resending the mail with patch file for an easy diff.

This is missing something:

p2p_supplicant.c: In function ?wpas_get_p2p_dev_addr?:
p2p_supplicant.c:2349: error: implicit declaration of function
?wpa_drv_get_p2p_dev_addr?
../src/drivers/driver_nl80211.c: In function
?wpa_driver_nl80211_get_p2p_dev_addr?:
../src/drivers/driver_nl80211.c:6650: error: ?WPA_P2P_SYSFS_PATH?
undeclared (first use in this function)
../src/drivers/driver_nl80211.c:6745: error: unknown field
?get_p2p_dev_addr? specified in initializer

> We are trying to do the below patch to make supplicant compatible with Drivers using Virtual Interface for P2P operations. We would appreciate your suggestions for the same.

You can also use virtual interfaces for P2P groups without any changes,
so I'm assuming this is mainly for the case where the driver would not
expose any netdev with the P2P Device Address. Is that the case here or
did I miss something on why this patch would be needed?

The concept of allowing the driver to indicate which P2P Device Address
is to be used even if there is not a specific netdev with that address
sounds possible for some driver designs. In most cases, I would assume
it would be possible to share the address on any netdev, but there is no
such requirement if it is easier to use a separate address. Just keep in
mind that there are various limitations in mac80211 and cfg80211 due to
commands assuming that there is an interface with a specific MAC
address, e.g., to scan or send Action frames.

> Originally wpa_supplicant uses a primary mac address for the P2P dev_addr. For concurrent mode (LegacySTA and P2P), it could be better, if we can use separate mac_addr for P2P and legacy STA right from the beginning. Also Wifi firmware which support multiple interfaces will be easier to support if P2P device address is different from the primary mac address (with local administered bit set).

You can already start wpa_supplicant with multiple interfaces, e.g.,
first one being the one with the P2P Device Address and the second one
being the non-P2P STA. This can be used either by allocating the first
interface only for P2P management purposes (i.e., use a separate virtual
interface for each group) or by sharing it between the P2P management
and group operations if only a single P2P group is supported.

What kind of netdev design would you like to use for this? If you
already have a netdev with the P2P Device Address before starting
wpa_supplicant, I would expect that design to be already supported. If
that is not the case, this type of change can be considered, but the
mac80211/cfg80211 changes to support the use case needs to be discussed
before this specific change in wpa_supplicant can be justified.

> As a generic solution, we modified supplicant to check for P2P dev address exported by driver via /proc/sys/. This check is done runtime, when the supplicant starts up. If proc interface for p2p_device_addr is present, supplicant uses this virtual mac address in cfg->p2p_dev_addr and use this address for P2P operations. If an implementation doesn't use virtual interface for p2p operations, supplicant copies primary mac address to cfg->p2p_dev_addr and uses it.

Which interface is this? Here you are referring to procfs, but the
driver_nl80211.c change talks about "Sysctl interface" or sysfs path
(the undefined WPA_P2P_SYSFS_PATH).. I think I would prefer a new
nl80211 command for this, but this topic should be discussed on the
linux-wireless mailing list first to make sure that there is a shared
mechanism for all drivers.

> Basically cfg->p2p_dev_addr stores the p2p device address irrespective of whether it uses the primary or virtual interface. We made changes in the the following files to use the cfg->p2p_dev_addr so that supplicant can seamlessly use this variable to refer p2p_device_address (without checking every time whether it uses virtual or primary mac address).

OK.

Is you driver using mac80211? Do you see problems in NL80211_CMD_FRAME
commands using a netdev that has a local address that does not match
with the Address 2 in the 802.11 header?

-- 
Jouni Malinen                                            PGP id EFC895FA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: p2p_dev_addr2.patch
Type: application/octet-stream
Size: 10599 bytes
Desc: p2p_dev_addr2.patch
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20110706/f00b9444/attachment.obj