On 15 January 2014 23:50, Patrick McHardy <kaber@xxxxxxxxx> wrote: > [resending because of incorrect list address] > > I was looking at some incorrect output in netlink debugging for set elements > and noticed a few things that seem odd: > > First, the regular netlink debugging seems very incomplete, it doesn't > print verdict types, it prints [end] whether the set contains intervals > and the set is an interval end or not and its messing up the output. > It's true, most of the development went to the JSON/XML formats, not the default one. > Next I'm wondering about what DATA_CHAIN is supposed to be. I guess its > the chain for a jump or goto verdict, This is even encoded in the > XML and JSON output. This seems wrong to me, there is no DATA_CHAIN, > there are JUMP or GOTO verdicts that include a chain. The specific > verdict is also missing, so its not possible to distinguish these > two cases. > Ok, let's fix that. Do you have a proposal? This is what I think you want: * a <data_reg type=value> with raw data. * a <data_reg type=verdict> with a concrete verdict (eg drop accept) * a <data_reg type=jump> with a chain to jump to. * a <data_reg type=goto> with a chain to go to. Or maybe: * a <data_reg type=value> with raw data. * a <data_reg type=verdict> with a concrete verdict (eg drop accept) and if verdict == jump or goto, then a <chain> with the destination. > I could fix up the debugging output, but this looks like someone more > familiar with the XML and JSON stuff should have a look at this and > fix all of this consistently before we release it as wire format. I can handle it. regards -- Arturo Borrero González -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
