ISC DHCPD 4.4.2-r2 5 bad IP checksums seen in 5 packets

custom82

this is the syslog dhcpd
Nov 4 20:05:32 thunderdome dhcpd[11327]: DHCPDISCOVER from 08:00:27:8a:48:da via br0
Nov 4 20:05:33 thunderdome dhcpd[11327]: DHCPOFFER on 192.168.178.149 to 08:00:27:8a:48:da via br0
Nov 4 20:05:46 thunderdome dhcpd[11327]: DHCPDISCOVER from 08:00:27:8a:48:da via br0
Nov 4 20:05:47 thunderdome dhcpd[11327]: DHCPOFFER on 192.168.178.150 to 08:00:27:8a:48:da via br0
Nov 4 20:07:19 thunderdome dhcpd[11327]: DHCPDISCOVER from 08:00:27:8a:48:da via br0
Nov 4 20:07:20 thunderdome dhcpd[11327]: DHCPOFFER on 192.168.178.151 to 08:00:27:8a:48:da via br0

customsrescuecd ~ # dhclient -v eth0
Internet Systems Consortium DHCP Client 4.4.2 Gentoo-r2
Copyright 2004-2020 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/08:00:27:8a:48:da
Sending on LPF/eth0/08:00:27:8a:48:da
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 16
5 bad IP checksums seen in 5 packets
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

it seems that the udp packets generated by the server despite being a physical machine have the wrong checksum!
can someone help me?
_________________
you never stop learning!
https://customrescuecd.sourceforge.io

mike155 · Posted: Thu Nov 05, 2020 8:22 pm Post subject:

Duplicate of: https://gitlab.isc.org/isc-projects/dhcp/-/issues/145

custom82 · Posted: Thu Nov 05, 2020 9:37 pm Post subject:

rnbw · n00b Joined: 03 Jun 2021 Posts: 3

I have the same problem with dhcp-4.4.2-r3. It worked fine until it suddenly broke at night. The server was receiving DHCPREQUESTs (and replying with DHCPACK) one minute and one minute later, only DHCPDISCOVERs and DHCPOFFERs.

Tcpdump and wireshark revealed that packets produced by dhcpd have wrong checksums in IP header. Same wrong chcksum value on both the client and server.

Recompiled dhcp with DEBUG_CHECKSUM enabed in includes/site.h only to find that it works... Looks like a compiler bug (gcc-10.2.0-r5)?

rnbw · n00b Joined: 03 Jun 2021 Posts: 3

Seems that -O3 with gcc-10.2.0-r5 triggers the bug. Changed CFLAGS to -O2, recompiled dhcp and it works.

One mystery remains: why did it work with -O3 until now?

Hu · Administrator Joined: 06 Mar 2007 Posts: 22876

-O3 is widely documented to enable optimizations that can break programs which do not strictly conform to the C standard. Perhaps you upgraded to a version which relies on some bit of non-conforming behavior. Your post is a bit unclear. Do you mean that a dhcp daemon that was working suddenly ceased working, without upgrading or even restarting the once-working process?

rnbw · n00b Joined: 03 Jun 2021 Posts: 3

It seemed so but looks like I misread the logs. It died the day before but nobody noticed (as clients having valid lease still worked).
Working:

Hu · Administrator Joined: 06 Mar 2007 Posts: 22876

If glibc broke it, why did rebuilding dhcpcd with a lesser optimization option fix it?

If you want to pursue this, you could try to isolate what part of dhcpcd is compiled to the bad version under -O3. Once the affected code is identified, it can be analyzed to fix the problem.