3 ms·
Breaking down the oddity on 0x0000 and 0xFFFF further, it stems from this special behavior per the RFCs https://www.rfc-editor.org/rfc/rfc1122#page-29:~:text=is
by zamadatix 6mo ago
Breaking down the oddity on 0x0000 and 0xFFFF further, it stems from this special behavior per the RFCs https://www.rfc-editor.org/rfc/rfc1122#page-29:~:text=is%20very%20controversial.-,IMPLEMENTATION,-%3A%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20There%20is%20a https://www.rfc-editor.org/rfc/rfc1122#page-29:~:text=is%20v...:
> Unlike the TCP checksum, the UDP checksum is optional; the value zero is transmitted in the checksum field of a UDP header to indicate the absence of a checksum. If the transmitter really calculates a UDP checksum of zero, it must transmit the checksum as all 1's (65535). No special action is required at the receiver, since zero and 65535 are equivalent in 1's complement arithmetic.
Using 0x0000 and 0xFFFF as special values via 1's complement creates the error, only for these 2 specific values, when 2's complement logic is used to calculate.