netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Erik Skultety <eskultet@redhat.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [iptables PATCH] iptables: xshared: Ouptut '--' in the opt field in ipv6's fake mode
Date: Wed, 20 Jul 2022 16:20:02 +0200	[thread overview]
Message-ID: <20220720142002.GA22790@breakpoint.cc> (raw)
In-Reply-To: <bb391c763171f0c5511f73e383e1b2e6a53e2014.1658322396.git.eskultet@redhat.com>

Erik Skultety <eskultet@redhat.com> wrote:
> The fact that the 'opt' table field reports spaces instead of '--' for
> IPv6 as it would have been the case with IPv4 has a bit of an
> unfortunate side effect that it completely confuses the 'jc' JSON
> formatter tool (which has an iptables formatter module).
> Consider:
>     # ip6tables -L test
>     Chain test (0 references)
>     target     prot opt source   destination
>     ACCEPT     all      a:b:c::  anywhere    MAC01:02:03:04:05:06
> 
> Then:
>     # ip6tables -L test | jc --iptables
>     [{"chain":"test",
>       "rules":[
>           {"target":"ACCEPT",
>            "prot":"all",
>            "opt":"a:b:c::",
>            "source":"anywhere",
>            "destination":"MAC01:02:03:04:05:06"
>           }]
>     }]
> 
> which as you can see is wrong simply because whitespaces are considered
> as a column delimiter.

Looks like ip6tables and iptables had this behaviour since day 1.
original iptables:

       if (format & FMT_OPTIONS) {
               if (format & FMT_NOTABLE)
                       fputs("opt ", stdout);
               fputc(fw->ip.invflags & IPT_INV_FRAG ? '!' :
       		'-', stdout);
               fputc(flags & IPT_F_FRAG ? 'f' : '-', stdout);
               fputc(' ', stdout);
       }

original ip6tables (5eed48af2516ebce0412121713d285bc30edb10d, June 2000):
       if (format & FMT_OPTIONS) {
               if (format & FMT_NOTABLE)
                       fputs("opt ", stdout);
               fputc(' ', stdout);
               fputc(' ', stdout);
               fputc(' ', stdout);
       }

While I like the idea of making those two identical I'm not sure its
worh the risk, we've hit bugs for a myriad of other reasons when making 
seemingly innocent changes like this.

What do others think?

  reply	other threads:[~2022-07-20 14:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-20 13:06 [iptables PATCH] iptables: xshared: Ouptut '--' in the opt field in ipv6's fake mode Erik Skultety
2022-07-20 14:20 ` Florian Westphal [this message]
2022-07-20 16:11   ` Erik Skultety
2022-07-23  9:47     ` Phil Sutter
2022-07-23 12:35       ` Florian Westphal
2022-07-20 16:07 ` Jan Engelhardt
2022-07-20 16:56   ` Erik Skultety
2022-07-21  7:22     ` Jan Engelhardt
2022-07-25 21:39 ` Florian Westphal
2022-07-26  6:55   ` Erik Skultety

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220720142002.GA22790@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=eskultet@redhat.com \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).