Patrick Schaaf wrote:
>
> That's your policy choice. I may have others, in other situations.
Well, you're right this is a choice. I was just a little bit surprised
that:
1) This choice has not been so well documented,
2) No alternative, except the PATCH-O-MATIC, was proposed to the user.
But, once again, this is my policy choice.
> Any sensible patch to the current documentation has a good chance of being
> applied immediately.
I think, it could help to just add in the Packet-filtering HOWTO,
section 7.3 (Filtering Specifications) :
NEW
A packet which creates a new connection _and_all_ACK_packets_.
It sounds to be fair enough. At least the user know what he's doing.
> Disabling the current behaviour is out of the question. iptables is used
> as-is in the field.
Well, at least the PATCH-O-MATIC can help to disable if you choose it.
:-/
> My personal "must have" reason is proper per-tcp-connection NAT, i.e. the
> ability to change rules without breaking already-active connections.
>
> That's not dependant on reboot/pickup, so I probably personally wouldn't
> care in most setups where I used iptables' conntracking in the past.
>
> But if I learned that such a radical change were imminent, I'd be very
> alert to recall where it may bite me in my "installed base", and I'd
> probably miss one or two.
Well, I won't fight for it. :-)
> all the best, and low jitter to your students' measurements
Thanks for them. :-)
Regards
--
Emmanuel
De gustibus non disputandum.
-- Linus Torvalds
