[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#652573: busybox-udeb: debian stable busybox udhcp client does not support /32 netmasks

On 05.06.2012 20:41, Jens Ott - Profitbricks wrote:
> Michael
>> 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 via dev dummy0
>> ip: RTNETLINK answers: No such process
> That can't work.

Sure, because the "gateway" isn't reachable
when the netmask is /32, this is exactly what I described
(quoted below).

>  That's why my script sets the routers-variable to $ip
> when netmask is "".

And this does not work to.  I think you had a typo there.

[ "$subnet" = "" ] && routers=$ip
case "$1" in
                if [ -n "$router" ] ; then
                        for i in $router ; do
                                echo "Adding router $i"
                                route add default gw $i dev $interface metric $((metric++))

Note you're setting "routeS" while use "routeR".

This is why it should not work exactly the same way
as current busybox's version!

> 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.

Well.  In this case, the DHCP server should just set router
correctly, to be the same as client address, everything will
Just Work (tm).

This is a good piece of information, and why I asked for a
reproducer -- it didn't occur to me to use the same IP for
router and client's own ip address, even if I know it might
work exactly the way you describe by sending an ARP for everyhing.

The same can also be achieved by using not own's IP address
but all zeros, like,

 ip route add default via dev eth0

and this is even more correct, I think, this is equivalent
of not specifying "via" at all.  Again, this can be set in
the DHCP server.

I thought about a different case, when you actually specify
some non-dummy gateway, it is not this case...

So, I guess, nothing should be fixed on the busybox/debian
side, do you not agree? :)

Thank you!


>> 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 dev dummy0
>> and second is the actual default (or whatever) route going
>> via that gateway, the regular way:
>>  # busybox ip r add via
>> ("dev" is optional here, just like for the regular case).
>> Alternative is to use the keyword "onlink":
>>  # ip r add via dev dummy0 onlink
>> but this does not work with busybox (yet).

Reply to: