Re: [PATCH v2 nft] parser: tcpopt: fix tcp option parsing with NUM + length field

[Thomas Haller <thaller@redhat.com>]

On Wed, 2023-12-06 at 13:16 +0100, Florian Westphal wrote:
> Thomas Haller <thaller@redhat.com> wrote:
> > > Instead, feed the json-nft file to nft, then do a normal list-
> > > ruleset,
> > > then compare that vs. normal .nft file.
> > 
> > The .nft and .json-nft files are all fed back into `nft --check -
> > f`. So
> > that is happening too.
> 
> Not really, this checks that the parser eats the input.
> 
> > It will also comparing the raw files (after sanitize+prettify),
> > which
> > is closer to the original thing that is supposed to be tested. That
> > is
> > why it's done.
> 
> "metainfo": {
> -        "json_schema_version": 1,
> +        "version": "VERSION",
> "release_name": "RELEASE_NAME",
> -        "version": "VERSION"
> +        "json_schema_version": 1
> }
> },
> 
> i.e. it fails validation because the on-record file has a different
> layout/ordering than what is expected.

Does this mean all tests on `master` have this problem?

> 
> But if you feed it into nft, nft list ruleset will generate the
> expected
> (non-json) output.

where do you encounter that? How to reproduce this?

Is this an old libjansson? Since 2.8 (2016), JSON_PRESERVE_ORDER is
implied. Maybe libnftables needs to set JSON_PRESERVE_ORDER flag at a
few places.

> 
> > What issues do you mean? I don't see any. Did you test/review the
> > two
> > patches?
> 
> The first one is applied.  The second one I applied locally.
> 
> But its still picky about the formatting.

That's a problem...