Hi ! Have you tried to reach the device on its 192.168.1.1 address by adding a static route on you host stating that 192.168.1.1 is behind 192.168.77.1 ? 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. Regards, Willy 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 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. > > > - > : 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/ - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
