Erik Skultety <eskultet@xxxxxxxxxx> 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?
