[Pkg-utopia-maintainers] Bug#933930: Fwd: Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works

[Vincent Lefevre]

On 2019-08-12 09:40:43 +0200, Beniamino Galvani wrote:
> On Fri, Aug 09, 2019 at 05:03:34PM +0200, Vincent Lefevre wrote:
> > On 2019-08-09 16:05:11 +0200, Beniamino Galvani wrote:
> > > in the traces I see that there are 3 servers and one of them
> > > advertises a subnet different from other two.  This setup makes the
> > > behavior non-deterministic because clients can get an address either
> > > in the 10.0.1.0/24 or in the 140.77.12.0/23 network. Do you know if
> > > the network configured in this way on purpose?
> > 
> > I think so, as there are 2 kinds of machines: those that are supposed
> > to have a fixed IP address on the main network, and the other machines,
> > which will be on a secondary network. My machine is in the former
> > class. I don't know how such machines are supposed to be identified
> > (probably with a weak identification), but I can see my machine
> > name in the DHCP Discover and DHCP Request packets.
> 
> Ok, then this mechanism is not working since your machine is receiving
> offers for both networks and randomly takes one. I don't know how
> common this setup is, but the RFC seems to warn against it:
> 
>    Once the network address and lease have been determined, the server
>    constructs a DHCPOFFER message with the offered configuration
>    parameters.  It is important for all DHCP servers to return the same
>    parameters (with the possible exception of a newly allocated network
>    address) to ensure predictable client behavior regardless of which
>    server the client selects.

For machines with a static IP address that could be proposed to the
DHCP servers, this should not be an issue. This seems possible to do
with dhclient, but I suspect that users never do that in practice,
even we know our static address (it is given by the admin). So,
indeed, I suspect that there could be an issue with this configuration
in practice.

I'll ask the admins whether this configuration is expected (I can
see an advantage that this allows machines of the former class to
switch to the alternate network when there is an issue with the
main network, but I don't think that this is a good idea anyway,
because this can make machines indefinitely unreachable after a
temporary failure with the main DHCP servers).

BTW, I can see in the logs, that I never got a DHCPNAK before July 22.
So, it seems that something has changed. But I think that no-one
except me noticed, because I'm probably the first one to have upgraded
to the new NetworkManager versions.

> > It seems that RFC 2131 has some contradictions in case of several
> > DHCP servers on several networks. IMHO, the client should be
> > tolerant and ignore DHCPNAK if the server-id is different.
> 
> I checked again and the internal client doesn't do any filtering based
> on the server-id. In the dhclient log at:
> 
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933930#42
[...]
> the transaction succeeds because the ACK comes before any NAK, which
> is the same thing it happens when the transaction succeeds with the
> internal client. Perhaps could you capture other logs with dhclient
> too see how it handles multiple NAK?

Please look at the capture I had sent at

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933930#74

i.e.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=933930;filename=dhcp-dhclient.pcap;msg=74

The NAK comes first.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)