Re: target MARK in filter table?

[Harald Welte <laforge@netfilter.org>]

[-- Attachment #1: Type: text/plain, Size: 2699 bytes --]

On Sun, Jul 13, 2003 at 04:19:44PM +0200, Patrick Schaaf wrote:
> > If you do know a reason why this must not be done, please tell me. MARK is
> > usefull even without advanced routing.
> 
> I do not disagree, the rerouting indecision was just the one possible reason
> I could think of.
> 
> What do other developers think? What other reasons were there to keep the MARK
> target from working in the filter table?

Because it violates our idea of the iptables framework.  It is a policy
kind of decision, not a 'what is technically possible' decision.

The idea is to have targets for filtering in the filter table - and
anything that modifies the packet [or potentially affect other kernel
subsystems such as policy routing] in 'mangle'.

We could enable almost all mangle targets to be used in the filter
table, there is no inherent technical limitation.

But it just feels wrong with regard to the policy we are trying to
enforce.

In that particular practical case, I think Poltorak Serguei is 'abusing'
the mark mechanism for something that we didn't think it should be 

> While we are on the topic of seemingly arbitrary "sanity" checks, why is
> it that using the TCPMSS option throws a vague "invalid argument" error
> when one forgets to also specify --syn? Can't that target just check for
> tcp/syn dynamically, i.e. become a NOOP for non-syn packets, instead of
> forcing me to specify --syn at rule insertion time?

Error reporting is a whole discussion that I've had at least once a
couple of years ago.  There is no sane way to add verbose error
reporting back to iptables userspace because of the set/getsockopt
interface :(

the best we can do is printk() the error and ask the user to check dmesg
in case we receive -EINVAL.

But returning an error in this case is IMHO the correct behaviour.  What
is the idea behind blindly accepting rules that don't make sense for
non-syn packets?

And if there is one mechanism of checking for SYN, why should we
implement this check in other places as well?

Also, it gives the user/administrator a chance to see what is really
happening.  The user will know that TCPMSS will only affect SYN packets,
not any other (something he most likely doesn't know when it just
magically works).

> best regards
>   Patrick

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]