Everything was working beautifully: Windows 10 host with GeForce RTX 3070, GeForce Experience 3.21.0.36, MacOs Big Sur client with Moonlight-qt 3.1.1, both PCs on local 1Gb Ethernet LAN on same subnet. After GFE automatically upgraded to 3.22.0.32, and upgrading MacOS client to 3.1.2, I consistently get "Starting RTSP Handshake failed: Error 50" when trying to start or connect to any session (mostly trying Playnite or mstsc.exe). Tried reinstalling, then downgrading GFE and Moonlight-qt, but problem persists across reinstalls and reboots. Confirmed all firewalls are open and observed traffic with Wireshark, which shows no sign of blocked connections. Tried removing Moonlight prefs plist ~/Library/Preferences/com.moonlight-stream.Moonlight.plist and restarting/reconfiguring from scratch, but no change.

Moonlight log seems to indicate successful conversations, but failure with RTSP options request.

00:00:11 - SDL Info (0): Starting RTSP handshake... 00:00:11 - SDL Info (0): Failed to read RTSP response: 50 00:00:11 - SDL Info (0): RTSP OPTIONS request failed: 50 00:00:11 - SDL Info (0): failed: 50

Moonlight iOS client 7.0.7 on iPadOS 14.5.1 connects to the same host without any issues.

Windows Host: Win10 19042.064 (version 20H2) NVidia drivers 466.27 Antivirus: Sophos Home

MacOS client: MacBook Pro 15" 2018 model Radeon Pro 560X 4GB macOS Big Sur version 11.3.1

Have not seen any other reports of error 50. Moonlight log and error screenshot are attached.

Moonlight-1620239990.log

Am uncertain if some outdated info is being cached by the client which causes miscommunication, but not sure what to clear beyond the prefs plist. Thanks for any help!

Hokay. Since it had become obvious that something was messing around at the kernel level, I finally went ahead and completely uninstalled Sophos Home antivirus, and that seems to have fixed the problem. (I had tried disabling every piece of functionality previously, but that didn't seem to make a difference.) So it looks like Sophos Home needs to go on the list of software that can cause problems with Moonlight. I still have no idea why it suddenly started, since I've had Sophos on the Mac since the day I got it. Will have to check out some alternatives to see if they work better. Cameron, thank you for all your help and patience with this particularly aggravating issue! Moonlight is a great piece of software, and discovering it made me extremely happy! I'm equally happy to have it working properly again.

Hi there, I am also able to duplicate this behavior in Windows. I plugged in 4 controllers and the host recognized them in reverse order.

And, of course, things get even weirder. (I've re-enabled Windows firewall since it didn't seem to be making a big difference.) All errors are Error 50. Only WiFi connected: Starting a game fails. Resuming fails. Wired connected with or without WiFi: Starting a game fails, resuming fails. Wired connected with WiFi: Starting a game fails, disconnect wired interface leaving only WiFi, resuming is successful. Only WiFi connected: Starting a game fails, connect wired interface, resuming still fails.

This is all with the wired interfaces prioritized above WiFi in the Network system prefs panel. No apparent difference if I prioritize WiFi first. Seems like I have to physically disconnect the wired connection for WiFi resume to work -- merely inactivating it in the prefs panel does not get it to work. Only physically unplugging it.

I'm very confused now.

OK, that seems bizarre. I don't have anything installed that should be messing with network functionality at the kernel level, so far as I know. However, I just discovered something else, baffling but enlightening: I've been working with the wired Ethernet interface on my Thunderbolt dock, and have had WiFi disabled (on the basis that wired is more reliable). If I unplug the wired Ethernet and re-enable WiFi (still on the same local subnet as the server), the RTSP connection suddenly starts working. If I connect a USB-C Ethernet interface and try using that instead of the interface on the dock, it still fails. So we seem to be down to "WiFi works, wired Ethernet fails". Any chance there's something in the Moonlight code that sets up the connection differently for different interface types? Or is this some behavior that could have been introduced in Big Sur 11.3 or 11.3.1?

To get away from Nvidia need to make own server application, but since there are no others, the current options are the best solution.

Something fishy is happening with that RTSP socket. You should see the RTSP connect retry logic kick in and it would reattempt the connection 500 ms later for about 10 seconds.

In my case, I purposefully broke Moonlight to avoid starting the connection, and the RTSP retry logic is exactly what I see in my logs and PCAP (from a 2020 MBP on macOS 11.3.1, host has Windows Firewall disabled):

2021-05-11 10:10:19.473 Moonlight[79184:1675657] INFO: Initializing platform...
2021-05-11 10:10:19.474 Moonlight[79184:1675657] INFO: done
2021-05-11 10:10:19.474 Moonlight[79184:1675657] INFO: Resolving host name...
2021-05-11 10:10:19.474 Moonlight[79184:1675657] INFO: done
2021-05-11 10:10:19.474 Moonlight[79184:1675657] INFO: Initializing audio stream...
2021-05-11 10:10:19.474 Moonlight[79184:1675657] INFO: Selected receive buffer size: 65536
2021-05-11 10:10:19.474 Moonlight[79184:1675657] INFO: done
2021-05-11 10:10:19.474 Moonlight[79184:1675657] INFO: Starting RTSP handshake...
2021-05-11 10:10:19.510 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:20.044 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:20.575 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:21.108 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:21.637 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:22.255 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:22.793 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:23.322 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:23.855 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:24.384 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:24.920 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:25.471 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:26.106 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:26.642 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:27.174 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:27.707 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:28.248 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:28.777 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:29.306 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:29.835 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:30.575 Moonlight[79184:1675657] INFO: connect() failed: 61
2021-05-11 10:10:31.080 Moonlight[79184:1675657] INFO: RTSP OPTIONS request failed: 61
2021-05-11 10:10:31.080 Moonlight[79184:1675657] INFO: failed: 61

Instead, in your case, it receives an RST and ceases sending further SYN traffic, yet it never reports that error to Moonlight. So it seems clear that the macOS kernel processed the RST (otherwise you'd see repeated SYN traffic, as in the case of the port being closed on the host but the RST traffic being block by Windows Firewall stealth mode). For some reason that error doesn't make it back to Moonlight to trigger the retry logic though, and instead the poll() for readability times out which does not trigger the retry (since the kernel should have been sending SYNs the entire time).

Somewhere a bit less than official then, but still at least somewhere. I swear, I only got to figure out those two projects existed because I followed up on some random comment in forums and github. Even searching every odd month on google wasn't really helpful.

p.s. I thought GFE updates were still kind of good at the end of the day, in improving and fixing the protocol?

Great. Sounds like it could be used for remote desktopping then, which is something I wanted to try for quite a while.

Actually, they can be captured in windowed mode as well as fullscreen, as it was previously

System keyboard shortcuts (Alt+Tab, Windows key, Ctrl+Shift+Esc, etc.) can now be (optionally) captured in windowed mode

Only in Windowed mode in Xorg?

Good news, this is now possible by means of the keys being able to be passed through to the host. Complete immersion!

I don't think any current servers for Moonlight are in a performance and reliability state where we would like to officially support them as first-class options yet. I'm as eager as anyone to reduce the dependence on Nvidia to not break us with a GFE update ;)

Thanks -- was wondering where those Nvidia logs were. OK, ran the whole sequence again (start Moonlight, click on Remote Desktop to start it, wait for Error 60 to show up) while doing Wireshark captures on both client and server. Those are attached, filtered down to the requested ports, along with the host-side logs from the NvStream directory, and the Moonlight log from the client. They should all match the same session, having checked the timestamps (the matching streamer log should be NvStreamerCurrent.log). error60-failure-client-capture.pcapng.gz error60-failure-server-capture.pcapng.gz nvstreamerlogs.zip Moonlight-1620699877.log

I am a bit concerned that the only 48010 connection seems to be a SYN/RST at about the time that the failure is reported (hard to tell since Moonlight log has relative timestamps.) Please let me know what else I can dig up if needed.

Thanks!

I don't think the server opens the audio port (UDP 48000) until later in the RTSP handshake, so some ICMP Port Unreachable errors are expected there. I suspect the RTSP handshake just stalls before the point where UDP 48000 is opened, so this is a manifestation of the original issue.

The interesting change is that TCP 48010 is now failing with ETIMEDOUT, rather than that strange ENETDOWN error. It's still odd though, because you'd typically only see ETIMEDOUT if a firewall was dropping the SYN packets. Typically if the port wasn't open, you'd get a RST back from the server and fail immediately with ECONNREFUSED. And if the server process was hung, you'd end up with a socket that was "connected" then time out on the recv() but that's not what we see here either.

Please upload a packet capture with with tcp.port == 47989 || tcp.port == 47984 || udp.port == 47998 || udp.port == 47999 || udp.port == 48000

It also probably wouldn't hurt to upload the host-side logs too from C:\ProgramData\NVIDIA Corporation\NvStream

Bumps lodash from 4.17.19 to 4.17.21. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/lodash/lodash/commit/f299b52f39486275a9e6483b60a410e06520c538"><code>f299b52</code></a> Bump to v4.17.21</li> <li><a href="https://github.com/lodash/lodash/commit/c4847ebe7d14540bb28a8b932a9ce1b9ecbfee1a"><code>c4847eb</code></a> Improve performance of <code>toNumber</code>, <code>trim</code> and <code>trimEnd</code> on large input strings</li> <li><a href="https://github.com/lodash/lodash/commit/3469357cff396a26c363f8c1b5a91dde28ba4b1c"><code>3469357</code></a> Prevent command injection through <code>_.template</code>'s <code>variable</code> option</li> <li><a href="https://github.com/lodash/lodash/commit/ded9bc66583ed0b4e3b7dc906206d40757b4a90a"><code>ded9bc6</code></a> Bump to v4.17.20.</li> <li><a href="https://github.com/lodash/lodash/commit/63150ef7645ac07961b63a86490f419f356429aa"><code>63150ef</code></a> Documentation fixes.</li> <li><a href="https://github.com/lodash/lodash/commit/00f0f62a979d2f5fa0287c06eae70cf9a62d8794"><code>00f0f62</code></a> test.js: Remove trailing comma.</li> <li><a href="https://github.com/lodash/lodash/commit/846e434c7a5b5692c55ebf5715ed677b70a32389"><code>846e434</code></a> Temporarily use a custom fork of <code>lodash-cli</code>.</li> <li><a href="https://github.com/lodash/lodash/commit/5d046f39cbd27f573914768e3b36eeefcc4f1229"><code>5d046f3</code></a> Re-enable Travis tests on <code>4.17</code> branch.</li> <li><a href="https://github.com/lodash/lodash/commit/aa816b36d402a1ad9385142ce7188f17dae514fd"><code>aa816b3</code></a> Remove <code>/npm-package</code>.</li> <li>See full diff in <a href="https://github.com/lodash/lodash/compare/4.17.19...4.17.21">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~bnjmnt4n">bnjmnt4n</a>, a new releaser for lodash since your current version.</p> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

OK, made some progress with this. 3.1.3 makes no difference to the problem, but I was able to produce different failure modes by disabling the Windows Defender firewall. I've got a remote desktop entry defined using "mstsc.exe", so I tested with that, and with Windows firewall turned off.

When trying to start the Remote Desktop entry from Moonlight on Mac, there's a lengthy pause during "Starting RTSP handshake...", followed by Error 60. Corresponding log entries: 00:17:27 - SDL Info (0): Starting RTSP handshake... 00:17:37 - SDL Info (0): Connection timed out after 10 seconds (TCP port 48010) 00:17:37 - SDL Info (0): RTSP OPTIONS request failed: 60 00:17:37 - SDL Info (0): failed: 60

After the Remote Desktop "game" is started, trying to connect again results in a much quicker Error 50. Wireshark shows that when I get error 60, the client is repeatedly sending a packet on 48000/udp and receiving an ICMP Port Unreachable packet in return, for about 10 seconds. When I get error 50, the client sends one packet, gets an ICMP Port Unreachable, and immediately fails. The pattern is consistent: Error 60 when starting the "game", Error 50 when resuming. It appears that the nvstreamer process on the server is not creating a listener on 48000/udp when Moonlight on the Mac tries to connect to it.

However, when I try to connect to Remote Desktop from iPad using the iOS client, it immediately succeeds (even if I'm resuming the "game" started by Moonlight on Mac), and I can see using "netstat -aon" on the Windows server that the nvstreamer process is listening on port 48000/udp.

It seems like whenever Moonlight on Mac requests a connection, the server has some issue with the request and fails to open streaming on 48000/udp. However, it has no problem with the same request coming from the Moonlight iOS client.

Here's a capture of port 48000/udp traffic from the Mac client. Packets 1-30 are the initial attempt to connect resulting in Error 60. Packets 31-32 are attempting to reconnect, giving the quick Error 50. Port-48000_No-Windows-FW_Start-and-Resume.pcapng.gz

What else can I capture to help diagnose this? Would love to be able to get Moonlight working again and stop having to rely on Steam Remote Play.

Thanks!

These could be at least featured/advertised somewhere official though.

Ah I missed that comment and read elsewhere there was support on the nVidia side. Thanks for the reply.

I would really love to see this implemented. I use the AppleTV moonlight client thus cannot use the suggested workaround. Native support would be fantastic!

As would I. Unfortunately, my above comment still applies. There is no way to do this from NVIDIA GameStream as it is today. Not even the official NVIDIA Shield clients have mic support for GameStream.

Thanks @cgutman. I updated the apt version of moonlight yesterday. Had to install two packages (libcec4 and another), but otherwise it seems to work well. Haven't tried to actually use it yet, I'll find time for that later.

I would really love to see this implemented. I use the AppleTV moonlight client thus cannot use the suggested workaround. Native support would be fantastic!

Bumps hosted-git-info from 2.8.4 to 2.8.9. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/npm/hosted-git-info/blob/v2.8.9/CHANGELOG.md">hosted-git-info's changelog</a>.</em></p> <blockquote> <h2><a href="https://github.com/npm/hosted-git-info/compare/v2.8.8...v2.8.9">2.8.9</a> (2021-04-07)</h2> <h3>Bug Fixes</h3> <ul> <li>backport regex fix from <a href="https://github-redirect.dependabot.com/npm/hosted-git-info/issues/76">#76</a> (<a href="https://github.com/npm/hosted-git-info/commit/29adfe5">29adfe5</a>), closes <a href="https://github-redirect.dependabot.com/npm/hosted-git-info/issues/84">#84</a></li> </ul> <p><!-- raw HTML omitted --><!-- raw HTML omitted --></p> <h2><a href="https://github.com/npm/hosted-git-info/compare/v2.8.7...v2.8.8">2.8.8</a> (2020-02-29)</h2> <h3>Bug Fixes</h3> <ul> <li><a href="https://github-redirect.dependabot.com/npm/hosted-git-info/issues/61">#61</a> & <a href="https://github-redirect.dependabot.com/npm/hosted-git-info/issues/65">#65</a> addressing issues w/ url.URL implmentation which regressed node 6 support (<a href="https://github.com/npm/hosted-git-info/commit/5038b18">5038b18</a>), closes <a href="https://github-redirect.dependabot.com/npm/hosted-git-info/issues/66">#66</a></li> </ul> <p><!-- raw HTML omitted --><!-- raw HTML omitted --></p> <h2><a href="https://github.com/npm/hosted-git-info/compare/v2.8.6...v2.8.7">2.8.7</a> (2020-02-26)</h2> <h3>Bug Fixes</h3> <ul> <li>Do not attempt to use url.URL when unavailable (<a href="https://github.com/npm/hosted-git-info/commit/2d0bb66">2d0bb66</a>), closes <a href="https://github-redirect.dependabot.com/npm/hosted-git-info/issues/61">#61</a> <a href="https://github-redirect.dependabot.com/npm/hosted-git-info/issues/62">#62</a></li> <li>Do not pass scp-style URLs to the WhatWG url.URL (<a href="https://github.com/npm/hosted-git-info/commit/f2cdfcf">f2cdfcf</a>), closes <a href="https://github-redirect.dependabot.com/npm/hosted-git-info/issues/60">#60</a></li> </ul> <p><!-- raw HTML omitted --><!-- raw HTML omitted --></p> <h2><a href="https://github.com/npm/hosted-git-info/compare/v2.8.5...v2.8.6">2.8.6</a> (2020-02-25)</h2> <p><!-- raw HTML omitted --><!-- raw HTML omitted --></p> <h2><a href="https://github.com/npm/hosted-git-info/compare/v2.8.4...v2.8.5">2.8.5</a> (2019-10-07)</h2> <h3>Bug Fixes</h3> <ul> <li>updated pathmatch for gitlab (<a href="https://github.com/npm/hosted-git-info/commit/e8325b5">e8325b5</a>), closes <a href="https://github-redirect.dependabot.com/npm/hosted-git-info/issues/51">#51</a></li> <li>updated pathmatch for gitlab (<a href="https://github.com/npm/hosted-git-info/commit/ffe056f">ffe056f</a>)</li> </ul> <p><!-- raw HTML omitted --><!-- raw HTML omitted --></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/npm/hosted-git-info/commit/8d4b3697d79bcd89cdb36d1db165e3696c783a01"><code>8d4b369</code></a> chore(release): 2.8.9</li> <li><a href="https://github.com/npm/hosted-git-info/commit/29adfe5ef789784c861b2cdeb15051ec2ba651a7"><code>29adfe5</code></a> fix: backport regex fix from <a href="https://github-redirect.dependabot.com/npm/hosted-git-info/issues/76">#76</a></li> <li><a href="https://github.com/npm/hosted-git-info/commit/afeaefdd86ba9bb5044be3c1554a666d007cf19a"><code>afeaefd</code></a> chore(release): 2.8.8</li> <li><a href="https://github.com/npm/hosted-git-info/commit/5038b1891a61ca3cd7453acbf85d7011fe0086bb"><code>5038b18</code></a> fix: <a href="https://github-redirect.dependabot.com/npm/hosted-git-info/issues/61">#61</a> & <a href="https://github-redirect.dependabot.com/npm/hosted-git-info/issues/65">#65</a> addressing issues w/ url.URL implmentation which regressed nod...</li> <li><a href="https://github.com/npm/hosted-git-info/commit/7440afa859162051c191e55d8ecfaf69a193b026"><code>7440afa</code></a> chore(release): 2.8.7</li> <li><a href="https://github.com/npm/hosted-git-info/commit/2d0bb6615ecb8f9ef1019bc0737aab7f6449641f"><code>2d0bb66</code></a> fix: Do not attempt to use url.URL when unavailable</li> <li><a href="https://github.com/npm/hosted-git-info/commit/f2cdfcf33ad2bd3bd1acdba0326281089f53c5b1"><code>f2cdfcf</code></a> fix: Do not pass scp-style URLs to the WhatWG url.URL</li> <li><a href="https://github.com/npm/hosted-git-info/commit/e1b83df5d9cb1f8bb220352e20565560548d2292"><code>e1b83df</code></a> chore(release): 2.8.6</li> <li><a href="https://github.com/npm/hosted-git-info/commit/ff259a6117c62df488e927820e30bec2f7ee453f"><code>ff259a6</code></a> Ensure passwords in hosted Git URLs are correctly escaped</li> <li><a href="https://github.com/npm/hosted-git-info/commit/624fd6f301dd5a1fd7ad1b333d6f8921a12ff98c"><code>624fd6f</code></a> chore(release): 2.8.5</li> <li>Additional commits viewable in <a href="https://github.com/npm/hosted-git-info/compare/v2.8.4...v2.8.9">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~nlf">nlf</a>, a new releaser for hosted-git-info since your current version.</p> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>