new target or new option

new target or new option

[Kaloyan Kovachev]

Hello,
 i need to mark the connection with the realm number, but it seems there is no
'easy way' and there should be separate rule for each realm.

 Are there any plans to add this functionality and which is the preferable way
to go:
   1) create new REALMCONNMARK target with and/or mask
   2) extend the current CONNMARK by adding --realm-mark in addition to --set-mark

 I think the second one will be easier and can be done in iptables extension
only without touching the kernel source right?

Re: new target or new option

[Jan Engelhardt]

On Sep 28 2007 20:06, Kaloyan Kovachev wrote:
>Hello,
> i need to mark the connection with the realm number, but it seems there is no
>'easy way' and there should be separate rule for each realm.
>
> Are there any plans to add this functionality and which is the preferable way
>to go:
>   1) create new REALMCONNMARK target with and/or mask

Yeah, since there is already an xt_realm, a xt_REALM would be
the logical counterpart.

>   2) extend the current CONNMARK by adding --realm-mark in addition to --set-mark
>
> I think the second one will be easier and can be done in iptables extension
>only without touching the kernel source right?

Re: new target or new option

[Patrick McHardy]

Jan Engelhardt wrote:
> On Sep 28 2007 20:06, Kaloyan Kovachev wrote:
> 
>>Hello,
>>i need to mark the connection with the realm number, but it seems there is no
>>'easy way' and there should be separate rule for each realm.
>>
>>Are there any plans to add this functionality and which is the preferable way
>>to go:
>>  1) create new REALMCONNMARK target with and/or mask
> 
> 
> Yeah, since there is already an xt_realm, a xt_REALM would be
> the logical counterpart.


The realm belongs to the route, it can not be changed.

I'm currently working on the netlink based iptables successor,
perhaps we should split matches into a "collector" part that
gathers the data and some generic range/mask/... matching.
That would allow to tell a target like CONNMARK to gather
the data from somewhere else.

Re: new target or new option

[Kaloyan Kovachev]

On Fri, 28 Sep 2007 19:46:26 +0200, Patrick McHardy wrote
> Jan Engelhardt wrote:
> > On Sep 28 2007 20:06, Kaloyan Kovachev wrote:
> > 
> >>Hello,
> >>i need to mark the connection with the realm number, but it seems there is no
> >>'easy way' and there should be separate rule for each realm.
> >>
> >>Are there any plans to add this functionality and which is the preferable way
> >>to go:
> >>  1) create new REALMCONNMARK target with and/or mask
> > 
> > 
> > Yeah, since there is already an xt_realm, a xt_REALM would be
> > the logical counterpart.
> 
> The realm belongs to the route, it can not be changed.
> 
> I'm currently working on the netlink based iptables successor,
> perhaps we should split matches into a "collector" part that
> gathers the data and some generic range/mask/... matching.
> That would allow to tell a target like CONNMARK to gather
> the data from somewhere else.

Great, this will also replace IPMARK, IPCLASSIFY etc with only common targets
MARK, CONNMARK and CLASSIFY. It would be good to use the same sintax for match
and for the mark value i.e. if the entry is a macth return true or false and
if it is in the target - return the matched value.

Re: new target or new option

[Kaloyan Kovachev]

On Fri, 28 Sep 2007 19:36:15 +0200 (CEST), Jan Engelhardt wrote
> On Sep 28 2007 20:06, Kaloyan Kovachev wrote:
> >Hello,
> > i need to mark the connection with the realm number, but it seems there is no
> >'easy way' and there should be separate rule for each realm.
> >
> > Are there any plans to add this functionality and which is the preferable way
> >to go:
> >   1) create new REALMCONNMARK target with and/or mask
> 
> Yeah, since there is already an xt_realm, a xt_REALM would be
> the logical counterpart.

xt_REALM seams a logical name for changing the realm, not for marking the
packet or connection

> 
> >   2) extend the current CONNMARK by adding --realm-mark in addition to
--set-mark
> >
> > I think the second one will be easier and can be done in iptables extension
> >only without touching the kernel source right?