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 -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
