#1 Bug/Problem with optional checksum

[rmp]

Dear Rafal,

when using your nids library (by the way: great work), I
encountered the following situation:

A router skipped the calculation of check sums due to
performance issues. That's not really nice ;-), but under
certain circumstances the checksum may be omitted
(see below). When using libnids all packets with a value
of zero (0) in the checksum field of the UDP header are
silently discarded.
My proposal is to include a differentiation between zero
(0) and it's 1's complement (65535) into libnids. What do
you think about it? For my project I've made a small
patch (I hope it works fine with version 1.19, I currently
use 1.18), perhaps it is good and you like it - just have
a look.

My patch (I've adapted the line numbers to version
1.19):

diff libnids.c libnids_patch.c
316a317
> #define UH_CSUM uh_sum
320a322
> #define UH_CSUM check
338c340
< if (my_udp_check
---
> if ((udph->UH_CSUM) && (my_udp_check
340c342
< iph->ip_dst.s_addr)) return;
---
> iph->ip_dst.s_addr))) return;

Regards,
rmp

Excerpt from RFC 1122:
---snip

4.1.3.4 UDP Checksums

...

IMPLEMENTATION:
There is a common implementation error in UDP
checksums. 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.

---snap