UDP checksum calculation
A nice and easy to understand example of UDP checksum calculation is done by Gerd Hoffmann.
You can google for "net-checksum.c Gerd Hoffmann" or look at the file here:
https://gist.github.com/fxlv/81209bbd150abfeaceb1f85ff076c9f3
You can use net_checksum_tcpudp function, feed it the UDP payload length, proto, src and dst IPs and then the UDP payload itself and it will do the right thing.
At the end you have to call htons() on the checksum and you're good.
The UDP checksum is performed over the entire payload, and the other fields in the header, and some fields from the IP header. A pseudo-header is constructed from the IP header in order to perform the calculation (which is done over this pseudo-header, the UDP header and the payload). The reason the pseudo-header is included is to catch packets that have been routed to the wrong IP address.
Basically, at the receiving end, all the 16-bit words of the headers plus data area are added together (wrapping at 16 bits) and the result is checked against 0xffff.
On the sending side, it's a little more complex. A one's complement sum is performed on all the 16-bit values then the one's complement (i.e., invert all bits) is taken of that value to populate the checksum field (with the extra condition that a calculated checksum of zero will be changed into all one-bits).
The one's complement sum is not just the sum of all the one's complement values. It's a little more complex.
Basically, you have a running 16-bit accumulator starting at zero and you add every 16-bit value to that. Whenever one of those additions results in a carry, the value is wrapped around and you add one to the value again. This effectively takes the carry bit of the 16-bit addition and adds it to the value.
As an aside, and this is pure conjecture on my part but this could probably be efficiently done by use of the
ADC(add with carry) instruction rather thanADD(surprisingly enough, add), or whatever equivalent instructions were available on your CPU at the time.If there were no carry,
ADCwould just add the zero bit from the carry. In the days when this stuff was done (and yes, unfortunately, I am that old), memory was far more of a constraint than speed, not so much the case nowadays, so saving a few bytes in your code could well elevate you to the level of demi-god-emperor-of-the-universe :-)
Note that you never had to worry about carry the second time around (or a carry of two with the next ADC if you're using that method mentioned in the previous paragraph) since the two largest 16-bit values, when summed, produce (truncated from 0x1fffe) 0xfffe - adding one to that will never cause another carry.
Once the calculated one's complement sum is calculated, has its bits inverted and is inserted into the packet, that will cause the calculation at the receiving end to produce 0xffff, assuming no errors in transmission of course.
It's worth noting that the payload is always padded to ensure there's an integral number of 16-bit words. If it was padded, the length field tells you the actual length.
RFC768 is the specification which details this.