Package: fwupd
Version: 2.0.12-1
Severity: important

Dear Maintainer,

After installing fwupd on Debian 13 both the "fwupdmgr refresh" command
and the hourly timer result in a "host unreachable" error message.

The system does not appear to have any general networking issues and I
was able to request the metadata URI from the configuration using other
tools.

$ sudo apt install fwupd
$ sudo fwupdmgr refresh
Failed to download metadata for lvfs: network is unreachable: Host unreachable

$ HEAD https://cdn.fwupd.org/downloads/firmware.xml.zst
200 OK
Cache-Control: public, max-age=14400
Connection: close
Date: Sat, 19 Jul 2025 13:01:39 GMT
Via: 1.1 varnish
Accept-Ranges: bytes
Age: 4125
Server: gunicorn
Content-Length: 1627469
Content-Type: application/zstd
Client-Date: Sat, 19 Jul 2025 13:01:39 GMT
Client-Peer: 151.101.62.49:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Atlas R3 DV TLS CA 2025 Q1
Client-SSL-Cert-Subject: /CN=cdn.fwupd.org
Client-SSL-Cipher: ECDHE-RSA-CHACHA20-POLY1305
Client-SSL-Socket-Class: IO::Socket::SSL
Client-SSL-Version: TLSv1_2
Content-Disposition: attachment; filename=firmware.xml.zst
X-Cache: HIT
X-Cache-Hits: 0
X-Served-By: cache-lcy-egml8630096-LCY

There is nothing out of the ordinary in the logs:

2025-07-19T12:49:25.033904+00:00 pisang dbus-daemon[752]: [system] Activating via systemd: service name='org.freedesktop.fwupd' unit='fwupd.service' requested by ':1.1537' (uid=0 pid=1475723 comm="fwupdmgr refresh")
2025-07-19T12:49:25.041785+00:00 pisang systemd[1]: Starting modprobe@sd_mod.service - Load Kernel Module sd_mod...
2025-07-19T12:49:25.067776+00:00 pisang systemd[1]: modprobe@sd_mod.service: Deactivated successfully.
2025-07-19T12:49:25.068281+00:00 pisang systemd[1]: Finished modprobe@sd_mod.service - Load Kernel Module sd_mod.
2025-07-19T12:49:25.080713+00:00 pisang systemd[1]: Starting fwupd.service - Firmware update daemon...
2025-07-19T12:49:25.278265+00:00 pisang fwupd[1475735]: 12:49:25.278 FuPluginUefiCapsule skipping device that failed coldplug: ESRT GUID '00000000-0000-0000-0000-000000000000' was not valid
2025-07-19T12:49:25.347381+00:00 pisang fwupd[1475735]: 12:49:25.347 FuEngine failed to add device /sys/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8.3/1-8.3:1.0/host8/target8:0:0/8:0:0:0/block/sr0: failed to subclass open: failed to open /dev/
sr0: Operation not permitted
2025-07-19T12:49:25.349405+00:00 pisang fwupd[1475735]: 12:49:25.349 FuEngine failed to add device /sys/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8.3/1-8.3:1.0/host8/target8:0:0/8:0:0:0/block/sr0: failed to subclass open: failed to open /dev/
sr0: Operation not permitted
2025-07-19T12:49:25.353111+00:00 pisang fwupd[1475735]: 12:49:25.353 FuEngine failed to add device /sys/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8.3/1-8.3:1.0/host8/target8:0:0/8:0:0:0/block/sr0: failed to subclass open: failed to open /dev/
sr0: Operation not permitted
2025-07-19T12:49:25.492070+00:00 pisang fwupd[1475735]: 12:49:25.490 FuMain fwupd 2.0.8 ready for requests (locale en_GB.UTF-8)
2025-07-19T12:49:25.495938+00:00 pisang dbus-daemon[752]: [system] Successfully activated service 'org.freedesktop.fwupd'
2025-07-19T12:49:25.495977+00:00 pisang systemd[1]: Started fwupd.service - Firmware update daemon.
2025-07-19T12:49:26.225653+00:00 pisang polkitd[1471658]: Unregistered Authentication Agent for unix-process:1475723:65858054 (system bus name :1.1536, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8) (disconnected from
bus)

I reported this problem upstream and they said:

We're using the GLib g_network_monitor_can_reach() API to check if
we can get to the URL. Are you configuring your system in an unusual
way, e.g. with a VPN, SOCKS proxy or something like that?

This is a server system without a desktop environment. The networking is ifupdown configured statically. It does get its default route from the
bird BGP daemon. Upstream then could only suggest a Debian bug be
opened.

At reportbug's suggestion I installed fwupd from experimental but
experience the same issue.

I see from the template below that the contents of /etc/fwupd/fwupd.conf
were not added so I will add them here. I have not altered the config
file from what the apckage installed.

$ sudo cat /etc/fwupd/fwupd.conf
[fwupd]
# use `man 5 fwupd.conf` for documentation

-- System Information:
Debian Release: 13.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.12.35+deb13-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fwupd depends on:
ii libarchive13t64 3.7.4-3
ii libblkid1 2.41-5
ii libc6 2.41-9
ii libcbor0.10 0.10.2-2
ii libcurl3t64-gnutls 8.14.1-2
ii libdrm-amdgpu1 2.4.124-2
ii libdrm2 2.4.124-2
ii libflashrom1 1.4.0-3
ii libfwupd3 2.0.12-1
ii libglib2.0-0t64 2.84.3-1
ii libgnutls30t64 3.8.9-3
ii libjcat1 0.2.3-1
ii libjson-glib-1.0-0 1.10.6+ds-2
ii liblzma5 5.8.1-1
ii libmbim-glib4 1.32.0-1
ii libmbim-proxy 1.32.0-1
ii libmm-glib0 1.24.0-1
ii libpolkit-gobject-1-0 126-2
ii libprotobuf-c1 1.5.1-1
ii libqmi-glib5 1.36.0-1
ii libqmi-proxy 1.36.0-1
ii libsqlite3-0 3.46.1-6
ii libsystemd0 257.7-1
ii libtss2-esys-3.0.2-0t64 4.1.3-1.2
ii libusb-1.0-0 2:1.0.28-1
ii libxmlb2 0.3.22-1
ii shared-mime-info 2.4-5+b2
ii systemd [systemd-sysusers] 257.7-1
ii zlib1g 1:1.3.dfsg+really1.3.1-1+b1

Versions of packages fwupd recommends:
pn bolt <none>
ii dbus [default-dbus-system-bus] 1.16.2-2
ii fwupd-amd64-signed [fwupd-signed] 1:1.7+1
ii jq 1.7.1-6+deb13u1
ii python3 3.13.5-1
ii udisks2 2.10.1-12.1

Versions of packages fwupd suggests:
pn gir1.2-fwupd-2.0 <none>

-- Configuration Files:
/etc/fwupd/fwupd.conf [Errno 13] Permission denied: '/etc/fwupd/fwupd.conf'

-- no debconf information

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Mario,

On Mon, Jul 21, 2025 at 10:22:17AM -0500, Mario Limonciello wrote:

I don't believe this is a fwupd bug. If g_network_monitor_can_reach()
isn't working with fwupd for your network setup, it's a problem with glib
or glib dependencies IMO.

Sounds sensible. Do you have any advice for a minimal way to
test/reproduce that so I can put that in a bug report for glib? And
would it be package libglib2.0-0t64 that I report such a bug against?

Thanks,
Andy

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

retitle -1 g_network_monitor_can_reach() returns unreachable on system with fully working network
reassign -1 glib2.0 2.84.3-1
thanks

On Mon, Jul 21, 2025 at 10:59:46AM -0500, Mario Limonciello wrote:

A simple C app that uses just that symbol and prints the output is probably the way to go.

While I do know basic C coding I have never used GLib before and didn't
really know where to start. I ended up asking an LLM, which produced the attached example.

This example does indeed fail for me on the system in question while it
works on other systems.

I'll reassign this to glib2.0 and pursue it there.

Thanks!

Dear GLib maintainers,

On this install of Debian 13 g_network_monitor_can_reach() is returning unreachable even though the machine;s network is as far as I am aware
fully working.

This system is now in test deployment and up until I tried to make fwupd
work, every other aspect of it was seen to be working correctly. It was
only when finding that fwupd wouldn't download its metadata database due
to believing that it had no network access that I have begun to look in
to this.

Are you able to help me find out why this function is deciding this?

This is a server system with network statically configured by ifupdown.
Its network configuration is slightly out of the ordinary however, in
that it has two network interfaces with only IPv6 link-local addresses
on them, and some global scope addresses on the loopback interface.

The system talks BGP over its main interfaces and learns default routes
from the BIRD BGP daemon.

This is a valid network configuration since even if BGP were not in the picture, it could be talking to its default gateway router over one of
the link-local addresses and still be fully functional as an Internet
host. I recognise however that this kind of setup is probably rare so
this may be the area in which the problem lies.

$ ip a sh dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 85.119.80.32/32 brd 85.119.80.32 scope global lo:0
valid_lft forever preferred_lft forever
inet6 2a0a:1100:f20::/128 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
$ ip a sh dev e-25g-0
4: e-25g-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 40:a6:b7:2b:61:1c brd ff:ff:ff:ff:ff:ff
inet6 fe80::2/64 scope link nodad
valid_lft forever preferred_lft forever
inet6 fe80::42a6:b7ff:fe2b:611c/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
$ ip a sh dev e-25g-1
5: e-25g-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 40:a6:b7:2b:61:1d brd ff:ff:ff:ff:ff:ff
inet6 fe80::2/64 scope link nodad
valid_lft forever preferred_lft forever
inet6 fe80::42a6:b7ff:fe2b:611d/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
$ ip ro sh default
default proto bird src 85.119.80.32 metric 500
nexthop via inet6 fe80::1 dev e-25g-0 weight 1
nexthop via inet6 fe80::1 dev e-25g-1 weight 1
$ ip -6 ro sh default
default proto bird src 2a0a:1100:f20:: metric 500 pref medium
nexthop via fe80::1 dev e-25g-0 weight 1
nexthop via fe80::1 dev e-25g-1 weight 1

The test program attached shows that g_network_monitor_can_reach()
thinks that this system can't reach 8.8.8.8, yet I can use other
applications to reach that IP with no issue.

$ ./can_reach
Error checking network connectivity: Host unreachable

Thanks,
Andy

#include <glib.h>
#include <gio/gio.h>
#include <stdio.h>

int main(int argc, char *argv[]) {
GError *error = NULL;
GNetworkMonitor *monitor;
GSocketConnectable *connectable;
gboolean can_reach;

// Create a network monitor instance
monitor = g_network_monitor_get_default();

// Create a connectable for a test address (Google's DNS)
connectable = g_network_address_new("8.8.8.8", 53);

// Check if we can reach the address
can_reach = g_network_monitor_can_reach(monitor,
connectable,
NULL, // no cancellable
&error);

if (error != NULL) {
printf("Error checking network connectivity: %s\n", error->message);
g_error_free(error);
g_object_unref(connectable);
return 1;
}

printf("Can reach 8.8.8.8:53: %s\n", can_reach ? "YES" : "NO");

// Cleanup
g_object_unref(connectable);

return 0;
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dear GLib maintainers,

Sorry, it seems I made a bit of a mess of that last message. Here it is
again.

On this install of Debian 13 g_network_monitor_can_reach() is returning unreachable even though the machine's network is as far as I am aware
fully working.

This system is now in test deployment and up until I tried to make fwupd
work, every other aspect of it was seen to be working correctly. It was
only when finding that fwupd wouldn't download its metadata database due
to believing that it had no network access that I have begun to look in
to this. It was suggested by the fwupd maintainer that g_network_monitor_can_reach() is the thing returning the error.

Are you able to help me find out why this function is deciding this?

The test program attached shows that g_network_monitor_can_reach()
thinks that this system can't reach 8.8.8.8, yet I can use other
applications to reach that IP with no issue.

$ ./can_reach
Error checking network connectivity: Host unreachable

This is a server system with network statically configured by ifupdown.
Its network configuration is slightly out of the ordinary however, in
that it has two network interfaces with only IPv6 link-local addresses
on them, and some global scope addresses on the loopback interface.

The system talks BGP over its main interfaces and learns default routes
from the BIRD BGP daemon.

This is a valid network configuration since even if BGP were not in the picture, it could be talking to its default gateway router over one of
the link-local addresses and still be fully functional as an Internet
host. I recognise however that this kind of setup is probably rare so
this may be the area in which the problem lies.

$ ip a sh dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 85.119.80.32/32 brd 85.119.80.32 scope global lo:0
valid_lft forever preferred_lft forever
inet6 2a0a:1100:f20::/128 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
$ ip a sh dev e-25g-0
4: e-25g-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 40:a6:b7:2b:61:1c brd ff:ff:ff:ff:ff:ff
inet6 fe80::2/64 scope link nodad
valid_lft forever preferred_lft forever
inet6 fe80::42a6:b7ff:fe2b:611c/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
$ ip a sh dev e-25g-1
5: e-25g-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 40:a6:b7:2b:61:1d brd ff:ff:ff:ff:ff:ff
inet6 fe80::2/64 scope link nodad
valid_lft forever preferred_lft forever
inet6 fe80::42a6:b7ff:fe2b:611d/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
$ ip ro sh default
default proto bird src 85.119.80.32 metric 500
nexthop via inet6 fe80::1 dev e-25g-0 weight 1
nexthop via inet6 fe80::1 dev e-25g-1 weight 1
$ ip -6 ro sh default
default proto bird src 2a0a:1100:f20:: metric 500 pref medium
nexthop via fe80::1 dev e-25g-0 weight 1
nexthop via fe80::1 dev e-25g-1 weight 1

Thanks,
Andy

#include <glib.h>
#include <gio/gio.h>
#include <stdio.h>

int main(int argc, char *argv[]) {
GError *error = NULL;
GNetworkMonitor *monitor;
GSocketConnectable *connectable;
gboolean can_reach;

// Create a network monitor instance
monitor = g_network_monitor_get_default();

// Create a connectable for a test address (Google's DNS)
connectable = g_network_address_new("8.8.8.8", 53);

// Check if we can reach the address
can_reach = g_network_monitor_can_reach(monitor,
connectable,
NULL, // no cancellable
&error);

if (error != NULL) {
printf("Error checking network connectivity: %s\n", error->message);
g_error_free(error);
g_object_unref(connectable);
return 1;
}

printf("Can reach 8.8.8.8:53: %s\n", can_reach ? "YES" : "NO");

// Cleanup
g_object_unref(connectable);

return 0;
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Control: retitle -1 glib2.0: g_network_monitor_can_reach() returns unreachable on a BGP router
Control: reassign -1 src:glib2.0 2.84.3-1
Control: affects -1 fwupd
Control: tags -1 + upstream

On Mon, 21 Jul 2025 at 23:46:48 +0000, Andy Smith wrote:

On this install of Debian 13 g_network_monitor_can_reach() is returning >unreachable even though the machine's network is as far as I am aware
fully working.

g_network_monitor_can_reach() uses a plugin API (GNetworkMonitor
plugins) so there are several implementations floating around, and they
are not necessarily even in-tree. However...

This is a server system with network statically configured by ifupdown.

I assume you are not also running NetworkManager on this system, and
have not taken any particular steps to install extra GNetworkMonitor
plugins?

If you have not, then I believe the implementation in use should be gio/gnetworkmonitornetlink.c and its parent class
gio/gnetworkmonitorbase.c, in the glib2.0 source package.

The algorithm seems to be to iterate through a list of network routes discovered by querying the kernel via netlink, each of which has a
netmask, and return success if the target address is inside the netmask
of any of the given networks.

Inserting some debug messages into the implementation of
GNetworkMonitorNetlink would probably be helpful. If you run a
GLib-using program like fwupd with G_MESSAGES_DEBUG=all in the
environment, then calls to the g_debug() macro (which behaves similarly
to printf) will result in it producing log messages, usually on stdout
or stderr.

$ ip ro sh default
default proto bird src 85.119.80.32 metric 500
nexthop via inet6 fe80::1 dev e-25g-0 weight 1
nexthop via inet6 fe80::1 dev e-25g-1 weight 1
$ ip -6 ro sh default
default proto bird src 2a0a:1100:f20:: metric 500 pref medium
nexthop via fe80::1 dev e-25g-0 weight 1
nexthop via fe80::1 dev e-25g-1 weight 1

Assuming that's an abbreviation of "ip route show", I would have
expceted that this would be reported to GNetworkMonitorNetlink as the lo interface having (among other things) a route to either 85.119.80.32/0
or 0.0.0.0/0, which trivially includes 8.8.8.8 (and every other IPv4
address).

However, it looks like GNetworkMonitorNetlink expects any valid route to
have either a destination (RTA_DST, for directly-accessible local LANs),
a gateway (RTA_GATEWAY, for network clients that forward all traffic via
a gateway on the local LAN), or whatever RTA_OIF is (I have no idea).
Perhaps your default route via BIRD/BGP is not any of these, because it
is doing more complicated routing than the developers of GLib were aware
of?

GLib is really designed with endpoint client systems in mind, and
secondarily endpoint servers, rather than network routers: it seems
unlikely that anyone has really tested this on a fully-featured BGP
router.

I think this would likely go better if you can talk directly to upstream
via https://gitlab.gnome.org/GNOME/glib/-/issues/ - I am unlikely to be
able to add value to that conversation, since I am not an expert on
network routing or netlink. I don't think any of the other GLib
maintainers within Debian are, either.

This system is now in test deployment and up until I tried to make fwupd >work, every other aspect of it was seen to be working correctly. It was
only when finding that fwupd wouldn't download its metadata database due
to believing that it had no network access that I have begun to look in
to this. It was suggested by the fwupd maintainer that >g_network_monitor_can_reach() is the thing returning the error.

I'm a little surprised that there is no dummy plugin hard-coded to
report "I am online, all addresses are reachable" that you could force
via the GIO_USE_NETWORK_MONITOR environment variable, but that doesn't
seem to be something that is available for this particular extension
point. That might be a reasonable feature request for GLib upstream,
even if it's marked as lower priority than the netlink plugin and
therefore only used if explicitly requested.

A configuration option in fwupd.conf(5) to ignore network reachability
and try to download firmware regardless might also be a reasonable
upstream feature request for fwupd. It documents IgnorePower and IgnoreRequirements, but there doesn't seem to be an option like IgnoreNetworkMonitor.

This is a valid network configuration since even if BGP were not in the >picture, it could be talking to its default gateway router over one of
the link-local addresses and still be fully functional as an Internet
host.

Those link-local addresses are IPv6-only, though, so how would you contact
an IPv4 address like 8.8.8.8 that way? Even if the link-local addresses
have a default route to the entire IPv6 internet, that isn't going to
cover the IPv4 internet.

I don't see any sign of a default gateway router among the ip(8) output
you quoted - I think you would have to run "ip -4 route list" to show
the presence or absence of a default gateway (and if I understand
correctly, "ip -4 route list" is implemented in terms of netlink
requests similar to the one GLib is doing).

GLib will have been designed with a typical endpoint client system in
mind, where there is a default gateway that is some router on the local
LAN, a direct route to the local LAN, and a loopback interface:

default via 192.168.1.1 dev eth0 ...
127.0.0.0/8 dev lo ...
192.168.1.123/24 dev eth0 ...

plus maybe some extra routes for link-local routing, VPNs, virtual
machines and so on. Anything not fitting that model is unlikely to have
been tested.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Simon,

On Tue, Jul 22, 2025 at 12:55:31PM +0100, Simon McVittie wrote:

On Mon, 21 Jul 2025 at 23:46:48 +0000, Andy Smith wrote:

This is a server system with network statically configured by ifupdown.

I assume you are not also running NetworkManager on this system, and have
not taken any particular steps to install extra GNetworkMonitor plugins?

That's correct, there is no NetworkManager here. ifupdown is configured
to bring up interfaces e-25g-0 and e-25g-1 with static link-local
addresses, as well as some global scope addresses on interface lo. The
BIRD software then establishes BGP sessions which provide two default
routes.

I think this would likely go better if you can talk directly to upstream via https://gitlab.gnome.org/GNOME/glib/-/issues/ - I am unlikely to be able to add value to that conversation, since I am not an expert on network routing or netlink. I don't think any of the other GLib maintainers within Debian are, either.

Fair enough, I will give that a try.

This is a valid network configuration since even if BGP were not in the picture, it could be talking to its default gateway router over one of
the link-local addresses and still be fully functional as an Internet
host.

Those link-local addresses are IPv6-only, though, so how would you contact
an IPv4 address like 8.8.8.8 that way? Even if the link-local addresses have a default route to the entire IPv6 internet, that isn't going to cover the IPv4 internet.

Linux has supported an IPv6 next-hop for IPv4 for quite a while now. So
again, taking BGP out of the picture you could on a Debian host type
something like:

# ip address add 192.168.1.1/32 dev eth0
# ip -4 route add default via inet6 fe80::1 src 192.168.1.1

and assuming that fe80::1 was an address available on the network that
eth0 is connected to, that would work to direct all IPv4 traffic through
it.

However, last time I looked it was not possible to configure that in
typical distribution-level network configuration frameworks like
NetworkManager or systemd-networkd. In ifupdown you'd have to do it by
calling "ip" commands directly in hooks.

I've also seen other software that is very confused by the fact that the
IPv4 Internet is reachable (only) through an IPv6 address.

Maybe that is what is going on here.

I appreciate how this would be a bit outside of the norm for a desktop
setup, though if it is that then I think it's still a bug worth
reporting because IPv6-only networks are a thing that should be
supported, and will be seen sooner by those with mobile devices.

Of course, my goal here is to get firmware updates for which fwupd is
really my only option aside from hunting the updates down manually.

I don't see any sign of a default gateway router among the ip(8) output you quoted - I think you would have to run "ip -4 route list" to show the presence or absence of a default gateway (and if I understand correctly, "ip -4 route list" is implemented in terms of netlink requests similar to the
one GLib is doing).

$ ip -4 route list | grep -A2 default
default proto bird src 85.119.80.32 metric 500
nexthop via inet6 fe80::1 dev e-25g-0 weight 1
nexthop via inet6 fe80::1 dev e-25g-1 weight 1

I note that cdn.fwupd.org does have an IPv6 address as well, yet g_network_monitor_can_reach() on this host also fails for that.

Thanks,
Andy

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)