p2p_mgmt interface and tdls_init

Arend van Spriel arend at broadcom.com
Thu Jun 25 13:16:02 EDT 2015


On 06/25/15 19:05, Krishna Chaitanya wrote:
> On Thu, Jun 25, 2015 at 10:32 PM, Arend van Spriel<arend at broadcom.com>  wrote:
>> On 06/25/15 17:10, Krishna Chaitanya wrote:
>>>
>>> On Thu, Jun 25, 2015 at 8:21 PM, Arend van Spriel<arend at broadcom.com>
>>> wrote:
>>>>
>>>> On 06/25/15 16:47, Arend van Spriel wrote:
>>>>>
>>>>>
>>>>> On 06/25/15 16:21, Krishna Chaitanya wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I wanted to know the reason for blocking TDLS L2 Packet registration
>>>>>> if the driver doesn't support
>>>>>> dedicated p2p interface.
>>>>>>
>>>>>> this was introduced in this commit
>>>>>> http://lists.shmoo.com/pipermail/hostap/2013-May/028008.html
>>>>>>
>>>>>
>>>>> The intention was to block it for the dedicated p2p interface as it is
>>>>> not transporting data and looking at the patch it is doing that, but I
>>>>> might be wrong.
>>>>
>>>>
>>>>
>>>> Looking at it again I support "dedicated p2p interface" is not same as
>>>> P2P
>>>> device interface. The patch avoids l2 for both, but for "dedicated p2p
>>>> interface" it was already true before this patch. But the flag is a
>>>> driver
>>>> flag so not sure if that is a correct check.
>>>
>>> Currently the check is as below: It checks for both DRIVER capability
>>> and adding p2p_dev interface.
>>>
>>> #ifdef CONFIG_TDLS
>>>           if ((!iface->p2p_mgmt ||
>>>                !(wpa_s->drv_flags&
>>>                  WPA_DRIVER_FLAGS_DEDICATED_P2P_DEVICE))&&
>>>               wpa_tdls_init(wpa_s->wpa))
>>>                   return -1;
>>> #endif /* CONFIG_TDLS */
>>>
>>> So is my understanding, this check is to avoid
>>> registering for EAPOL/TDLS framesfor P2P_DEV interface, correct?
>>
>>
>> Correct. The above deals with TDLS part although the check for drv_flags was
>> not in my patch.
> Yes, this code is from ToT.
>> I think it is allow tdls operation for non-p2pdev interface
>> that is assigned to be used for p2p mgmt.
> Not sure that is possible, using a p2p interface and invoking
> TDLS, but yes this check allows that.

As Jouni explained to me once any interface could be p2p *management* 
interface on their equipment. So a sta interface wlan0 could be assigned 
as p2p *management* interface in wpa_supplicant dealing with discovery 
and group negotiation, etc. while being connected to an AP. The code 
above allows for the regular sta traffic to setup a TDLS connection.

When my explanation is crap I guess Jouni may correct me.

Regards,
Arend

>> Below fragment deals with EAPOL
>> (if not mistaken):
>>
>> diff --git a/wpa_supplicant/wpa_supplicant.c
>> b/wpa_supplicant/wpa_supplicant.c
>> index ea2d06b..0fa794d 100644
>> --- a/wpa_supplicant/wpa_supplicant.c
>> +++ b/wpa_supplicant/wpa_supplicant.c
>> @@ -2327,7 +2327,8 @@ int wpa_supplicant_update_mac_addr(struct
>> wpa_supplicant *wpa_s)
>>                  const u8 *addr = wpa_drv_get_mac_addr(wpa_s);
>>                  if (addr)
>>                          os_memcpy(wpa_s->own_addr, addr, ETH_ALEN);
>> -       } else if (!(wpa_s->drv_flags&
>> +       } else if (!wpa_s->p2p_mgmt&&
>> +                  !(wpa_s->drv_flags&
>>                       WPA_DRIVER_FLAGS_P2P_DEDICATED_INTERFACE)) {
>>                  l2_packet_deinit(wpa_s->l2);
>>                  wpa_s->l2 = l2_packet_init(wpa_s->ifname,
> Yes, got that.



More information about the HostAP mailing list