Issue with raspberry pi 4 and Microsoft surface pro

[crims0nHD]

I installed and set up the raspberry pi accordingly and this is what happenes:

1) surface pro connects to pi successfully 2) i see the mirrored screen on the pi 3) after 3 to 10 seconds the connection shuts down

I'm thankful to anyone trying to look into my problem.

Log:

pi@raspberrypi:~/lazycast $ ./all.sh Selected interface 'p2p-wlan0-1' Available interfaces: p2p-wlan0-1 p2p-dev-wlan0 wlan0 already on p2p-wlan0-1 The display is ready Your device is called: lazycast_on_raspberrypi PIN: 31415926 ---M1---> OPTIONS * RTSP/1.0 Require: org.wfa.wfd1.0 CSeq: 1

<-------- RTSP/1.0 200 OK CSeq: 1 \Public: org.wfa.wfd1.0, SET_PARAMETER, GET_PARAMETER

<---M2--- OPTIONS * RTSP/1.0 CSeq: 100 Require: org.wfa.wfd1.0

--------> RTSP/1.0 200 OK Server: MSMiracastSource/10.00.18362.0693 guid/86A74632-FA38-0006-6A80-598738FAD501 Public: org.wfa.wfd1.0, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER CSeq: 100

---M3---> GET_PARAMETER rtsp://localhost/wfd1.0 RTSP/1.0 Content-Length: 673 Content-Type: text/parameters CSeq: 2

wfd_video_formats wfd_audio_codecs wfd_client_rtp_ports wfd_display_edid wfd_connector_type wfd_uibc_capability wfd2_rotation_capability wfd2_video_formats wfd2_audio_codecs wfd2_video_stream_control wfd_content_protection wfd_idr_request_capability intel_friendly_name intel_sink_manufacturer_name intel_sink_model_name intel_sink_version intel_sink_device_URL microsoft_latency_management_capability microsoft_format_change_capability microsoft_diagnostics_capability microsoft_cursor microsoft_rtcp_capability microsoft_video_formats microsoft_max_bitrate microsoft_multiscreen_projection microsoft_audio_mute microsoft_color_space_conversion

<-------- RTSP/1.0 200 OK CSeq: 2 Content-Type: text/parameters Content-Length: 485

wfd_client_rtp_ports: RTP/AVP/UDP;unicast 1028 0 mode=play wfd_audio_codecs: LPCM 00000002 00 wfd_video_formats: 00 00 02 10 0001FEFF 3FFFFFFF 00000FFF 00 0000 0000 00 none none wfd_3d_video_formats: none wfd_coupled_sink: none wfd_display_edid: none wfd_connector_type: 05 wfd_uibc_capability: input_category_list=GENERIC, HIDC;generic_cap_list=Keyboard, Mouse;hidc_cap_list=Keyboard/USB, Mouse/USB;port=none wfd_standby_resume_capability: none wfd_content_protection: none

---M4---> SET_PARAMETER rtsp://localhost/wfd1.0 RTSP/1.0 Content-Length: 367 Content-Type: text/parameters CSeq: 3

wfd_video_formats: 00 00 02 10 00000000 00000008 00000000 00 0000 0000 00 none none wfd_audio_codecs: LPCM 00000002 00 wfd_presentation_URL: rtsp://192.168.173.80/wfd1.0/streamid=0 none wfd_client_rtp_ports: RTP/AVP/UDP;unicast 1028 0 mode=play wfd_uibc_capability: input_category_list=HIDC;generic_cap_list=none;hidc_cap_list=Keyboard/USB, Mouse/USB;port=50000

<-------- RTSP/1.0 200 OK CSeq: 3

uibcport:50000

---M5---> SET_PARAMETER rtsp://localhost/wfd1.0 RTSP/1.0 Content-Length: 27 Content-Type: text/parameters CSeq: 4

wfd_trigger_method: SETUP

<-------- RTSP/1.0 200 OK CSeq: 4

<---M6--- SETUP rtsp://192.168.101.80/wfd1.0/streamid=0 RTSP/1.0 CSeq: 101 Transport: RTP/AVP/UDP;unicast;client_port=1028

--------> RTSP/1.0 200 OK Transport: RTP/AVP/UDP;unicast;client_port=1028;server_port=62908;ssrc=77b8eb05;rtcp-fb-ssrc=77b8eb06 Server: MSMiracastSource/10.00.18362.0693 guid/86A74632-FA38-0006-6A80-598738FAD501 Blocksize: 1450 Session: 1023620112 CSeq: 101

['RTSP/1.0 200 OK\r\nTransport: RTP/AVP/UDP', 'unicast', 'client_port=1028', 'server_port=62908', 'ssrc=77b8eb05', 'rtcp-fb-ssrc=77b8eb06\r\nServer: MSMiracastSource/10.00.18362.0693 guid/86A74632-FA38-0006-6A80-598738FAD501\r\nBlocksize: 1450\r\nSession: 1023620112\r\nCSeq: 101\r\n\r\n'] ['server_port=62908'] 62908 <---M7--- PLAY rtsp://192.168.101.80/wfd1.0/streamid=0 RTSP/1.0 CSeq: 102 Session: 1023620112

--------> RTSP/1.0 200 OK Server: MSMiracastSource/10.00.18362.0693 guid/86A74632-FA38-0006-6A80-598738FAD501 Date: Wed, 25 Mar 2020 12:40:58 GMT Session: 1023620112 CSeq: 102

---- Negotiation successful ---- idrport:47921 audiodest:0 set audio backend :hdmi oldcc 0 cc 3 recv timeout

[crims0nHD]

UPDATE: It works perfectly (with a 2 second delay) with a samsung m30 phone

[homeworkc]

Seems like a connection stability issue. recv timeout means Pi hasn't received packets for 10 seconds. You could try installing NetworkManager (follow the instructions here, except only purge dhcpcd5: sudo apt purge dhcpcd5). I found on some systems NetworkManager makes the connection more stable. However, this may break the DNS of the network configuration so first try on a different SD card or backup your data.

[crims0nHD]

sadly i have to wait for amazon to ship the new sd card I ordered before I can try it... :(

But anyway thanks in advance

[cgmastertecnology]

Seems like a connection stability issue. recv timeout means Pi hasn't received packets for 10 seconds. You could try installing NetworkManager (follow the instructions here, except only purge dhcpcd5: sudo apt purge dhcpcd5). I found on some systems NetworkManager makes the connection more stable. However, this may break the DNS of the network configuration so first try on a different SD card or backup your data.

i have the same problem i tried to do sudo apt install dhcpcd5 after i did purge and i lose network (wifi doesn't work) i did again purge and i had back connection and now seems problem solved i have the rasp pointer on screen, is there solution to hide it?

more: i want lazycast to start on boot without terminal on screen, so i added your command in the mentioned path with final &: @lxterminal -l --working-directory=/home/pi/lazycast -e ./all.sh & but terminal appears suggestion?

thanks

[homeworkc]

You can try using bash instead of lxterminal. However, getting the relative path right is extremely tricky, especially without the help of error messages. I didn't find any elegant solution when I tried to use bash. An alternative here might be hiding the window of lxterminal.

[crims0nHD]

i have the same problem i tried to do sudo apt install dhcpcd5 after i did purge and i lose network (wifi doesn't work) i did again purge and i had back connection and now seems problem solved

This did the job! Thank you very much!

[cgmastertecnology]

I don't know why last days mirror quality became very bad moreover, sometimes my rasp disconnects from my 5ghz network (maybe the network manager needed for lazycast? ) suggestions?

[homeworkc]

Using NetworkManager is highly recommended. Are you using the latest commit? I recently added a feature to manage the frequency of the p2p interface. You can also try turning it off by modifying this line: https://github.com/homeworkc/lazycast/blob/c7015eed5a6cb08e41a21050a3fc6d4511ed3d59/all.sh#L12 to managefrequency=0.

[cgmastertecnology]

i had random disconnection

suggestion?

[marcinkukielka]

Did anyone solve this out? I have the same issue (RPI4 - Hololens), after 5 seconds display freeze with recv timeout message as above. I tried this:

i have the same problem
i tried to do sudo apt install dhcpcd5 after i did purge and i lose network (wifi doesn't work)
i did again purge and i had back connection and now seems problem solved

But it did not solve this issue. Also change managefrequency to 0 but it also did not work. Same story, few seconds, display freeze and timeout message appear. I tested 2 separate SD cards, difference between them is seconds between display freeze after connection (2 seconds on Lexar, 5-6 seconds on SanDisc, both 32 GB). Also Windows 10 laptop cast to RPI without any problem, change socket settings in d2.py too (nothing works). I assume that Hololens have something to do with it but do not know how to fix it. Any ideas?

[homeworkc]

'recv timeout' means the majority of the wifi packets is lost. Multiple factors can result in this issue. One is frequency management. Since both Pi and the PC will use wifi direct, this means that each could potentially work on 2 different wifi channels. (PC-wlan, PC-wifi-direct, Pi-wlan, Pi-wifi-direct) In my experience, if a device work on two wifi channels simultaneously, it usually leads to very unstable connection. One way to debug this is to let PC and Pi connect to the same AP (so that PC-wlan and Pi-wlan are on the same frequency), check (e.g., using iwconfig on Pi) that the p2p and wlan interfaces are on the same frequency and see if this helps. It is also possible that some hardware or software configuration on the PC side cause unstable connection. I had a issue with a Windows 8 device and I had to reset the device. If this is the case, it might be worthwhile to try MICE (./mice.py) instead of wifi direct, especially if you are using Ethernet or an AP with low latency. Microsoft developed this protocol to specifically overcome the wifi direct issues on some wifi hardware (by not using wifi direct at all).

[eduardobbs]

Hi, I use Windows 10 and Raspberry Pi 4, I tried using wifi and then ethernet for both devices. In both situations, I experience the same problems aforementioned: 3 to 8 seconds working properly and then suddenly disconnects with the recv timeout msg. I also tried MICE, but in this case, it never connects, not even for a few secs. I followed all the instructions: wpa downgrade; installed network manager; purged dhcpcd5; removep2p after each try; I tried quite a few times. Congrats anyway for this great initiative, I hope someday I can use it, I will be watching new releases. My workaround at the moment is to use Roku as the receiver, but RPI4 would be much better for me.

Thank you

[aokolovskis]

First of all - Thank You! Awesome project.

I could also establish a connection by the phone, with a high delay but it worked stable.

I need also to line up regarding connection issues with surface pro 7 running Win10.

I followed the instructions, and was also facing the wpasupplicant issue, running Raspbian 10 on Raspberry 4, down grading to 2.4 solved it.

I used the small debian image. After installing some python dependencies mice.py was running too, it was possible to connect from surface pro 7 Win10 but the connection lasted also just couple of seconds 5-8, but it reconnected and again with 5-8 seconds screen time.

The awesome part ist, before it colapses it has really low latency. Awesome!

Could you provide some insights where so search for connection disruption?

The output I get is same as above '''recv timeout''' and the connection is gone, but it is strange, I can see the cursor moving and suddenly it colapses.

Are there some more logs where to look into?