RE: Cursed Checksums

RE: Cursed Checksums

[Albert Cahalan]

I'm surprised to find that there doesn't seem to
be an ebtables mangle table. That'd be the place
to match on a u32, then either change that or just
mark the packet for checksuming.

RE: Cursed Checksums

[Josan Kadett]

In normal conditions, when NAT translates an IP header, it should do correct
checksumming. However; when the source IP address of a packet is
manipulated, Iptables still seems to use the "original" IP address and
calculate the checksum accordingly. This way even if I use 3 three boxes;

Original Packet --> NAT 1 --> NAT 2 --> NAT3 --> Still incorrect checksum

The wrong checksum is carried over and over the line. It is really a strange
issue and I could not find a reason why still I get the incorrect checksum
even after the IP header is translated three times...

As I said, the original packet must be corrected before it is transmitted to
another place and I think it is just two or three lines of code in the
kernel, but the question is "where"...

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Albert Cahalan
Sent: Sunday, August 22, 2004 8:55 PM
To: linux-kernel mailing list
Subject: RE: Cursed Checksums

I'm surprised to find that there doesn't seem to
be an ebtables mangle table. That'd be the place
to match on a u32, then either change that or just
mark the packet for checksuming.


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

RE: Cursed Checksums

[Albert Cahalan]

On Sun, 2004-08-22 at 18:38, Josan Kadett wrote:
> In normal conditions, when NAT translates an IP header, it should do correct
> checksumming. However; when the source IP address of a packet is
> manipulated, Iptables still seems to use the "original" IP address and
> calculate the checksum accordingly. This way even if I use 3 three boxes;
> 
> Original Packet --> NAT 1 --> NAT 2 --> NAT3 --> Still incorrect checksum

Sure. That's why I think this is a job for ebtables.
Note: EBtables, not IPtables. This is lower level,
dealing with raw Ethernet packets. It should be able
to mangle anything in the packet.

Just as iptables lets you change any 32-bit value in
an IP packet, ebtables should let you change any 32-bit
value in an Ethernet packet. Unlike iptables, it could
operate prior to the IP checksum verification.

Sadly, it looks like u32 mangle rules are missing.

Cursed Checksums

[Josan Kadett]

I have an issue with the incorrect TCP and UDP checksum dropped by the
kernel. A network node is calculating TCP/UDP header checksums with wrong
psuedo-headers, so kernel does not let these packets to reach to userspace;

When I manually calcaulate the checksum in the incoming TCP and UDP packets
and re-inject them back to the socket, everything works fine. That is, the
data integrity is not damaged or corrupted at all.

I tried to investigate the code in tcp_input.c and udp.c to see if I can
disable the checksum control for inbound packets entirely. No use it was
since I need to do this urgently.

Any ideas?

Re: Cursed Checksums

[Alan Cox]

On Sad, 2004-08-21 at 03:37, Josan Kadett wrote:
> When I manually calcaulate the checksum in the incoming TCP and UDP packets
> and re-inject them back to the socket, everything works fine. That is, the
> data integrity is not damaged or corrupted at all.

At least for the few you looked at. That proves nothing.

> I tried to investigate the code in tcp_input.c and udp.c to see if I can
> disable the checksum control for inbound packets entirely. No use it was
> since I need to do this urgently.

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

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@lxorguk.ukuu.org.uk] 
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

RE: Cursed Checksums

[Josan Kadett]

Perhaps there is a way to recompute IP header checksums before they get into
the interface? As I outlined, I have found a way to manipulate IP source
address before the packet is flushed to system, but a means of recalculating
the IP header checksum after that manipulation should be found. Because even
if I ignore IP header CRC in one system, all other boxes connected to this
machine has to be patched the same. That is impossible anyway.

Only if I could find a way to recalculate the checksum in IP headers by
doing a simple hack to the kernel, everything would be alright. 

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of 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.

Alan


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

RE: Cursed Checksums

[Alan Cox]

On Sul, 2004-08-22 at 22:03, Josan Kadett wrote:
> Perhaps there is a way to recompute IP header checksums before they get into
> the interface? As I outlined, I have found a way to manipulate IP source
> address before the packet is flushed to system, but a means of recalculating
> the IP header checksum after that manipulation should be found. Because even
> if I ignore IP header CRC in one system, all other boxes connected to this
> machine has to be patched the same. That is impossible anyway.
> 
> Only if I could find a way to recalculate the checksum in IP headers by
> doing a simple hack to the kernel, everything would be alright. 

Providing your hardware isn't doing the checksums then you can do 
this. Each ethernet packet driver with pass packets up to the 
layer above (netif_rx()). Something like

	skb->protocol = eth_type_trans(...)
	/* Check packet here */
	whack_packet(skb->h.raw skb->len);
	netif_rx(skb);

in the driver. Before the netif_rx you can validly mangle the bits

Re: Cursed Checksums

[Olivier Galibert]

On Sun, Aug 22, 2004 at 11:03:54PM +0200, Josan Kadett wrote:
> Perhaps there is a way to recompute IP header checksums before they get into
> the interface? As I outlined, I have found a way to manipulate IP source
> address before the packet is flushed to system, but a means of recalculating
> the IP header checksum after that manipulation should be found. Because even
> if I ignore IP header CRC in one system, all other boxes connected to this
> machine has to be patched the same. That is impossible anyway.
> 
> Only if I could find a way to recalculate the checksum in IP headers by
> doing a simple hack to the kernel, everything would be alright. 

Why don't you patch the checksum when you change the IP?  It's just a
not of the sum the 16-bit words so take the old one, not it, add the
two 16-bits differences, re-not it and write it back.

  OG.

RE: Cursed Checksums

[Josan Kadett]

It is what I intend to do, yet could you paste a working source code for;

- sniff data from a chosen interface
- put the same data in the same interface's inbound socket

If I could find how to do this via low-level libraries, I think I could
write an applet to do the mangling.

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Olivier Galibert
Sent: Monday, August 23, 2004 12:59 AM
To: linux-kernel@vger.kernel.org
Subject: Re: Cursed Checksums

Why don't you patch the checksum when you change the IP?  It's just a
not of the sum the 16-bit words so take the old one, not it, add the
two 16-bits differences, re-not it and write it back.

  OG.