[PATCH 00/20] wpa_s: p2p: support nl80211 P2P_DEVICE interface

Wed May 22 07:03:35 PDT 2013

On 05/21/2013 02:02 PM, Jouni Malinen wrote:
> On Tue, May 21, 2013 at 01:53:38PM +0200, Arend van Spriel wrote:
>> On 05/19/2013 09:08 PM, Jouni Malinen wrote:
>>> Thanks. I started applying commits, but had to stop with that pretty
>>> quickly since this broke number of things in my tests (including hostapd
>>> build and wpa_supplicant start).. I think I managed to fix most of the
>>> issues, but this still does not work in my hwsim tests.
>>
>> Can you elaborate what does not work in you hwsim tests. I tested
>> with your devel branch and I can connect and ping. However, I am
>> using 3.10-rc1 on the peer using P2P Device interface. Reason for
>> this is that it needs a nl80211 patch to make P2P_FIND succeed.
>
> I did not see device discovery working. hwsim0 shows Probe Request
> frames, but there was no reporting if Probe Request frames to
> wpa_supplicant and as such, no responses to these.
>
>>    commit 97990a060e6757f48b931a3946b17c1c4362c3fb
>>    Author: Johannes Berg <johannes.berg at intel.com>
>>    Date:   Fri Apr 19 01:02:55 2013 +0200
>>
>>        nl80211: allow using wdev identifiers to get scan results
>
> I'd assume I had that in my tests. I was using a wireless-testing.git
> snapshot. Anyway, whether I had that there or not does not matter since
> there is obviously at least one snapshot of the kernel where this breaks
> P2P completely at least for hwsim tests. I cannot apply such changes
> into hostap.git without protection that avoids regressions with any past
> kernel snapshot in the default configuration. It would be unfortunate if
> we have managed to push kernel changes in to claim support for this
> without it actually working. That would mean that there may be need for
> manual configuration to enable this in wpa_supplicant and/or a new
> capability bit in the kernel once things start working.
>
>> Another thing is that for P2P Device I use the same configuration
>> file, but that starts scanning on P2P Device for the networks
>> configured in it. So I patched wpa_supplicant_enabled_networks() to
>> return 0 if wpa_s->p2p_mgmt is 1.
>
> Hmm.. I don't think this would explain the issues I saw.
>

The issue you saw were that pcap dump shows only probe requests, right? 
I ran hwsim tests or actually the tests in test_p2p_discovery.py and 
used cfg80211 tracing. It seems mac80211 only calls cfg80211_rx_mgmt() 
for wdev(1) and returns false as it is not registered for that. The P2P 
Device interface is wdev(2). I am not that familiar with mac80211 rx 
path, but probe request register seems to succeed for wdev(2). The 
function __ieee80211_rx_handle_packet() seems to feed the frame to the 
virtual interfaces.

Johannes, do you have any clues here? I think this is the issue that 
David saw when using my patch fixing registration of probe requests as 
that failed for him (using a mac80211 driver).

commit 1b3aa0c188ddc3f912f1ee5cd3c7207088a32751
Author: Arend van Spriel <arend at broadcom.com>
Date:   Mon Mar 25 14:47:25 2013 +0100

     p2p_supplicant: probe reporting should be from listen interface

     P2P listen phase is used to listen for P2P probe request messages
     from peers. The probe reporting call should be done on the same
     interface as the remain_on_channel.

     Signed-hostap: Arend van Spriel <arend at broadcom.com>

Below is part of tracing done during the hwsim test.

Regards,
Arend

---8<--------------------------------------------------------------
   wpa_supplicant-12507 [000]  2213.950690: rdev_mgmt_frame_register: 
phy5, wdev(2), frame_type: 0x40, reg: true
   wpa_supplicant-12507 [000]  2213.950696: rdev_return_void:     phy5
   wpa_supplicant-12507 [000]  2213.950712: rdev_remain_on_channel: 
phy5, wdev(2), band: 0, freq: 2437, duration: 102
   wpa_supplicant-12507 [000]  2213.950715: rdev_return_int_cookie: 
phy5, returned 0, cookie: 1
   wpa_supplicant-12505 [001]  2213.951216: rdev_mgmt_frame_register: 
phy6, wdev(2), frame_type: 0x40, reg: true
   wpa_supplicant-12505 [001]  2213.951218: rdev_return_void:     phy6
   wpa_supplicant-12505 [001]  2213.951229: rdev_remain_on_channel: 
phy6, wdev(2), band: 0, freq: 2412, duration: 204
   wpa_supplicant-12505 [001]  2213.951231: rdev_return_int_cookie: 
phy6, returned 0, cookie: 1
      kworker/u:0-5     [000]  2213.951394: cfg80211_ready_on_channel: 
wdev(2), cookie: 1, band: 0, freq: 2412, duration: 204
      kworker/u:1-16    [001]  2213.951406: cfg80211_ready_on_channel: 
wdev(2), cookie: 1, band: 0, freq: 2437, duration: 102
      kworker/u:1-16    [001]  2214.053242: 
cfg80211_ready_on_channel_expired: wdev(2), cookie: 1, band: 0, freq: 2437
   wpa_supplicant-12507 [001]  2214.074569: rdev_mgmt_frame_register: 
phy5, wdev(2), frame_type: 0x40, reg: false
   wpa_supplicant-12507 [001]  2214.074611: rdev_return_void:     phy5
   wpa_supplicant-12507 [001]  2214.075060: rdev_scan:            phy5
   wpa_supplicant-12507 [001]  2214.075166: rdev_return_int:      phy5, 
returned: 0
      kworker/u:1-16    [000]  2214.101758: cfg80211_rx_mgmt: 
wdev(1), freq: 2412, sig mbm: -30
      kworker/u:1-16    [000]  2214.101771: cfg80211_return_bool: 
returned false
      kworker/u:1-16    [000]  2214.101786: cfg80211_rx_mgmt: 
wdev(1), freq: 2412, sig mbm: -30
      kworker/u:1-16    [000]  2214.101798: cfg80211_return_bool: 
returned false
      kworker/u:1-16    [000]  2214.153664: 
cfg80211_ready_on_channel_expired: wdev(2), cookie: 1, band: 0, freq: 2412
   wpa_supplicant-12505 [000]  2214.176914: rdev_mgmt_frame_register: 
phy6, wdev(2), frame_type: 0x40, reg: false