However under testing, in practice is not. As covered in the bug. Fields: CTA_IP_V4_DST, CTA_PROTOINFO_TCP_FLAGS_ORIGINAL & CTA_PROTOINFO_TCP_FLAGS_REPLY Result: "**.**.56.135: 10 3" It's only being set on one side. I believe this is because the reply side flags are being set/initialised after the fact (i.e where they are initialised in that function for incoming connections would do it too). On Fri, Oct 21, 2016 at 6:22 PM, Arturo Borrero Gonzalez <arturo@xxxxxxxxxx> wrote: > (please keep the netfilter-devel list in CC) > > On 21 October 2016 at 09:18, Mathew Heard <mat999@xxxxxxxxx> wrote: >> That's been covered already. >> >> The problem with it is that only the ORIG side of the connection ends >> up set. REPLY does not. >> >> I don't know the fundamental reason why this occurs, only the effect. >> > > In that same function, in conntrackd: > http://git.netfilter.org/conntrack-tools/tree/src/netlink.c#n256 > > we set the same flags in both original and reply directions: > > nfct_set_attr_u8(ct, ATTR_TCP_FLAGS_ORIG, flags); > nfct_set_attr_u8(ct, ATTR_TCP_MASK_ORIG, flags); > nfct_set_attr_u8(ct, ATTR_TCP_FLAGS_REPL, flags); > nfct_set_attr_u8(ct, ATTR_TCP_MASK_REPL, flags); -- 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
