After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 704610 - let GNetworkMonitor be more flexible with routes
let GNetworkMonitor be more flexible with routes
Status: RESOLVED DUPLICATE of bug 701609
Product: glib
Classification: Platform
Component: gio
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2013-07-20 15:53 UTC by Jonh Wendell
Modified: 2013-07-20 15:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jonh Wendell 2013-07-20 15:53:31 UTC
In my case, I'm under VPN and the default route has no explicitly address, but a network interface:

jwendell:~$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 vpn0
10.x.x.0        0.0.0.0         255.255.252.0   U     0      0        0 vpn0
x.y.z.k         192.168.0.1     255.255.255.255 UGH   0      0        0 wlp3s0
192.168.0.0     0.0.0.0         255.255.255.0   U     9      0        0 wlp3s0
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

Here, x.y.z.k is the main address of the vpn (the other peer), and it must go through my physical network interface wlp3s0, with the gateway 192.168.0.1.

Currently GNetworkMonitor only cares about destinations, and g_network_monitor_get_network_available() always returns FALSE.

In this patch I'm turning it more flexible: it checks if there's a gateway set; if yes, then we assume we have connectivity, by using the address 0.0.0.0/0 and making g_network_monitor_base_add_network() happy.
Comment 1 Jonh Wendell 2013-07-20 15:56:32 UTC

*** This bug has been marked as a duplicate of bug 701609 ***