netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [rfc] using xor in mark targets
@ 2007-11-29 22:50 Jan Engelhardt
  2007-11-29 23:27 ` Patrick McHardy
  0 siblings, 1 reply; 12+ messages in thread
From: Jan Engelhardt @ 2007-11-29 22:50 UTC (permalink / raw)
  To: Netfilter Developer Mailing List

Hi,


the usual MARK targets all have something like:

	newmark = (oldmark & ~mask) | newmark;

in Fall 2007's tproxy patches, the following is used instead:

	newmark = (oldmark & ~mask) ^ newmark;

this puzzled me at first but looks well-thought. The new xt_TOS
already uses the XOR variant, to get that extra bit of expressive
power[1].

I would have liked to do the same for MARK, but I suspect it is not
quite backwards-compatible with respect to user scripts and
iptables-save output. So what could be done?
	* -j MARK2 --set-mark 0x81/0x7F
	* -j MARK --set-mark-v2 0x81/0x7F
other ideas, thoughts, criticism?


[1] http://www.spinics.net/lists/netfilter-devel/msg00050.html

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [rfc] using xor in mark targets
  2007-11-29 22:50 [rfc] using xor in mark targets Jan Engelhardt
@ 2007-11-29 23:27 ` Patrick McHardy
  2007-12-03 15:03   ` Jan Engelhardt
  0 siblings, 1 reply; 12+ messages in thread
From: Patrick McHardy @ 2007-11-29 23:27 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Netfilter Developer Mailing List

Jan Engelhardt wrote:
> Hi,
>
>
> the usual MARK targets all have something like:
>
> 	newmark = (oldmark & ~mask) | newmark;
>
> in Fall 2007's tproxy patches, the following is used instead:
>
> 	newmark = (oldmark & ~mask) ^ newmark;
>
> this puzzled me at first but looks well-thought. The new xt_TOS
> already uses the XOR variant, to get that extra bit of expressive
> power[1].
>
> I would have liked to do the same for MARK, but I suspect it is not
> quite backwards-compatible with respect to user scripts and
> iptables-save output. So what could be done?
> 	* -j MARK2 --set-mark 0x81/0x7F
> 	* -j MARK --set-mark-v2 0x81/0x7F
> other ideas, thoughts, criticism?
>

Check out:

http://lists.netfilter.org/pipermail/netfilter-devel/2004-June/015718.html

it can be done fully compatible and can express an arbitary amount of
combined bit operations.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [rfc] using xor in mark targets
  2007-11-29 23:27 ` Patrick McHardy
@ 2007-12-03 15:03   ` Jan Engelhardt
  2007-12-03 15:09     ` Patrick McHardy
  0 siblings, 1 reply; 12+ messages in thread
From: Jan Engelhardt @ 2007-12-03 15:03 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: Netfilter Developer Mailing List


On Nov 30 2007 00:27, Patrick McHardy wrote:
>> I would have liked to do the same for MARK, but I suspect it is not
>> quite backwards-compatible with respect to user scripts and
>> iptables-save output. So what could be done?
>>  * -j MARK2 --set-mark 0x81/0x7F
>>  * -j MARK --set-mark-v2 0x81/0x7F
>> other ideas, thoughts, criticism?
>
> Check out:
>
> http://lists.netfilter.org/pipermail/netfilter-devel/2004-June/015718.html
>
> it can be done fully compatible and can express an arbitary amount of
> combined bit operations.
>

Well yes yes... but that was not what I was asking about.


I was asking what name I should give to the option that enables
"new-style" handling (origmark & ~mask ^ val):

	--set-extended-mark val/mask

because it is not sooo extended after all, just a different notation of 
what libxt_MARK takes right now.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [rfc] using xor in mark targets
  2007-12-03 15:03   ` Jan Engelhardt
@ 2007-12-03 15:09     ` Patrick McHardy
  2007-12-03 17:35       ` Jan Engelhardt
  0 siblings, 1 reply; 12+ messages in thread
From: Patrick McHardy @ 2007-12-03 15:09 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Netfilter Developer Mailing List

Jan Engelhardt wrote:
> I was asking what name I should give to the option that enables
> "new-style" handling (origmark & ~mask ^ val):
> 
> 	--set-extended-mark val/mask
> 
> because it is not sooo extended after all, just a different notation of 
> what libxt_MARK takes right now.


Why not simply "--and-mark", "--or-mark", "--xor-mark", ...?


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [rfc] using xor in mark targets
  2007-12-03 15:09     ` Patrick McHardy
@ 2007-12-03 17:35       ` Jan Engelhardt
  2007-12-04  8:11         ` Patrick McHardy
  0 siblings, 1 reply; 12+ messages in thread
From: Jan Engelhardt @ 2007-12-03 17:35 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: Netfilter Developer Mailing List


On Dec 3 2007 16:09, Patrick McHardy wrote:
> Jan Engelhardt wrote:
>> I was asking what name I should give to the option that enables
>> "new-style" handling (origmark & ~mask ^ val):
>> 
>>  --set-extended-mark val/mask
>> 
>> because it is not sooo extended after all, just a different notation of what
>> libxt_MARK takes right now.
>
> Why not simply "--and-mark", "--or-mark", "--xor-mark", ...?
>
Alright, I just saw that MARK will remain compatible to my plans.
But it concerns CONNMARK. See this patch, which introduces --set-xmark.

Assumes a xt_CONNMARK.ko v2 that does:
--set:
	ctmark = (ctmark & info->ctmark_mask) ^ info->ctmark_value;
--save:
	ctmark = (nfmark & info->nfmark_mask) ^ (ctmark & info->ctmark_mask);
--restore:
	nfmark = (nfmark & info->nfmark_mask) ^ (ctmark & info->ctmark_mask);


As you can see, it would introduce a new option "--set-xmark", and
that name does not sound as appalling as --set-mark, so I was looking
for a better one ;-)


---
 extensions/libxt_CONNMARK.c |  266 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 266 insertions(+)

Index: iptables-modules/extensions/libxt_CONNMARK.c
===================================================================
--- iptables-modules.orig/extensions/libxt_CONNMARK.c
+++ iptables-modules/extensions/libxt_CONNMARK.c
@@ -28,6 +28,13 @@
 #include <linux/netfilter/x_tables.h>
 #include <linux/netfilter/xt_CONNMARK.h>
 
+enum {
+	F_HALF_SAVE    = 1 << 0,
+	F_HALF_RESTORE = 1 << 1,
+	F_HALF         = F_HALF_SAVE | F_HALF_RESTORE,
+	F_COMPLETE     = 1 << 2,
+};
+
 #if 0
 struct markinfo {
 	struct xt_entry_target t;
@@ -35,6 +42,13 @@ struct markinfo {
 };
 #endif
 
+struct xt_connmark_target_info_v2 {
+	u_int32_t ctmark_value;
+	u_int32_t ctmark_mask;
+	u_int32_t nfmark_mask;
+	u_int8_t mode;
+};
+
 /* Function which prints out usage message. */
 static void CONNMARK_help(void)
 {
@@ -47,6 +61,19 @@ static void CONNMARK_help(void)
 IPTABLES_VERSION);
 }
 
+static void connmark_tg_help(void)
+{
+	printf(
+		"CONNMARK target v%s options:\n"
+		"  --set-xmark value[/mask]         Set conntrack mark value\n"
+		"  --save-mark                      Copy nfmark to ctmark\n"
+		"  --restore-mark                   Copy ctmark to nfmark\n"
+		"  --save-xmark ctmask[/nfmask]     XOR ctmark with nfmark using masks\n"
+		"  --restore-xmark ctmask[/nfmask]  XOR nfmark with ctmark using masks\n"
+		"\n",
+		IPTABLES_VERSION);
+}
+
 static const struct option CONNMARK_opts[] = {
 	{ "set-mark", 1, NULL, '1' },
 	{ "save-mark", 0, NULL, '2' },
@@ -55,6 +82,18 @@ static const struct option CONNMARK_opts
 	{ }
 };
 
+static const struct option connmark_tg_opts[] = {
+	{.name = "set-xmark",     .has_arg = true,  .val = 'A'},
+	{.name = "save-xmark",    .has_arg = true,  .val = 'S'},
+	{.name = "restore-xmark", .has_arg = true,  .val = 'R'},
+	{.name = "save-mark",     .has_arg = false, .val = 's'},
+	{.name = "restore-mark",  .has_arg = false, .val = 'r'},
+	/* Deprecated options, hence not documented: */
+	{.name = "set-mark",      .has_arg = true,  .val = 'a'},
+	{.name = "mask",          .has_arg = false, .val = 'm'},
+	{},
+};
+
 /* Function which parses command options; returns true if it
    ate an option */
 static int
@@ -112,6 +151,149 @@ CONNMARK_parse(int c, char **argv, int i
 	return 1;
 }
 
+static int
+connmark_tg_parse(int c, char **argv, int invert, unsigned int *flags,
+                  const void *entry, struct xt_entry_target **target)
+{
+	struct xt_connmark_target_info_v2 *info = (void *)(*target)->data;
+	unsigned int value, mask = ~0U;
+	char *end;
+
+	switch (c) {
+	case 'A': /* --set-xmark */
+		if (*flags & (F_COMPLETE | F_HALF))
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: --set-xmark is in "
+			           "conflict with other CONNMARK parameters.");
+		if (!bound_strtou(optarg, &end, &value, 0, ~0U))
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: Illegal value");
+		if (*end == '/')
+			if (!bound_strtou(optarg, &end, &mask, 0, ~0U))
+				exit_error(PARAMETER_PROBLEM,
+				           "CONNMARK target: Illegal mask");
+		if (*end != '\0')
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: Illegal specification");
+		info->mode         = XT_CONNMARK_SET;
+		info->ctmark_value = value;
+		info->ctmark_mask  = mask;
+		*flags            |= F_COMPLETE;
+		break;
+
+	case 'S': /* --save-xmark */
+		if (*flags & (F_COMPLETE | F_HALF))
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: --save-xmark is in "
+			           "conflict with other CONNMARK parameters.");
+		if (!bound_strtou(optarg, &end, &value, 0, ~0U))
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: Illegal ctmask");
+		if (*end == '/')
+			if (!bound_strtou(optarg, &end, &mask, 0, ~0U))
+				exit_error(PARAMETER_PROBLEM,
+				           "CONNMARK target: Illegal nfmask");
+		if (*end != '\0')
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: Illegal specification");
+		info->mode        = XT_CONNMARK_SAVE;
+		info->ctmark_mask = value;
+		info->nfmark_mask = mask;
+		*flags           |= F_COMPLETE;
+		break;
+
+	case 'R': /* --restore-xmark */
+		if (*flags & (F_COMPLETE | F_HALF))
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: --restore-xmark is in "
+			           "conflict with other CONNMARK parameters.");
+		if (!bound_strtou(optarg, &end, &value, 0, ~0U))
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: Illegal ctmask");
+		if (*end == '/')
+			if (!bound_strtou(optarg, &end, &mask, 0, ~0U))
+				exit_error(PARAMETER_PROBLEM,
+				           "CONNMARK target: Illegal nfmask");
+		if (*end != '\0')
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: Illegal specification");
+		info->mode        = XT_CONNMARK_RESTORE;
+		info->ctmark_mask = value;
+		info->nfmark_mask = mask;
+		*flags           |= F_COMPLETE;
+		break;
+
+	case 'a': /* --set-mark */
+		if (*flags & (F_COMPLETE | F_HALF))
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: --set-mark is in "
+			           "conflict with other CONNMARK parameters.");
+		if (!bound_strtou(optarg, &end, &value, 0, ~0U))
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: Illegal value");
+		if (*end == '/')
+			if (!bound_strtou(optarg, &end, &mask, 0, ~0U))
+				exit_error(PARAMETER_PROBLEM,
+				           "CONNMARK target: Illegal mask");
+		if (*end != '\0')
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: Illegal specification");
+		info->mode         = XT_CONNMARK_SET;
+		info->ctmark_value = value;
+		info->ctmark_mask  = ~mask;
+		*flags            |= F_COMPLETE;
+		break;
+
+	case 's': /* --save-mark */
+		if (*flags & (F_COMPLETE | F_HALF))
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: --save-mark is in "
+			           "conflict with other CONNMARK parameters.");
+		info->mode        = XT_CONNMARK_SAVE;
+		info->ctmark_mask = ~0U;
+		info->nfmark_mask = 0;
+		*flags           |= F_HALF_SAVE;
+		break;
+
+	case 'r': /* --restore-mark */
+		if (*flags & (F_COMPLETE | F_HALF))
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: --restore-mark is in "
+			           "conflict with other CONNMARK parameters.");
+		info->mode        = XT_CONNMARK_RESTORE;
+		info->ctmark_mask = 0;
+		info->nfmark_mask = ~0U;
+		*flags           |= F_HALF_RESTORE;
+		break;
+
+	case 'm':
+		if (!(*flags & F_HALF))
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: Need --save-mark or "
+			           "--restore-mark for --mask");
+		if (!bound_strtou(optarg, &end, &mask, 0, ~0U))
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: Illegal value");
+		if (*end != '\0')
+			exit_error(PARAMETER_PROBLEM,
+			           "CONNMARK target: Illegal specifcation");
+		if (*flags & F_HALF_SAVE) {
+			info->ctmark_mask = ~mask;
+			info->nfmark_mask = mask;
+		} else if (*flags & F_HALF_RESTORE) {
+			info->ctmark_mask = mask;
+			info->nfmark_mask = ~mask;
+		}
+		*flags |= F_COMPLETE;
+		break;
+
+	default:
+		return false;
+	}
+
+	return true;
+}
+
 static void CONNMARK_check(unsigned int flags)
 {
 	if (!flags)
@@ -119,6 +301,13 @@ static void CONNMARK_check(unsigned int 
 		           "CONNMARK target: No operation specified");
 }
 
+static void connmark_tg_check(unsigned int flags)
+{
+	if (!(flags & F_COMPLETE))
+		exit_error(PARAMETER_PROBLEM,
+		           "CONNMARK target: No operation specified");
+}
+
 static void
 print_mark(unsigned long mark)
 {
@@ -161,6 +350,29 @@ static void CONNMARK_print(const void *i
 	}
 }
 
+static void
+connmark_tg_print(const void *ip, const struct xt_entry_target *target,
+                  int numeric)
+{
+	const struct xt_connmark_target_info_v2 *info =
+		(const void *)target->data;
+
+	switch (info->mode) {
+		case XT_CONNMARK_SET:
+			printf("MARK set 0x%x/0x%x ",
+			       info->ctmark_value, info->ctmark_mask);
+			break;
+		case XT_CONNMARK_SAVE:
+			printf("CONNMARK save CT:0x%x NF:0x%x ",
+			       info->ctmark_mask, info->nfmark_mask);
+			break;
+		case XT_CONNMARK_RESTORE:
+			printf("CONNMARK restore CT:0x%x NF:0x%x ",
+			       info->ctmark_mask, info->nfmark_mask);
+			break;
+	}
+}
+
 /* Saves the target into in parsable form to stdout. */
 static void CONNMARK_save(const void *ip, const struct xt_entry_target *target)
 {
@@ -188,6 +400,28 @@ static void CONNMARK_save(const void *ip
 	}
 }
 
+static void
+connmark_tg_save(const void *ip, const struct xt_entry_target *target)
+{
+	const struct xt_connmark_target_info_v2 *info =
+		(const void *)target->data;
+
+	switch (info->mode) {
+		case XT_CONNMARK_SET:
+			printf("--set-xmark 0x%x/0x%x ",
+			       info->ctmark_value, info->ctmark_mask);
+			break;
+		case XT_CONNMARK_SAVE:
+			printf("--save-xmark 0x%x/0x%x ",
+			       info->ctmark_mask, info->nfmark_mask);
+			break;
+		case XT_CONNMARK_RESTORE:
+			printf("--restore-mark 0x%x/0x%x ",
+			       info->ctmark_mask, info->nfmark_mask);
+			break;
+	}
+}
+
 static struct xtables_target connmark_target = {
 	.family		= AF_INET,
 	.name		= "CONNMARK",
@@ -216,8 +450,40 @@ static struct xtables_target connmark_ta
 	.extra_opts	= CONNMARK_opts,
 };
 
+static struct xtables_target connmark_tg_reg = {
+	.version       = IPTABLES_VERSION,
+	.name          = "CONNMARK",
+	.revision      = 2,
+	.family        = AF_INET,
+	.size          = XT_ALIGN(sizeof(struct xt_connmark_target_info_v2)),
+	.userspacesize = XT_ALIGN(sizeof(struct xt_connmark_target_info_v2)),
+	.help          = connmark_tg_help,
+	.parse         = connmark_tg_parse,
+	.final_check   = connmark_tg_check,
+	.print         = connmark_tg_print,
+	.save          = connmark_tg_save,
+	.extra_opts    = connmark_tg_opts,
+};
+
+static struct xtables_target connmark_tg6_reg = {
+	.version       = IPTABLES_VERSION,
+	.name          = "CONNMARK",
+	.revision      = 2,
+	.family        = AF_INET6,
+	.size          = XT_ALIGN(sizeof(struct xt_connmark_target_info_v2)),
+	.userspacesize = XT_ALIGN(sizeof(struct xt_connmark_target_info_v2)),
+	.help          = connmark_tg_help,
+	.parse         = connmark_tg_parse,
+	.final_check   = connmark_tg_check,
+	.print         = connmark_tg_print,
+	.save          = connmark_tg_save,
+	.extra_opts    = connmark_tg_opts,
+};
+
 void _init(void)
 {
 	xtables_register_target(&connmark_target);
 	xtables_register_target(&connmark_target6);
+	xtables_register_target(&connmark_tg_reg);
+	xtables_register_target(&connmark_tg6_reg);
 }

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [rfc] using xor in mark targets
  2007-12-03 17:35       ` Jan Engelhardt
@ 2007-12-04  8:11         ` Patrick McHardy
  2007-12-04  8:54           ` Jan Engelhardt
  0 siblings, 1 reply; 12+ messages in thread
From: Patrick McHardy @ 2007-12-04  8:11 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Netfilter Developer Mailing List

Jan Engelhardt wrote:
> On Dec 3 2007 16:09, Patrick McHardy wrote:
>> Jan Engelhardt wrote:
>>> I was asking what name I should give to the option that enables
>>> "new-style" handling (origmark & ~mask ^ val):
>>>
>>>  --set-extended-mark val/mask
>>>
>>> because it is not sooo extended after all, just a different notation of what
>>> libxt_MARK takes right now.
>> Why not simply "--and-mark", "--or-mark", "--xor-mark", ...?
>>
> Alright, I just saw that MARK will remain compatible to my plans.
> But it concerns CONNMARK. See this patch, which introduces --set-xmark.
> 
> Assumes a xt_CONNMARK.ko v2 that does:
> --set:
> 	ctmark = (ctmark & info->ctmark_mask) ^ info->ctmark_value;
> --save:
> 	ctmark = (nfmark & info->nfmark_mask) ^ (ctmark & info->ctmark_mask);
> --restore:
> 	nfmark = (nfmark & info->nfmark_mask) ^ (ctmark & info->ctmark_mask);
> 
> 
> As you can see, it would introduce a new option "--set-xmark", and
> that name does not sound as appalling as --set-mark, so I was looking
> for a better one ;-)


It would be easier for me if you'd explain what every option does,
especially why you need this set-xmark option.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [rfc] using xor in mark targets
  2007-12-04  8:11         ` Patrick McHardy
@ 2007-12-04  8:54           ` Jan Engelhardt
  2007-12-04  9:17             ` Patrick McHardy
  0 siblings, 1 reply; 12+ messages in thread
From: Jan Engelhardt @ 2007-12-04  8:54 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: Netfilter Developer Mailing List


On Dec 4 2007 09:11, Patrick McHardy wrote:
>> But it concerns CONNMARK. See this patch, which introduces --set-xmark.
>> 
>> Assumes a xt_CONNMARK.ko v2 that does:
>> --set:
>> 	ctmark = (ctmark & info->ctmark_mask) ^ info->ctmark_value;
>> --save:
>> 	ctmark = (nfmark & info->nfmark_mask) ^ (ctmark & info->ctmark_mask);
>> --restore:
>>  nfmark = (nfmark & info->nfmark_mask) ^ (ctmark & info->ctmark_mask);
>> 
>> As you can see, it would introduce a new option "--set-xmark", and
>> that name does not sound as appalling as --set-mark, so I was looking
>> for a better one ;-)
>
> It would be easier for me if you'd explain what every option does,
> especially why you need this set-xmark option.
>
--set-xmark would use the (yet to be written) xt_CONNMARK v2 semantic,
while --set-mark would do the compatible v0/v1 one.

What xt_CONNMARK does at the moment (.revision=0/1):
	ctmark = (ctmark & info->mask) | info->mark;

Essential operation of xt_CONNMARK (.revision=2):
>> 	ctmark = (ctmark & info->ctmark_mask) ^ info->ctmark_value;

For CONNMARK, this allows to and/or/xor bits in one go rather than just
selectively and/or, as it is now.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [rfc] using xor in mark targets
  2007-12-04  8:54           ` Jan Engelhardt
@ 2007-12-04  9:17             ` Patrick McHardy
  2007-12-04 10:52               ` Jan Engelhardt
  0 siblings, 1 reply; 12+ messages in thread
From: Patrick McHardy @ 2007-12-04  9:17 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Netfilter Developer Mailing List

Jan Engelhardt wrote:
> On Dec 4 2007 09:11, Patrick McHardy wrote:
>>> But it concerns CONNMARK. See this patch, which introduces --set-xmark.
>>>
>>> Assumes a xt_CONNMARK.ko v2 that does:
>>> --set:
>>> 	ctmark = (ctmark & info->ctmark_mask) ^ info->ctmark_value;
>>> --save:
>>> 	ctmark = (nfmark & info->nfmark_mask) ^ (ctmark & info->ctmark_mask);
>>> --restore:
>>>  nfmark = (nfmark & info->nfmark_mask) ^ (ctmark & info->ctmark_mask);
>>>
>>> As you can see, it would introduce a new option "--set-xmark", and
>>> that name does not sound as appalling as --set-mark, so I was looking
>>> for a better one ;-)
>> It would be easier for me if you'd explain what every option does,
>> especially why you need this set-xmark option.
>>
> --set-xmark would use the (yet to be written) xt_CONNMARK v2 semantic,
> while --set-mark would do the compatible v0/v1 one.
> 
> What xt_CONNMARK does at the moment (.revision=0/1):
> 	ctmark = (ctmark & info->mask) | info->mark;
> 
> Essential operation of xt_CONNMARK (.revision=2):
>>> 	ctmark = (ctmark & info->ctmark_mask) ^ info->ctmark_value;
> 
> For CONNMARK, this allows to and/or/xor bits in one go rather than just
> selectively and/or, as it is now.


I still don't see why you can't keep --set-mark and add new options
--and-mark, --xor-mark, ...




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [rfc] using xor in mark targets
  2007-12-04  9:17             ` Patrick McHardy
@ 2007-12-04 10:52               ` Jan Engelhardt
  2007-12-04 10:54                 ` Patrick McHardy
  0 siblings, 1 reply; 12+ messages in thread
From: Jan Engelhardt @ 2007-12-04 10:52 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: Netfilter Developer Mailing List


On Dec 4 2007 10:17, Patrick McHardy wrote:
>
> I still don't see why you can't keep --set-mark and add new options
> --and-mark, --xor-mark, ...
>

	-j CONNMARK --xor-mark 0x01
	-j CONNMARK --and-mark 0xffffffdf
	-j CONNMARK --or-mark 0x400

I would prefer the single invocation:

	-j CONNMARK --set-xmark 0x401/0xfffffbdf

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [rfc] using xor in mark targets
  2007-12-04 10:52               ` Jan Engelhardt
@ 2007-12-04 10:54                 ` Patrick McHardy
  2007-12-04 14:05                   ` Jan Engelhardt
  0 siblings, 1 reply; 12+ messages in thread
From: Patrick McHardy @ 2007-12-04 10:54 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Netfilter Developer Mailing List

Jan Engelhardt wrote:
> On Dec 4 2007 10:17, Patrick McHardy wrote:
>> I still don't see why you can't keep --set-mark and add new options
>> --and-mark, --xor-mark, ...
>>
> 
> 	-j CONNMARK --xor-mark 0x01
> 	-j CONNMARK --and-mark 0xffffffdf
> 	-j CONNMARK --or-mark 0x400
> 
> I would prefer the single invocation:
> 
> 	-j CONNMARK --set-xmark 0x401/0xfffffbdf
> 

I wouldn't, thats way less readable :) Feel free to add a xmark
(maybe --raw-mark?) option, but the other ones should still exist
and --set-mark should behave as currently.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [rfc] using xor in mark targets
  2007-12-04 10:54                 ` Patrick McHardy
@ 2007-12-04 14:05                   ` Jan Engelhardt
  2007-12-04 14:08                     ` Patrick McHardy
  0 siblings, 1 reply; 12+ messages in thread
From: Jan Engelhardt @ 2007-12-04 14:05 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: Netfilter Developer Mailing List


On Dec 4 2007 11:54, Patrick McHardy wrote:
> Jan Engelhardt wrote:
>> On Dec 4 2007 10:17, Patrick McHardy wrote:
>> > I still don't see why you can't keep --set-mark and add new options
>> > --and-mark, --xor-mark, ...
>> >
>> 
>>  -j CONNMARK --xor-mark 0x01
>>  -j CONNMARK --and-mark 0xffffffdf
>>  -j CONNMARK --or-mark 0x400
>> 
>> I would prefer the single invocation:
>> 
>>  -j CONNMARK --set-xmark 0x401/0xfffffbdf
>
> I wouldn't, thats way less readable :) Feel free to add a xmark
> (maybe --raw-mark?) option, but the other ones should still exist
> and --set-mark should behave as currently.
>
If you had looked at the patch, it keeps all the original options :-)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [rfc] using xor in mark targets
  2007-12-04 14:05                   ` Jan Engelhardt
@ 2007-12-04 14:08                     ` Patrick McHardy
  0 siblings, 0 replies; 12+ messages in thread
From: Patrick McHardy @ 2007-12-04 14:08 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Netfilter Developer Mailing List

Jan Engelhardt wrote:
> On Dec 4 2007 11:54, Patrick McHardy wrote:
>> Jan Engelhardt wrote:
>>> On Dec 4 2007 10:17, Patrick McHardy wrote:
>>>> I still don't see why you can't keep --set-mark and add new options
>>>> --and-mark, --xor-mark, ...
>>>>
>>>  -j CONNMARK --xor-mark 0x01
>>>  -j CONNMARK --and-mark 0xffffffdf
>>>  -j CONNMARK --or-mark 0x400
>>>
>>> I would prefer the single invocation:
>>>
>>>  -j CONNMARK --set-xmark 0x401/0xfffffbdf
>> I wouldn't, thats way less readable :) Feel free to add a xmark
>> (maybe --raw-mark?) option, but the other ones should still exist
>> and --set-mark should behave as currently.
>>
> If you had looked at the patch, it keeps all the original options :-)


"The others" was refering to --and-mark, --or-mark etc.

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2007-12-04 14:08 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-29 22:50 [rfc] using xor in mark targets Jan Engelhardt
2007-11-29 23:27 ` Patrick McHardy
2007-12-03 15:03   ` Jan Engelhardt
2007-12-03 15:09     ` Patrick McHardy
2007-12-03 17:35       ` Jan Engelhardt
2007-12-04  8:11         ` Patrick McHardy
2007-12-04  8:54           ` Jan Engelhardt
2007-12-04  9:17             ` Patrick McHardy
2007-12-04 10:52               ` Jan Engelhardt
2007-12-04 10:54                 ` Patrick McHardy
2007-12-04 14:05                   ` Jan Engelhardt
2007-12-04 14:08                     ` Patrick McHardy

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).