My Xoom usually disconnects the VPN immediately after opening any file from an SMB Share using ES File Explorer. I preferred Astro but the SMB addon doesn't work with Honeycomb yet. A variation of different vpn clients all do the same, as soon as data is done being transferred from a single download, the VPN will disconnect.
Is there a workaround for this? It would be great to only have the VPN connect when resources on the network were accessed or written.
I haven't found a workaround or solution to keep the VPN up and stable.
(btw, this is a typical MS 2008 PPTP on a Windows Domain)
At the moment, I'm having to reconnect after every file transfer- again, the wireless network doesn't seem to make a difference (although the 3g connection is obviously poor)
I've done a little troubleshooting on this in the last few days using the magic of wireshark. MS PPTP Server, makes the connection and then drops after SMB traffic is attempted, as well any website will not load, and no email / communication will work.
I believe this fully involves a Default Gateway setting on the Xoom, being it's a client-side setting and the Xoom doesn't appear allow that option to be changed (silly that it's missing, imo).
When I make a connection, Verizon's firewall policies see a foreign IP return traffic at some point on their network and blocks the transmission completely, eventually causing PPTP to timeout.
Here's a good read on how to get around the restriction:
http://jbenisek.wordpress.com/2010/10/05/android-2-1-and-2-2-vpn-pptp-over-verizon/
I myself have been on the phone this morning regarding this issue, I'm up to about a 3rd level of tech support and he is trying to tell me 'nothing is blocked at all on the Verizon network'...
I'm awaiting a call back now... at which I'll try to show him the above site/resource and maybe he'll move me to an unrestricted IP block. We bought 3 Xooms with the intention of working remotely in the field using PPTP- 4 more coming soon---
At this point, I'm still tempted to go back to Sprint and just wait on their Xoom release.
*btw, you can verify the above by tethering to the Xoom and changing your default gateway on a laptop/pc, the connection will work fine.
edit:
AH-HAH!
And more info;
http://code.google.com/p/android/issues/detail?id=4706
Apparently this is a known issue.
Encrypted PPTP is broken on Android: http://code.google.com/p/android/issues/detail?id=4706
I've posted about this problem in this thread:
http://forum.xda-developers.com/showthread.php?t=992876
I've tried it on every version of Android since 2.1. I tried it with my Xoom on 3.0 and the problem remains. It appears to be a pretty low priority for Google.
sangreal06 said:
Encrypted PPTP is broken on Android: http://code.google.com/p/android/issues/detail?id=4706
Click to expand...
Click to collapse
Turned off encryption on the server and all was well. I can't believe google let that slide... !?
I guess I'll transition to a L2TP VPN...
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.
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.
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!
daethang said:
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!
Click to expand...
Click to collapse
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.
cgutman said:
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.
Click to expand...
Click to collapse
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
daethang said:
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
Click to expand...
Click to collapse
Cool, I updated the instructions to mention that the Visual C++ 2013 x86 runtime is required.
Oh, nice.
Since VPN method didn't work on my rig, I tried this one... and works great!
thanks a lot.
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.
daethang said:
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.
Click to expand...
Click to collapse
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 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?
HobsonA said:
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
Click to expand...
Click to collapse
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.
cgutman said:
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.
Click to expand...
Click to collapse
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!
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
cgutman said:
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).
Click to expand...
Click to collapse
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!
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.
HobsonA said:
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.
Click to expand...
Click to collapse
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.
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?
Yosizach said:
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?
Click to expand...
Click to collapse
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?
cgutman said:
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?
Click to expand...
Click to collapse
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..
Yosizach said:
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..
Click to expand...
Click to collapse
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.
[Q] Does the Nexus Player support "login" WiFi networks (such as those at a hotel(?
One of the biggest disappointments I had with Chromecast was that it was impossible to set the unit up in a hotel. Since many hotels have WiFi that require you to log in, you couldn't set up your Chromecast on these networks.
Is this the case with the Nexus Player?
Not really sure, but I have a trick you can try with your Chromecast. Not sure if it will work, but we used to do it back when I was in college because the University network required a username/password login (which sucked if you wanted your XBOX on the network).
Figure out the MAC address of your Chromecast. Go to your laptop or PC, and spoof the mac address of your NIC (or wifi) to match the chromecast. You can usually do this through the device manager in Windows by going to the Properties for your NIC. After that, use your brower to sign in. Go back to Chromecast and see if it worked.
Usually they tie the authentication to your NIC's MAC address...so the theory is that as long as you authenticate the mac address somehow, then any device with that mac address will work. Things might have changed over the past 6 or 7 years though when we used to do that.
IBNobody said:
One of the biggest disappointments I had with Chromecast was that it was impossible to set the unit up in a hotel. Since many hotels have WiFi that require you to log in, you couldn't set up your Chromecast on these networks.
Is this the case with the Nexus Player?
Click to expand...
Click to collapse
Another option if you are a frequent traveler is a portable travel router like the D-Link DIR-510L. This tiny router easily fits in your briefcase yet can turn any wifi network into your own personal wifi hotspot. Basically it connects to a hotel wifi and through your phone, tablet or pc you can log in with your hotel credentials. It then creates a separate wifi network for your own use, one that you control for all your devices (including your chromecast) without having to pay the hotel more for multiple device connections, etc. It even has a built in battery to either run without power or to charge your devices and, with its 3 usb ports, can share a USB drive full of media with all your wireless devices. I know I sound like a commercial here, but I simply couldn't live without this tiny little beauty on the road.