Hi Pablo, On Sat, Nov 21, 2020 at 01:11:54PM +0100, Pablo Neira Ayuso wrote: > On Fri, Nov 20, 2020 at 08:37:23PM +0100, Phil Sutter wrote: > > Hi, > > > > On Fri, Nov 20, 2020 at 07:50:00PM +0100, Pablo Neira Ayuso wrote: > > > On Fri, Nov 20, 2020 at 06:57:57PM +0100, Phil Sutter wrote: > > > > Netlink debug output varies depending on host's endianness and therefore > > > > the test fails on Big Endian machines. Since for the sake of asserting > > > > no needless bitwise expressions in output the actual data values are not > > > > relevant, simply crop the output to just the expression names. > > > > > > Probably we can fix this in libnftnl before we apply patches like this > > > to nft as well? > > > > You're right, ignoring the problems in nft testsuite is pretty > > inconsistent. OTOH this is the first test that breaks iptables testsuite > > on Big Endian while nft testsuite is entirely broken. ;) > > Do you think we can fix this from the testsuite site? It would require > to replicate payload files. The snprintf printing is used for > debugging only at this stage. That would fix nft and this specific case. > > > I had a look at libnftnl and it seems like even kernel support is needed > > to carry the endianness info from input to output. IMHO data should be > > in a consistent format in netlink messages, but I fear we can't change > > this anymore. I tried to print the data byte-by-byte, but we obviously > > still get problems with any data in host byte order. Do you see an > > easier way to fix this than adding extra info to all expressions > > containing data? > > Probably we can make assumptions based on context, such as payload > expression always express things in network byte order, and annotate > that such register stores something in network byteorder. For meta, > assume host byte order. Unless there is an explicit byteorder > expression. I like this simple approach, but it's not easy to implement: libnftnl doesn't know about other expressions, so 'cmp' for instance doesn't know which expression stored data in reg 1 and therefore can't deduce the likely endianness of its stored data. Any idea how to solve that? Thanks, Phil
