dhcpd will discard DHCP request when checksum value of packet is 0xffff.

[Fons de Jongh]

Hi Yoshihiro,
 
When the transmitted checksum in the UDP header is all zeros, then UDP checksumming has not been done by the transmitter.
 
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.
 
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.
 
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.
 
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.
 
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.
 
Thanks, good luck and kind regards,
 
Fons

>>> Yoshihiro takahashi <yoshihiro.takahashi at miraclelinux.com> 8/24/2011 9:54 AM >>>
Hi.

dhcpd will discard DHCP request when checksum value of packet is 0xffff.
0xffff for checksum value is equivalent to 0x0000.
In 0xffff case, is the packet treated as error?

RFC768
------
If the computed checksum  is zero, it is transmitted as all ones
------

dhcp-discover did not work when checksum of packet is 0xffff.
----
52 0.853890 172.18.76.162 172.18.76.161DHCP DHCP Request - Transaction ID 0x2862
Frame 52 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: ********* (00:40:66:43:99:b2), Dst: ******** (00:07:32:16:47:b0)
Internet Protocol, Src: 172.18.76.162 (172.18.76.162), Dst: 172.18.76.161 (172.18.76.161)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootps (67)
  Source port: bootps (67)
  Destination port: bootps (67)
  Length: 1480
  Checksum: 0xffff [validation disabled]
Bootstrap Protocol
----


Best regards,

diff -aurp dhcp-4.2.2.orig/common/packet.c dhcp-4.2.2/common/packet.c
--- dhcp-4.2.2.orig/common/packet.c     2011-08-24 13:44:50.251979028 +0900
+++ dhcp-4.2.2/common/packet.c  2011-08-24 14:10:46.688060536 +0900
@@ -322,7 +322,10 @@ decode_udp_ip_header(struct interface_in
                                           8, IPPROTO_UDP + ulen))));

   udp_packets_seen++;
-  if (usum && usum != sum) {
+  /* RFC768
+   * If the computed checksum  is zero, it is transmitted as all ones
+   */
+  if (usum && usum != sum && !(usum == 0xffff && sum == 0)) {
          udp_packets_bad_checksum++;
          if (udp_packets_seen > 4 &&
              (udp_packets_seen / udp_packets_bad_checksum) < 2) {
_______________________________________________
dhcp-hackers mailing list
dhcp-hackers at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-hackers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-hackers/attachments/20110824/3fc4ab8d/attachment.html>