* new target or new option
@ 2007-09-28 17:06 Kaloyan Kovachev
2007-09-28 17:36 ` Jan Engelhardt
0 siblings, 1 reply; 5+ messages in thread
From: Kaloyan Kovachev @ 2007-09-28 17:06 UTC (permalink / raw)
To: netfilter-devel
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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: new target or new option
2007-09-28 17:06 new target or new option Kaloyan Kovachev
@ 2007-09-28 17:36 ` Jan Engelhardt
2007-09-28 17:46 ` Patrick McHardy
2007-10-01 6:52 ` Kaloyan Kovachev
0 siblings, 2 replies; 5+ messages in thread
From: Jan Engelhardt @ 2007-09-28 17:36 UTC (permalink / raw)
To: Kaloyan Kovachev; +Cc: netfilter-devel
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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: new target or new option
2007-09-28 17:36 ` Jan Engelhardt
@ 2007-09-28 17:46 ` Patrick McHardy
2007-10-01 7:04 ` Kaloyan Kovachev
2007-10-01 6:52 ` Kaloyan Kovachev
1 sibling, 1 reply; 5+ messages in thread
From: Patrick McHardy @ 2007-09-28 17:46 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Kaloyan Kovachev, netfilter-devel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: new target or new option
2007-09-28 17:36 ` Jan Engelhardt
2007-09-28 17:46 ` Patrick McHardy
@ 2007-10-01 6:52 ` Kaloyan Kovachev
1 sibling, 0 replies; 5+ messages in thread
From: Kaloyan Kovachev @ 2007-10-01 6:52 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter-devel
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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: new target or new option
2007-09-28 17:46 ` Patrick McHardy
@ 2007-10-01 7:04 ` Kaloyan Kovachev
0 siblings, 0 replies; 5+ messages in thread
From: Kaloyan Kovachev @ 2007-10-01 7:04 UTC (permalink / raw)
To: Patrick McHardy, Jan Engelhardt; +Cc: netfilter-devel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-10-01 7:04 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-28 17:06 new target or new option Kaloyan Kovachev
2007-09-28 17:36 ` Jan Engelhardt
2007-09-28 17:46 ` Patrick McHardy
2007-10-01 7:04 ` Kaloyan Kovachev
2007-10-01 6:52 ` Kaloyan Kovachev
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).