Testing IPv6 support in Roon (for users locked out of ARC due to ISP reliance on IPv6 or CGNAT)

little feedback
updating to earlyaccess 257 worked fine for me after reinstall with the .bin file and two times rebooting Rock

ARC is still working (over IPv4 for me)

I ordered fiber internet (with only IPv6) this week but have to wait over a year for it.
Good to know that I can then continue to use ARC :slightly_smiling_face:

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.

1 Like

I updated my Nucleus to Roon OS Build 257 remotely using Mac Mini and Splashtop. I’m not home to test it, but Roon ARC is working, so that’s good.

How is this arc configuration supposed to work? I get an error still.

Did you update Roon ARC using TestFlight?

Hi René-

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!! :face_holding_back_tears:
Just kidding, congrats!

6 Likes

I did and now I went back to production after it didn’t work.

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?)

Wish I could be of more help.

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 :slight_smile:

USA
T-Mobile Home Internet
Failure :slight_smile:

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.

Test results:

{
"ipv6_connectivity": {"status":"NetworkError","status_code":504,"error":"error: Error: ETIMEDOUT, response code: undefined, body: undefined connected? undefined"},
"ipv4_connectivity": {"status":"NetworkError","status_code":504,"error":"error: Error: ETIMEDOUT, response code: undefined, body: undefined connected? undefined"},
"external_ip": {"actual_external_ip":"172.ggg.hhh.iii","actual_external_ipv6":"2607:aaa:bbb:ccc:ddd:eee:ddd:fff","router_external_ip":"null"},
"natpmp_autoconfig": {"status":"NotFound"},
"upnp_autoconfig": {"status":"NotFound"}
}

Host: Windows 10 latest updates (I think latest updates)
Version: 2.0 Build 1228 (64bit)

Looking at a packet capture, I see nothing hitting my Core as an incoming request.

However, It is listening…

TCP    0.0.0.0:55000          0.0.0.0:0              LISTENING
TCP    [::]:55000             [::]:0                 LISTENING

I can connect to the link-local address from the Core machine.
ARC works locally as expected.

1 Like

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.

Hope all that helps.

4 Likes

:grinning:Tada! It finally works for me. Well done.

4 Likes

I have T-Mobile home internet with TP Link routers. So definitely I’ll be following your posts. Yes I am also in the USA.

What internet do you have?

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.

1 Like

What were the instructions?

Abe,

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.
  • If you are running your core on RoonOS (Nucleus or ROCK) then you will need to update to the latest earlyaccess build of RoonOS."

Roland

Hi everyone,

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.

1 Like

Edit: my ISP PlusNet in the UK is not ipv6 enabled

I’ll have a go at updating on Wednesday.

1 Like