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

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.

Looking at dhcp-int-failure.pcap, there is an offer from

  12:29:03.690421 94:f1:28:19:08:00 > 98:90:96:bd:7f:f7, ethertype IPv4 (0x0800), length 366: (tos 0x0, ttl 
63, id 55318, offset 0, flags [DF], proto UDP (17), length 352) > BOOTP/DHCP, Reply, length 324, hops 1, xid 0xff001675, secs 2, Flags 
        Client-Ethernet-Address 98:90:96:bd:7f:f7
        file "/lpxelinux.0"[|bootp]

to which the internal client replies with a request. Note the
server-id set to

  12:29:03.690539 98:90:96:bd:7f:f7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 340: (tos 0xc0, 
ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 326) > BOOTP/DHCP, Request from 98:90:96:bd:7f:f7, length 298, xid 
0xff001675, secs 2, Flags [none]
        Client-Ethernet-Address 98:90:96:bd:7f:f7
        Vendor-rfc1048 Extensions
          Magic Cookie 0x63825363
          DHCP-Message Option 53, length 1: Request
          Client-ID Option 61, length 7: ether 98:90:96:bd:7f:f7
          Parameter-Request Option 55, length 18: 
            Subnet-Mask, Default-Gateway, Hostname, Domain-Name
            Domain-Name-Server, Time-Zone, MTU, BR
            Classless-Static-Route, Static-Route, YD, YS
            NTP, Server-ID, Option 119, Classless-Static-Route-Microsoft
            Option 252, RP
          MSZ Option 57, length 2: 576
          Server-ID Option 54, length 4:
          Requested-IP Option 50, length 4:
          Hostname Option 12, length 7: "cventin"

The DHCP server at NAKs the request even if it had a
different server-id; I don't think this is correct:

  12:29:03.691585 5c:96:9d:6d:9d:48 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, 
ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) > BOOTP/DHCP, Reply, length 300, xid 0xff001675, secs 2, Flags 
        Client-Ethernet-Address 98:90:96:bd:7f:f7
        Vendor-rfc1048 Extensions
          Magic Cookie 0x63825363
          DHCP-Message Option 53, length 1: NACK
          Server-ID Option 54, length 4:
          MSG Option 56, length 31: "requested address not available"

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?

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.

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

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