P2P Connection Channel Issues
j at w1.fi
Sun Apr 7 07:10:53 PDT 2019
On Tue, Apr 02, 2019 at 12:08:26PM +0200, Andreea Lutac wrote:
> The GO negotiation succeeds, with the tablet always ending up as the group owner, as intended.
> Now the problem is that a lot of the time the group formation step times out. On its end, the tablet seems to set up the DIRECT-xy-<name> group usually on the same frequency as the AP, but on the board wpa_cli shows:
> <3>P2P-GO-NEG-SUCCESS role=client freq=5220 ht40=0 peer_dev=e2:b6:f5:82:18:b5 peer_iface=e2:b6:f5:82:18:b5 wps_method=PBC
> <3>P2P-GROUP-REMOVED p2p-wlan0-32 client reason=FORMATION_FAILED
It would be helpful to look at more detailed debug messages from
wpa_supplicant (-ddt on command line and debug output from stdout).
> I think I have narrowed this down to an issue with the operating channels, where the board's wpa_supplicant tries to scan the various channels during provisioning, but doesn't find the right one before formation times out.
wpa_supplicant starts by scanning the exact channel that was negotiated
during the GO negotiation (i.e., 5220 MHz in this particular example)
and if the GO is not found there in number of scans, more channels are
added to the scan. Maybe this device has some issues scanning 5 GHz
channels (which might cause it to use passive scanning).
> I have tried to add freq=<AP freq> to the p2p_connect command and with some frequencies (5745, 5765) this fixes the timeout and the connection is instant, but with others (5700, 5560, 5580), I get the error message:
wpa_supplicant does not allow channels that require DFS/radar detection
to be used for P2P in most cases which is where that unsupported channel
result comes for those 5700, 5570, 5580 MHz channels.
> Running "iw reg get" on both the tablet and the board shows that the country is unset (00), so I don't think there should be any restriction on the channels. I have however noticed that the operating frequency of the tablet (as reported by p2p_peer) is often different from that of the AP. But adding this operating frequency to p2p_connect still results in timeouts.
00 means that there are lots of restrictions.. I.e., all of 5 GHz is
passive scanning only.
> What could be causing the "channel usupported" message? Is there a way to tell wpa_supplicant which channels to scan during the provisioning phase?
wpa_supplicant debug log shows which channels are being scanned.
Jouni Malinen PGP id EFC895FA
More information about the Hostap