<HTML><HEAD>
<META content="text/html; charset=utf-8" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19088"></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Hi Yoshihiro,</DIV>
<DIV> </DIV>
<DIV>When the transmitted checksum in the UDP header is all zeros, then UDP checksumming has not been done by the transmitter.</DIV>
<DIV> </DIV>
<DIV>When the transmitted checksum in the UDP header is all ones, then UDP checksumming has been done by the transmitter and the calculated checksum is all zeros.</DIV>
<DIV> </DIV>
<DIV>If the UDP checksum has been miscalculated by the transmitter or changed by a device in between the transmitter and the receiver, then the receiver will appropriately discard the packet, because of the incorrect checksum.</DIV>
<DIV> </DIV>
<DIV>Apparently your trace analysis tool can also verify the UDP checksum, so that you can check if it was correct or not, but it seems that checksum validation was disabled with your trace analysis tool when you saved the concerning packet to a text formatted file.</DIV>
<DIV> </DIV>
<DIV>In case of UDP/TCP/IP checksum issues at the transmitter or receiver side, you may want to try disabling checksum offload with the driver of the network interface controller. Please read the documentation of the LAN driver on the given platform for information about checksum offloading.</DIV>
<DIV> </DIV>
<DIV>For example, I am using a tg3 driver on Linux and I can use 'ethtool -k eth0' to see the supported offload parameters and use 'ethtool -K eth0 tx off rx off' to disable transmit and receive checksum offload.</DIV>
<DIV> </DIV>
<DIV>Thanks, good luck and kind regards,</DIV>
<DIV> </DIV>
<DIV>Fons<BR><BR>>>> Yoshihiro takahashi <yoshihiro.takahashi@miraclelinux.com> 8/24/2011 9:54 AM >>><BR>Hi.<BR><BR>dhcpd will discard DHCP request when checksum value of packet is 0xffff.<BR>0xffff for checksum value is equivalent to 0x0000.<BR>In 0xffff case, is the packet treated as error?<BR><BR>RFC768<BR>------<BR>If the computed checksum is zero, it is transmitted as all ones<BR>------<BR><BR>dhcp-discover did not work when checksum of packet is 0xffff.<BR>----<BR>52 0.853890 172.18.76.162 172.18.76.161DHCP DHCP Request - Transaction ID 0x2862<BR>Frame 52 (1514 bytes on wire, 1514 bytes captured)<BR>Ethernet II, Src: ********* (00:40:66:43:99:b2), Dst: ******** (00:07:32:16:47:b0)<BR>Internet Protocol, Src: 172.18.76.162 (172.18.76.162), Dst: 172.18.76.161 (172.18.76.161)<BR>User Datagram Protocol, Src Port: bootps (67), Dst Port: bootps (67)<BR> Source port: bootps (67)<BR> Destination port: bootps (67)<BR> Length: 1480<BR> Checksum: 0xffff [validation disabled]<BR>Bootstrap Protocol<BR>----<BR><BR><BR>Best regards,<BR><BR>diff -aurp dhcp-4.2.2.orig/common/packet.c dhcp-4.2.2/common/packet.c<BR>--- dhcp-4.2.2.orig/common/packet.c 2011-08-24 13:44:50.251979028 +0900<BR>+++ dhcp-4.2.2/common/packet.c 2011-08-24 14:10:46.688060536 +0900<BR>@@ -322,7 +322,10 @@ decode_udp_ip_header(struct interface_in<BR> 8, IPPROTO_UDP + ulen))));<BR><BR> udp_packets_seen++;<BR>- if (usum && usum != sum) {<BR>+ /* RFC768<BR>+ * If the computed checksum is zero, it is transmitted as all ones<BR>+ */<BR>+ if (usum && usum != sum && !(usum == 0xffff && sum == 0)) {<BR> udp_packets_bad_checksum++;<BR> if (udp_packets_seen > 4 &&<BR> (udp_packets_seen / udp_packets_bad_checksum) < 2) {<BR>_______________________________________________<BR>dhcp-hackers mailing list<BR>dhcp-hackers@lists.isc.org<BR><A href="https://lists.isc.org/mailman/listinfo/dhcp-hackers">https://lists.isc.org/mailman/listinfo/dhcp-hackers</A><BR></DIV></BODY></HTML>