[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2ef3a60fc3ec47993801bdaf7486fba615072c44.camel@redhat.com>
Date: Thu, 04 May 2023 10:39:15 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Martin Wetterwald <martin@...terwald.eu>, Jakub Kicinski
<kuba@...nel.org>
Cc: davem@...emloft.net, dsahern@...nel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v2] net: ipconfig: Allow DNS to be overwritten by DHCPACK
On Thu, 2023-05-04 at 10:00 +0200, Martin Wetterwald wrote:
> Some DHCP server implementations only send the important requested DHCP
> options in the final BOOTP reply (DHCPACK).
> One example is systemd-networkd.
> However, RFC2131, in section 4.3.1 states:
>
> > The server MUST return to the client:
> > [...]
> > o Parameters requested by the client, according to the following
> > rules:
> >
> > -- IF the server has been explicitly configured with a default
> > value for the parameter, the server MUST include that value
> > in an appropriate option in the 'option' field, ELSE
>
> I've reported the issue here:
> https://github.com/systemd/systemd/issues/27471
>
> Linux PNP DHCP client implementation only takes into account the DNS
> servers received in the first BOOTP reply (DHCPOFFER).
> This usually isn't an issue as servers are required to put the same
> values in the DHCPOFFER and DHCPACK.
> However, RFC2131, in section 4.3.2 states:
>
> > Any configuration parameters in the DHCPACK message SHOULD NOT
> > conflict with those in the earlier DHCPOFFER message to which the
> > client is responding. The client SHOULD use the parameters in the
> > DHCPACK message for configuration.
>
> When making Linux PNP DHCP client (cmdline ip=dhcp) interact with
> systemd-networkd DHCP server, an interesting "protocol misunderstanding"
> happens:
> Because DNS servers were only specified in the DHCPACK and not in the
> DHCPOFFER, Linux will not catch the correct DNS servers: in the first
> BOOTP reply (DHCPOFFER), it sees that there is no DNS, and sets as
> fallback the IP of the DHCP server itself. When the second BOOTP reply
> comes (DHCPACK), it's already too late: the kernel will not overwrite
> the fallback setting it has set previously.
>
> This patch makes the kernel overwrite its fallback DNS by DNS servers
> specified in the DHCPACK if any.
As strictly speaking this looks like a change of behavior more than a
fix, I think it should land on net-next so it needs to wait for net-
next to open, see below.
There are a few issues to be addresses. The patch is mangled - context
lines are truncated to 80 bytes, corrupting the patch itself. Please
double check your setup to solve such issue.
Please specify the target tree inside the patch subj.
Please do not reply with new version of this patch inside the same
thread.
## Form letter - net-next-closed
The merge window for v6.3 has begun and therefore net-next is closed
for new drivers, features, code refactoring and optimizations.
We are currently accepting bug fixes only.
Please repost when net-next reopens after May 8th.
RFC patches sent for review only are obviously welcome at any time.
See:
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle
Cheers,
Paolo
Powered by blists - more mailing lists