I have a double-NAT configuration (two routers in my network, but with port forwarding configured to support ARC). I tested it with one of the router’s port forwarding disabled and a new error code appears, Error 200. It does not matter which router PF rule I disable, my WAN or my LAN, Error 200 now appears if either PF rule is disabled. This is more about troubleshooting, but wanted to ask what Error 200 means.
Actually, the instructions for how to get your core on RoonOS earlyaccess (not to get Roon Server on earlyaccess, you can do that on either production or early access RoonOS devices) are in the below link… I wish that the difference was detailed on the link you sent, but it’s not, so it’s confusing. All’s well in any case, thanks.
Noooooooo, a month of arguing with my ISP about their broken static external IPv4 address as well as several months of teaching people about CG-NAT and IPv4 port forwarding are utterly wasted!!
Just kidding, congrats!
So, I have IPv6 enabled on my router (UDM Pro), and I now have RoonOS 257 and latest build (1228 I think). So RoonARC is passing the port Roon ARC readiness test, but I have port forwarding set up, so I don’t know if it’s a good test. How can I tell if I’m actually working the way you want? I also use IPv4 - it’s not like I have to use IPv6 (does anyone have to use it?)
You could turn off the IPv4 port forwarding rule? Or maybe turn off IPv4 completely on the router if that’s possible
Yes, the people who have an ISP who moved wholly to IPv6 and has limited IPv4 support by using CG-NAT, DS Lite, or any other tech that shares IPv4 addresses between users, i.e., does not provide real, forwardable IPv4 addresses externally. That’s the point of supporting IPv6
This is expected as the 5G Home Internet device has no port forwarding configuration and I suspect that T-Mobile drops all incoming (InternetTubes → Me) unsolicited connections.
USA
T-Mobile 5G Network Tethering to Mobile Device
Tests Ready (but shows v4 address)
Doesn’t work
I think this is a client issue and it may be two different issues:
In my home network I don’t have IPv6 network. Just too lazy to get this going. In this case the client should fail. Instead it just spins.
On a phone connected to T-Mobile’s LTE network I think this should work. But ARC would see dual-stack network… it needs to know only v6 will work and not try the v4 network. Same behavior as above; the client just spins trying to connect.
In both cases, it lists 2 Cores my primary and my test core. The Primary correctly reports yellow ! with “local only”. My test Core spins, properly reports the “last seen” from the time I initiated a test, but just spins with no status. It still lets my try to connect.
And, because there is still no way to see this come on, been asking this for months now…
I can’t see what IP address the clients are trying to connect to and I have no idea if the clients are actually using the v6 IP.
Roon Core IP (on ARC Settings screen) is reported as: 172 address (IPv4 DHCP from the phone). This should report both v4 (local only) and v6 (Ready). In this configuration it appears v6 should work I know v4 will not. So, this screen is now confusing as to what is actually working and not working.
I can see in a packet capture it is testing the IPv6 address and it appears to me that there is a SYN, SYN/ACK, and successful TLS handshake from Google v6 space to my Core.
EDIT: I just had another thought. I currently only have T-Mobile SIMs. They might block device to device connectivity. That would prevent me from testing this. I really should get IPv6 up on my home network.
EDIT: On Android the client is now telling me that my test core is local only. Core ARC settings still says Ready.
The ISP is Rogers in Canada. Using eero mesh. Unable to make ARC work till the recent Roon fix. Followed the ARC update instructions and successful first try.
All you likely need is the following extract from Roon’s email of March 9 email with the same title as this thread. If needed, the full explanation is there as well,
" ### Notes on IPv6
IPv6 has been enabled for all cores running Early Access. To ensure that support is enabled on your core you will need to restart Roon or Roon Server twice (once to update the configuration and again to ensure that the new networking code runs at statup)
This change involves changes to Roon as well as our back-end services which facilitate communication between ARC and your Roon core.
Thank you for taking the time to test this out, and in particular to those of you for whom this requires some hardware rearrangement or network reconfiguring.
The team is eagerly consolidating test results as reports come in here. In particular, we’re curious to hear how RoonOS users are faring (please be sure to update to the latest #earlyaccess RoonOS build here, if you haven’t already).
For those of you who have yet to post: the granularity of your report is up to you, but please include 1) your Core operating system and 2) a basic list or overview of your network hardware and setup. For example:
MacOS Core → Google Mesh → Verizon FIOS router
If the Roon Settings port test fails, please include any diagnostics or a description of the error message. We’re here to assist with any questions and the team is very grateful for the time and expertise you’ve lent here.