mirror of
https://github.com/Radarr/Radarr.git
synced 2026-03-02 22:57:34 -05:00
IPv6 outgoing connections not working #6787
Labels
No labels
Area: API
Area: Database
Area: Db-migration
Area: Download Clients
Area: Extras
Area: Import Lists
Area: Indexer
Area: Metadata API
Area: Notifications
Area: Organizer
Area: Parser
Area: Scanning
Area: Tooling
Area: UI
Area: Unit Tests
On Hold: MetadataAPI Blocking
On Hold: MetadataAPI Blocking
Priority: High
Priority: Low
Priority: Medium
Status: Accepted
Status: Cannot Reproduce
Status: Confirmed
Status: Help Wanted
Status: In Progress
Status: Indexer - need invite
Status: Info Needed
Status: Investigating
Status: Logs Needed
Status: Maybe One Day
Status: Needs Triage
Status: On Hold
Status: Ready for Review
Status: Unlikely
Status: Waiting for OP
Status: Won't Fix
Type: Bug
Type: Documentation
Type: Duplicate
Type: Enhancement
Type: External Bug
Type: Feature Request
Type: Regression
Type: Support
Type: Support.
conflict
lidarr-pull
no-conflict
not-pulled
readarr-pull
readarr-pull
sonarr upstream
sonarr-pull
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Radarr#6787
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lrsksr on GitHub (Sep 25, 2022).
Is there an existing issue for this?
Current Behavior
My download client is IPv6 only. When I try to set it up, I get the following HTTP 400 reply:
trace log at the end of the issue.
More so, when I disable IPv4 on the machine running radarr, when searching for movies I get a HTTP 503 with the stack trace in the response, also attached below.
I can see DNS requests for
api.radarr.videoand responses for both A and AAAA records using wireshark. When both IPv4 and IPv6 are enabled, the connection is established using the IPv4 adress from the A record. With only IPv6 enabled, no connection is established with the errorNetwork is unreachableOn the same machine, Sonarr is able to connect to the IPv6-only download client.
curlalso works as expected, even preferring IPv6 over IPv4 addresses.Expected Behavior
When dual stack is available, outgoing connections should be preferred via IPv6 instead of IPv4.
When only IPv6 is available and the remote host has an IPv6 address, a connection should be established.
Steps To Reproduce
or
Environment
What branch are you running?
Master
Trace Logs?
The "No data available" for remote IPv6-only hosts:
The "Network is unreachable" when trying to connect to dual stack remote hosts but from IPv6-only machine:
I suspect the relevant line is
NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.onConnect(SocketsHttpConnectionContext context, CancellationToken cancellationToken) in D:\a\1\s\src\NzbDrone.Common\Http\Dispatchers\ManagedHttpDispatcher.cs:line 272The mentioned issue in the source code is still open, but when you investigate further, there are PRs merged that claim to fix the issue?
AB#3824
@vosdev commented on GitHub (Oct 15, 2022):
Can reproduce. Have had this issue for months :/
@Qstick commented on GitHub (Oct 18, 2022):
I can spin a test build to remove the custom fallback handler if you fancy a go?
@lrsksr commented on GitHub (Oct 29, 2022):
That would be great! Will the installation procedure be the same as described here? https://wiki.servarr.com/radarr/installation
@ntrp commented on GitHub (Nov 9, 2022):
I am using the Helm chart from truecharts (hence docker) and have the same issues, this is the chart https://truecharts.org/docs/charts/stable/radarr.
The app cannot connect to a publicly available transmission instance unless ipv4 is enabled on that instance. If I ssh into the Radarr pod I can connect via IPv6. Looks more like a software issue also because Sonarr was working fine.
@bakerboy448 commented on GitHub (Jan 10, 2023):
github.com/Radarr/Radarr@c11f72c098should have this at least partly fixed / working combined with the ipv6 fallback logic
@lrsksr commented on GitHub (Jan 11, 2023):
I upgraded to v4.3.2.6857 which includes this commit.
Unfortunately the problem remains with the same stack trace.
It's the same when I put in the IPv6 address instead of a domain name.
Do you need further information? Thanks!
@lrsksr commented on GitHub (Feb 25, 2023):
Issue remains in v4.4.2.6956
@bakerboy448 could you please remove the tags you added so this gets attention again?
@bakerboy448 commented on GitHub (Feb 25, 2023):
Fresh round of trace logs anyone?
@lrsksr commented on GitHub (Feb 25, 2023):
I don't think anything except line numbers has changed since I opened this issue:
@tungstenostrich commented on GitHub (Apr 13, 2023):
Just ran into the same issue while migrating my home lab to IPv6 only. It doesn't only affect connections towards my download client but indexers as well. The Radarr version used 4.3.2.6857.
@heliochronix commented on GitHub (Jun 27, 2023):
I just ran into this myself on an IPv6-only system. Is there a workaround some people have found until this is fixed?
@h1ght commented on GitHub (Nov 5, 2023):
got pretty much the same error. i can curl the prowlarr/sonarr api's on all hosts/docker instances. e.g. when entering https ipv6 e.g. https://[ipv6:test:0123] it says it is invalid. same as https://[ipv6]:9696
edit//
after figuring out why its not working, looks like the arrs wont connect each other with ipv6. im running this in docker but switched to network_mode: host so no docker-nat inbetween. if i want to sync prowlarr and radarr(or sonarr e.g.) i get http.400 bad request. if i want to add the tornab rss url out of prowlarr of the specific indexer e.g. its the same "no data available" im using global routeable address that my provider gives me. i can curl it outside of my network, within each container. i tried it before via ipv6 bridge network via ip6-prefix delegation (/62 subnet out my /56 net) with global routable addresses. looks the same. i tried http reverse proxy e.g. traefik, same. i'll add some logs
radarr log trying to connect to prowlarr
prowlarr log.
i removed my ipv6 prefix because its routeable. it looks like the can authenticate, but then shit hits the fan. somehow the http requets are not 200 but 400.
edit//
didnt wanted to create new issue, because my problem looks similiar to this.
regards
@covert8 commented on GitHub (Dec 13, 2023):
I spent some time looking at this a few months back and came to the realisation that the happy eyeballs algorithm has not been implemented. Meaning that if for one reason or another ipv6 connectivity is lost it will never be retried until radarr is restarted.
In a k8s environment that happens often as pods are moved between hosts
The above line is the offending one.
The most simple patch would be to add a setting forcing ipv6 attempts always.
if (useIPv6) -> if (useIPv6 || forceIPv6)on linegithub.com/Radarr/Radarr@fcda6faf3d/src/NzbDrone.Common/Http/Dispatchers/ManagedHttpDispatcher.cs (L246C13-L247C1)The suggested patch for an override is simple, but i don't known the codebase enough to add such a setting to config.xml
@covert8 commented on GitHub (Dec 13, 2023):
I Wanted to add the forceIPv6 flag to the constructor of the
ManagedHttpDispatcherbut I can't seem to find it's factory or where it's being constructed. Any pointers would be much appreciated