[HOWTO] Shield streaming remotely without a VPN

Search This thread

cgutman

Senior Member
Aug 14, 2010
485
430
Over the past couple of weeks since I got a GTX 760 for my main rig, I've been playing with getting Shield streaming to work through a NAT. With a combination of an Android app and Windows app, I've been able to get the Shield to stream through a NAT device.

This is alpha software, so it may not work for you. I'll be continuing development on it to make it more robust based on bug reports filed here and on the GitHub projects

This method is potentially more complex than running a VPN, but it is lower overhead and works in environments where VPNs cannot.

For those who don't care about the technical details, skip the next section.

Relay Technical Details

The Shield uses MDNS to discover compatible streaming PCs. It issues a query for _nvstream._tcp.local to which streaming PCs reply with PTR, A, AAAA, and TXT records. MDNS isn't routable outside of the local network (and sometimes blocked within the network too), so naturally PCs outside the Shield's local network won't be available as streaming targets.

To solve the MDNS problem, I wrote MDNS relays for Android and Windows that operate on UDP port 5354. The Android relay sends MDNS queries to the Windows relay where the Windows relay replays them local and sends the reply back to the Shield. The Android relay then takes the reply and parses it to look at the A record. It replaces the IP address specified in the A record with the IP address it received the MDNS reply from so it can properly connect to PCs behind a NAT. With the MDNS relay code in place, the Shield could see the PC and even start games.

There was still a problem getting the video stream back. It turns out that the way that UDP port 47998 is used on the Shield streaming software running on the PC prevents it from traversing NATs when going back to the Shield because it assumes that the source is always 47998. This is IMHO a bug because all other ports deal with NAT traversal properly, but needless to say I still had to deal with this.

The only option I had for fixing the port 47998 issue was to capture the packets as they go onto the wire in the Windows relay. I used WinPcap to capture the UDP packets leaving the machine. I then filter based on whether the packet was addressed to us. If it's a packet from the Shield to us on port 47998, then I save the source port of that packet. When I see a packet going out from us to port 47998, I extract the data from that packet and send it again on my own socket also bound to port 47998 (so the source port is correct) with the destination specified in the packet and the port that we saved from the Shield's last communication. With this code, the Shield can connect to a PC from behind a NAT.

Instructions
1. Download and install the Shield Proxy APK on the Shield from https://github.com/cgutman/ShieldProxyAndroid/releases
2. Install WinPcap on your streaming PC from http://www.winpcap.org/install/
2.1 Only required for v0.1-- Install the Visual C++ 2013 runtime library for x86 (use x86 even on x64 systems) from http://www.microsoft.com/en-us/download/details.aspx?id=39315
3. Ensure your router is configured properly as described in the next section.
4. Download and run the Shield Proxy Windows program on your streaming PC from https://github.com/cgutman/ShieldProxyWindows/releases
5. On the Android app, fill in the externally accessible IP address or DNS name for your router. You can get your external IP address from http://www.whatsmyip.org/ on your streaming PC.
6. Tap the start button to start the Android relay service
7. Stream like normal from the TegraZone app

NAT/Router configuration for Shield streaming
The following ports need to be forwarded to the streaming PC:
UDP 47998, 47999, 48000, 5354 (MDNS relay port)
TCP 35043, 47989, 47991, 47995, 47996

Troubleshooting
Make sure ShieldProxy.exe is allowed through Windows Firewall for Private and Public networks.
Make sure ShieldProxy.exe and the Android Shield Proxy service are running
Make sure the external IP address of your streaming PC is correct in the Android app (use http://www.whatsmyip.org/ from your streaming PC)

If TegraZone doesn't show your PC as online and you see "We haven't received any DNS responses. Is the Windows Shield Proxy running on your PC?",
Ensure the router is properly forwarding the specified ports to your PC. Note that TCP vs UDP matters when setting the router forwarding configuration.

Issues
If anyone encounters problems, please report them here or on the GitHub issues page. I'll try my best to get them fixed.
 
Last edited:

Jonbo298

Senior Member
Oct 3, 2009
73
12
After getting all the initial setup done, it's seemingly ran great so far; considering the circumstances. Haven't had any errors besides some DNS thing I didn't get to read fully when it booted up Steam but did not have any impact on playability.
 

daethang

Member
Jul 7, 2008
6
0
DLL error

I keep getting an error that MSVCR120.dll is missing. I checked the windows\system32 folder and it wasn't there, so installed the Visual C++ redistributable package for Visual Studio 2012 and 2013 Preview. This added the DLL to the system32 folder, but still getting the same error after a reboot. Tried copying the DLL to the directory for Shield Proxy and it then gives me an error "The application was unable to start correctly (0xc000007b). Click ok to close the application.

Any ideas?

Thanks and thanks for putting this together!

Cheers!
 

cgutman

Senior Member
Aug 14, 2010
485
430
I keep getting an error that MSVCR120.dll is missing. I checked the windows\system32 folder and it wasn't there, so installed the Visual C++ redistributable package for Visual Studio 2012 and 2013 Preview. This added the DLL to the system32 folder, but still getting the same error after a reboot. Tried copying the DLL to the directory for Shield Proxy and it then gives me an error "The application was unable to start correctly (0xc000007b). Click ok to close the application.

Any ideas?

Thanks and thanks for putting this together!

Cheers!

I can't remember whether the 64-bit Visual C++ redistributable includes both 32-bit and 64-bit runtime dlls. The relay is built as a 32-bit program so it needs the 32-bit runtime even on a 64-bit machine.

For the next version, I'll build it with the runtime linked into the executable so people won't have to hunt down the runtime.
 

daethang

Member
Jul 7, 2008
6
0
I can't remember whether the 64-bit Visual C++ redistributable includes both 32-bit and 64-bit runtime dlls. The relay is built as a 32-bit program so it needs the 32-bit runtime even on a 64-bit machine.

For the next version, I'll build it with the runtime linked into the executable so people won't have to hunt down the runtime.

Thanks - installed the 2013 32bit preview and it worked like a charm after. Will start testing the remote streaming now. Thanks for the quick pointer. Appreciate it!

Cheers
 

david419kr

Member
Jul 13, 2010
7
0
Oh, nice.

Since VPN method didn't work on my rig, I tried this one... and works great!

thanks a lot.
 

daethang

Member
Jul 7, 2008
6
0
Seems to be working here as well, although similar to VPN, streaming outside of my WIFI connection doesn't seem to work. The game will start and every once in a while I will see video start (more often though just a blank screen followed by a timeout). My home connection has 55 down and ~12 up, so I think the connection on that end is good. I have tried from multiple remote locations, but none of them have worked so far. Will do some speed tests on the remote connections to see if they are the cause. Splashtop seems to stream fine when on remote connection, so I dont think its a connection issue. One thing that works better on this solution is the PC actually shows as available, for some reason it does not when on VPN.
 

cgutman

Senior Member
Aug 14, 2010
485
430
Seems to be working here as well, although similar to VPN, streaming outside of my WIFI connection doesn't seem to work. The game will start and every once in a while I will see video start (more often though just a blank screen followed by a timeout). My home connection has 55 down and ~12 up, so I think the connection on that end is good. I have tried from multiple remote locations, but none of them have worked so far. Will do some speed tests on the remote connections to see if they are the cause. Splashtop seems to stream fine when on remote connection, so I dont think its a connection issue. One thing that works better on this solution is the PC actually shows as available, for some reason it does not when on VPN.

From what it sounds like, the MDNS relay is working fine and the router is definitely configured correctly because you get video sometimes. I assume you also see the message in the ShieldProxy.exe console: "Shield is now communicating with us on port XXXXX".

If I had to speculate, I'd say it's related to high packet loss. Shield streaming (both on the network and through my proxy) use UDP for the video stream and a PPTP VPN uses GRE packets which are both lossy protocols, while Splashtop uses TCP which retransmits lost packets. It may be that the ISP is doing some QoS stuff that's causing non-TCP packets to be dropped at a higher rate, but this is complete speculation.

The Shield pings the streaming PC and the streaming PC sends back video data, but if the pings aren't reaching the streaming PC or the video isn't reaching the Shield, you get the dreaded "Streaming failed due to network interference ... etc" message.

The upside is that we can better troubleshoot the issue based on the output from the Windows Shield proxy. If you could paste that here, I could take a look (remove the last 2 octets of the IP addresses, so 192.168.1.1 becomes 192.168.X.X). Also if you would post what ISP you're using and where you were trying to connect from (whichever ones you feel comfortable mentioning).
 

HobsonA

Senior Member
Dec 26, 2011
91
4
Albany
I can't seem to get any of those ports open except 47989, even when I change my setup to be directly connected to my SB6141 modem. Port 5354 always appears closed and can't be accessed so I never can see my computer when I try connecting with the shield proxy app posted above.

Anyway to change the port to something other than 5354 or any idea why the port always appears closed even when connected from computer to modem?

Thanks

Edit: It seems only ports that are being listened to on netstat -an will appear as open to a port checker. Shouldn't there be something on that list listening for 5354 in order for Shield proxy to connect to that port?
 
Last edited:

cgutman

Senior Member
Aug 14, 2010
485
430
I can't seem to get any of those ports open except 47989, even when I change my setup to be directly connected to my SB6141 modem. Port 5354 always appears closed and can't be accessed so I never can see my computer when I try connecting with the shield proxy app posted above.

Anyway to change the port to something other than 5354 or any idea why the port always appears closed even when connected from computer to modem?

Thanks

Ports will appear closed even if the router is properly forwarding them to your PC, but the PC is blocking them. Check your Windows Firewall settings and make sure ShieldProxy.exe is allowed through for both public and private networks. I also found out the hard way that it won't always prompt you to allow for public networks if it's already allowed for private and vice versa.

I think it's normal for those other Shield Streaming ports to be closed until streaming actually starts, but 5354 should appear open while ShieldProxy.exe is running.

It is possible for me to (and I plan to) add some code to make the MDNS relay port configurable but I don't think that would solve your issue here.

EDIT: Also make sure you're testing 5354 (and other UDP ports) as UDP, not TCP. TCP 5354 is not the same as UDP 5354. In fact, you can host different services on the same ports on TCP and UDP at the same time.
 

HobsonA

Senior Member
Dec 26, 2011
91
4
Albany
Ports will appear closed even if the router is properly forwarding them to your PC, but the PC is blocking them. Check your Windows Firewall settings and make sure ShieldProxy.exe is allowed through for both public and private networks. I also found out the hard way that it won't always prompt you to allow for public networks if it's already allowed for private and vice versa.

I think it's normal for those other Shield Streaming ports to be closed until streaming actually starts, but 5354 should appear open while ShieldProxy.exe is running.

It is possible for me to (and I plan to) add some code to make the MDNS relay port configurable but I don't think that would solve your issue here.

EDIT: Also make sure you're testing 5354 (and other UDP ports) as UDP, not TCP. TCP 5354 is not the same as UDP 5354. In fact, you can host different services on the same ports on TCP and UDP at the same time.

Ah good call out of my lack of attention to detail I forgot to run Shieldproxy.exe again after removing my router from the loop and rebooting everything. It appears to be working now. Unfortunately my Linksys E2000 with DD-WRT has been having major issues port forwarding but at least I know it's my router now and I can keep playing with it to get it working like I had to do with VPN.

Thanks!
 

cgutman

Senior Member
Aug 14, 2010
485
430
v0.2 released

I've posted updated releases for Android and Windows on the GitHub projects. None of the changes in either version break compatibility with v0.1 so you can update them at separate times.

Android v0.2 Changelog:
- Fix several bugs preventing the "MDNS relay not running" warning from showing up consistently
- Tighten the check that determines whether the MDNS query will be forwarded

Windows v0.2 Changelog:
- Statically link to the VC++ runtime so installing the runtime isn't required anymore
- Tighten the check that determines whether the MDNS query will be forwarded
 

daethang

Member
Jul 7, 2008
6
0
From what it sounds like, the MDNS relay is working fine and the router is definitely configured correctly because you get video sometimes. I assume you also see the message in the ShieldProxy.exe console: "Shield is now communicating with us on port XXXXX".

If I had to speculate, I'd say it's related to high packet loss. Shield streaming (both on the network and through my proxy) use UDP for the video stream and a PPTP VPN uses GRE packets which are both lossy protocols, while Splashtop uses TCP which retransmits lost packets. It may be that the ISP is doing some QoS stuff that's causing non-TCP packets to be dropped at a higher rate, but this is complete speculation.

The Shield pings the streaming PC and the streaming PC sends back video data, but if the pings aren't reaching the streaming PC or the video isn't reaching the Shield, you get the dreaded "Streaming failed due to network interference ... etc" message.

The upside is that we can better troubleshoot the issue based on the output from the Windows Shield proxy. If you could paste that here, I could take a look (remove the last 2 octets of the IP addresses, so 192.168.1.1 becomes 192.168.X.X). Also if you would post what ISP you're using and where you were trying to connect from (whichever ones you feel comfortable mentioning).

I think you are right in regards to packet loss. I have Comcast at home, and have tried various providers (ATT LTE, ATT WIFI so far with this solution and VPN over some other WIFI networks). I will be testing it again in the next couple of days and will report back with the additional details requested. I have the ASUS NT-R66U router as well. Thanks for the reply and offer of assistance, really appreciated.

Cheers!
 

HobsonA

Senior Member
Dec 26, 2011
91
4
Albany
Finally had some time to play with this more than some quick tests. This seems to run so much smoother than my old VPN configuration.

I don't know if anyone else has experienced with this but even though it's running like almost perfectly smooth sometimes the connection just completely drops. VPN would have big lag spikes but would rarely drop me.

Edit: Hm not sure if this is normal but there seems to be a larger audio latency (> 200-300 ms) which wasn't as bad with VPN. If I go to a friends house instead of playing around at work I'll try hard wiring my shield to ethernet to see if that improves anything.
 
Last edited:

cgutman

Senior Member
Aug 14, 2010
485
430
Finally had some time to play with this more than some quick tests. This seems to run so much smoother than my old VPN configuration.

I don't know if anyone else has experienced with this but even though it's running like almost perfectly smooth sometimes the connection just completely drops. VPN would have big lag spikes but would rarely drop me.

Edit: Hm not sure if this is normal but there seems to be a larger audio latency (> 200-300 ms) which wasn't as bad with VPN. If I go to a friends house instead of playing around at work I'll try hard wiring my shield to ethernet to see if that improves anything.

Glad to hear that it's smoother than VPN for you.

The Shield Relay is just the same Shield streaming traffic just sent over the Internet rather than your home network. This comes with benefits (speed) and drawbacks (lower reliability). Both of the oddities that you mention are probably related to packet loss, latency spikes, and routing changes that are more prevalent on the Internet than the average home network.

I suspect that the reason the stream drops during big lag spikes is because the lag spikes are due to packet loss or high latency. If the Shield's pings to the streaming PC get lost or arrive very late, the PC will timeout the stream, stop sending video, and the stream will drop.

The audio latency is probably due to variances in the latency and routing of the Internet. It's possible that the video packets and the audio packets take different paths through the Internet, so they can reach the Shield at different times. Normally the latency is close on a home network because there's only one route from your computer to your Shield, but the Internet can have tens or hundreds of routes to get your packets from point A to point B (sometimes even the route from A -> B is different than B -> A).

Nvidia could timestamp the audio and video packets so they can be played back at the same time, but that would force the Shield to delay displaying the video while it waits for the audio packets to come (and vice versa). Since this is a gaming feature, they probably don't want to introduce more latency.
 

-yz-

Senior Member
Aug 15, 2013
73
3
ok how to know if everything if ok ?

ok how to know if everything if ok ? ?


i done everything like it write over here and i don't get any error just "stop" after i click run in the shield.

so everything working right?
 

cgutman

Senior Member
Aug 14, 2010
485
430
ok how to know if everything if ok ? ?


i done everything like it write over here and i don't get any error just "stop" after i click run in the shield.

so everything working right?

Do you see both lines like "Shield is now communicating with us on port XXXXX" and "Relaying MDNS traffic to XXX.XXX.XXX.XXX" on the Shield Proxy running on Windows?
 

-yz-

Senior Member
Aug 15, 2013
73
3
Do you see both lines like "Shield is now communicating with us on port XXXXX" and "Relaying MDNS traffic to XXX.XXX.XXX.XXX" on the Shield Proxy running on Windows?

dmm...no i don't see it ...this is what i get when i run the

ShieldProxy.exe


all i get is "shield streaming proxy for windows v0.2"

joined MDNS multicast group with interface 192.168.1.13 (my pc)
listening on Microsoft for shield traffic

relay is up and running..."


what i am doing wrong .. i open all the ports i have RT-AC66U so..
 

cgutman

Senior Member
Aug 14, 2010
485
430
dmm...no i don't see it ...this is what i get when i run the

ShieldProxy.exe


all i get is "shield streaming proxy for windows v0.2"

joined MDNS multicast group with interface 192.168.1.13 (my pc)
listening on Microsoft for shield traffic

relay is up and running..."


what i am doing wrong .. i open all the ports i have RT-AC66U so..

Does your PC show up as available in the TegraZone app with Shield Relay running on Windows and Android? The start button on the Android relay doesn't do anything other than just start the relay service in the background. You still need to use the TegraZone app to access streaming. If you see an error message saying "We haven't received any DNS responses. Is the Windows Shield Proxy running on your PC?" then check that ShieldProxy.exe is allowed through Windows Firewall on public and private networks.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    Over the past couple of weeks since I got a GTX 760 for my main rig, I've been playing with getting Shield streaming to work through a NAT. With a combination of an Android app and Windows app, I've been able to get the Shield to stream through a NAT device.

    This is alpha software, so it may not work for you. I'll be continuing development on it to make it more robust based on bug reports filed here and on the GitHub projects

    This method is potentially more complex than running a VPN, but it is lower overhead and works in environments where VPNs cannot.

    For those who don't care about the technical details, skip the next section.

    Relay Technical Details

    The Shield uses MDNS to discover compatible streaming PCs. It issues a query for _nvstream._tcp.local to which streaming PCs reply with PTR, A, AAAA, and TXT records. MDNS isn't routable outside of the local network (and sometimes blocked within the network too), so naturally PCs outside the Shield's local network won't be available as streaming targets.

    To solve the MDNS problem, I wrote MDNS relays for Android and Windows that operate on UDP port 5354. The Android relay sends MDNS queries to the Windows relay where the Windows relay replays them local and sends the reply back to the Shield. The Android relay then takes the reply and parses it to look at the A record. It replaces the IP address specified in the A record with the IP address it received the MDNS reply from so it can properly connect to PCs behind a NAT. With the MDNS relay code in place, the Shield could see the PC and even start games.

    There was still a problem getting the video stream back. It turns out that the way that UDP port 47998 is used on the Shield streaming software running on the PC prevents it from traversing NATs when going back to the Shield because it assumes that the source is always 47998. This is IMHO a bug because all other ports deal with NAT traversal properly, but needless to say I still had to deal with this.

    The only option I had for fixing the port 47998 issue was to capture the packets as they go onto the wire in the Windows relay. I used WinPcap to capture the UDP packets leaving the machine. I then filter based on whether the packet was addressed to us. If it's a packet from the Shield to us on port 47998, then I save the source port of that packet. When I see a packet going out from us to port 47998, I extract the data from that packet and send it again on my own socket also bound to port 47998 (so the source port is correct) with the destination specified in the packet and the port that we saved from the Shield's last communication. With this code, the Shield can connect to a PC from behind a NAT.

    Instructions
    1. Download and install the Shield Proxy APK on the Shield from https://github.com/cgutman/ShieldProxyAndroid/releases
    2. Install WinPcap on your streaming PC from http://www.winpcap.org/install/
    2.1 Only required for v0.1-- Install the Visual C++ 2013 runtime library for x86 (use x86 even on x64 systems) from http://www.microsoft.com/en-us/download/details.aspx?id=39315
    3. Ensure your router is configured properly as described in the next section.
    4. Download and run the Shield Proxy Windows program on your streaming PC from https://github.com/cgutman/ShieldProxyWindows/releases
    5. On the Android app, fill in the externally accessible IP address or DNS name for your router. You can get your external IP address from http://www.whatsmyip.org/ on your streaming PC.
    6. Tap the start button to start the Android relay service
    7. Stream like normal from the TegraZone app

    NAT/Router configuration for Shield streaming
    The following ports need to be forwarded to the streaming PC:
    UDP 47998, 47999, 48000, 5354 (MDNS relay port)
    TCP 35043, 47989, 47991, 47995, 47996

    Troubleshooting
    Make sure ShieldProxy.exe is allowed through Windows Firewall for Private and Public networks.
    Make sure ShieldProxy.exe and the Android Shield Proxy service are running
    Make sure the external IP address of your streaming PC is correct in the Android app (use http://www.whatsmyip.org/ from your streaming PC)

    If TegraZone doesn't show your PC as online and you see "We haven't received any DNS responses. Is the Windows Shield Proxy running on your PC?",
    Ensure the router is properly forwarding the specified ports to your PC. Note that TCP vs UDP matters when setting the router forwarding configuration.

    Issues
    If anyone encounters problems, please report them here or on the GitHub issues page. I'll try my best to get them fixed.