| View previous topic :: View next topic |
| Author |
Message |
custom82
Tux's lil' helper
Joined: 13 Feb 2020
Posts: 76
Location: Collecorvino (PE) Italy
|
 Posted: Thu Nov 05, 2020 9:18 am Post subject: ISC DHCPD 4.4.2-r2 5 bad IP checksums seen in 5 packets |
 |
|
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 |
|
| Back to top |
|
 |
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
|
| Back to top |
|
|
custom82
Tux's lil' helper
Joined: 13 Feb 2020
Posts: 76
Location: Collecorvino (PE) Italy
|
|
| Back to top |
|
|
rnbw
n00b
Joined: 03 Jun 2021
Posts: 3
|
| Posted: Thu Jun 03, 2021 7:57 pm Post subject: |
|
|
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)? |
|
| Back to top |
|
|
rnbw
n00b
Joined: 03 Jun 2021
Posts: 3
|
| Posted: Thu Jun 03, 2021 9:00 pm Post subject: |
|
|
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? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22875
|
| Posted: Fri Jun 04, 2021 1:50 am Post subject: |
|
|
| -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? |
|
| Back to top |
|
|
rnbw
n00b
Joined: 03 Jun 2021
Posts: 3
|
| Posted: Fri Jun 04, 2021 12:01 pm Post subject: |
|
|
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:
| Code: | 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:
| Code: | 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:
| Code: | 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. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22875
|
| Posted: Fri Jun 04, 2021 4:16 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
|
Networking & Security
