Hi Daniel,
>I think what's happening is that dhcpcd's default is to wait for "any
>IP address to be assigned" meaning that in a network with IPv6 SLAAC
>it's going to return with only a v6 address assigned as that's almost
>always way faster than legacy DHCP which may not be what you're
>expecting.
interesting, but also entirely unexpected: the kernel does SLAAC
(rtsol, from the rtadvd running on the same network), whereas the
DHCP client does DHCPv4 only (or also DHCPv6 if configured and
available, neither of which is true for my setup).
At least that’s what I’d expect from my /etc/network/interfaces
and how things on previous releases work.
I wouldn’t mind having to specify more things there now, so for
example the not assigning the Microsoft addresses in the absence
of a DHCP server would also best be available there, and if it is
too tricky to do the DHCPv4-only/v4+v6/v6-only dance with the old
/etc/network/interfaces two stanzas approach, that could also be
an option.
But my user story here is, I just want the DHCP client to do a
DHCPv4 and return afterwards, like it used to, and ideally not
having to touch any other file than /e/n/i, especially not a
conffile… we got so far to make it possible to do WPA (even WPA
Enterprise) WLAN with just /e/n/i config, so mere DHCP ought to
work that way as well.
>I'm working on a patch for the dhcpcd<>ifupdown integration that will
>fix this.
Thanks for caring. I’ll be available for testing that (on a trixie
setup so with extra effort), if needed.
bye,
//mirabilos
--
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec
