You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 14, 2024. It is now read-only.
As per RFC 768, if the calculated UDP checksum is 0, it should be instead set as 0xFFFF in the frame. A value of 0 in the checksum field indicates to the receiver that no checksum was calculated and hence it should not verify the checksum.
… frame as per RFC 768. A checksum value of 0 in the frame is "special" and indicates that no checksum was calculated and hence receiver should not verify the same. This special case seems to be only for UDP, not TCP though.
Fixespstavirs#160
Hello pstavirs,
Thanks a lot for your comments about UDP checksum calculation resulting in 0x0000, which must be converted to 0xFFFF according to RFC 768:
If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care).
It took me a long time trying to identify where my Library code was wrong and the result is simply no error at all, it is just a question to add a final check of this UDP checksum Rule.
Just as extra info this rule is not applicable to TCP checksum, which is OK to be 0x0000.
For those who want to know the checksum algorithm in C, see RFC1071 https://tools.ietf.org/html/rfc1071
Just pay attention that it is not included the final check and transformation from 0x0000 to 0xFFFF required by UDP checksum.
As per RFC 768, if the calculated UDP checksum is 0, it should be instead set as 0xFFFF in the frame. A value of 0 in the checksum field indicates to the receiver that no checksum was calculated and hence it should not verify the checksum.
Reported on the mailing list -
https://groups.google.com/forum/#!topic/ostinato/6HnlOihYJ40
The text was updated successfully, but these errors were encountered: