From: "Neal P. Murphy" <neal.p.murphy@alum.wpi.edu>
To: "netfilter@vger.kernel.org" <netfilter@vger.kernel.org>
Subject: bursts of INVALID packets
Date: Fri, 29 Apr 2016 19:51:29 -0400 [thread overview]
Message-ID: <20160429195129.2e5b9d27@playground> (raw)
Kernel: 3.4.112
Iptables: 1.4.21
System: Smoothwall Express 3.1
This isn't exactly a problem; it's more of an oddity that raises some questions.
Take two linux systems. Using ssh (and a shell script), transfer /dev/zero from one to /dev/null on the other. With a decent system and 100Mb NICs, they should climb to about 97Mb/s in and out. Very nice. Now interrupt one with CTRL/C. All of a sudden, a burst of INVALID RST packets arrives at (at least) one side. The number of packets in the burst can be from few to many.
I surmise that one side buffered a bunch of packets and continued to transmit them after the transfer was interrupted. The other side received these packets, noted the now-closed connection, and sent RST packets back. The one side, upon receiving the RST packets, marked them INVALID and logged them. All is working as expected.
This leads to my questions. Can (or could, or should) netfilter detect that outgoing packets belong to closed conns and mark them INVALID? Should netfilter be able to detect and drop INVALID packets on output? Or, as an alternative, should netfilter be able to see that a conn is closed and mark outgoing packets INVALID so that rules can handle them? Is it worth the CPU cycles to do this?
Dropping INVALID packets on input (mangle:PREROUTING) works marvelously.
Of course, if the outgoing packets have already left netfilter and are queued for transmission, netfilter is out of the loop and cannot stop them.
Aside, I've bumped SWE3.2 to iptables 1.6.0; but it'll be a long while before 3.2 is releasable.
Thanks,
Neal
next reply other threads:[~2016-04-29 23:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-29 23:51 Neal P. Murphy [this message]
2016-05-02 7:26 ` bursts of INVALID packets André Paulsberg-Csibi (IBM Consultant)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160429195129.2e5b9d27@playground \
--to=neal.p.murphy@alum.wpi.edu \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox