On Fri, Aug 09, 2019 at 01:10:55PM +0200, Vincent Lefevre wrote:
On 2019-08-09 09:42:10 +0200, Beniamino Galvani wrote:On Thu, Aug 08, 2019 at 06:07:41PM +0200, Vincent Lefevre wrote:...Could you capture DHCP packets with: tcpdump -i enp0s25 -s 0 -w dhcp.pcap udp port 67 or port 68 when using dhclient and the failing internal client, and attach the files?dhcp-dhclient.pcap - using dhclient (success, though NAK came first) dhcp-int-failure.pcap - using the internal client (failures until I stopped the capture; ACK never came first) dhcp-int-success.pcap - using the internal client (success after several requests, once ACK came first)
Hi,
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?
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"
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.
Beniamino
Attachment:
signature.asc
Description: PGP signature