Interestingly enough, i explored the same issue yesterday in another context (IPSec NAT-T) and checked te 2.5 netfilter code which implement incremental checksum. As far as a quick look in 2.4.20 code, net/ipv4/netfilter/ip_nat_core.c:ip_nat_cheat_check() seems to do the job at the right place. JeF On Wed, Jun 11, 2003 at 09:17:24AM -0400, Ben Collins wrote: > (not sub'd, please Cc) > > I've been tasked with trying to fix a quirk in 2.0 masquerading code, > where a tcp packet incoming that is to be masqueraded can have a bad > checksum (especially when it's the data), and the rewritten packet gets > a correct checksum and is passed through. So bad data actually gets > forwarded through the stacks and to the application. > > I've looked through and the checksum is not checked for packets getting > masqueraded, but it is checked for packets getting demasqueraded. Why > one way and not the other? > > I looked at 2.4's netfilter, and it seems the same logic applies (csum > gets redone no matter if it was incorrect before). > > Two approaches to fixing this: > > 1) Actually check the csum on packets getting masqueraded. Lots of > overhead? > > 2) Implement RFC1141 incremental csum to recalculate the masqueraded > packets csum. This would allow the packet through, but it would keep > it's bad csum and allow the destination to handle dropping it. Anyone > know of any tcpip csum recalculation functions for masqueraded > packets? > > > Thanks > > -- > Debian - http://www.debian.org/ > Linux 1394 - http://www.linux1394.org/ > Subversion - http://subversion.tigris.org/ > Deqo - http://www.deqo.com/ > - > : send the line "unsubscribe linux-net" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- -> Jean-Francois Dive --> jef@linuxbe.org There is no such thing as randomness. Only order of infinite complexity. - Marquis de LaPlace - deterministic Principles - - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
