On 18-01-17 17:03, Pablo Neira Ayuso wrote: > On Wed, Jan 18, 2017 at 04:07:45PM +0100, Florian Westphal wrote: >> Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: >>> On Wed, Jan 18, 2017 at 03:54:32PM +0100, Florian Westphal wrote: >>>> destroy events currently don't contain the tcp state info and no >>>> secmark and conntrack labels. >>>> >>>> Quoting Victor: >>>> "I was hoping to get the last TCP state in a conntrack destroy event, >>>> however it seems to be unavailable." >>>> >>>> Quoting Jarno: >>>> "I have a use case where we want to log terminating connections, but >>>> only if a specific label bit is set." >>>> >>>> While at it, also include SECMARK in destroy events if one is available. >>> >>> I'm fine with this. >>> >>> But to remember the original problem is that netlink bandwidth is >>> limited, so the more we load the netlink message, the more chances we >>> have to hit ENOBUFS. >>> >>> connlabel is optional, so you only get it if needed. >> >> Yes, and only if there was a label change or at least one label bit is >> set. >> >>> But the protoinfo thing, I would prefer we just dump the state given >>> this the usecase we have now. >>> >>> Probably extend ->to_nlattr() to have a bool that indicates if this is >>> a dump? >> >> Could do that by it only avoids 4 attributes (so we only save 32bytes >> per message). > > IIRC, the destroy message is rather small. Moreover, think of > thousands of messages in that queue, that makes a difference. And I > cannot think of anything useful people can do with window scale and > flags at that stage, right? If with flags you mean tracking the tcp flags seen (SYN, RST, etc), then I think that could be useful. Netflow logging often logs that. I was planning to use that when/if it's available. -- --------------------------------------------- Victor Julien http://www.inliniac.net/ PGP: http://www.inliniac.net/victorjulien.asc --------------------------------------------- -- 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
