# 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?

----------

## mike155

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

----------

## custom82

 *mike155 wrote:*   

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

 

I opened that issue

----------

## rnbw

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

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

-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

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:

```
Jun  2 11:20:26 main dhcpd: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via eth1

Jun  2 11:20:27 main dhcpd: DHCPOFFER on 192.168.0.170 to aa:bb:cc:dd:ee:ff via eth1

Jun  2 11:20:28 main dhcpd: DHCPREQUEST for 192.168.0.170 (192.168.0.1) from aa:bb:cc:dd:ee:ff via eth1

Jun  2 11:20:28 main dhcpd: DHCPACK on 192.168.0.170 to aa:bb:cc:dd:ee:ff via eth1
```

Not working:

```
Jun  2 15:58:55 main dhcpd: DHCPDISCOVER from 00:11:22:33:44:55 via eth1

Jun  2 15:58:55 main dhcpd: DHCPOFFER on 192.168.0.189 to 00:11:22:33:44:55 via eth1

Jun  2 15:58:57 main dhcpd: DHCPDISCOVER from 00:11:22:33:44:55 via eth1

Jun  2 15:58:57 main dhcpd: DHCPOFFER on 192.168.0.189 to 00:11:22:33:44:55 via eth1

Jun  2 15:59:00 main dhcpd: DHCPDISCOVER from 00:11:22:33:44:55 via eth1

Jun  2 15:59:00 main dhcpd: DHCPOFFER on 192.168.0.189 to 00:11:22:33:44:55 via eth1

Jun  2 15:59:04 main dhcpd: DHCPDISCOVER from 00:11:22:33:44:55 via eth1
```

dhcpd was restarted two times because of upgrade:

```
Jun  2 11:45:10 main dhcpd: Internet Systems Consortium DHCP Server 4.4.2 Gentoo-r3

Jun  2 15:38:34 main dhcpd: Internet Systems Consortium DHCP Server 4.4.2 Gentoo-r3
```

The first restart was because of glibc upgrade (glibc-2.32-r7 -> glibc-2.33).

The second one was because dhcpd itself was rebuilt.

Unfortunately, sysklogd was restarted on 11:45:45 and this probably killed logging from dhcpd until the second dhcpd restart.

Looks like glibc broke it.

----------

## Hu

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.

----------

