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!
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.
I wanted to believe this, but was looking for proof (I’m also debugging the program that receives those datagrams. )
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.
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.