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

[Beniamino Galvani]

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.

> > Looking at dhcp-int-failure.pcap, there is an offer from 140.77.1.11:
> > [...]
> > to which the internal client replies with a request. Note the
> > server-id set to 140.77.1.11:
> > [...]
> > The DHCP server at 10.0.1.1 NAKs the request even if it had a
> > different server-id; I don't think this is correct:
> >
> > [...]
> 
> RFC 2131 says: "If a server receives a DHCPREQUEST message with an
> invalid 'requested IP address', the server SHOULD respond to the
> client with a DHCPNAK message and may choose to report the problem
> to the system administrator."
> 
> So this seems correct. Note that it does not say that the server must
> check the server-id, and the fact that it says "a server" instead of
> "the server" tends to make me think that this is how it works.
> 
> BTW, if the server implicitly needs to check the server-id, why
> doesn't the internal client do this too about the DHCPNAK response?

This part of RFC 2131 is quite clear in my opinion:

 3. The client receives one or more DHCPOFFER messages from one or more
     servers.  The client may choose to wait for multiple responses.
     The client chooses one server from which to request configuration
     parameters, based on the configuration parameters offered in the
     DHCPOFFER messages.  The client broadcasts a DHCPREQUEST message
     that MUST include the 'server identifier' option to indicate which
     server it has selected, and that MAY include other options
     specifying desired configuration values. [...]

  4. The servers receive the DHCPREQUEST broadcast from the client.
     Those servers not selected by the DHCPREQUEST message use the
     message as notification that the client has declined that server's
     offer.  The server selected in the DHCPREQUEST message commits the
     binding for the client to persistent storage and responds with a
     DHCPACK message containing the configuration parameters for the
     requesting client. [...]

So the behavior of server 10.0.1.1 seems not compliant to RFC.

> > Also, RFC 2131 says that the "If the client receives a DHCPNAK
> > message, the client restarts the configuration process", that is what
> > the internal client does, until the ACK comes before or until
> > timeout. dhclient apparently ignores the NAK, but I haven't found yet
> > in the code where this is done and based on what.
> 
> 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

 Aug 06 15:48:15 cventin NetworkManager[797]: <info>  [1565099295.6037] dhcp4 (enp0s25): dhclient started with pid 1052
 Aug 06 15:48:15 cventin dhclient[1052]: DHCPREQUEST for 140.77.13.17 on enp0s25 to 255.255.255.255 port 67
 Aug 06 15:48:21 cventin dhclient[1052]: DHCPREQUEST for 140.77.13.17 on enp0s25 to 255.255.255.255 port 67
 Aug 06 15:48:21 cventin dhclient[1052]: DHCPNAK from 10.0.1.1
 Aug 06 15:48:21 cventin NetworkManager[797]: <info>  [1565099301.7956] dhcp4 (enp0s25): state changed unknown -> expire
 Aug 06 15:48:21 cventin NetworkManager[797]: <info>  [1565099301.8037] dhcp4 (enp0s25): state changed expire -> unknown
 Aug 06 15:48:21 cventin dhclient[1052]: DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 4
 Aug 06 15:48:21 cventin dhclient[1052]: DHCPOFFER of 140.77.13.17 from 140.77.1.12
 Aug 06 15:48:21 cventin dhclient[1052]: DHCPREQUEST for 140.77.13.17 on enp0s25 to 255.255.255.255 port 67
 Aug 06 15:48:21 cventin dhclient[1052]: DHCPACK of 140.77.13.17 from 140.77.1.12

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?

Thank you

Beniamino
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-utopia-maintainers/attachments/20190812/fdb465e7/attachment-0001.sig>