Need help with UDP checksums [Solved]

[richb-hanover (Rich Brown)]

I inherited a go program that sends UDP datagrams. Those packets arrive successfully on the far end, and have the expected contents.

THE PROBLEM… Wireshark tells me that the UDP checksums are incorrect. I will note that Wireshark shows the actual checksum field is non-zero, and different from the calculated data.

I looked through the Net package documentation(https://golang.org/pkg/net/), but it is silent on checksums. Full code is at: https://github.com/richb-hanover/nflow-generator especially the nflow-generator.go file, but basically, my code looks like this:

conn, err := net.DialUDP("udp", nil, udpAddr)
// ... build up a buffer of the datagram to send
_, err := conn.Write(buffer)

Any thoughts? Many thanks!

[lutzhorn]

@richb-hanover

different from the calculated data

Calculated by whom?

[richb-hanover (Rich Brown)]

Sorry, I wasn’t clear. Wireshark compares the checksum value that’s present in the datagram header to its own calculation of the checksum based on the data of the datagram. It flags an error if those values are different, and that’s what I’m seeing.

So (as a newbie to go), I’m wondering if there’s anything else I should do in the program to ensure the correct calculation of the datagram checksum… Thanks!

[calmh (Jakob Borg)]

If the packets arrive successfully and have the expected contents, the checksums were correct. However, the checksums are often calculated by the NIC (hardware checksum offloading), meaning that for outgoing traffic Wireshark does not see the actual checksum. This is expected and fine. Do not worry about it. It is not your responsibility as the “user” of UDP to ensure the checksum.

[richb-hanover (Rich Brown)]

@calmh

If the packets arrive successfully and have the expected contents, the checksums were correct.

I wanted to believe this, but was looking for proof (I’m also debugging the program that receives those datagrams. )

However, the checksums are often calculated by the NIC (hardware checksum offloading), meaning that for outgoing traffic Wireshark does not see the actual checksum. This is expected and fine. Do not worry about it. It is not your responsibility as the “user” of UDP to ensure the checksum.

YES! This totally matches the evidence. Wireshark running on the sending computer sees bad checksums. But I ran Wireshark on the destination computer, and the checksums are correct. So I conclude:

• The conn.Write() function does cause the correct checksum to be computed and added to the UDP datagram.
• Wireshark running on the computer sending the datagrams may not show correct checksums, because of checksum offloading.
• Wireshark running on the computer receiving those datagrams should show correct checksums.
• (In fact, the internet RFCs specify that datagrams with incorrect checksums should be dropped/ignored. So the receiver should never have received the datagrams if they had bad checksums. But because I’m debugging both ends of the process, I am suspicious of everything…)

Thanks for a great answer. I’m marking it as solved.

[dfc (Dave Cheney)]

What calmh said. Modern (anything about 100mbit) NICs offload the TCP checksums to the hardware. When the is send the packet the checksum is either zeros or garbage, nice hardware will fix it on the way out.

[richb-hanover (Rich Brown)]

Yup. Thanks for confirming the mechanism that matches the observed data.