Bug 2404963 - Multiple apps fail to connect to IPv6 services if device has IPv6-only network access
Summary: Multiple apps fail to connect to IPv6 services if device has IPv6-only networ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: glib2
Version: 43
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Debarshi Ray
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-10-18 20:51 UTC by Maurice Walker
Modified: 2025-11-13 00:51 UTC (History)
20 users (show)

Fixed In Version: glib2-2.86.1-5.fc43
Clone Of:
Environment:
Last Closed: 2025-11-13 00:51:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME glib merge_requests 4877 0 None merged gresolver: Fix loopback detection of IPv6 addresses 2025-11-10 21:35:33 UTC
GNOME Gitlab GNOME glib merge_requests 4878 0 None merged Backport "gresolver: Fix loopback detection of IPv6 addresses" 2025-11-10 21:37:39 UTC

Description Maurice Walker 2025-10-18 20:51:33 UTC
When a Fedora 43 system is connected to an IPv6-only network (with DNS64 / NAT64), multiple apps fail to connect to IPv6 services.
For example, the default file manager (Gnome Nautilus) fails to access WebDAV shares.

This issue is new in Fedora 43 (Workstation as well as Silverblue).
No similar issues were observed in Fedora 42 on the same device, same network.

Recent changes to glibc being the culprit is just a wild guess.

Reproducible: Always

Steps to Reproduce:
1.Connect device to IPv6-only network (with DNS64 / NAT64).
2.Open the 'Files' app.
3.Go to 'Network', enter a WebDAV FQDN into the 'Server address' field (e. g. davs://webdav.smartdrive.web.de) and click 'Connect'.
4. See error message: "Unable to access location - Error resolving "webdav.smartdrive.web.de": No valid addresses were found"
Actual Results:
Can't connect to WebDAV server.

Expected Results:
Successful connection to WebDAV server.

Additional Information:
This is not a DNS64 / NAT64 issue - the affected FQDNs do have AAAA records and the services can be accessed via IPv6. 'resolvectl query' works, so does ping.

Similar error messages regarding name resolution can be observed in multiple other apps (e. g. Gnome Extensions and Evolution).

Firefox and Chromium can access https://webdav.smartdrive.web.de without issues (on the same device, same network).

It works when the device is connected to a Dual-Stack network.

Comment 1 Florian Weimer 2025-10-19 10:34:32 UTC
Could you post the output of these commands when running them on the impacted system:

getent ahosts webdav.smartdrive.web.de
getent ahostsv4 webdav.smartdrive.web.de
getent ahostsv6 webdav.smartdrive.web.de
resolvectl query webdav.smartdrive.web.de

Comment 2 Maurice Walker 2025-10-19 10:53:04 UTC
$ getent ahosts webdav.smartdrive.web.de
2001:8d8:5f9::8e STREAM webdav.smartdrive.web.de
2001:8d8:5f9::8e DGRAM  
2001:8d8:5f9::8e RAW    
$ getent ahostsv4 webdav.smartdrive.web.de
$ getent ahostsv6 webdav.smartdrive.web.de
2001:8d8:5f9::8e STREAM webdav.smartdrive.web.de
2001:8d8:5f9::8e DGRAM  
2001:8d8:5f9::8e RAW    
$ resolvectl query webdav.smartdrive.web.de
webdav.smartdrive.web.de: 2001:8d8:5f9::8e     -- link: wlp0s20f3
                          195.20.251.142       -- link: wlp0s20f3

-- Information acquired via protocol DNS in 98.8ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: cache network

Comment 3 Florian Weimer 2025-10-19 12:31:21 UTC
So the low-level data looks good. If this impacts predominantly GNOME applications, I wonder if this a libsoup issue. Maybe this issue is related?

Resolving IP addresses sometimes fails in IPv6 only environments
<https://gitlab.gnome.org/GNOME/libsoup/-/issues/392>

Comment 4 Maurice Walker 2025-10-19 16:16:13 UTC
Thanks for looking into this.

Correct, so far I've only observed it in GNOME apps.

It only affects some protocols:
In Nautilus, sftp, ssh and smb work, while ftp, ftps, dav and davs fail.
In Evolution, IMAP fails with exactly the same error message.

Not sure about libsoup / libsoup3. Fedora 42 and 43 seem to use the same versions and this issue is new in Fedora 43.

A search for the exact error message ("Error resolving" + "No valid addresses were found") suggests it's coming from GIO:
https://gitlab.gnome.org/GNOME/glib/-/blob/glib-2-86/gio/gthreadedresolver.c#L424

glib2 was indeed updated from 2.84 in Fedora 42 to 2.86 in Fedora 43.

I'll change the affected component to glib2.

Comment 5 Maurice Walker 2025-10-20 16:47:48 UTC
Workaround: Add an IPv4 address to the interface. Link-local is sufficient, e. g. by setting IPv4 to "Link-Local Only" in the Wi-Fi network settings.

This commit could be the culprit: https://gitlab.gnome.org/GNOME/glib/-/commit/fe0139ee985075f3c12932d7123cb594356e7e9d

Comment 6 Maurice Walker 2025-10-21 18:01:01 UTC
Confirmed to be caused by a bug in the mentioned commit to glib2:
https://gitlab.gnome.org/GNOME/glib/-/commit/fe0139ee985075f3c12932d7123cb594356e7e9d#note_2582188

Comment 7 Fedora Update System 2025-11-11 12:53:14 UTC
FEDORA-2025-f4950d8592 (glib2-2.86.1-5.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-f4950d8592

Comment 8 Fedora Update System 2025-11-12 02:58:20 UTC
FEDORA-2025-f4950d8592 has been pushed to the Fedora 43 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-f4950d8592`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-f4950d8592

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2025-11-13 00:51:17 UTC
FEDORA-2025-f4950d8592 (glib2-2.86.1-5.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.