Description of problem: There is a problem running an EL6 KVM host with dhcp server and an EL5 KVM guest using dhclient. Version-Release number of selected component (if applicable): dhclient-3.0.5-33.el5_9 (on EL5 guest) dhcp-4.1.1-34.P1.el6 (on EL6 host) How reproducible: Always Steps to Reproduce: 1. run dhcpd on EL6 KVM host 2. run dhclient on EL5 KVM guest 3. wait until dhclient does DHCPREQUEST Actual results: dhclient repeats the DHCPREQUEST endlessly because of "bad udp checksums" until the lease times out and then it renews it. Expected results: Bad udp checksums should not happen. Additional info: The logs show like this: EL6 KVM host: Jul 7 03:56:02 el6 dhcpd: DHCPREQUEST for 192.168.10.12 from 52:54:00:dd:04:5a via eth0 Jul 7 03:56:02 el6 dhcpd: DHCPACK on 192.168.10.12 to 52:54:00:dd:04:5a via eth0 Jul 7 03:56:12 el6 dhcpd: DHCPREQUEST for 192.168.10.12 from 52:54:00:dd:04:5a via eth0 Jul 7 03:56:12 el6 dhcpd: DHCPACK on 192.168.10.12 to 52:54:00:dd:04:5a via eth0 Jul 7 03:56:25 el6 dhcpd: DHCPREQUEST for 192.168.10.12 from 52:54:00:dd:04:5a via eth0 Jul 7 03:56:25 el6 dhcpd: DHCPACK on 192.168.10.12 to 52:54:00:dd:04:5a via eth0 Jul 7 03:56:40 el6 dhcpd: DHCPREQUEST for 192.168.10.12 from 52:54:00:dd:04:5a via eth0 Jul 7 03:56:40 el6 dhcpd: DHCPACK on 192.168.10.12 to 52:54:00:dd:04:5a via eth0 Jul 7 03:57:00 el6 dhcpd: DHCPREQUEST for 192.168.10.12 from 52:54:00:dd:04:5a via eth0 Jul 7 03:57:00 el6 dhcpd: DHCPACK on 192.168.10.12 to 52:54:00:dd:04:5a via eth0 EL5 KVM guest: Jul 7 03:56:02 el5 dhclient: DHCPREQUEST on eth0 to 192.168.10.10 port 67 (xid=0x58f8333b) Jul 7 03:56:40 el5 last message repeated 3 times Jul 7 03:57:00 el5 dhclient: DHCPREQUEST on eth0 to 192.168.10.10 port 67 (xid=0x58f8333b) Jul 7 03:57:00 el5 dhclient: 5 bad udp checksums in 5 packets There is a "xen partial checksums patch" in the dhclient rpm which I expected to fix this, but it does not. I get access denied to the BZs in question (#221964 and #219681) so I don't know what exactly the patch is about. This hack on the EL6 host makes it work but I guess the EL5 dhclient should be fixed instead: iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM --checksum-fill Regards, Simon
(In reply to Simon Matter from comment #0) > There is a "xen partial checksums patch" in the dhclient rpm which I > expected to fix this, but it does not. Yes, that patch has been there to work-around this problem.
(In reply to Simon Matter from comment #0) > I get access denied to the BZs in > question (#221964 and #219681) so I don't know what exactly the patch is about. Yes, they're marked private, sorry. You can also take a look at http://comments.gmane.org/gmane.comp.emulators.kvm.devel/65236 https://lists.isc.org/pipermail/dhcp-hackers/2010-April/001835.html
But, why do I see the problem above even with the patch in the EL5 package? And I'm not alone, a quick google search shows that others have the same problem.
Here is a report of exactly the same issue on CentOS 5. I think that's the same because it also happens with other distributions like older Debian. http://lists.centos.org/pipermail/centos/2013-February/132080.html
(In reply to Simon Matter from comment #3) > But, why do I see the problem above even with the patch in the EL5 package? No idea, really, this needs more investigation.
Additional info: The host where the problem shows up has not firewall rules at all. I don't know why this should matter but just wanted to make clear. The interesting thing is that I have another guest where the problem doesn't seem to appear but I can't find why it should behave different. The only differences I see, despite having the same dhclient-3.0.5-33.el5_9, are: - There are some netfilter rules but they have nothing to do with dhcp or checksumming AFAIK. - The kernel is a custom kernel based on EL5 kernel-2.6.18-26x. So, if virtio_net has changed between 2.6.18-26x and current kernels, could it also cause problems?
(In reply to Simon Matter from comment #6) > So, if virtio_net has changed between 2.6.18-26x and current kernels, could > it also cause problems? Could be possible, yes.
This Bugzilla has been reviewed by Red Hat and is not planned on being addressed in Red Hat Enterprise Linux 5, and therefore will be closed. If this bug is critical to production systems, please contact your Red Hat support representative and provide sufficient business justification. Issue is already fixed in RHEL-6/7.