Bug 4604

Summary: debian stable busybox udhcp client does not support /32 netmasks
Product: Busybox Reporter: Conrad Wood <cnw>
Component: NetworkingAssignee: unassigned
Status: RESOLVED FIXED    
Severity: normal CC: busybox-cvs
Priority: P5    
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Host: Target:
Build:

Description Conrad Wood 2011-12-14 12:24:44 UTC
the subject says it all ;-)
debian stable busybox udhcp client does not support /32 netmasks. Changing the netmask to <32 works.
Debian boots with busybox udhcp and the DHCP configuration fails.
Once Debian is booted and running with the isc dhclient, the configuration works ok.
Comment 1 Michael Tokarev 2012-04-05 11:24:57 UTC
This is http://bugs.debian.org/652573 .
Comment 2 Michael Tokarev 2012-06-05 16:11:46 UTC
After quite some digging it appears the issue is in ip addr implementation, which does not allow /32 netmask.
Comment 3 Michael Tokarev 2012-06-05 16:38:52 UTC
Please excuse me for the noize. -Etoomuchwork today.  This was completely wrong change... And the problem might be debian-specific after all, but generic enough so can affect all users.  I'll post a followup here if/when I'll able to diagnose it further.
Comment 4 Michael Tokarev 2012-07-06 08:36:15 UTC
The problem here is more, well, complex.

With /32 netmask, any routes will be outside the "host network", since it includes only one host address and nothing more.  So any routes has to be handled in a special, two-step, way: first adding a route to the router itself, and second adding the regular route using that router.  Or, with modern iproute command, one-step using "onlink" attribute.

Original issue was in debian udhcpc script, which does not handle such complexity.  Busybox code does the right thing, it merely passes all the info to the script for further processing.

So I'm not sure what to do with this bugreport now: the busybox code is correct, but the issue is tricky enough to hit other users too, who implements the script, and cloud environments (where this issue is most likely to happen) becomes more and more popular and widespread to affect more users, so this buugreport should at least be visible somehow.  Maybe adding some notes to examples/udhcp/simple.script will do the trick?

Thanks,

/mjt
Comment 5 Michael Tokarev 2014-08-07 06:46:26 UTC
I fixed this bug in debian finally.  It required 2 components:

1) the "onlink" keyword patch for ip route, and
2) the fix for udhcpc default.script to use this keyword when the netmask is all-ones.

Other my attempts to fix this, by adding host routes to the gateway first, failed, because there's no easy way to reset routes on renew if something is changed, at least not without keeping a state information somewhere.

I also special-cased the /32 subnet there, -- onlink keyword can be used unconditionally, but since it is a rarely-used feature, I don't know what extra surprizes it can give us.
Comment 6 Denys Vlasenko 2017-04-05 22:55:31 UTC
Fixed in git:

commit 1a1143907c84308781e23f07d0c6c597bfd13abb
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Mon Jul 28 10:05:41 2014 +0400

    iproute: support onelink route option and print route flags

commit 9c192e7f946a351c811e2278bbf56b4dc6a4b663
Author: Denys Vlasenko <vda.linux@googlemail.com>
Date:   Thu Apr 6 00:53:43 2017 +0200

    examples: make udhcpc script handle /32 netmasks