On Wed, Jul 20, 2022 at 04:20:02PM +0200, Florian Westphal wrote:
> 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.
Hmm, the only reason why I submitted this change is because our libvirt test
suite suddenly started failing on CentOS Stream 9 and only on CS9. Now, the
test suite is flawed in its own way checking libvirt actions against iptables
CLI output (yes, very fragile), but at the time the tests were written there
essentially wasn't a programatic way of checking the changes like we could do
today with the nftables library and its JSON formatter.
So I investigated what's changed on CentOS Stream 9 compared to CS8 or Fedora
35/36 and it turned out that CS9 ships iptables-nft 1.8.8 while e.g. Fedora 36
ships 1.8.7 (so we're bound to failures there as well in the future).
Let me describe the output difference in between the 2 versions of iptables:
< v1.8.8
# ip6tables -L FI-tck-7081731
Chain FI-tck-7081731 (1 references)
target prot opt source destination
RETURN icmpv6 f:e:d::c:b:a/127 a:b:c::d:e:f MAC01:02:03:04:05:06 DSCP match 0x02 ipv6-icmptype 12 code 11 ctstate NEW,ESTABLISHED
*** NOTE ^^HERE ***
>= v1.8.8
ip6tables -L FI-tck-7081731
Chain FI-tck-7081731 (1 references)
target prot opt source destination
RETURN ipv6-icmp f:e:d::c:b:a/127 a:b:c::d:e:f MAC01:02:03:04:05:06 DSCP match 0x02 ipv6-icmptype 12 code 11 ctstate NEW,ESTABLISHED
*** NOTE ^^HERE ***
If my detective work was correct it was caused by commit
b6196c7504d4d41827cea86c167926125cdbf1f3 which swapped the order of the
protocol keys in the 'xtables_chain_protos'.
If the protocol key order could be reverted back to its previous state then
essentially it doesn't matter much to libvirt whether this patch lands in or
not (well, it would have to be downstreamed to both CS9 and Fedora 36 anyway),
I'm just looking for ways to fix our test suite even though I'd like to make
use of a more programatic way of checking the chain rules, e.g. the JSON output
as we've had many breakages in this area over the past couple of years. Note
that the 'nft's JSON parser is currently not an answer for us in ^^this regard
as for some reason it doesn't format the iptables' module extension data like
the source MAC 01:02... you see above, but it does so when the rule was created
with the nft frontend - I'm going to file a bug about this.
Regards,
Erik
