Why do you need uPnP to reach my ROCK over IPv6 since that provides direct mapping across it’s huge address space? Here are the Roon ARC test results for manual port forwarding with UPnP disabled:
{
“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”:“98.hhh.ddd.iii”,“actual_external_ipv6”:“2605:aaa:bbb:ccc:ddd:eee:fff:ggg”,“router_external_ip”:“null”},
“natpmp_autoconfig”: {“server_ip”:“192.168.2.1”,“found_natpmp”:true},
“upnp_autoconfig”: {“status”:“NotFound”}
}
Here are the Roon ARC results with UPnP enabled and manual port forward removed:
{
“ipv4_connectivity”: {“status”:“NetworkError”,“status_code”:504,“error”:“error: Error: ETIMEDOUT, response code: undefined, body: undefined connected? undefined”},
“external_ip”: {“actual_external_ip”:“98.hhh.ddd.iii”,“actual_external_ipv6”:“null”,“router_external_ip”:“100.67.235.245”},
“status”: “status”: MultipleNatFound
,
“natpmp_autoconfig”: {“server_ip”:“192.168.2.1”,“found_natpmp”:true},
“upnp_autoconfig”: {“server_ip”:“192.168.2.1”,“found_upnp”:true}
}
I’ve been working with you guys to get this fixed for over a year now, close to 2 years so please check my previous support messages. I have an ASUS RT-AX3000 Router coming from a bridged Starlink dish over IPv6. Although it also has an IPv4 address it’s dual-NAT so you guys shouldn’t be trying to reach my ROCK over IPv4. I will be happy to provide you with any other test results that might help you fix this. Based on my previous testing with Roon technicians, the problem is that Roon fails on an IPv6 address containing a zero hex digit in the first position of the third quad of an IPv6 address (ipv6 ASN 14593) even though this clearly complies with the IPv6 standard. There are several other ISPs that also use leading zero addresses and none of your users on these ISPs can use Roon ARC. We were told by Connor that this bug had been submitted to development for a fix but we have not had a status update for months. Is Roon still planning on fixing their IPv6 problems now that Harmon has taken over?
The vast majority of our users are on IPv4-only networks for which the UPnP stack can autoconfigure port forwarding. That’s the only reason we’ve curated our support tools to include these IPv4-related questions.
If you’re on an IPv6 or true dual-stack network, you obviously won’t require UPnP. Our helpful moderator @Rugby was merely including the full, exhaustive troubleshooting tree at our instruction to cast a wide net.
You’re correct that we’ve yet to release the fix for the known issue with IPv6 affecting Starlink users. It remains in the pipeline, although the priority is now raised.
We provide updates as they’re available from engineering - the acquisition has had no bearing on our timeline to fix this ticket and we’ve set the timeline with the urgency permitted by our available engineering resources. Having moderated the forums for the duration of this issue’s effect on users, I’m keenly aware of how frustrating it can be. If you haven’t already, please look into some of the reliable workarounds on this site for now.
Connor, thank you so much for the update. If you are aware of any work-arounds that support both IPv4 and IPv6 and will work for ROCK installed on a NUC then I would love to know about this. I’ve already tried all the solutions I could find on Roon none of them will work in my environment without making changes that will cause problems with other systems I require.
I’m really happy to hear that the IPv6 fix has been given a higher priority now and I will keep an eye on the above support thread. Thanks again for your help in getting this issue resolved.