MAC randomization not inhibited on Wi-Fi Direct (p2p) persistent group

[Ircama]

Summary

Reinvoking a persistent group after restarting wpa_supplicant will change the related virtual interface local address, breaking the reuse of the saved group in the peer system.

This limitation prevents to setup effective Wi-Fi Direct configurations between Raspberry Pi and Android mobile phones.

Is this the right place for my bug report?
This issue describes a bug that is either related to:

• the wifi driver of the internal Rasperry Pi 4 board
• wpa_supplicant (notice anyway that this issue remains unchanged by compilng git://w1.fi/srv/git/hostap.git, so it is most probably related to the device driver)
• a need for a specific (and undocumented) setting of the device driver

Describe the bug
When wpa_supplicant.conf includes the configuration of Wi-Fi Direct (p2p) persistent groups, by specification the process should reuse the last local MAC address to avoid breaking the group restart process: unfortunately this does not happen, I believe due to a device driver bug: the MAC randomization feature performed by the Raspberry Pi changes the local bssid of the P2P interface (Wi-Fi Direct) each time wpa_supplicant is restarted.

To reproduce
Create a Wi-Fi Direct persistent group, e.g., by manually editing a template in wpa_supplicant.conf like the following:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1 # this allows wpa_supplicant to update wpa_supplicant.conf with new network stanzas
device_name=DIRECT-<my SSID> # this is the name which appears when connecting
device_type=6-0050F204-1 # this means Access Point
p2p_go_intent=151 # this forces the Raspberry Pi to become a GO (Group Owner)
persistent_reconnect=1 # accept reinvoking a persistent group without separate authorization
p2p_go_ht40=1
country=IT

network={ # persistent group template
        ssid="DIRECT-Myssid"
        psk="my password"
        proto=RSN
        key_mgmt=WPA-PSK
        mode=3
        disabled=2
}

Send the following commands via wpa_cli to activate a Wi-Fi Direct connection using the previously configured persistent group and ensuring of no active AP interface (we assume usage of the p2p-dev-wlan0 interface, keypad config method, only one configured network thus enumerated by number 0, persistent group named p2p-wlan0-0 by p2p_group_add):

wpa_cli -i p2p-dev-wlan0
set config_methods keypad
p2p_group_add persistent=0
interface p2p-wlan0-0
set config_methods keypad
p2p_prov_disc <android_MAC_address> keypad

Setup the first Wi-Fi Direct session on an Android client: Settings > WiFi > Advanced settings > Wi-Fi Direct; as soon as the SSID appears, select it and enter the pin (e.g., 00000000, 8 digits). Immediately after receiving the WPS-ENROLLEE-SEEN event, on that newly created interface issue:

wps_pin any 00000000

After some seconds, the device gets connected.

When the connection is activated, a new saved group appears on the Wi-Fi Direct Android panel, to allow fast reconnection. In fact, if you now disconnect the link on the Android phone and try to reconnect it, including Android reboot, the connection becomes immediately active without password request (i.e., reusing the same saved group).

Actual behavior
Nevertheless, if you restart wpa_supplicant on the Raspberry Pi and redo the previously described wpa_cli procedure, the pin is asked again (should not) and a new saved group is created on the Android phone, below the previous one which remains useless (and can be deleted).

This is effectively the problem and might happen because the bssid of the Raspberry Pi also includes the saved group, which is expected to remain unchanged with a reboot of wpa_supplicant. But the MAC randomization feature performed by the Raspberry Pi, enhancing privacy, changes the local bssid of the P2P interface (Wi-Fi Direct) each time wpa_supplicant is restarted.

Expected behavior
When wpa_supplicant.conf includes the configuration of persistent groups, the process should reuse the last local MAC address to avoid breaking the group restart process.

Further analysis
To better analyze this issue I tested an undocumented way to force a specific MAC for P2P session, by setting the following two parameters in wpa_supplicant.conf:

p2p_device_random_mac_addr=1 # by default it is set to zero
p2p_device_persistent_mac_addr=<use a valid MAC address here>

By running wpa_supplicant with -dd option, the following error is returned, essentially produced by wpa_drv_set_mac_addr(wpa_s, addr):

p2p-dev-wlan0: Restore last used MAC address.
Could not read interface p2p-dev-wlan0 flags: No such device
p2p-dev-wlan0: Failed to set random MAC address
p2p-dev-wlan0: Failed to initialize P2P random MAC address.
p2p-dev-wlan0: Failed to init P2P
Failed to add interface p2p-dev-wlan0
p2p-dev-wlan0: Request to deauthenticate - bssid=00:00:00:00:00:00 pending_bssid=00:00:00:00:00:00 reason=3 state=INACTIVE

Also the parameter mac_addr=0 has no effect.

It appears that randomization is a default feature for the virtual interfaces managed by the device driver of the internal wifi board of the Raspberry Pi and changing the local MAC address is not allowed.

System
Results of the raspinfo command

• Which model of Raspberry Pi? Pi4 Model B

• Which OS and version (cat /etc/rpi-issue)?
  Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 9a3a10bf1019ebb2d59053564dc6b90068bad27d, stage4

• Which firmware version (vcgencmd version)?
  Oct 22 2020 13:59:27
  Copyright (c) 2012 Broadcom
  version 74e754ff8947c58d2773253f77f6f68a303188f8 (clean) (release) (start)

• Which kernel version (uname -a)?
  Linux RaspberryPi 5.4.72-v7l+ tvservice HDMI dropout in dual screen mode #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/Linux

[pelwell]

This forum is for problems with the VPU firmware, not the WiFi. Also, I think you might have stumbled across a general problem in systemd/udev: systemd/systemd#13642

[Ircama]

[Edited after some investigation on wpa_supplicant]

@pelwell, I am closing this issue here; I have also verified that the problem is not in the firmware but related to userspace tools and has to be analyzed elsewhere.

In relation to systemd/systemd#13642, I think my problem could be different because it only occurs after restarting wpa_supplicant. Without restarting, persistent groups work correctly with Raspberry Pi acting as a GO, allowing fast reconnection of the peer without authentication (after the first connection process is accomplished). After restarting wpa_supplicant, by issuing p2p_group_add persistent=0, a new persistent group is created in wpa_supplicant.conf, with a different bssid (instead of reusing the previously defined one). I think that this produces the need for the peer to redo the authentication process when a reconnection is asked, so that it can also register this new group (instead of fast reconnection to the previously saved group).

[Ircama]

There is now a solution to this issue.

In summary, the wlan device driver of the CYW43455 802.11 wireless interface (or the firmware) uses randomized MAC addresses by default when starting network interfaces. This might be probably checked with iw list | grep 'randomizing MAC-addr':

Device supports randomizing MAC-addr in sched scans.

Anyway, when using Wi-Fi Direct P2P persistent groups, MAC addresses shall not vary in order to avoid breaking the group restart.

The current Raspberry Pi device driver does not support setting p2p_device_random_mac_addr=1 as this option relies on SIOCGIFFLAGS/SIOCSIFFLAGS ioctl interface control operations to change the MAC address, that are not working with the Raspberry Pi wlan device driver (or the firmware) at the moment.

In order to overcome such kind of limitations, a new version of wpa_supplicant now supports p2p_device_random_mac_addr=2, which allows correctly managing persistent groups on a Raspberry Pi.

How to compile, install and use this option is described here.

@pelwell, the MAC address that needs to be reused shall not be the P2P group (e.g, p2p-wlan0-0 of type P2P-GO), but the P2P-device, which is an unnamed/non-netdev interface, that is not controlled by systemd/udev. To check this, after appropriately configuring wpa_supplicant.conf, run the following:

systemctl stop dhcpcd # this stops wpa_supplicant
udevadm monitor --environment kernel & # monitor udev events
systemctl start dhcpcd # restarts wpa_supplicant
fg # use control-C to stop udevadm

Example:

Add this configuration in wpa_supplicant.conf:

p2p_device_random_mac_addr=2
p2p_device_persistent_mac_addr=ee:11:6c:59:a3:d4

This is the result of iw dev:

phy#0
        Interface p2p-wlan0-0
                ifindex 10
                wdev 0x10
                addr ee:11:6c:59:23:d4
                type P2P-GO
                channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
                txpower 31.00 dBm
        Unnamed/non-netdev interface
                wdev 0xf
                addr ee:11:6c:59:a3:d4
                type P2P-device
                txpower 31.00 dBm
        Interface wlan0
                ifindex 3
                wdev 0x1
                addr dc:a6:32:00:9a:f5
                ssid WLAN-ROUTER
                type managed
                channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
                txpower 31.00 dBm

Notice that the P2P-device reuses the MAC address configured in p2p_device_persistent_mac_addr, while the p2p-wlan0-0 MAC address, which can be controlled by udev, is different (and this is appropriate for the P2P-GO to work).