Difference between match and target

Difference between match and target

[Sumit Pandya]

Hi All,

    What is difference between writing match and target extension for
netfilter? Is there something in match which I cannot achieve in target and
vice-versa?
    So far I's under impression that I cannot alter skb in match because of
prototype for "match_entry()". Today I did following test with ipt_tos.c

static int
-- match(const struct sk_buff *skb,
      const struct net_device *in,
static int
++ match( struct sk_buff *skb,
      const struct net_device *in,

       const struct ipt_tos_info *info = matchinfo;
--    const struct iphdr *iph = skb->nh.iph;
--
--     return (iph->tos == info->tos) ^ info->invert;
++    struct iphdr *iph = skb->nh.iph;
++    u_int16_t diffs[2];
++
++        diffs[0] = htons(iph->tos) ^ 0xFFFF;
++        iph->tos = (iph->tos & IPTOS_PREC_MASK) | 0xFF;
++        diffs[1] = htons(iph->tos);
++        iph->check = csum_fold(csum_partial((char *)diffs,
++                                            sizeof(diffs),
++                                             iph->check^0xFFFF));
++        skb->nfcache |= NFC_ALTERED;
++        return IPT_CONTINUE;

then appended a rule for tos match with this changed match module inserted
into kernel.
[root@manage netfilter]# iptables -I OUTPUT -p tcp --dport 25  -m tos \
--tos 0x04 -j RETURN

 And surprisingly(for me), On the other machine when I observed traffic for
port 25, I get packet with TOS set to 0xFF.

 Someone to throw some light on this design? Mr. Rusty, Mr. Harald?

-- Sumit

Re: Difference between match and target

[Harald Welte]

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

On Fri, Jun 20, 2003 at 06:33:58PM +0530, Sumit Pandya wrote:
> Hi All,
> 
>     What is difference between writing match and target extension for
> netfilter? Is there something in match which I cannot achieve in target and
> vice-versa?

from a technical point of view, there is not much differrence. 
There are no technical restrictions, it's a mere policy:
Matches match against packet data
Targets connect some action with previously matched packets.

>  Someone to throw some light on this design? Mr. Rusty, Mr. Harald?
> 
> -- Sumit

-- 
- 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 --]

Re: Difference between match and target

[Sumit Pandya]

Hi Harald and All,
    Then do Netfilter core team or Netfilter individual module authors will
think of reconsidering this policy? Like ipt_foo and ipt_FOO can be combined
in one kernel module and that module will call both ipt_register_match and
ipt_register_target in MODULE_INIT. In my point of view if we are inserting
2 modules then it is definitely consuming extra (some) memory of kernel.
-- Sumit

> Date: Tue, 24 Jun 2003 18:08:24 +0200
> From: Harald Welte <laforge@netfilter.org>
>
> On Fri, Jun 20, 2003 at 06:33:58PM +0530, Sumit Pandya wrote:
> >     What is difference between writing match and target extension for
> > netfilter? Is there something in match which I cannot achieve in target
a=
> nd
> > vice-versa?
>
> From a technical point of view, there is not much differrence.
> There are no technical restrictions, it's a mere policy:
> Matches match against packet data
> Targets connect some action with previously matched packets.

Re: Difference between match and target

[Harald Welte]

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

On Wed, Jun 25, 2003 at 11:59:06AM +0530, Sumit Pandya wrote:
> Hi Harald and All,
>     Then do Netfilter core team or Netfilter individual module authors will
> think of reconsidering this policy? 

No, not really.

> Like ipt_foo and ipt_FOO can be combined in one kernel module and that
> module will call both ipt_register_match and ipt_register_target in
> MODULE_INIT. In my point of view if we are inserting 2 modules then it
> is definitely consuming extra (some) memory of kernel.

yes, every module consumes at least one page (4k on x86).  So if you
want to save that memory (and even more, by skipping the __exit
functions), statically link it into the kernel rather than using a
module.

btw: you can do this now (having match and target in one kernel module,
registering as match and target - but this would break iptables
module-on-demand-loading code).  Where should iptables  know from, that
when the user specifies '-m foo' it should load a kernel module called
'ipt_BAR.o' ?

> -- Sumit

-- 
- 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 --]

Re: Difference between match and target

[Andy Whitcroft]

--On 25 June 2003 11:10 +0200 Harald Welte <laforge@netfilter.org> wrote:

> btw: you can do this now (having match and target in one kernel module,
> registering as match and target - but this would break iptables
> module-on-demand-loading code).  Where should iptables  know from, that
> when the user specifies '-m foo' it should load a kernel module called
> 'ipt_BAR.o' ?

I guess we could say that this could be placed in the modules 
configuration.  Are not aliases in modules.conf used for exactly this kind 
of thing for instance when probing for eth0?  That said it would add a 
significant maintenance overhead to keep the netfilter specific aliases in 
sync with the kernel.  Given that if you care about 1 page you likely 
should not be using modules anyhow its likely not worth the effort.

Cheers.

-apw