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
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.
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.
Hi Mario, 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
Hi Mario, 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
A simple C app that uses just that symbol and prints the output is probably the way to go. Yeah glib2.0 is the source package iirc.
A simple C app that uses just that symbol and prints the output is probably the way to go. Yeah glib2.0 is the source package iirc.
retitle -1 g_network_monitor_can_reach() returns unreachable on system with fully working network
reassign -1 glib2.0 2.84.3-1
thanks
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
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
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
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...
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.
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.
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.
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
Hi Simon,
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.
Fair enough, I will give that a try.
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.
$ 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
Hi, Just to note that the recent fwupd 2.0.14 release added a feature to ignore network reachability detection by means of setting the environment variable FWUPD_IGNORE_NETWORK_REACHABLE. This package is now available in sid. I added an override to the fwupd.service file like: [Service] Environment="FWUPD_IGNORE_NETWORK_REACHABLE=1" and restarted it, After this, issuing # fwupdmgr refresh still failed with a message about there being a network reachability problem. However, # FWUPD_IGNORE_NETWORK_REACHABLE=1 fwupdmgr refresh *did* work. I remain unsure if both programs require to run with this environment, but that functionality *does* now seem to be present in the fwupd package. Thanks, Andy