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

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 or in the 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
to which the internal client replies with a request. Note the
server-id set to
The DHCP server at 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 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:

 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 on enp0s25 to port 67
 Aug 06 15:48:21 cventin dhclient[1052]: DHCPREQUEST for on enp0s25 to port 67
 Aug 06 15:48:21 cventin dhclient[1052]: DHCPNAK from
 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 port 67 interval 4
 Aug 06 15:48:21 cventin dhclient[1052]: DHCPOFFER of from
 Aug 06 15:48:21 cventin dhclient[1052]: DHCPREQUEST for on enp0s25 to port 67
 Aug 06 15:48:21 cventin dhclient[1052]: DHCPACK of from

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


Attachment: signature.asc
Description: PGP signature

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