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

[Chengyi Zhao]

Hi Jouni,

I think Google, Boardcom and Intel use this solution for the Wi-Fi P2P
cross connection, but it can not run fine in Android 4.2.2 yet. Please
refer to the following information of android P2P, it is a P2P-GO role in
mobile,
if wlan0 connect the internet, and system uses iptable(maybe more another
techonology) to create a special relation between p2p0  and wlan0, P2P-Client
will very conveniently surf internet via  the Wi-Fi P2P cross connection.
In fact this functionality is simalerly tetheing

May be described as:
Cross Connection is the optional capability of a P2P Group Owner to provide
WLAN access to P2P Clients within its P2P Group.

In fact, this is an integrated technology, concurrently enable Wi-Fi
tethering and P2P.


Hi Arend,

Could you please consult with the firmware or Android network system
engineer in Boardcom,
and please clarify the thinking behind this one?

Thanks.

---------------------------------------------------------------------------------------------------------
Reference information:
root at android:/ # ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:18401 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18401 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:149934880 (142.9 MiB)  TX bytes:149934880 (142.9 MiB)

p2p0      Link encap:Ethernet  HWaddr 12:68:3F:38:6E:2C
          inet addr:192.168.49.1  Bcast:192.168.49.255  Mask:255.255.255.0
          inet6 addr: fe80::1068:3fff:fe38:6e2c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:0
          TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:1285 (1.2 KiB)  TX bytes:2677 (2.6 KiB)

wlan0     Link encap:Ethernet  HWaddr 10:68:3F:38:6E:2C
          inet addr:192.168.1.100  Bcast:255.255.255.255  Mask:255.255.255.0
          inet6 addr: fe80::1268:3fff:fe38:6e2c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11553 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8693 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:8538960 (8.1 MiB)  TX bytes:1071653 (1.0 MiB)

Cheers,

Chengyi



2013/7/1 Jouni Malinen <j at w1.fi>

> 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.
>
> 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).
>
> 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).
>
> --
> Jouni Malinen                                            PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20130702/8a80f498/attachment.htm>