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

Bug#953149: udhcp needs "dev" option for setting up "onlink" default route



Hi Knut,

voxspox <voxspox@gmx.net> (2020-03-05):
> Package: debian-installer
> Version: 20190702+deb10u3
> 
> 
> What I did:
> 
> Booting from a Debian 10 Install-CD in a virtual environment (IaaS). I
> hope the package version above is correct.

If you used a 10.3 image, that looks good.

> Investigations:
> 
> DHCP configuration is done via udhcpc. It calls a script
> /etc/udhcpc/default.script
> The script terminates with "ip: RTNETLINK answers: No such device" in
> line 73
> 
> 
> How to Fix:
> 
> The netmask given to the script is 32. Thus, the "onlink" variable is
> set. It seems that udhcpc needs a "dev" option for this case.
> 
> Thus, I extended line 73 in /etc/udhcpc/default.script to:
> 
> ip -4 route add default via "$r" $online dev "$interface"

I suppose that'd be this instead (“$online” vs. “$onlink”):

> ip -4 route add default via "$r" $onlink dev "$interface"

;)

> If I modify the script in the very beginning of the installation, the
> network setup phase runs smooth with no interaction and I get to
> "enter hostname" directly.

Could you please perform an extra check for us?

What happens if you change this instead:

    --- a/debian/tree/busybox-udeb/etc/udhcpc/default.script
    +++ b/debian/tree/busybox-udeb/etc/udhcpc/default.script
    @@ -68,7 +68,7 @@ case "$1" in
     
                    # special case for /32 subnets, use onlink when adding routes
                    [ ".$subnet" = .255.255.255.255 ] \
    -                        && onlink=onlink || onlink=
    +                        && onlink="onlink dev $interface" || onlink=
                    for r in "$router"; do
                            ip -4 route add default via "$r" $onlink
                    done

(The path is taken from the git source tree, please modify the same
file you've toyed with.)

That would make the change more mergeable (as it would be limited to
cases where we indeed have a /32) than the quick fix you've tested
successfully, which would only be valid for such /32 cases, I think?

(You can safely pretend I'm not used to that particular option.)


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature


Reply to: