Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specifying gamestream server by hostname results in no video, audio or input. #352

Closed
cybern0id opened this issue Apr 1, 2016 · 5 comments

Comments

@cybern0id
Copy link
Contributor

NVidia Geforce Experience version: 2.11.2.55, 2.11.2.46 and 2.10.2.40
Moonlight Embedded version: 2.1.4 (built from git master 1 April '16 20:00)
Moonlight Embedded running on: Raspberry Pi 3 - Jessie (up to date as of 1 April '16)

Output of Moonlight Embedded:
pi@raspberrypi:~ $ moonlight stream -mapping ~/xbox360.conf -input /dev/input/event0 gamebox
Moonlight Embedded 2.1.4 (EMBEDDED;CEC;PI)
Connect to gamebox...
NVIDIA GeForce GTX 670, GFE 2.11.2.55 (protocol version 7)
Add input /dev/input/event0 (mapping /home/pi/xbox360.conf)...
Stream 1280 x 720, 60 fps, 10000 kbps
Initializing platform...done
Resolving host name...done
Starting RTSP handshake...done
Initializing control stream...done
Initializing video stream...done
Initializing audio stream...done
Initializing input stream...done
Starting control stream...done
Starting video stream...done
Starting audio stream...done
Starting input stream...done
Control stream received disconnect event
Loss Stats: Transaction failed: 11
Stopping input stream...done
Stopping audio stream...done
Stopping video stream...done
Stopping control stream...done
Cleaning up input stream...done
Cleaning up audio stream...done
Cleaning up video stream...done
Cleaning up control stream...done
Terminating RTSP handshake...done
Cleaning up platform...done

What is the expected result?
Video, audio from game. Input to game.

What happens instead of that?
Control stream works (start and stop streaming) however no video is displayed, no audio is heard, no input is sent to server. Only result is output to stdout.
If hostname switch is omitted, or if IP address is used instead, then streaming works as expected.

@cgutman
Copy link
Member

cgutman commented Apr 2, 2016

I can't reproduce this on my machine. I suspect your host name may be resolving to an IPv6 address which is causing problems. Can you run Wireshark on your PC and get a packet capture?

@cybern0id
Copy link
Contributor Author

Good catch! You hit the nail on the head: I am running IPv6 on my network. Disabling IPv6 kernel parameters on the Raspberry Pi alone, using /etc/sysctl.conf, allows me to stream now when specifying the hostname.

Strange that the control stream uses IPv4 whereas the video, audio and input streams use IPv6 by default in a dual stack network.

If moonlight is not intended to work with IPv6 then this isn't a bug and can be closed.

@irtimmer
Copy link
Collaborator

irtimmer commented Apr 2, 2016

Moonlight Embedded did work on IPv6, but since the new protocol used for the control stream support for IPv6 is dropped. And I have no intention to readd support since it doesn't look like Gamestream is developed for IPv6. (no ipv6 addresses found in the http responses)

@irtimmer irtimmer closed this as completed Apr 2, 2016
@cgutman
Copy link
Member

cgutman commented Apr 2, 2016

It's more nuanced than that. Moonlight-common-c as written in the official upstream repo is fully IPv6-ready because Apple mandates it for iOS. I routinely test it on NAT64 networks to make sure nothing breaks.

The issue is that moonlight-common-c's IPv6 readiness depends on my modified version of ENet which I have included a submodule because ENet is officially only IPv4 and they seem to have no intention of changing that. @irtimmer opted to use the platform's existing libenet which has no IPv6 support.

With that said, I think the actual issue here is that common-c is IPv6-ready. When I'm doing the DNS resolution, I allow IPv6 or IPv4 answers. Normally, this is fine on NAT64 because the packets reaching the host are converted back to IPv4. On a network with end-to-end IPv6, we have a problem because GFE itself doesn't support IPv6. This means that our sockets opened in common-c that expect IPv6 packets break but because libenet doesn't support IPv6, we can actually establish a connection.

@cgutman
Copy link
Member

cgutman commented Apr 2, 2016

This is now fixed upstream in moonlight-common-c.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants