Entirely ignoring TCP and UDP checksum in kernel level
Quoted 6 lines · Josan Kadett
That is certainly what I require but I need some guidelines; I investigated into the issue and fount out that;
- By only changing the source address coded in the IP header
- And by just applying checksum to IP header [Not TCP or UDP]
Quoted 7 lines
The problem would be gone since when the source IP in the IP address field is validated, the checksum in the underlying protocol is automatically validated (because the sender system had already computed this CRC using the IP address which we want to write onto the packet)
I do not have much time to build a code just for this purpose and thus I am looking for a simple app. or some other way...
So if we took any packet that came in from 192.168.1.1 and substituted 192.178.77.1 for the Source address and then re-calculated the IP checksum you would be up and running?
Regards,
Brad
Absolutely, that would correct the problem with the best possible resolution.
-----Original Message-----
From: Brad Campbell [mailto:[email protected]]
Sent: Sunday, August 22, 2004 8:17 AM
To: Josan Kadett
Cc: [email protected]
Subject: Re: Entirely ignoring TCP and UDP checksum in kernel level
So if we took any packet that came in from 192.168.1.1 and substituted 192.178.77.1 for the Source
address and then re-calculated the IP checksum you would be up and running?
Regards,
Brad
**Indeed there is no longer such a need to recalculate the IP checksum because I have found a way to disable it by patching the kernel. So, only requirement is this;
Change the source address of the packet before it reaches to the socket buffer aka skbuff.h. Because if it reaches that code with the wrong IP header, the csum will just drop it away.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Brad Campbell
Sent: Sunday, August 22, 2004 8:17 AM
To: Josan Kadett
Cc: [email protected]
Subject: Re: Entirely ignoring TCP and UDP checksum in kernel level
So if we took any packet that came in from 192.168.1.1 and substituted 192.178.77.1 for the Source
address and then re-calculated the IP checksum you would be up and running?
Regards,
Brad
Quoted 7 lines · Josan Kadett
**Indeed there is no longer such a need to recalculate the IP checksum because I have found a way to disable it by patching the kernel. So, only requirement is this;
Change the source address of the packet before it reaches to the socket buffer aka
skbuff.h. Because if it reaches that code with the wrong IP header, the csum will just drop it away.
The main reason I suggested correcting the checksum is if it was done that way, the kernel would behave normally for all other IP traffic and simply do a dodgy on only traffic from 192.168.1.1
If nobody else jumps in, let me think about it for a day or so and I'll see what I can do. It's been a couple of years since I last looked at the network code though.
What kernel are you running?
Regards,
Brad
Linux Kernel 2.4.18-14 [Redhat 8 standard installation]
As I underlined, I have been able to disable IP header checksumming for the received packets, so the system will not drop the packets even after CRC becomes invalid when the source address changes.
I have been asking this question over ten different mailing list and forums and no one has come up with a "solid" solution. I would be exteremely glad if I get a working source code.
I know the application will be so very simple, just changing some bits with another and putting it back to userspace, but it requires some low-level libraries and the knowledge to use them...
-----Original Message-----
From: Brad Campbell [mailto:[email protected]]
Sent: Sunday, August 22, 2004 9:04 AM
To: Josan Kadett
Cc: [email protected]
Subject: Re: Entirely ignoring TCP and UDP checksum in kernel level
The main reason I suggested correcting the checksum is if it was done that way, the kernel would
behave normally for all other IP traffic and simply do a dodgy on only traffic from 192.168.1.1
If nobody else jumps in, let me think about it for a day or so and I'll see what I can do. It's been
a couple of years since I last looked at the network code though.
What kernel are you running?
Regards,
Brad
Quoted 6 lines · Josan Kadett
Linux Kernel 2.4.18-14 [Redhat 8 standard installation]
As I underlined, I have been able to disable IP header checksumming for the received packets, so the system will not drop the packets even after CRC becomes invalid when the source address changes.
Quoted 7 lines
I have been asking this question over ten different mailing list and forums and no one has come up with a "solid" solution. I would be exteremely glad if I get a working source code.
I know the application will be so very simple, just changing some bits with another and putting it back to userspace, but it requires some low-level libraries and the knowledge to use them...
This *MAY* do what you want.. (Compiled and tested on 2.4.26)
ipv4/ip_input.c 2004-08-22 12:22:41.000000000 +0400 renamed from usr/src/linux-2.4.26/net/ipv4/ip_input.c 2002-08-03 04:39:46.000000000 +0400 +4 -0
@@ -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);
When you verify what it's doing, just remove the printk's.
I did it here using one of my local addresses (uml == 192.168.2.84) And had the above addresses convert 192.168.2.85 to 192.168.77.1
bklaptop:/home/brad# tcpdump -i tap0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes 12:24:16.723748 IP 192.168.2.85 > uml: icmp 64: echo request seq 0 12:24:16.725119 arp who-has gateway tell uml 12:24:17.289458 arp reply gateway is-at 00:ff:14:7a:fe:66 12:24:17.290282 IP uml > 192.168.77.1: icmp 64: echo reply seq 0 12:24:17.720057 IP 192.168.2.85 > uml: icmp 64: echo request seq 256 12:24:17.723690 IP uml > 192.168.77.1: icmp 64: echo reply seq 256 12:24:18.720632 IP 192.168.2.85 > uml: icmp 64: echo request seq 512 12:24:18.724369 IP uml > 192.168.77.1: icmp 64: echo reply seq 512
Good luck.
Regards,
Brad