Virtual Interface for P2P operations

Jouni Malinen j
Tue Jul 5 08:10:36 PDT 2011


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



More information about the Hostap mailing list