[PATCH V2 21/23] nl80211: verify P2P-GO/CLIENT address with all interface addresses

[Arend van Spriel]

On 07/01/2013 12:03 AM, Jouni Malinen wrote:
> On Sun, Jun 30, 2013 at 10:43:46PM +0200, Arend van Spriel wrote:
>> Good point. The P2P interface address and P2P device address only
>> need to be different if one would want to do P2P management and have
>> a group connection concurrently (correct me if I am wrong here,
>> maybe it is a restriction for brcm firmware only) so the check seems
>> a bit too restrictive.
>
> There is no such restriction in the P2P protocol specification. I've
> been trying to figure out why Broadcom went with such design, but
> anyway, if that is indeed a restriction in the firmware, it could be
> useful to provide a driver capability flag to allow wpa_supplicant to
> determine which rule to use.. I would use either the non-P2P station
> interface MAC address or alternatively, the first P2P Interface Address
> (which should be that non-P2P station interface MAC address with the
> locally administered bit set to 1 or another globally unique MAC
> address) as the P2P Device Address.

Hi Jouni,

The address scheme that we used with the dummy netdev aka p2p0 was:
p2p-dev-mac = non-p2p-mac with local administered bit set.
p2p-ifc-mac = p2p-dev-mac with byte 3 (or 4) modified.

> I would really like to avoid confusion and unjustifiable requests in
> this area where that existing design could be used to claim that other
> drivers need to behave similarly when there is no real technical reason
> for doing that. In other words, drivers should be able to select
> whichever P2P spec compliant mechanism they need. wpa_supplicant should
> hide these internal details from anything above it (and that can now
> finally be the case with the global control interface for P2P
> operations).

Agree.

> An earlier thread  seemed to already imply that some people may believe
> that this new dedicated P2P_DEVICE is needed for some concurrent P2P
> operations which is simply not the case; it just adds another option for
> internal driver/firmware/hardware design which should not add or remove
> any functionality and the only externally observable difference should
> be in MAC addresses potentially being different (but even those could be
> assigned using the same style between P2P_DEVICE and p2p-mgmt-netdev).

The last sentence is confusing to me. To me the P2P_DEVICE is a 
replacing solution to the p2p-mgmt-netdev, right?

Regards,
Arend