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
