Re: [RFC] Die to NOTRACK/TRACE, long live MARK!

[Philip Craig <philipc@snapgear.com>]

Jozsef Kadlecsik wrote:
> We could introduce a new silly target for that purpose like NOTRACK or
> TRACE. However it's pure marking and we do have a interface to mark
> packets: the MARK target. So if we could tell the system which mark value
> has got the given special meaning, we wouldn't need a new target and we
> could even eliminate the NOTRACK/TRACE targets.

I assume this will mean allowing the MARK target to be used in the raw
table, otherwise you can't mark the packets before conntrack.

Will this mean that only one of these features can be used at a time,
since a packet cannot have multiple marks?  And use of any of these
features would preclude current uses of MARK, such as policy routing?
You could add support for masking bits of the mark, but you would have
to add this to the policy routing also.

What happens when you modify the /proc setting?  This will change the
state of packets currently being processed, which could cause problems.

-- 
Philip Craig - SnapGear, A CyberGuard Company - http://www.SnapGear.com