
Messages in this thread
Patch in this message
SubjectRE: Cursed Checksums
Well, I have patched the kernel with the following code in ip_input.c 

--- /usr/src/linux-2.4.26/net/ipv4/ip_input.c 2002-08-03
04:39:46.000000000 +0400
+++ net/ipv4/ip_input.c 2004-08-22 12:22:41.000000000 +0400
@@ -417,6 +417,10 @@

if (ip_fast_csum((u8 *)iph, iph->ihl) != 0)
goto inhdr_error;
+ printk("Ip saddr %08x -- ",iph->saddr);
+ if (iph->saddr == 0x0101a8c0) //
+ iph->saddr = 0x014da8c0; //
+ printk("Ip saddr %08x\n",iph->saddr);

__u32 len = ntohs(iph->tot_len);
This way whenever an IP packet with the source address of
reaches the patched box, the code changes that address of

Thus at the time before the box was not patched, this was happening;
ping reply from

Now with the patch, this is corrected;
ping reply from

This is a type of packet mangling, but there is still one problem we could
not resolve. Iptables SNAT does not work in this configuration, the box just
does not redirect the ping replies to the SNATted host. Tcpdump shows that
the ping replies reach the patched box which will do the NAT, but the system
just does not redirect them back to the requesting host.

I thought the patch was in socket-level, and my prediction was correct. Even
the tcpdump (presumably the lowest layer application that receives raw
packs) shows that system is told to receive packets from even
if they are originally from

But now, NAT does not work in anyway. Is IPTables working in a lower-level
than tcpdump itself, how can this be? It should have received the packets as
tcpdump receives them (manipulated). Can I debug IPTables by actually
viewing what it receives from the socket? Or perhaps the patch I applied to
ip_input.c just does not affect Iptables at all? (I still cannot believe it)

-----Original Message-----
From: Alan Cox []
Sent: Sunday, August 22, 2004 1:40 PM
To: Josan Kadett
Cc: Linux Kernel Mailing List
Subject: Re: Cursed Checksums
It depends on your hardware. With modern network cards we do the
checksum processing in hardware. For older setups passing a packet
through a Linux box won't directly help as the ttl recomputation is done
without recalculation from scratch.

We also have a pile of paths for checksumming including copy/checksum
rolled into one so it isn't easy to remove there.

I'd take up the issue with the vendor of the broken object. If its
something like an internal prototype you need to test then you'll
probably have to write a user space application using raw sockets to
communicate with it and do the fixups/passthrough in use space. Pretty
horrible either way.



the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
©2003-2011 Jasper Spaans