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

[Vincent Lefevre <vincent vinc17 net>]

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.

> Looking at dhcp-int-failure.pcap, there is an offer from 140.77.1.11:
>
>   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)
>     140.77.1.11.67 > 140.77.13.17.68: BOOTP/DHCP, Reply, length 324, hops 1, xid 0xff001675, secs 2, Flags 
> [none]
>         Your-IP 140.77.13.17
>         Server-IP 140.77.14.50
>         Gateway-IP 140.77.12.1
>         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 140.77.1.11:
>
>   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)
>     0.0.0.0.68 > 255.255.255.255.67: 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: 140.77.1.11
>           Requested-IP Option 50, length 4: 140.77.13.17
>           Hostname Option 12, length 7: "cventin"
>
> 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:
>
>   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)
>     10.0.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0xff001675, secs 2, Flags 
> [Broadcast]
>         Server-IP 10.0.1.1
>         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: 10.0.1.1
>           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: <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)