WARNING: supplicant: wpa_supplicant or driver does not support P2P (supplicant_status_fn() in /home/pi/miraclecast/src/wifi/wifid-supplicant.c:1698)

[keny5551]

WARNING: supplicant: wpa_supplicant or driver does not support P2P (supplicant_status_fn() in /home/pi/miraclecast/src/wifi/wifid-supplicant.c:1698)

on raspberry pi

[albfan]

You have to check if your usb dongle support P2P (as rpi1 do not has WiFi hardware). There's a script to check that

[keny5551]

pi@raspberrypi:~/miraclecast/res $ ./test-hardware-capabilities.sh wlan0 supports P2P

[albfan]

Then you need to submit your logs to check the problem

https://github.com/albfan/miraclecast/wiki/FAQ#log-for-support

[keny5551]

logs.tar.gz

[albfan]

Here https://github.com/albfan/miraclecast/blob/master/src/wifi/wifid-supplicant.c#L1697 miraclecast read the response from dbus to enable p2p. a good response is:

TRACE: wpa: raw message: p2p_device_address=00:00:00:00:00:00
p2p_state=IDLE
wifi_display=1
ifname=p2p-dev-wlan0
address=00:00:00:00:00:00
ifname=wlan0
address=00:00:00:00:00:00

but yours is

TRACE: wpa: raw message: wifi_display=1
ifname=wlan0
address=b8:27:eb:31:0b:83

can you include dbus messages in log? Why your drivers decide to not enable p2p is beyond the competence of miraclecast, if test-hardware-capabilities.sh say so it should

Did you stop the network manager before run miraclecast? At this time miraclecast reuses the existing wpa_supplicant launched, and the one created by networkmanager have a non p2p config. If you stop it, miraclecast create a new one with p2p enabled. Read how in https://github.com/albfan/miraclecast/wiki/FAQ#bring-down-wifi-interfaces

[keny5551]

Hi, if i want to stop network manager

pi@raspberrypi:~ $ sudo systemctl stop NetworkManager
Failed to stop NetworkManager.service: Unit NetworkManager.service not loaded.

now i have installed it "sudo apt-get install network-manager", reboot and again have error

"WARNING: supplicant: wpa_supplicant or driver does not support P2P (supplicant_status_fn() in /home/pi/miraclecast/src/wifi/wifid-supplicant.c:1698)"

where i can see dbus messages?

[albfan]

what you need to stop is whatever process that launches wpa_supplicant

You can check

ps -ef | grep wpa_supplican[t]

to find if wpa_supplicant is launched, and kill it with

kill -9 <pid>

Stopping a service is recommended as many network managers relaunch wpa_supplicant, so although you kill it it will be up again

To see dbus messages you need a CLI tool like dbus-monitor, as said on https://github.com/albfan/miraclecast/wiki/FAQ#log-for-support

I think will be useful to say what OS, version, systemd version (systemctl --version) and network manager you use to give you support

[ComradePashka]

Hello! I have same issue. I am using R-Pi 3 model B, I downloaded your suggested Pi image archarm230716.gz and followed all steps listed in https://github.com/albfan/miraclecast/wiki/raspberry-pi-3

Everytime I kill wpa_supplicant proccess there is a messages from miracle-wifid:

ERROR: supplicant: wpas (pid:696) failed unexpectedly, relaunching after short grace period.. (supplicant_failed() in wifid-supplicant.c:2331)
WARNING: supplicant: wpa_supplicant or driver does not support P2P (supplicant_status_fn() in wifid-supplicant.c:1698)

in my case scrip test-hardware-capabilities.sh also said:

wlan0 supports P2P

here is my logs created as mentioned in https://github.com/albfan/miraclecast/wiki/FAQ#log-for-support : logs.tar.gz

output for systemctl --version:

systemd 230
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN

[albfan]

@ComradePashka did you stop the network manager as said on https://github.com/albfan/miraclecast/wiki/raspberry-pi-3?

[ComradePashka]

@albfan yes, sure

[ganeshjkale]

ps -eaf | grep wpa
root       434     1  0 05:32 ?        00:00:00 wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant.conf -iwlan0 -Dnl80211,wext
kill -9 434

[albfan]

These days I'm trying with raspbian as systemd is updated enough (v232) to run miraclecast

@gnshkl1 what OS and version are you using?

@ComradePashka is better that you open your own issue. See if you kill your wpa_supplicant while running miracle-wifid it will restart it. You need to stop wpa_supplicant (or anything that restart it like NetworkManager) before run miracle-wifid

See after merge #135, this could be not needed anymore, so this annoying step will be removed soon allowing #75 which is a long wanted feature

[ganeshjkale]

@albfan raspbian strech

[albfan]

@gnshkl1 then hope my recent tries can help on these. Will update soon

[Aeronaut]

Same issue with my Intel(R) Dual Band Wireless AC 9560 M.2 Card...

TRACE: wpa: raw message: wifi_display=1
ifname=wlp0s12f0
address=00:00:00:00:00:00

WARNING: supplicant: wpa_supplicant or driver does not support P2P (supplicant_status_fn() in /root/miraclecast/src/wifi/wifid-supplicant.c:1698)

Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-36-generic x86_64)

[albfan]

@aeronaut did you check your P2P capabilities? See README for that

[Aeronaut]

Yes,

$ ./test-hardware-capabilities.sh
wlp0s12f0 supports P2P

Edit: Added dbus.log

[albfan]

@Aeronaut then is possible that you do not disable NetworkManager. We are working on #75, but by now you need to stop NetworkManager

if there's a wpa_supplicant -u doing:

ps -ef | grep wpa_supplicant

I'm sure that's the cause (miraclecast try to reuse an existing wpa_supplicant which is not configured for p2p)

See those services try to reconnect if stopped so you need to do:

systemctl disable wpa_supplicant
systemctl disable NetworkManager
systemctl stop wpa_supplicant
systemctl stop NetworkManager

When you want to use Wifi again do:

systemctl enable wpa_supplicant
systemctl enable NetworkManager
systemctl start wpa_supplicant
systemctl start NetworkManager

[Aeronaut]

I already added to NetworkManager.conf:

[keyfile]
unmanaged-devices=mac:<my mac>

And NetworkManager shows the Card as unmanaged... Also there is no wpa_supplicant process. And after strating miracle-wifid:

$ ps -ef | grep wpa_supplicant
root      5984  5982  0 10:27 pts/1    00:00:00 /sbin/wpa_supplicant -c /run/miracle/wifi/wlp0s12f0-3.conf -C /run/miracle/wifi -i wlp0s12f0 -g /run/miracle/wifi/wlp0s12f0-3.global
root      5988  2014  0 10:28 pts/2    00:00:00 grep --color=auto wpa_supplicant

Is there a way to figure out, if wpa_supplicant isn't able to get the Card in P2P mode?

[albfan]

Then read in wiki FAQ, how to provide logs for support

[Aeronaut]

Sorry, I just see that I have sent a tailed log... Full log of miracle-wifid, essentially:

$ miracle-wifid --log-level trace
INFO: miracle-wifid - revision 1.0 Oct 21 2018 18:35:25
DEBUG: friendly-name from local hostname: ursl (manager_read_name() in /root/miraclecast/src/wifi/wifid.c:388)
DEBUG: link: new link: wlp0s12f0 (3) (link_new() in /root/miraclecast/src/wifi/wifid-link.c:71)
DEBUG: supplicant: new supplicant for wlp0s12f0 (supplicant_new() in /root/miraclecast/src/wifi/wifid-supplicant.c:2103)
INFO: link: add link: wlp0s12f0
INFO: link: manage link wlp0s12f0
DEBUG: supplicant: start supplicant of wlp0s12f0 (supplicant_start() in /root/miraclecast/src/wifi/wifid-supplicant.c:2628)
DEBUG: supplicant: spawn supplicant of wlp0s12f0 (supplicant_spawn() in /root/miraclecast/src/wifi/wifid-supplicant.c:2478)
INFO: supplicant: wpa_supplicant found: /sbin/wpa_supplicant
INFO: supplicant: wpas spawned as pid:5984
DEBUG: supplicant: open supplicant of wlp0s12f0 (supplicant_open() in /root/miraclecast/src/wifi/wifid-supplicant.c:2269)
TRACE: wpa: raw message: OK

TRACE: wpa: raw message: wifi_display=1
ifname=wlp0s12f0
address=00:00:00:00:00:00

WARNING: supplicant: wpa_supplicant or driver does not support P2P (supplicant_status_fn() in /root/miraclecast/src/wifi/wifid-supplicant.c:1698)

[albfan]

@Aeronaut try to get them on files and upload journalctl.log and others to see what's happening

[Aeronaut]

logs.zip

[albfan]

@Aeronaut I guess your problem is related with:

Okt 23 12:38:09 ursl miracle-wifid-wlp0s12f0-3[13633]: Successfully initialized wpa_supplicant
Okt 23 12:38:09 ursl miracle-wifid-wlp0s12f0-3[13633]: Failed to create interface p2p-dev-wlp0s12f0: -22 (Invalid argument)
Okt 23 12:38:09 ursl miracle-wifid-wlp0s12f0-3[13633]: nl80211: Failed to create a P2P Device interface p2p-dev-wlp0s12f0
Okt 23 12:38:09 ursl miracle-wifid-wlp0s12f0-3[13633]: P2P: Failed to enable P2P Device interface

But not sure what's is happening underneath

[htto]

I stumbled on the same issue like @Aeronaut on my Intel(R) Dual Band Wireless AC 8265, REV=0x230 and it seems that the generated p2p interface name is too long (my interface is 'wireless' and generated one is 'p2p-dev-wireless'):

# iw phy0 interface add p2p-dev-wireless type adhoc
kernel reports: Attribute failed policy validation
command failed: Invalid argument (-22)
# iw phy0 interface add p2p-dev-wireles type adhoc

From the looks of it, it seems the limit is 14 chars. Since I found no way to tell miraclecast how to name the interface I resorted to rename (actually re-create with different name) my interface from 'wireless' to 'wifi':

# iw dev wireless del
# iw dev add wifi type managed

miracle-wifid then works and has the correct trace:

p2p_state=IDLE
wifi_display=1
ifname=p2p-dev-wifi
address=aa:bb:cc:dd:ee:ff
ifname=wifi
address=aa:bb:cc:dd:ee:ff

However according to the source p2p-dev-... should be the legacy p2p device if the card/driver doesn't support client/go p2p directly. Though, my card has

Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * AP/VLAN
                 * monitor
                 * P2P-client
                 * P2P-GO
                 * P2P-device

and thus shouldn't need the legacy interface in the first place. Maybe there's a check missing in the code?

[albfan]

@htto Nice research. If you can find evidences that name should be that long max would be great.

No magic here, https://github.com/albfan/miraclecast/blob/master/src/wifi/wifid-supplicant.c#L1698

if wpa_supplicant do not report it has a p2p_state, miraclecast cannot use it. As always provide logs for support (check the FAQ in wiki)

[htto]

@htto Nice research. If you can find evidences that name should be that long max would be great.

Ok, so I mis-counted...

It's actually length 15 that still works:

# iw phy0 interface add p2p-dev-wireles type adhoc

and 16 that starts to fail:

# iw phy0 interface add p2p-dev-wireless type adhoc
kernel reports: Attribute failed policy validation
command failed: Invalid argument (-22)

though net/if.h does #define IF_NAMESIZE 16, but probably the terminating NULL counts as 16th char.

Anyway this leaves 7 chars for the interface name to still support the legacy p2p-dev-...-interface, since 8 chars get prepended... I wonder if one could reduce the prepended character count...

About the other not-so-issueish-issue:

No magic here, https://github.com/albfan/miraclecast/blob/master/src/wifi/wifid-supplicant.c#L1698

if wpa_supplicant do not report it has a p2p_state, miraclecast cannot use it. As always provide logs for support (check the FAQ in wiki)

In my previous post I put the trace output excerpt (with the shortened interface name) which shows the wpas response containing p2p_state=IDLE, which wpa_supplicant returns only if these hold:

#ifdef CONFIG_P2P
    if (global->p2p && !global->p2p_disabled) {

So I assume that's the relevant one and my chipset/driver supports it.

What I'm actually driving at is

 * We support rate-controlled restarting of wpas connections, respawning in case
 * of errors and other fallback handling. We open one connection to the global
 * control interface of wpas, and in case of legacy drivers, a separate
 * p2p-dev-* iface connection.

* Devices with P2P_DEVICE support (instead of direct P2P_GO/CLIENT
 * support) are broken with a *lot* of wpa_supplicant versions on the
 * global interface. Therefore, try to open the p2p-dev-* interface
 * after the global-ATTACH succeded (which means the iface is properly
 * set up). If this works, use the p2p-dev-* interface, otherwise, just
 * copy the global interface over to bus_dev.

So reading that I feel like not actually needing the legacy interface, because my device has direct P2P_GO/CLIENT support (see last comment of mine), but the legacy interface seems to be unconditionally added in https://github.com/albfan/miraclecast/blob/master/src/wifi/wifid-supplicant.c#L2223 or https://github.com/albfan/miraclecast/blob/master/src/wifi/wifid-supplicant.c#L2640 (not that familiar with the code). But that's probably some future feature to think about.

[tomakkermans]

I am also stuck at this error :(

[AVCHD]

Same issue with my Intel(R) Dual Band Wireless AC 9560 M.2 Card...

TRACE: wpa: raw message: wifi_display=1
ifname=wlp0s12f0
address=00:00:00:00:00:00

WARNING: supplicant: wpa_supplicant or driver does not support P2P (supplicant_status_fn() in /root/miraclecast/src/wifi/wifid-supplicant.c:1698)

Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-36-generic x86_64)

I met this error, have you issue be solved ?

[benzea]

This should be fixed by https://patchwork.ozlabs.org/project/hostap/patch/20200615151142.1434683-1-benjamin@sipsolutions.net/

EDIT: Wait … at least part of the issues that people are having seems to be that p2p wifi is not supported. Which is either a wpa_supplicant (configuration option) or HW limitation (iw phy would show).

[albfan]

@benzea at what version it should be released?

[benzea]

@albfan it has not been accepted yet :)

I half suspect that Jouni will merge something different. I did submit an PR for wpa_supplicant in Fedora so that it will be available there. I think this is only needed with newer systemd versions (as the device renaming scheme changed).

[JeromeDeBretagne]

I've faced exactly the same issue. Compiling wpa_supplicant from master fixes the problem indeed since your patch @benzea was merged in October: P2P: Limit P2P_DEVICE name to appropriate ifname size.

For anyone interested, I've submited a bug report to Debian for this issue: Long Wi-Fi interface name crashes wpa_supplicant impacting Wi-Fi Display and P2P

[geofflangenderfer]

pi@raspberrypi:~/miraclecast/res $ ./test-hardware-capabilities.sh wlan0 supports P2P

$ ./test-hardware-capabilities.sh
Sorry, wlo1 do not support P2P

[Photon89]

I stumbled upon this as well. Using the latest git commit (via https://aur.archlinux.org/packages/miraclecast-git/) I get:

Mai 18 17:22:20 ThinkpadL13Yoga miracle-wifid-wlp0s20f3-3[4649]: Successfully initialized wpa_supplicant
Mai 18 17:22:20 ThinkpadL13Yoga miracle-wifid-wlp0s20f3-3[4649]: nl80211: kernel reports: Attribute failed policy validation
Mai 18 17:22:20 ThinkpadL13Yoga miracle-wifid-wlp0s20f3-3[4649]: Failed to create interface p2p-dev-wlp0s20f3: -22 (Invalid argument)
Mai 18 17:22:20 ThinkpadL13Yoga miracle-wifid-wlp0s20f3-3[4649]: nl80211: Failed to create a P2P Device interface p2p-dev-wlp0s20f3
Mai 18 17:22:20 ThinkpadL13Yoga miracle-wifid-wlp0s20f3-3[4649]: P2P: Failed to enable P2P Device interface
Mai 18 17:22:20 ThinkpadL13Yoga miracle-wifid-wlp0s20f3-3[4649]: wlp0s20f3: CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=WORLD

What can I do?

[JeromeDeBretagne]

What can I do?

You can check if your version of wpa_supplicant is recent enough and contains the fix discussed above: http://w1.fi/cgit/hostap/commit/?id=c0b88d

[Photon89]

No, I don't, thanks. :smile: Didn't think that the latest stable version is older than the fix... Will try the latest git version and report back asap.

[wanted002]

https://github.com/albfan/miraclecast/issues/285#issuecomment-400187904 I' realy puzzled at this point shown in your answer which is linked above. "Did you stop the network manager before run miraclecast? At this time miraclecast reuses the existing wpa_supplicant launched" ---- I got two questions, please help me ~ 1) why miraclecast reuses the existing wpa_supplicant ? I do meet the situation. But from the code in file wifi_wupplicant.c , supplicant_spawn is really executed, and a new wpa_supplicant is spawned, but my miracle-wifid seems to attached to the existing wpa_supplicant. I really don't known why..... 2) "At this time ...", is it means that : If the wireless device not have the "P2P-DEVICE" interface modes shown in "iw list" cmd ? What does "P2P-DEVICE" mean? My opinion, if the device dose not have this mode, wifi and widi cannot be used at the same time.

Thanks a lot.

[albfan]

@wanted002 miraclecast spawns wpa_supplicant and use it, but there's no way to check if it is configured as expected. If your network manager already spawns it, miraclecast just found it and reuses (but config will not work for wifi direct)

What a wifi card needs is a P2P-client and P2P-GO (as which device will be group owner and client is decided on handshake)

Allow to use wifi and widi at same time depends on multi network capability (almost all network cards allow that)

To do that miraclecast should talk with dbus interface of existing wpa_supplicant to spawn a wifi direct connection at same time that it has the normal wifi running.

[phmarek]

Hi!

I make sure there's no NetworkManager or wpasupplicant running; then

$ test-hardware-capabilities.sh
Sorry, wlan0 do not support P2P

but

$ iw phy phy0 info | grep P2P
                 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * P2P-client: 0x40 0xd0
                 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
                 * P2P-device: 0x40 0xd0

See attached; start_p2p_device also comes up in that dump. iw-phy-info.txt

Should P2P work in this setup? (Debian testing/unstable, AMD64, Realtek Semiconductor Co., Ltd. RTL8822BE 802.11a/b/g/n/ac WiFi adapter 10ec:b822).

Trying to receive I get

WARNING: supplicant: wpa_supplicant or driver does not support P2P (supplicant_status_fn() in wifid-supplicant.c:1705)

Thanks for any help!

[albfan]

Os not just find P2P on that output, needs to be on "Support interface mode" section:

https://github.com/albfan/miraclecast/blob/master/res/miracle-utils.sh#L112

[phmarek]

Ok. Well, Supported Commands shows start_p2p_device. Does that mean

1. The hardware is incompatible? Or
2. The kernel-driver is missing this feature? (I'm already running 5.18.0-2-amd64, so no much hope of improvement)
3. The kernel-driver is misreporting some flag
4. The detection for support needs improvement

I have a hard time believing that some special features are needed - if I use Ethernet for upstream connectivity, and wlan0 is completely available, couldn't at least the frames be constructed in userspace entirely and sent via libpcap or some equivalent?

Furthermore, my understanding was that there's some broadcast packet to announce a receiver on the same LAN - so the sender could use Wifi and the receiver Ethernet, as long as they're sharing a broadcast segment and can connect via TCP??

Thanks for your patience!!

[phmarek]

This SSDP frame is what I'm thinking of... my smartphone sends these as soon as I try screen sharing:

Frame 48: 136 bytes on wire (1088 bits), 136 bytes captured (1088 bits) on interface eth0, id 0
Ethernet II, Src: SamsungE_xx:xx:xx (0c:2f:b0:xx:xx:xx), Dst: IPv4mcast_7f:ff:fa (01:00:5e:7f:ff:fa)
Internet Protocol Version 4, Src: 10.x.x.x, Dst: 239.255.255.250
User Datagram Protocol, Src Port: 3942, Dst Port: 1900
Simple Service Discovery Protocol
    M-SEARCH * HTTP/1.1\r\n
    ST: ssdp:all\r\n
    MX: 1\r\n
    MAN: "ssdp:discover"\r\n
    HOST: 239.255.255.250:1900\r\n
    \r\n
    [Full request URI: http://239.255.255.250:1900*]
    [HTTP request 4/4]
    [Prev request in frame: 47]

Wouldn't replying to such a query be good enough as well, obviating the need for special Wifi features?

[albfan]

I don't think so.

https://github.com/lwfinger/rtw88/issues/39

miracast is a protocol over wifi direct, so all interaction happen over it

[phmarek]

Ah, thanks. Though that says

Have you tried P2P using NetworkManager. That should work for any mac80211-based wireless driver.

So it's just waiting for someone else ;/

I hoped that it would be easy enough to reply to SSDP and receive the same(?) data stream then over TCP -- but if it's a completely different protocol...