ARC has been running fine on my phone / Android Auto for a long time. Just recently (I presume after upgrade last week) it no longer connects to the server over the mobile network. No trouble over local WiFi
If, on the mobile net, I enable a tailscale link back to my NAS then again ARC works just fine. Suggests a port problem. But no change to setups and Roon shows ARC server can access internet.
I use an Ubiquiti network controller but the most recent changes to the setup (Ad blocking and using DNS over HTTP) predate the problem as far as I know. In any case disabling both of these does NOT fix the inability to directly access over mobile net. Obviously, I set up port 43430 ages ago through a couple of router layers so ARC could work at all - and as noted it has been doing so with no problem until now.
So I at least have a "work around" - but clearly something is broken with the WAN comms; when ARC has access directly to the server (via VPN) it's sweet.
Everything is latest version; Roon server 2.0 buiild 1368 on Synology NAS and ARC android Feb 2nd build 232
For completeness. I have checked my WAN IP address and confirmed it is not behind a CGNAT. I am using Telstra Cable (256Mbps) and a traceroute matches my router WAN address - and shows the matching internal telstra name as cpe-101-X-X-X.vb01.vic.asp.telstra.net (disguised), which itself is a confirmation there’s not a separate translation layer
The port test pings an upstream server and listens for a response on the assigned port; it does not test the downstream connection to the phone, and it will retain a “Ready” status until the same port test fails, regardless of whether ARC is actively capable of connecting or not. So, a failing cellular connection to ARC with a positive port test indicates that either:
a) the downstream connection, another app or the phone OS, or ARC itself is the blockage
or, in rare cases:
b) RoonServer’s upstream connection can send a ping, but it’s is being filtered sufficiently that ARC can’t sync
Just in case, what happens if you augment the port assignment you’ve hardcoded in the port forwarded rules by a few hundred? It’s unlikely the port test would miss a port mapping conflict, but this is worth a try.
Do you have any QoS rules in your Ubiquiti router that might be throttling RoonServer’s upstream connection at times?
Are you encountering any popup errors or banners? Please share a screenshot of the screen when you lose connection after switching to cellular.
Created new port at 54321 at set up chain of firewall rules.
This, after a bit of a wait and a couple of retries, tested fine in the Roon config
Phone ARC would not connect when on mobile network unless I used my wireguard server link
Enabling mobile hotspot on same phone and linked tablet to it. ARC works find - though slowish as may be expected over mobile (HUH?!?!?)
Uninstalled phone ARC. Reinstalled and asked to relink, got “online and ready”
Tapping the tick gives me this which then times out:
Checked phone ARC still works with VPN link - of course it does.
Uninstalled, reinstalled, rebooted.
RESOLVED
No idea why but just going with it. Perhaps this will be instructive for others; clearly something was cached in the config that borked the existing install or was incompatible version to version. Clearing it all has worked.
Sorry to take your time and thanks for pushing me forward
Thank you for your time and detailed follow-up and we’re glad to see it’s resolved with an uninstall/reinstall. For clarity, did you uninstall/reinstall RoonServer, or just Roon ARC? I’m passing this bug report along to our ARC Dev and QA team - diagnostics seem to confirm that ARC was attempting and failing to call a previous closed session during the period just before you posted.
Server side stable as there was no indication that it was the problem at any point.
The fact that the gonzo state of the Android client was able to recognise the server (get to tick box) but not open a full session is very perplexing. Clearly the wireguard VPN opened a server path that was otherwise blocked when on mobile.
Why it started when it did and why a reinstall alone did not work but with a reboot suggests some cached parameter corruption - where the parameters were handed differently between versions.
Thank you! I’ve passed these results off to development.
This is precisely the mechanism we uncovered in logs with the A/B test above. We’re keeping an eye on this for future improvement. If you encounter any erroneous or frustrating behavior moving forward, please reach out in a new topic thread.
ARC is retaining parameters from a previous session under certain circumstances, causing authorization failures. This is highly specific to network implementation and not something widespread within the experience of the ARC user base. Obviously, it’s frustrating for those affected.
Development will be pushing improvements to prevent this from happening, but they’ll involve a constellation of tickets, rather than something we’ll track within a single release.
If this connectivity issue starts to impede your ARC experience, please create a new topic thread accurately describing the current symptom. Ideally, it’s something that will go away quietly as we release improvements incrementally.