Entirely ignoring TCP and UDP checksum in kernel level
The problem is that the interface 192.168.1.1 does not allow any tranmission to occur. An implementation error I think... We send packets to 192.168.1.1, we get no reply, but when we send packets to 192.168.77.1 we get the replies (that is where the abnormality begins). However; the replies are now sourced from 192.168.1.1 instead. That is, the blasted code in the device calculates the checksum using the wrong IP address which it thinks it is assigned to...
-----Original Message-----
From: Aidas Kasparas [mailto:[email protected]]
Sent: Saturday, August 21, 2004 9:47 AM
To: Josan Kadett
Subject: Re: Entirely ignoring TCP and UDP checksum in kernel level
But will these checksums be incorect if crazy box would communicate with address in 192.168.1.x only?
The whole idea was based on the fact, that if that box works well in 192.168.1.x networkd, then let it think it works in the network it knows how to work!
Quoted 1 line · Josan Kadett
It is definetely impossible to use IPTables to handle packets with
incorrect
Quoted 1 line
checksums since NAT would drop the connection right away, otherwise I
would
Quoted 15 lines
not have been asking this question here.
-----Original Message-----
From: Aidas Kasparas [mailto:[email protected]]
Sent: Saturday, August 21, 2004 8:54 AM
To: Josan Kadett
Subject: Re: Entirely ignoring TCP and UDP checksum in kernel levelHow about setting up a separate box which would listen on that 192.168.77.1 address and MASQUERADE connections to your crazy box from 192.168.1.x address? Maybe then you would no longer need to break things
in kernel?
Signature · 3 lines
Aidas Kasparas IT administrator GM Consult Group, UAB
Quoted 7 lines · Josan Kadett
The problem is that the interface 192.168.1.1 does not allow any tranmission to occur. An implementation error I think... We send packets to 192.168.1.1, we get no reply, but when we send packets to 192.168.77.1 we get the replies (that is where the abnormality begins). However; the replies are now sourced from 192.168.1.1 instead. That is, the blasted code in the device calculates the checksum using the wrong IP address which it thinks it is assigned to...
Maybe dust off some old Pentium 133 and replace that piece of electronic crap with decent Linux machine?
Signature · 1 line
vda
That is not much of an intelligible idea. A way to hack the kernel could be found as I still presume. "Turn off checksums" but not by re-writing the whole tcp code in the kernel. Isn't that possible ? Linux is an operating system of infinite possibilities, right ? But only if you know how to hack it...
-----Original Message-----
From: Denis Vlasenko [mailto:[email protected]]
Sent: Saturday, August 21, 2004 10:11 AM
To: Josan Kadett; 'Aidas Kasparas'
Cc: [email protected]
Subject: RE: Entirely ignoring TCP and UDP checksum in kernel level
Quoted 2 lines · Josan Kadett
The problem is that the interface 192.168.1.1 does not allow any tranmission to occur. An implementation error I think... We send packets
to
Quoted 3 lines
192.168.1.1, we get no reply, but when we send packets to 192.168.77.1 we get the replies (that is where the abnormality begins). However; the replies are now sourced from 192.168.1.1 instead. That is, the blasted
code
Quoted 2 lines
in the device calculates the checksum using the wrong IP address which it thinks it is assigned to...
Maybe dust off some old Pentium 133 and replace that piece of electronic crap with decent Linux machine?
Signature · 1 line
vda
Quoted 6 lines · Josan Kadett
That is not much of an intelligible idea. A way to hack the kernel could be found as I still presume. "Turn off checksums" but not by re-writing the whole tcp code in the kernel. Isn't that possible ? Linux is an operating system of infinite possibilities, right ? But only if you know how to hack it...
Can't you just go into the networking code, and find the part where it checks the checksum, and just have it return success, even if the checksum was bad? Seems like a quick copy and paste hack. Am I missing something?
Lee
-----Original Message-----
From: Lee Revell [mailto:[email protected]]
Sent: Saturday, August 21, 2004 10:26 AM
To: Josan Kadett
Cc: 'Denis Vlasenko'; linux-kernel
Subject: RE: Entirely ignoring TCP and UDP checksum in kernel level
Quoted 1 line · Josan Kadett
That is not much of an intelligible idea. A way to hack the kernel could
be
Quoted 12 lines
found as I still presume. "Turn off checksums" but not by re-writing the whole tcp code in the kernel. Isn't that possible ? Linux is an operating system of infinite possibilities, right ? But only if you know how to hack it...
Quoted 6 lines
Can't you just go into the networking code, and find the part where it checks the checksum, and just have it return success, even if the checksum was bad? Seems like a quick copy and paste hack. Am I missing something?
Lee
Very well, it is what I really wish to do. The networking code is no simple issue in linux. As I underlined, two c files, tcp_input.c and udp.c controls how the checksum is done and the code looks very complicated. Perhaps you have some idea about where in 100K source code to change in order to disable checksumming but at the same time not to break normal operation. I can apply a change in the code, recompile the kernel and test it. I have installed a virtual machine running linux in order to experiment with the settings, but the problem is that I do not have enough time to understand what the code is all about. Perhaps it is in sock.h, perhaps skbuff.h, or any other file. Each and every file seems to contain some function related to checksumming.
Quoted 6 lines · Josan Kadett
The problem is that the interface 192.168.1.1 does not allow any tranmission to occur. An implementation error I think... We send packets to 192.168.1.1, we get no reply, but when we send packets to 192.168.77.1 we get the replies (that is where the abnormality begins). However; the replies are now sourced from 192.168.1.1 instead. That is, the blasted code in the device calculates the checksum using the wrong IP address which it thinks it is assigned to...
How about assigning an IP address that generates the same checksum to the second interface? That'd solve your problem.
Or assign both interfaces the same IP address, maybe the device allows it.
Quoted 48 lines
-----Original Message-----
From: Aidas Kasparas [mailto:[email protected]]
Sent: Saturday, August 21, 2004 9:47 AM
To: Josan Kadett
Subject: Re: Entirely ignoring TCP and UDP checksum in kernel levelBut will these checksums be incorect if crazy box would communicate with address in 192.168.1.x only?
The whole idea was based on the fact, that if that box works well in 192.168.1.x networkd, then let it think it works in the network it knows how to work!
Quoted 1 line · Josan Kadett
It is definetely impossible to use IPTables to handle packets with
incorrect
Quoted 1 line
checksums since NAT would drop the connection right away, otherwise I
would
Quoted 15 lines
not have been asking this question here.
-----Original Message-----
From: Aidas Kasparas [mailto:[email protected]]
Sent: Saturday, August 21, 2004 8:54 AM
To: Josan Kadett
Subject: Re: Entirely ignoring TCP and UDP checksum in kernel levelHow about setting up a separate box which would listen on that 192.168.77.1 address and MASQUERADE connections to your crazy box from 192.168.1.x address? Maybe then you would no longer need to break things
in kernel?Signature · 11 lines
Aidas Kasparas IT administrator GM Consult Group, UAB - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR