Virtual Interface for P2P operations

[Jithu Jance]

Thanks Jouni for your feedback. Agree with your suggestion that using primary mac address for sending Tx NL_CMD_FRAME looks ugly and is not the correct way to do it. May be exposing a network interface for p2p device address interface would be a better approach and should work with current supplicant. I will try this way.  Thanks again for your valuable suggestions and sorry for the trouble.

Thanks,

Jithu. 




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

On Wed, Jul 06, 2011 at 06:42:15AM -0700, Jithu Jance wrote:
> 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.  

> 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. 

The P2P Device "interface" needs to be available also when the group is
running (e.g., for invitation mechanism), but anyway, yes, this is a
compliant design for P2P.

> 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.  

This sounds quite strange.. Are you saying that wpa_supplicant is using
the non-P2P station interface (eth0 in your description) to send the P2P
frames and the source address in those frames is PMA, not P2PDA? And the
driver/firmware then magically patches the frame header by replacing PMA
with P2PDA for the frames? If so, how does the driver/firmware know
which frames get this special address change? Please note that the
NL80211_CMD_FRAME commands are used to send other than P2P Action
frames, too, e.g., SA Query Request for PMF.

> 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.

I understand that wpa_supplicant needs to know P2PDA and I'm fine with
this part (with the procfs/sysfs/whatever mechanism replaced with
something based on nl80211). However, I find the TX mechanism used here
quite ugly (assuming I understood it correctly). This really needs to be
discussed on the linux-wireless mailing list to get more acceptable
mechanism for sending out Action frames using the P2P Device Address as
the source address even if there is no user visible netdev with that MAC
address.

I have no problems modifying wpa_supplicant to use this mechanism once
it is accepted into wireless-testing.git. Hacking something on top of
what is currently available in the form of NL80211_CMD_FRAME without
clarifying that use case in nl80211/cfg80211/mac80211 does not sound
acceptable.

-- 
Jouni Malinen                                            PGP id EFC895FA