Usage with Raspberry Pi

[AllergicMushroom]

Hello, I have a very old TV. I didn't check but I would be surprised to run this on that TV.

However, I have a Raspberry Pi that is just below the TV. Can I use fluxcast to send image from my computer in another room to the Raspberry Pi, and then plug HDMI cable from the Pi to the TV?

I thought this was possible with Miracast, but I don't have the same feeling from fluxcast's readme.

[IlyaP358]

Good question.
FluxCast is the sender, so the Pi needs to run a Miracast sink. On a Pi option is lazycast (a wireless-display receiver, i think miraclecast can also do the sink side too). In theory it should work, FluxCast speaks standard Wi-Fi Display and handles the RTSP handshake from either side, lazycast is a standard WFD sink, so the two should pair over Wi-Fi Direct and stream, with the Pi driving your old TV over HDMI. "Small" distance isn't the issue, Wi-Fi Direct works fine through the wall from my other room.

Honest disclaimer! I haven't tested FluxCast against a Pi/lazycast sink, so I can't promise the handshake lines up first try. The usual sticking points between two implementations that have never met are the P2P group-owner negotiation and the video-format negotiation. But it's the right thing to try, because it's the low-latency path, and latency is the whole point of Miracast.

The DLNA route (a UPnP renderer like gmrender-resurrect on the Pi + --protocol dlna) is more likely to just work over your network, but it has several seconds of latency, so I'd treat it only as a fallback if the lazycast route doesn't pan out.

If you do try lazycast, i'd genuinely love to hear whether it works =]. That combo is uncharted for FluxCast and confirming it would help a lot of people with an old TV and a spare Pi.

[AllergicMushroom]

So I've just tried Miracast, and I feel like I'm blocked now.

Miracast sink seems to be working, as in there's no error messages. However, neither FluxCast nor my Android phone can cast to it. Same for Gnome Network Displays.

[FluxCast Doctor] System capability report
[FluxCast Doctor] Miracast/WFD looks possible via NetworkManager; raw supplicant access is optional for this backend.

  Status Check                  Details
  ------ ---------------------- ------------------------------------------
  ok     python                 runtime (3.14.6 on Linux 7.0.14-arch1-1)
  ok     ffmpeg                 video/audio transcoding (/usr/bin/ffmpeg)
  warn   wf-recorder            Wayland/wlroots screen capture (not found in PATH)
  warn   xdg-desktop-portal     portal daemon running but no backend process detected (is a portal backend installed and enabled?)
  ok     pactl                  PulseAudio/PipeWire-Pulse audio monitor detection (/usr/bin/pactl)
  ok     xrandr                 X11 monitor detection fallback (/usr/bin/xrandr)
  ok     nmcli                  NetworkManager Wi-Fi Direct control (/usr/bin/nmcli)
  ok     dnsmasq                NetworkManager P2P DHCP server (/usr/bin/dnsmasq)
  ok     iw                     kernel Wi-Fi interface inspection (/usr/bin/iw)
  ok     wpa_cli                active Wi-Fi Direct scan/control (/usr/bin/wpa_cli)
  ok     gdbus                  passive wpa_supplicant D-Bus capability checks (/usr/bin/gdbus)
  ok     gst-launch-1.0         optional future WFD GStreamer pipeline (/usr/bin/gst-launch-1.0)
  ok     gst-inspect-1.0        optional future WFD codec inspection (/usr/bin/gst-inspect-1.0)
  warn   gst element pipewiresrc Wayland portal GStreamer capture source is missing (No such element or plugin 'pipewiresrc'; install the GStreamer PipeWire plugin (Debian/Ubuntu: gstreamer1.0-pipewire; Arch/Fedora: gst-plugin-pipewire))
  warn   gst element x264enc    Wayland portal GStreamer H.264 encoder is missing (No such element or plugin 'x264enc'; install the GStreamer x264 plugin (Debian/Ubuntu: gstreamer1.0-plugins-ugly; Arch/Fedora: gst-plugins-ugly))
  warn   dbus_next              WFD portal capture control plane for KDE/GNOME Wayland (python module is missing; install with pip)
  ok     ffmpeg encoders        H.264 and AAC encoders are available (h264=libx264, h264_vaapi, h264_nvenc, h264_qsv, h264_v4l2m2m; aac=yes)
  ok     screen capture         X11 capture path is available (DISPLAY=:0; xrandr=/usr/bin/xrandr)
  warn   audio capture          default audio sink was not reported (Connection failure: Connection refused | pa_context_connect() failed: Connection refused)
  ok     NetworkManager         Wi-Fi and P2P devices are visible (nmcli tool, version 1.56.1-1; enp38s0:ethernet:connected | wlo1:wifi:connected | lo:loopback:connected (externally) | wg0-mullvad:wireguard:connected (externally) | p2p-dev-wlo1:wifi-p2p:disconnected)
  ok     iw P2P                 kernel exposes a P2P-device interface (phy#0 | 	Interface p2p-wlo1-1 | 		ifindex 21 | 		wdev 0x9 | 		addr 8c:c6:81:cd:18:84 | 		type P2P-client | 		multicast TXQ: | 			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets | 		00	0	0	0	0	0	0		0 | 	Unnamed/non-netdev interface | 		wdev 0x7 | 		addr 8c:c6:81:cd:18:83 | 		type P2P-device | 	Interface wlo1 | 		ifindex 3 | 		wdev 0x1 | 		addr 8c:c6:81:cd:18:83 | 		ssid SFR_1AA0_5GHZ | 		type managed | 		channel 48 (5240 MHz), width: 80 MHz, center1: 5210 MHz | 		txpower 22.00 dBm | 		multicast TXQ: | 			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets | 			0	0	0	0	0	0	0	0		0)
  ok     wpa_supplicant P2P     wpa_supplicant reports P2P support ((<['ap', 'ibss-rsn', 'p2p', 'interworking', 'pmf', 'mesh', 'fils', 'fils_sk_pfs', 'ft', 'sha384', 'owe', 'suiteb192', 'wep_disabled']>,))
  ok     wpa_supplicant WFD     wpa_supplicant accepts Wi-Fi Display IEs ((<@ay []>,))
  skip   firewall               no supported firewall front-end detected (checked ufw and firewall-cmd; open port 7236/tcp manually if a firewall blocks it)

I have no idea how to debug further. Do you perhaps have any hint?

Also, I noticed that Miracast creates a p2p-dev-wlan0 entry, whereas FluxCast scans for a p2p-dev-wlo1. Could this affect the outcome?

Note: I can't install FluxCast from AUR due to broken dependencies.

[IlyaP358]

Hi @AllergicMushroom. Thanks, that's really useful.

The key thing: your phone and Gnome Network Displays can't reach the sink either, not just FluxCast. when three different senders all fail, the problem is almost certainly the sink on the Pi, not the sender. "no errors" from MiracleCast doesn't mean it's actually advertising itself over the air.

quick note on the names: p2p-dev-wlan0 (Pi) vs p2p-dev-wlo1 (your PC) is expected, those are just two different machines with different naming. no effect on pairing.

please check on your PC:
python3 src/main.py --wfd-scan
does the Pi show up as a peer at all? if not, there's simply nothing for any sender to connect to.

on the Pi (base tools, nothing to install):
iw list | grep -A8 "Supported interface modes"
iw list | grep -A15 "valid interface combinations"
sudo dmesg | grep -i brcmfmac | tail -20

the first one check if can the Pi's wifi even do P2P (look for P2P-GO / P2P-client).
second if can it do P2P while connected to your home wifi (single radio).
third: driver errors.

send those outputs over and we'll know which way this is going 👍

[AllergicMushroom]

@IlyaP358 I also thought that it's MiracleCast, I just have no idea how to debug this, and the repo is kinda dead.

python3 src/main.py --wfd-scan shows only a "G600 series", which I guess is my printer.

iw list | grep -A8 "Supported interface modes" returns

	Supported interface modes:
		* IBSS
		* managed
		* AP
		* P2P-client
		* P2P-GO
		* P2P-device
	Band 1:
		Capabilities: 0x1020

iw list | grep -A15 "valid interface combinations" returns

valid interface combinations:
		* #{ managed } <= 2, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
		  total <= 3, #channels <= 2
		* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
		  total <= 4, #channels <= 1
	Device supports SAE with AUTHENTICATE command
	Device supports scan flush.
	Device supports randomizing MAC-addr in sched scans.
	max # scan plans: 1
	max scan plan interval: 508
	max scan plan iterations: 0
	Supported TX frame types:
		* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		* AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		* 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

sudo dmesg | grep -i brcmfmac | tail -20 returns

[    2.672952] brcmfmac: F1 signature read @0x18000000=0x15264345
[    2.674472] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    2.689670] usbcore: registered new interface driver brcmfmac
[    2.862684] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2)
[    2.862951] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Aug 29 2023 01:47:08 version 7.45.265 (28bca26 CY) FWID 01-b677b91b
[    3.785773] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[   71.259607] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[  825.823175] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[  843.802704] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[ 1019.351503] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[ 3066.976743] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[32187.181339] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled

[IlyaP358]

Thanks for running all that. Combined with the #548 thread, here's the honest picture.

Your iw list shows the Pi does advertise P2P (P2P-GO is listed), and the clean dmesg is only because your sink never became discoverable, so the driver never reached the step that actually fails. --wfd-scan seeing just your printer confirms the sink isn't advertising yet (the NetworkManager/wpa_supplicant holding the interface thing).

The real wall is the next step. On the same Pi 5 built-in chip, Manoj in #548 got past discovery and the driver died right at the handshake:

ieee80211 phy0: brcmf_p2p_send_action_frame: Failed to send Action Frame(retry 5)
P2P-GO-NEG-FAILURE status=-1

That's a known, widespread bug in the Pi's built-in Broadcom wifi (reported on Pi 3/4 and a Pi 5 too), not a config mistake on your side. So even if you fix discovery, you'd very likely hit that same wall.

Honest bottom line: the built-in Pi 5 wifi is effectively a dead end for a Miracast sink right now =[, and it isn't something you did wrong. The only theoretical way around it is a USB wifi dongle with a chip that does P2P properly, but I couldn't find anyone confirming a working sink that way, so treat it as a gamble, not a fix. I'd rather be straight about that than have you lose days on the onboard chip like Manoj did.

[AllergicMushroom]

Thank you for your message. Do you have any idea why the sink isn't advertising?

If it's quick to fix I'd like to check if I have the same other wall (I expect to have it but we never know). If I get the same problem I'll just abandon the idea of using the Raspberry for this purpose.

Also, out of curiosity, what do most users use as sink? Old computers?

[IlyaP358]

The sink isn't advertising because NetworkManager/wpa_supplicant still hold the wifi, so MiracleCast can't take the interface over. To get past that (and reach the point where you can test the second wall), on the Pi:

sudo systemctl stop NetworkManager wpa_supplicant
if a wpa_supplicant is still running (e.g. wpa_supplicant@wlan0):
sudo pkill wpa_supplicant

sudo iw dev wlan0 set power_save off
sudo miracle-wifid -i wlan0 --config-methods display --use-dev &
sudo miracle-sinkctl

then in sinkctl: set-managed <link#> yes, run <link#> (Manoj's exact steps). Do it from the Pi's keyboard or over ethernet, since this drops its wifi.

Once it's discoverable, connect from your phone and watch sudo dmesg -w. If brcmf_p2p_send_action_frame: Failed / P2P-GO-NEG-FAILURE shows up, that's the same wall and I'd call it there.

On sinks. almost always a smart TV with built-in Miracast, or a cheap HDMI Miracast dongle, not old computers. For your case a dongle into the old TV is the clean version of what you wanted the Pi to do, it's purpose-built so the Wi-Fi Direct just works.
FluxCast is untested against dongles (except Microsoft wireless adapter), but they're standard sinks so it should behave like a TV.

[AllergicMushroom]

I had already stopped those services, and I still can't get to that error you mention or the other thread mentions. I have no idea what to do at this point.

I tried using the famous LLM to debug this, and at this point it ruled out everything other than brcmfmac being crap.

I also tried setting the sink in my main computer, but it obviously can't see itself since I've stopped NetworkManager and wpa_supplicant.

Also, I just learned that my phone, a google pixel, does not support miracast, so this is on hold until I get my hands on another computer.

[IlyaP358]

yeah, I think you and the LLM landed on the right answer.

and good catch on the Pixel, Google dropped Miracast from Pixels years ago, so it was never going to work as a test device. (a machine can't really cast to its own sink either, so that one wouldn't tell you much.)

parking it until you get another machine to test with is fair. thanks for digging into this so thoroughly, it also confirms the Pi 5 wall for the next person who asks.
If you ever need help again, don't hesitate to reach out🙂