Bug 1693684

Summary: incorrect handling of p2p_listen (always use p2p_long_listen)
Product: Red Hat Enterprise Linux 8 Reporter: Vladimir Benes <vbenes>
Component: wpa_supplicantAssignee: Davide Caratti <dcaratti>
Status: CLOSED ERRATA QA Contact: Ken Benoit <kbenoit>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.1CC: atragler, bberg, bgalvani, fgiudici, jkoten, lrintel, rkhan, rvr, sukulkar, thaller
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-18 15:07:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
journal log
none
Updated patch none

Description Vladimir Benes 2019-03-28 13:28:04 UTC
Description of problem:
p2p connection cannot be established at all, it works in F30 with the same NM version.

running 2 mac80211_hwsim devices with one unmanaged by NM with running wpa_supplicant
wpa_supplicant -i wlan1 -C /tmp/wpa_supplicant_peer_ctrl

Then I have executed
wpa_cli -i wlan1 -p /tmp/wpa_supplicant_peer_ctrl p2p_listen

and after connecting NM's connection (details to follow) I am waiting for a 
P2P-GO-NEG-REQUEST 02:00:00:00:00:00 dev_passwd_id=4 go_intent=7

then running:
wpa_cli -i wlan1 -p /tmp/wpa_supplicant_peer_ctrl p2p_connect 02:00:00:00:00:00 pbc auth go_intent=0
and I see always
FAIL

Version-Release number of selected component (if applicable):
NetworkManager-1.16.1-22449.065fa28373.el8.x86_64
wpa_supplicant-2.7-1.el8.x86_64
kernel-4.18.0-67.el8.x86_64

How reproducible:
always

Steps to Reproduce:
0. disable mac randomization  and restart NM service
        echo -e "[device-wifi]\nwifi.scan-rand-mac-address=no" > /etc/NetworkManager/conf.d/99-wifi.conf
        echo -e "[connection-wifi]\nwifi.cloned-mac-address=preserve" >> /etc/NetworkManager/conf.d/99-wifi.conf

1. modprobe mac80211_hwsim
2. nmcli device set wlan1 managed off
3. wpa_supplicant -i wlan1 -C /tmp/wpa_supplicant_peer_ctrl
4. nmcli connection add connection.type wifi-p2p ifname p2p-dev-wlan0 wifi-p2p.peer 02:00:00:00:01:00 autoconnect no
5. wpa_cli -i wlan1 -p /tmp/wpa_supplicant_peer_ctrl p2p_listen
6. nmcli con up wifi-p2p-p2p-dev-wlan0
7. sleep 5; wpa_cli -i wlan1 -p /tmp/wpa_supplicant_peer_ctrl p2p_connect 02:00:00:00:00:00 pbc auth go_intent=0

Comment 1 Vladimir Benes 2019-03-28 13:31:31 UTC
I am waiting for NEG request shown in a terminal where wpa_supplicant -i wlan1 -C /tmp/wpa_supplicant_peer_ctrl is running but I see nothing. So granting access fails.

I ended with these devices:
32: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 02:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
33: wlan1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
34: hwsim0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ieee802.11/radiotap 12:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
36: p2p-wlan1-0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 46:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff

Comment 2 Vladimir Benes 2019-03-28 13:31:56 UTC
Created attachment 1549028 [details]
journal log

Comment 4 Beniamino Galvani 2019-08-29 13:30:35 UTC
On RHEL8 it seems that MACs of the p2p devices are respectively

 42:00:00:00:00:00, 42:00:00:00:01:00

instead of

 02:00:00:00:00:00, 02:00:00:00:01:00

P2P with NM works fine here using these addresses.

Comment 5 Benjamin Berg 2019-09-18 16:41:51 UTC
After a lot of debugging (and help from my brother at Intel), I traced it down to a wpa_supplicant issue. This results in wpa_supplicant to stop listening after 5 seconds, and we never can never see the remote peer on the NetworkManager side.

I submitted a patch upstream which fixes the tests
  http://lists.infradead.org/pipermail/hostap/2019-September/040569.html

I am not sure whether this patch is acceptable upstream; but I am pretty sure it is safe.

Comment 6 Benjamin Berg 2019-09-23 15:00:30 UTC
Created attachment 1618237 [details]
Updated patch

Updated patch. The first revision (as currently submitted upstream) will cause a crash when the P2P interface is brought down again.

Comment 8 Davide Caratti 2020-10-15 15:46:31 UTC
*** Bug 1794332 has been marked as a duplicate of this bug. ***

Comment 12 Ken Benoit 2020-12-18 17:16:04 UTC
Using the MACs from comment 4 with the process from the description, I was able to get a successful connection when testing against RHEL-8.4.0-20201212.n.0. Marking as verified.

Comment 16 errata-xmlrpc 2021-05-18 15:07:07 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: wpa_supplicant security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:1686