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