What to do with malformed l4proto packets?

What to do with malformed l4proto packets?

[John Heffner]

We have someone on the end of a DSL line that seems to be 
non-deterministically corrupting some of his packets (a rate of ~1e-5) 
in a way that causes the TCP checksum to fail.  While he hopes to get 
this situation remedied, the immediate problem is that his connections 
that go through our firewall are getting reset every time a corrupted 
segment is received.

AFAICT, what's happening is that tcp_error() finds the TCP checksum 
wrong, returning -NF_ACCEPT back up to nf_conntrack_in(), which quits 
and sends NF_ACCEPT back up.  So we have a TCP packet not associated 
with a connection, so our firewall rules send back a RST.

So, the question is: is there any reason to ACCEPT TCP segments with 
known bad checksums?

Thanks,
   -John

Re: What to do with malformed l4proto packets?

[Ross Vandegrift]

On Thu, Apr 05, 2007 at 06:11:55PM -0400, John Heffner wrote:
> So, the question is: is there any reason to ACCEPT TCP segments with 
> known bad checksums?

If you capture traffic from a Windows machine that has a NIC with
hardware checksum offload and load the pcap into wireshark, it almost
always seems to have invalid checksums.

I have no idea why, if they do this under other operating systems, or
if it's just this chipset (BCM NetXtreme II) or all checksum offload.
It doesn't seem to affect anything, as the packets are otherwise
always valid.


-- 
Ross Vandegrift
ross@kallisti.us

"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
	--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37