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:04 +0100, Florian Westphal wrote:
> Florian Westphal <fw@strlen.de> wrote:
> > Thomas Haller <thaller@redhat.com> wrote:
> > > On Wed, 2023-12-06 at 12:38 +0100, Florian Westphal wrote:
> > > > Thomas Haller <thaller@redhat.com> wrote:
> > > > > Hi Florian,
> > > > > 
> > > > > On Tue, 2023-12-05 at 12:56 +0100, Florian Westphal wrote:
> > > > > >  .../packetpath/dumps/tcp_options.nft          | 14 +++++++
> > > > > 
> > > > > is there a reason not to also generate a .json-nft file?
> > > > 
> > > > Yes, I am not adding more one-line monsters.
> > > > 
> > > > I'll add one once there is a solution in place that has human
> > > > readable
> > > > json dumps that don't fail validation because of identical but
> > > > differently formatted output.
> > > > 
> > > 
> > > What about the "[PATCH nft 0/2] pretty print .json-nft files"
> > > patches?
> > 
> > I'm fine with that. Phil? Pablo? This is re:
> > 
> > https://patchwork.ozlabs.org/project/netfilter-devel/patch/20231124124759.3269219-3-thaller@redhat.com/
> 
> What about making it so we NEVER compare json-nft at all?
> 
> 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.

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.

> 
> This avoids any and all formatting issues and also avoids breakage
> when
> the json-nft file is formatted differently.
> 
> Eg. postprocessing via json_pp won't match what this patch above
> expects.
> 

What issues do you mean? I don't see any. Did you test/review the two
patches?


Thomas