Turning off TCP and UDP checksum in kernel level

I will explain the problem briefly;

- We have an old network concentrator device in our WAN, this device uses IP
number 192.168.77.1 as its primary address
- The device has another IP number (a local address) that is 192.168.1.1

When we ping the device from the internal network, we have to use the
device's primary IP number which is 192.168.77.1:

ping -> 192.168.77.1
reply from 192.168.1.1

Normally the reply should come from 192.168.77.1, 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 192.168.77.1
TCP SYN ACK reply from 192.168.1.1
TCP SYN sent to 192.168.77.1
TCP SYN sent to 192.168.77.1
TCP SYN sent to 192.168.77.1
..... [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 192.168.1.1 instead of getting a packet from 192.168.77.1. 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 192.167.77.1, however; our client that gets the
packet from the address 192.168.1.1 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
192.168.1.1 back to 192.168.77.1)
- 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: 192.168.1.1 (This is where the problem begins, it
should have been 192.168.77.1)
Dest. IP: 192.168.1.5 (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 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/





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

Re: Turning off TCP and UDP checksum in kernel level

Rather than modify the TCP stack, you might want to look at setting up
a NAT translation on the linux box. See iptables for details.

I haven't thought this all the way through, but you problaby want some rules
like:

src: 192.168.1.1, dst: $LINUX_IP_ADDRESS, port: any, state: any
translates to:
src: 192.168.77.1, dst: $LINUX_IP_ADDRESS, port: orig, state: orig

-Aaron

On Sat, 21 Aug 2004, Josan Kadett wrote:

> I will explain the problem briefly;
>
> - We have an old network concentrator device in our WAN, this device uses IP
> number 192.168.77.1 as its primary address
> - The device has another IP number (a local address) that is 192.168.1.1
>
> When we ping the device from the internal network, we have to use the
> device's primary IP number which is 192.168.77.1:
>
> ping -> 192.168.77.1
> reply from 192.168.1.1
>
> Normally the reply should come from 192.168.77.1, 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 192.168.77.1
> TCP SYN ACK reply from 192.168.1.1
> TCP SYN sent to 192.168.77.1
> TCP SYN sent to 192.168.77.1
> TCP SYN sent to 192.168.77.1
> .... [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 192.168.1.1 instead of getting a packet from 192.168.77.1. 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 192.167.77.1, however; our client that gets the
> packet from the address 192.168.1.1 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
> 192.168.1.1 back to 192.168.77.1)
> - 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: 192.168.1.1 (This is where the problem begins, it
> should have been 192.168.77.1)
> Dest. IP: 192.168.1.5 (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 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/
>
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>

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