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