Topic: JRemote No Longer Works Away from Home (Read 12329 times)

another side · « **on:** December 19, 2016, 05:48:42 pm »

A couple of weeks ago. JRemote stopped working for me away from home using cellular service. It works fine at home. This happened I think around the time that the app was updated for IOS 10. I have tried everything including a clean install both on my iPhone and on my mac. How should I go about troubleshooting?

JimH · « **Reply #1 on:** December 19, 2016, 05:52:53 pm »

It's probably a change on your router or with the firewall on your computer. The wiki has a topic called Network Access.

another side · « **Reply #2 on:** December 20, 2016, 11:46:38 pm »

I don't see anything different with the setup with the router (in this case an Airport Extreme).

The error I get says: "Could not connect (Error: ConnectFailure (Network is unreachable))"

yenibahar · « **Reply #3 on:** December 27, 2016, 02:06:35 pm »

I have the same problem. JRemote stopped connecting using iOS 10 on an iPhone(6) when trying to connect from outside of my home network, over my phone's cellular connection (T-Mobile).

I think I diagnosed where the problem is (or rather is not)!

I have spent several hours thinking it was something potentially wrong on my end, with the router's firewall settings etc. But, the good news is that I have been able to determine that the problem is either with the latest iOS update, the JRemote app or T-Mobile. I would imagine it is likely the JRemote app and the iOS interaction.

Interestingly, I came across a weird workaround that solved the problem... My wife also has an iPhone 6 on the latest iOS version with the same JRemote app installed. She cannot connect home via cellular network neither. However, I turned on her phone's HotSpot function, connected my phone to her HotSpot through WiFi. She had no wifi connection to internet. Just cellular network access to internet. And, magically, through this "bridged" setup over HotSpot and the cellular network, my phone's JRemote magically connected to my home Media Center 22 Server without a glitch!!! This is really weird. So, the issue is not with my home setup. At least I know this issue is not something I can do anything about, other than hoping that JRiver/Apple will have it solved soon. A real bummer!

glynor · « **Reply #4 on:** December 30, 2016, 11:53:21 pm »

Just for the record, music streaming using JRemote (current version) is working here for me on iOS 10.2, even when outside of my LAN/Wifi Network. I used it all weekend on a recent trip.

I did have a few minor issues with music stalling out places where signal wasn't ideal, which is frustrating, but otherwise it worked well.

I'd strongly suggest that something is blocking it on your network. Port forwarding can be very unreliable on some cruddy consumer routers (they crash a lot).

And the Netgear router I've been using while I'm moving and my real network also has a thing where it opens the ports up (and closes them again) based on activity, and I've never been able to get it to work right with MC (or with a variety of other applications). It works for a while, and then the ports get closed and I'd have to "jiggle the handle" to get them to open again. Once you enable regular port forwarding via its byzantine UI, this Netgear router handles MCWS just fine.

jsolo53 · « **Reply #5 on:** January 01, 2017, 02:57:48 pm »

I too am having this problem with T-Mobile and an iPhone. I have learned from T-Mobile support that the problem is that while T-Mobile has switched from ipv4 to ipv6, JRemote does not yet support ipv6, and T-Mobile has stopped supporting ipv4. This switch/migration/upgrade to ipv6 is industry wide but not all the cell providers are dropping ipv4 support the way T-Mobile did. JRemote on my iPhone with Verizon still works fine - Verizon is supporting ipv4 and ipv6.

This is a JRiver shortcoming. Hopefully they will address (ha ha) the problem soon.

One thing you might check on your router is to be sure it is set to support ipv6. Mine wasn't.

JimH · « **Reply #6 on:** January 02, 2017, 02:03:46 am »

I think T-Mobile will have a revolt on their hands. We'll see.

AndrewFG · « **Reply #7 on:** January 02, 2017, 03:54:12 am »

I'm sure you're right Jim about T-Mobile facing a revolt.

But OTOH I am actually quite surprised to hear that MC doesn't support IPv6 "out of the box". As I understand it, the transactions between JRemote and MC are MCWS web services done via Http (?). And I assume you did not knit your own TCP stack, but rather use some standard library (open source) code, which presumably has built in DNS resolution services (be it to IPv4 or IPv6) etc. So perhaps it is as simple as turning on a compiler switch??

JimH · « **Reply #8 on:** January 02, 2017, 03:56:56 am »

You may be right. If T-mobile doesn't back track, we'll look into it.

glynor · « **Reply #9 on:** January 03, 2017, 01:30:11 pm »

MC is far from the only small consumer-style server like this to not support IPv6...This would be, IMHO, a reason not to use TMobile. Supporting IPv6 with a IPv4 fallback is one thing. Forcing users to IPv6 only is another thing entirely.

Large swaths of the Internet are not IPv6 enabled. There are plenty of ISPs that don't even offer IPv6 connectivity yet (Time Warner Cable only finished their nationwide rollout in early 2016), and being able to actually use it means you need all updated computer OSes, modems, routers, and software. And that's just one ISP. There are plenty of other smaller ISPs out there that still don't offer IPv6 addresses (or which charge extra).

So... This would be a bigger issue than just MC being updated. That said, I agree that it should be updated, but... Wow. TMobile is being extremely aggressive here. Probably due to cost.

another side · « **Reply #10 on:** January 03, 2017, 01:37:11 pm »

I did not mention in my original post that I also have T-Mobile, so this would seem to be the most logical explanation. Thanks!

jsolo53 · « **Reply #11 on:** January 03, 2017, 02:03:04 pm »

Supposedly, the internet is running out of IP addresses, so there is a need to adopt to the new standard, IPv6, which allows for LOTS more addresses. As of last June, Apple has been requiring that all apps submitted for listing/sale on the app store comply with IPv6. Apple made this change, not T-Mobile. But you have to wonder why Apple stopped supporting IPv4 so quickly. ?

IPv6 appears to be the unavoidable future for us all, and that the future is now for iOS users. JRemote really should adopt this standard sooner rather than later. here is a link: https://developer.apple.com/news/?id=05042016a

glynor · « **Reply #12 on:** January 03, 2017, 03:39:15 pm »

Quote from: jsolo53 on January 03, 2017, 02:03:04 pm

But you have to wonder why Apple stopped supporting IPv4 so quickly. ?

They did not stop supporting IPv4. They required all new app submissions to also support IPv6. That's pretty different from requiring IPv6 only, which is the case with TMobile here. The idea is that if you do that for a few years, over time, all the apps in the app store will support it (and eventually the server back-ends, routers, load balancers, management endpoints, and everything else needed to make it actually function will be upgraded over time so that this support can actually be used).

Yes, the IPv4 address space is getting pretty quashed, though there is still quite a bit of address space available (and you can fix the rest with NAT). IPv6 has a huge amount of additional complexity, and is no simple matter to implement at home yourself on typical consumer routers.

As I said before, it would be "good" if JRemote and MC itself supported IPv6. It will need to eventually. But the fact that it does not currently is not an indication that MC is "way behind", it is an indication that IPv6 is complicated and the rollout has been very slow and somewhat troublesome all along.

The cold hard truth is that IPv6 was about 10% deployed at the beginning of last year:
http://arstechnica.com/business/2016/01/ipv6-celebrates-its-20th-birthday-by-reaching-10-percent-deployment/

We've had some improvements since then, but it isn't at even 30%, much less ubiquitous.

jsolo53 · « **Reply #13 on:** January 03, 2017, 04:20:44 pm »

Actually, Apple says otherwise. Per Apple Support, once an iOS device installs a current version of the OS, there is no IPv4 support in the iOS and there is no way to un-upgrade your iPhone. And earlier today, T-Mobile tech support claimed that T-Mobile does support both IPv4 and IPv6.

So who did what? T-Mobile? Apple? Don't know and don't particularly care.

What we do know is that a growing number of JRemote users are now having this problem because the current version of JRemote does not comply with Apple's minimum requirements. Regardless of who did what, there is a problem with JRemote that JRemote needs to handle.

mwillems · « **Reply #14 on:** January 03, 2017, 05:47:06 pm »

T-mobile is the main culprit here, but apple also has a more passive role in the issue. T-mobile definitely discontinued ipv4 on their phones, and their forums are currently on fire with help requests and frustrated people. The issue is worse on ios devices, though, because Android supports a more useful/modern ipv6 to ipv4 translation standard/layer (464XLAT) that allows most (but not all) apps to work transparently even when talking to ipv4-only endpoints. My understanding is that ios did not implement 464XLAT which means more ipv4 only services are failing for T-mobile ios customers. So it's an unfortunate double-whammy.

The specific failure mode for ios T-mobile phones (as I understand it) is that ipv4 literals, in particular, fail, as opposed to DNS requests which get transparently encoded as ipv6 even if the far-end site is ipv4 only. It apparently screws up routing too as I've seen multiple complaints of ipv4 VPNs not working correctly with ios devices on T-Mobile.

glynor · « **Reply #15 on:** January 03, 2017, 09:10:33 pm »

Quote from: jsolo53 on January 03, 2017, 04:20:44 pm

Actually, Apple says otherwise. Per Apple Support, once an iOS device installs a current version of the OS, there is no IPv4 support in the iOS and there is no way to un-upgrade your iPhone.

This is not correct, and would be crazy. If someone from Apple's real support told you that, they gave you incorrect information, and you should follow up with management (so they get better training). It happens though (I've seen, in person, Apple "Geniuses" tell people to quit applications who didn't know what the heck they're talking about).

If you mean some dude on the Apple Support Forums, well... I've seen all kinds of crazy stuff there.

It is easy enough to verify:
http://ipv6-test.com/

Or, you know, open Google via:
http://172.217.1.78

glynor · « **Reply #16 on:** January 03, 2017, 09:13:49 pm »

Quote from: mwillems on January 03, 2017, 05:47:06 pm

T-mobile definitely discontinued ipv4 on their phones, and their forums are currently on fire with help requests and frustrated people.

That is also not quite correct. According to World IPv6 Launch Day (who tracks these things), T-Mobile USA's current IPv6 deployment is just shy of 72%. That means, 28% of T-Mobile's subscribers are, not only not on IPv6 only, they don't have a valid IPv6 address.

glynor · « **Reply #17 on:** January 03, 2017, 09:24:18 pm »

If it is due to lack of CLAT support on iOS, then you might be able to work around the issue by simply referencing your MCWS server via a FQDN instead of by an IPv4 literal.

Don't know because I can't test it because my provider has a rational IPv6 strategy (you know, NAT64/DNS64). But you could try signing up with a dynamic DNS service (there are free ones) and see if setting your server up via a FQDN instead of by an Access Key (which would result in a IPv4 string literal being returned by the JRiver servers).

Good chance it would work though, if it is a CLAT problem (a brief search indicates that this is exactly what T-Mobile did with a portion of their network).

Also...

Do the people in this thread who need this have fully set up IPv6 networks and firewalls on their computers at home? Because I have IPv6 on my home network, but it works via Teredo since my Netgear (a current model device) can't do IPv6 port forwarding through the NAT firewall. So, even if it was enabled in JRemote, it wouldn't work here. When I move and get back on my real network, then it'd work right, but...

My Netgear is a ~$200 2016 model with the latest firmware. So... I don't know how common this really is out there that people could actually use this. I think there's some misunderstanding of what is required for IPv6 to really work, and what the limitations T-Mobile is really putting on you amount to...

mwillems · « **Reply #18 on:** January 03, 2017, 09:40:40 pm »

Quote from: glynor on January 03, 2017, 09:13:49 pm

That is also not quite correct. According to World IPv6 Launch Day (who tracks these things), T-Mobile USA's current IPv6 deployment is just shy of 72%. That means, 28% of T-Mobile's subscribers are, not only not on IPv6 only, they don't have a valid IPv6 address.

My understanding is that older phones are exempt (as they may not have full support), but that all newly setup phones (and most existing newer phones) are now ipv6 only. I'm not on T-mobile, I only know what I read around the net.

glynor · « **Reply #19 on:** January 03, 2017, 09:44:11 pm »

That's why I said not quite correct. They certainly didn't discontinue IPv4 support on their network, or it would have killed all those old phones.

I also found a bunch of announcements about them doing IPv6 on a "portion" of their network, starting in 2015, but no firm announcements that "ok, we're done, it is everywhere now" (but I only searched for 10 minutes because I don't care).

JimH · « **Reply #20 on:** January 04, 2017, 02:51:02 am »

Quote from: mwillems on January 03, 2017, 05:47:06 pm

The specific failure mode for ios T-mobile phones (as I understand it) is that ipv4 literals, in particular, fail, as opposed to DNS requests which get transparently encoded as ipv6 even if the far-end site is ipv4 only. It apparently screws up routing too as I've seen multiple complaints of ipv4 VPNs not working correctly with ios devices on T-Mobile.

What were they thinking? Let's just make the switch and see what happens?

jsolo53 · « **Reply #21 on:** January 04, 2017, 10:21:18 am »

Quote from: JimH on January 04, 2017, 02:51:02 am

What were they thinking? Let's just make the switch and see what happens?

YES!

another side · « **Reply #22 on:** January 04, 2017, 10:55:30 am »

Quote from: glynor on January 03, 2017, 09:10:33 pm

This is not correct, and would be crazy. If someone from Apple's real support told you that, they gave you incorrect information, and you should follow up with management (so they get better training). It happens though (I've seen, in person, Apple "Geniuses" tell people to quit applications who didn't know what the heck they're talking about).

If you mean some dude on the Apple Support Forums, well... I've seen all kinds of crazy stuff there.

It is easy enough to verify:
http://ipv6-test.com/

Or, you know, open Google via:
http://172.217.1.78

I just tried this on my T-Mobile iPhone and I get:

In the IPv4 section, I get IPv4 Supported

But for Browser, I get IPv6 as the default and for Fallback I get "No".

Are these two results contradictory?

mwillems · « **Reply #23 on:** January 04, 2017, 06:34:30 pm »

Quote from: JimH on January 04, 2017, 02:51:02 am

What were they thinking? Let's just make the switch and see what happens?

My understanding is that they ran out of their Ipv4 address allotment, so they simply had not enough addresses for new and existing customers and not much wiggle room with older customers who have phones that don't support ipv6, so they started pushing folks with capable phones onto ipv6.

glynor · « **Reply #24 on:** January 04, 2017, 09:02:44 pm »

Quote from: mwillems on January 04, 2017, 06:34:30 pm

My understanding is that they ran out of their Ipv4 address allotment, so they simply had not enough addresses for new and existing customers and not much wiggle room with older customers who have phones that don't support ipv6, so they started pushing folks with capable phones onto ipv6.

Pshaw. That's not the only reason. They could have just given NATed IPv4 addresses. I often get a 10.x.x.x address on AT&T.

I'm sure doing that just requires more complex (expensive) routing logic or hardware. Or some engineering executive there is a "true believer". The lack of IPv4 addresses is a reason, but also an excuse.

glynor · « **Reply #25 on:** January 04, 2017, 09:14:19 pm »

Quote from: another side on January 04, 2017, 10:55:30 am

Are these two results contradictory?

No. It is what we've been talking about. T-Mobile apparently has set (at least portions of) their network up to not allow IPv4 fallback on devices that support IPv6.

This means you cannot resolve IPv4 addresses natively. The DNS can translate it for you, so you can access servers which are only served via IPv4 (70-80% of the Internet) but you must use a DNS name so that the T-Mobile DNS server can do its proxy trickery.

I'd bet if you try to use that link to Google I provided with only their IP address, it'd fail.

But, that's not what you need to test. You need to test from your home computer that serves MC. If it does not show native IPv6 support (no Teredo or other transitional routing cleverness) then you wouldn't be able to use JRemote to access your home computer via IPv6 even if it was fixed.

That was the point I was making above. Just fixing JRemote is only a tiny portion of the issue. You would need a fully IPv6 chain accessible from your home machine through to the Internet, and then through to T-Mobile, for it to work. This is possible, but isn't likely unless you've done a lot of work on your home network to make sure it would work (and have a home ISP which is prepared in your service area).

However, from what I've read, setting up a dynamic DNS account for your home machine and accessing your MC server that way through JRemote (instead of using an Access Key) would almost certainly work to solve your issue. It would have the side effect that you'd need to connect to a different server in JRemote when on your local LAN (unless you can set up Full NAT in your home router, and you probably can't) but that doesn't seem like the end of the world.

So, you'd have two servers in JRemote: (1) set up with an Access Key for use on Wifi, and (2) set up with your dynamic DNS hostname for use on cellular.

glynor · « **Reply #26 on:** January 04, 2017, 09:19:24 pm »

JRiver could possibly fix this by changing the Access Key lookup process to include the FQDN in addition to the IP addresses. So, for example, mine is like this right now:
cpe-##-##-###-###.maine.res.rr.com
(Pound signs inserted to protect the guilty.)

I suspect if the Access Key lookup included that, rather than just my IP, it would work on T-Mobile's stupid system. Tough to test without a T-Mobile device.

I couldn't even get one if I wanted to. If you try to sign up for T-Mobile here, they say no. We have very little service with them in the whole state.

another side · « **Reply #27 on:** January 05, 2017, 10:13:34 am »

Well, as you suspected, the IPv6 test failed on my home computer. My ISP does not support IPv6.

I'm going to look into the dynamic DNS account option to see if that's workable for me.

bob · « **Reply #28 on:** January 06, 2017, 10:51:56 am »

Quote from: glynor on January 04, 2017, 09:19:24 pm

JRiver could possibly fix this by changing the Access Key lookup process to include the FQDN in addition to the IP addresses. So, for example, mine is like this right now:
cpe-##-##-###-###.maine.res.rr.com
(Pound signs inserted to protect the guilty.)

I suspect if the Access Key lookup included that, rather than just my IP, it would work on T-Mobile's stupid system. Tough to test without a T-Mobile device.

I couldn't even get one if I wanted to. If you try to sign up for T-Mobile here, they say no. We have very little service with them in the whole state.

I think that fix would work. I remember trying it a year or so ago when I was playing with the ipv6 stack on my android phone T-Mobile and Gizmo.

I'm going to stick with my iphone 4s and iOS8.4 on t-mobile.

bob · « **Reply #29 on:** January 06, 2017, 11:02:51 am »

Quote from: glynor on January 04, 2017, 09:19:24 pm

JRiver could possibly fix this by changing the Access Key lookup process to include the FQDN in addition to the IP addresses. So, for example, mine is like this right now:
cpe-##-##-###-###.maine.res.rr.com
(Pound signs inserted to protect the guilty.)

I suspect if the Access Key lookup included that, rather than just my IP, it would work on T-Mobile's stupid system. Tough to test without a T-Mobile device.

Also, I think that would be a pretty simple change to MC and wouldn't require changing JRemote or Gizmo.

bob · « **Reply #30 on:** January 06, 2017, 02:55:32 pm »

Quote from: bob on January 06, 2017, 11:02:51 am

Also, I think that would be a pretty simple change to MC and wouldn't require changing JRemote or Gizmo.

Unfortunately I forgot some ISP's don't supply reverse mapping for their dynamic customer subnets.
JRemote unlike Gizmo will take a FQDN as the IP address, not just numeric addresses.
I tested that and it worked with my home server.

So I setup a test for "another side" to use a FQDN. I'm not seeing how that gets through an IPV6 network to the IPV4 only site just via the DNS reply.

glynor · « **Reply #31 on:** January 06, 2017, 05:38:33 pm »

Quote from: bob on January 06, 2017, 02:55:32 pm

So I setup a test for "another side" to use a FQDN. I'm not seeing how that gets through an IPV6 network to the IPV4 only site just via the DNS reply.

I'm not sure about that either, but I suspect it could be something like this:

1. They have an IPv4 Proxy server, which maps external IPv4-only hosts to internal-only IPv6 addresses.
2. DNS lookup sends you this "fake" IPv6 address when you look up something like blog.glynor.com.
3. The proxy server does a transparent proxy and just forwards the packets (fixing the IP headers) so that TLS connections still work (the DNS record is correct, and DNS isn't secure, so TLS wouldn't be impacted by the "faked" IP address).

The end.

glynor · « **Reply #32 on:** January 06, 2017, 05:40:03 pm »

Quote from: bob on January 06, 2017, 02:55:32 pm

Unfortunately I forgot some ISP's don't supply reverse mapping for their dynamic customer subnets.

Yeah. Not all of them will work. But some will!

Those who have ISPs whom aren't friendly, would probably have to resort to Dynamic DNS. Unless JRiver wants to roll their own dynamic DNS system, but that seems like overkill for dumb T-Mobile.

bob · « **Reply #33 on:** January 06, 2017, 06:20:34 pm »

Quote from: glynor on January 06, 2017, 05:40:03 pm

Yeah. Not all of them will work. But some will!

Those who have ISPs whom aren't friendly, would probably have to resort to Dynamic DNS. Unless JRiver wants to roll their own dynamic DNS system, but that seems like overkill for dumb T-Mobile.

A good point. Probably makes sense to add an entry for the ones that have reverse DNS. Can't hurt anything.
We already have a dyndns but it's not linked into the access code system at all.

bob · « **Reply #34 on:** January 10, 2017, 02:56:07 pm »

The access key server has been updated to look up and send FQDN's (if they exist).
For most this should solve the issue, I tested with both JRemote and Gizmo and both worked.

For those who have a public IP address without reverse DNS mapping, you need to use a DYNDNS service until we automate that as well.

JimH · « **Reply #35 on:** January 11, 2017, 10:21:07 am »

FQDN means Fully Qualified Domain Name.

Example: yabb.jriver.com

glynor · « **Reply #36 on:** January 11, 2017, 10:10:11 pm »

Nice job, Bob!! That was really a simple change. Glad it worked out.

INTERACT FORUM

Author Topic: JRemote No Longer Works Away from Home (Read 12329 times)