* What to do with malformed l4proto packets? (resend)
@ 2007-04-06 17:36 John Heffner
2007-04-06 18:29 ` Patrick McHardy
0 siblings, 1 reply; 3+ messages in thread
From: John Heffner @ 2007-04-06 17:36 UTC (permalink / raw)
To: netfilter-devel
(Apologies if this is a duplicate, but my original message didn't seem
to get through.)
We have someone on the end of a DSL line that seems to be
non-deterministically corrupting some of his packets (a rate of ~1e-5)
in a way that causes the TCP checksum to fail. While he hopes to get
this situation remedied, the immediate problem is that his connections
that go through our firewall are getting reset every time a corrupted
segment is received.
AFAICT, what's happening is that tcp_error() finds the TCP checksum
wrong, returning -NF_ACCEPT back up to nf_conntrack_in(), which quits
and sends NF_ACCEPT back up. So we have a TCP packet not associated
with a connection, so our firewall rules send back a RST.
So, the question is: is there any reason to ACCEPT TCP segments with
known bad checksums?
Thanks,
-John
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: What to do with malformed l4proto packets? (resend)
2007-04-06 17:36 What to do with malformed l4proto packets? (resend) John Heffner
@ 2007-04-06 18:29 ` Patrick McHardy
2007-04-06 19:32 ` John Heffner
0 siblings, 1 reply; 3+ messages in thread
From: Patrick McHardy @ 2007-04-06 18:29 UTC (permalink / raw)
To: John Heffner; +Cc: netfilter-devel
John Heffner wrote:
> We have someone on the end of a DSL line that seems to be
> non-deterministically corrupting some of his packets (a rate of ~1e-5)
> in a way that causes the TCP checksum to fail. While he hopes to get
> this situation remedied, the immediate problem is that his connections
> that go through our firewall are getting reset every time a corrupted
> segment is received.
>
> AFAICT, what's happening is that tcp_error() finds the TCP checksum
> wrong, returning -NF_ACCEPT back up to nf_conntrack_in(), which quits
> and sends NF_ACCEPT back up. So we have a TCP packet not associated
> with a connection, so our firewall rules send back a RST.
>
> So, the question is: is there any reason to ACCEPT TCP segments with
> known bad checksums?
The REJECT target verifies the checksum, so this shouldn't happen.
Are you sure its the REJECT target thats sending the RST?
In either case you should probably just drop state INVALID packets
since this can also happen for retransmits etc. when TCP window
tracking doesn't like the packet.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: What to do with malformed l4proto packets? (resend)
2007-04-06 18:29 ` Patrick McHardy
@ 2007-04-06 19:32 ` John Heffner
0 siblings, 0 replies; 3+ messages in thread
From: John Heffner @ 2007-04-06 19:32 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel
Patrick McHardy wrote:
> The REJECT target verifies the checksum, so this shouldn't happen.
> Are you sure its the REJECT target thats sending the RST?
You're right, I missed that.
Commit: 6150bacfec95c7042678667561664efcf10d4508
Author: Patrick McHardy <kaber@trash.net> Tue, 21 Jun 2005 14:03:46 -0700
[NETFILTER]: Check TCP checksum in ipt_REJECT
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
I'm guessing RHEL hasn't backported this fix into their ancient kernel
yet. Sorry to waste your time.
Thanks,
-John
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-04-06 19:32 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-04-06 17:36 What to do with malformed l4proto packets? (resend) John Heffner
2007-04-06 18:29 ` Patrick McHardy
2007-04-06 19:32 ` John Heffner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.