Entirely ignoring TCP and UDP checksum in kernel level
A message that is not in the archive (sent off-list or not yet received): [email protected]
It is definetely impossible to use IPTables to handle packets with incorrect checksums since NAT would drop the connection right away, otherwise I would 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 level
How 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?
Quoted 11 lines · Josan Kadett
It is definetely impossible to use IPTables to handle packets with incorrect checksums since NAT would drop the connection right away, otherwise I would 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?
Isn't rp_filter for this?
A chunk of my iptables firewall script is:
# Force route verification
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f; done
So why don't you try:
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo "0" > $f; done
Kalin.
Signature · 3 lines
|| ~~~~~~~~~~~~~~~~~~~~~~ || ( ) http://ThinRope.net/ ( ) || ______________________ ||
I already have rp_filter to 0 for all interfaces. It is rather a checksumming problem than a routing one. Only if there was such an easy way to disable checksumming as there is for solaris, disabling both the rp_filter and the checksums would finally end the problem. The poor system still think that it is getting the packet from 192.168.1.1 because the IP header tells as such, while the problematic network device computes the TCP/UDP checksum as if it is still sending it via its 192.168.77.1 source address. There is the kernel, and the code in it which handles checksumming. But I doubt whether a simple patch would do...
Quoted 11 lines
Isn't
rp_filterfor this?A chunk of my iptables firewall script is:
# Force route verification
for f in/proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f; doneSo why don't you try:
for f in/proc/sys/net/ipv4/conf/*/rp_filter; do echo "0" > $f; doneKalin.
Signature · 9 lines
|| ~~~~~~~~~~~~~~~~~~~~~~ || ( ) http://ThinRope.net/ ( ) || ______________________ || - 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/