RE: Cursed Checksums

[Josan Kadett]

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) // 192.168.1.1
+               iph->saddr = 0x014da8c0; // 192.168.77.1
+       printk("Ip saddr %08x\n",iph->saddr);

         {
                 __u32 len = ntohs(iph->tot_len);

This way whenever an IP packet with the source address of 192.168.1.1
reaches the patched box, the code changes that address of 192.168.77.1

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

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

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 192.168.77.1 even
if they are originally from 192.168.1.1

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 [mailto:alan@xxxxxxxxxxxxxxxxxxx] 
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.

Alan


Alan



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/