[lkml]   [2004]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Entirely ignoring TCP and UDP checksum in kernel level
Hi !

Have you tried to reach the device on its address by adding a
static route on you host stating that is behind ?

You might also give iproute a try, it can do static NAT, although I'm not
certain that checksums are recomputed entirely. There's a big probability
that it uses differential checksums.

Last solution would be to use iptables (without conntrack) and assign packets
to the QUEUE target, then mangling them with a small user-space program
which would then reinject them into the network stack. It might not be too
hard to do. There's even a 'perlipq' perl extension which might do all the
dirty work for you.


On Sat, Aug 21, 2004 at 08:15:30AM +0200, Josan Kadett wrote:
> I will explain the problem briefly;
> - We have an old network concentrator device in our WAN, this device uses IP
> number as its primary address
> - The device has another IP number (a local address) that is
> When we ping the device from the internal network, we have to use the
> device's primary IP number which is
> ping ->
> reply from
> Normally the reply should come from, but the device has some
> kind of programming failure and thus responds us using its internal IP
> number regardless of how we configure it.
> This does not affect the ping from returning back even it is sourced by a
> different address than it is originally destined to, however; if we telnet
> to the device we get the following failure:
> telnet -> TCP SYN sent to
> TCP SYN ACK reply from
> TCP SYN sent to
> TCP SYN sent to
> TCP SYN sent to
> .... [The connection times since our linux host does not "see" the TCP SYN
> ACK reply for an obvious reason)
> The client from which we send telnet requests to the device gets a packet
> from instead of getting a packet from However; at
> this case, the returning TCP SYN ACK packet has the wrong CRC checksum
> because;
> The network concentrator computes the TCP checksum with the source address
> header of its IP number, however; our client that gets the
> packet from the address uses this address instead of the correct
> one in order to compute the checksum and thus they mismatch;
> Eg.
> 0D 74 (Checksum computed by concentrator device)
> 13 D6 (Checksum computed by our client)
> So the incoming packets are dropped due to the fact that they have "wrong"
> checksum... Now either we should find a way to correct the source address
> and the IP checksum in each incoming packet received by our client, or we
> should "program" a utility for it. Here is what we plan to do;
> - Intercept each packet coming from interface eth0
> - Put the IP data in buffer
> - Find and change the bits in which the source IP address is encoded (from
> back to
> - Since the TCP packet has already been checksummed for the correct IP,
> after we change the source, the TCP checksum would be "automatically"
> corrected
> - But since we modified the source IP, now the IP header checksum is broken;
> so recalculate it and put it in correct place
> - "Re-inject" the packet to the interface eth0, but to the "incoming" data
> path that would be received by kernel (just as generating a packet that goes
> to system itself, instead of an external link)
> I found that in /usr/src/linux/net/ipv4/tcp_input.c and udp.c are the two
> sources that control how the communication occurs. I experimented with the
> code and re-compiled the kernel times over times, though either the "CRC"
> checksum checking was still there or the communication was totally cut out.
> I also investigated terms such as CRC checksum offloading and such, and as I
> could see that there was no easy way (a switch or a definition) to disable
> CRC checksumming of received packets, either it be TCP or UDP. I am still
> sure that if the kernel is "told" to allow all packets regardless of their
> CRC field, I would resolve the problem with our network, but the question is
> "how ??"
> Below is a detailed view of the malformed packet;
> Ethernet II Header
> |
> - IP Header
> (flags) Source IP: (This is where the problem begins, it
> should have been
> Dest. IP: (Our client's IP number)
> Checksum [0x7d43] --> Correct CRC for IP header
> |
> - UDP Header (The same case for TCP)
> (flags) Source Port: 161
> Dest. Port: 32816
> Length: 0x0048
> Checksum [0x341a] --> Wrong CRC that causes all problems.**
> Our system thinks that the checksum would be what it wants to be, so the
> conflict between these two devices makes communication impossible. I know,
> if a patch is applied to the source code of the kernel, both TCP and UDP
> would ingore the CRC and allow communication. Since our network is
> absolutely reliable, there will not be a single side effect of disabling
> TCP/UDP checksums.
> Now if all else fails, at least I have one option though I really do not
> wish to program a packet interceptor for no reason but the dumbness of a
> router and the "abhorrent rigidity" of linux TCP/IP stack. But if I must
> then I will... (We will not replace a multi-K$ UAC device just for this
> reason)
> Perhaps there is a small utility that corrects checksums of the incoming
> data (in real-time) ? Indeed many sniffers have this option to correct the
> CRC (or show the correct value), but none of them are programmed to create a
> stream in which the modifications are done and the packets get re-injected.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> More majordomo info at
> Please read the FAQ at
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [W:0.071 / U:5.352 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site