Seen in a Google Compute Engine environment with a machine configured via cloud-init-dhcp, while testing Podman integration for pasta: the assigned address has a /32 netmask, and there's a default route, which can be added on the host because there's another route, also /32, pointing to the default gateway. This is not a valid configuration as far as I can tell: if the address is configured as /32, it shouldn't be used to reach a gateway outside its derived netmask. However, Linux allows that, and everything works. The problem comes when pasta --config-net sources address and default route from the host, and it can't configure the route in the target namespace because the gateway is invalid. Sourcing more routes than just the default is doable, but probably undesirable: pasta users want to provide connectivity to a container, not reflect exactly whatever trickery is configured on the host. Add a consistency check: if the configured default gateway is not reachable, shrink the given netmask until we can reach it. Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com> --- conf.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/conf.c b/conf.c index 90214f5..5b88547 100644 --- a/conf.c +++ b/conf.c @@ -562,6 +562,10 @@ static unsigned int conf_ip4(unsigned int ifi, ip4->mask = 0xffffffff; } + /* Mask consistency check: ensure we can reach the default gateway */ + while ((ip4->addr & ip4->mask) != (ip4->gw & ip4->mask)) + ip4->mask = htonl(ntohl(ip4->mask) << 1); + memcpy(&ip4->addr_seen, &ip4->addr, sizeof(ip4->addr_seen)); if (MAC_IS_ZERO(mac)) -- 2.35.1