Bug#1109667: g_network_monitor_can_reach() returns unreachable on a BGP router

[Simon McVittie]

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