Bug#652573: busybox-udeb: debian stable busybox udhcp client does not support /32 netmasks
Michael
On 05.06.2012 18:36, Michael Tokarev wrote:
> On 05.06.2012 20:10, Michael Tokarev wrote:
> []
>> It is not udhcpc, and not the udhcpc script either. It is busybox's
>> `ip' utility.
>>
>> # busybox ip -4 add 192.168.77.10/32 dev dummy0
>> ip: invalid argument '192.168.77.10/32' to 'ip'
>
> And this is, ofcourse, a typo... I forgot to use `addr'.
>
>> # busybox ip -4 add 192.168.77.10/31 dev dummy0
>
> And this one I actually didn't run at all, hitting CtrlC
> instead of Enter!
>
> That's what happens when you do things when you're too
> tired... :( Please excuse me for the noize. Digging
> further, and I'll update the bugreports accordingly
> (will restore it all back if I wont be able to find
> the issue).
>
> For now I see another _possible_ issue, which needs
> to be verified in d-i: this is the place which adds
> routes. Neither debian default.script nor your script
> is able to add routes:
>
> # busybox ip r add 10.255.0.0/28 via 192.168.77.11 dev dummy0
> ip: RTNETLINK answers: No such process
That can't work. That's why my script sets the routers-variable to $ip
when netmask is "255.255.255.255".
Somewhere in ARP-RFC it is defined that a router shall respond to
WHO-HAS requests where requester and sender is the same address. So you
actually set default-route to the assigned IP on /32-Assignments.
>
> The same happens when using route(8) utility. For this
> to work, two routes should be added: first to the gateway
> host, without the "via" part:
>
> # busybox ip r add 192.168.77.11 dev dummy0
>
> and second is the actual default (or whatever) route going
> via that gateway, the regular way:
>
> # busybox ip r add 10.255.0.0/28 via 192.168.77.11
>
> ("dev" is optional here, just like for the regular case).
>
> Alternative is to use the keyword "onlink":
>
> # ip r add 10.255.0.0/28 via 192.168.77.11 dev dummy0 onlink
>
> but this does not work with busybox (yet).
>
> I think this /32 case is worth to handle specially, using the
> onlink or two route entries.
>
> But I'm not sure this is the actual case the regular bug is
> about: for the route to work with netmask != /32, the gateway
> must be within the netmask, so if you specify, eg, 1.1.1.1/31
> for the client, the router must be 1.1.1.0.
>
> Does it look real?
>
> But again, please note that the script provided by Jens should
> fail exactly the same way! So... I guess it is not the issue... :(
>
> Thank you for patience!
>
> /mjt
BR
Jens
Reply to: