[PATCH ulogd2] nfct: add flow end timestamp on hashtable purge

[PATCH ulogd2] nfct: add flow end timestamp on hashtable purge

[Corubba Smith]

In polling mode during normal operation, as well as in event mode with
hashtable when an overrun occurs, the hashtable is fully re-synced
against conntrack. When removing flows from the hashtable that are no
longer in conntrack, there is no way to get the actual end timestamp of
the flow from conntrack because it is already gone. Since the last
conntrack data in the hashtable for these flows will never contain an
end timestamp in this case, set_timestamp_from_ct() will always fall
back to using the current time, aka when the plugin determines that the
flow disappeared from conntrack. That is only an approximation, but
should be good enough; and certainly more accurate than no end timestamp
at all.

Signed-off-by: Corubba Smith <corubba@gmx.de>
---
 input/flow/ulogd_inpflow_NFCT.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/input/flow/ulogd_inpflow_NFCT.c b/input/flow/ulogd_inpflow_NFCT.c
index 93edb76..bddc9cc 100644
--- a/input/flow/ulogd_inpflow_NFCT.c
+++ b/input/flow/ulogd_inpflow_NFCT.c
@@ -911,6 +911,7 @@ static int do_purge(void *data1, void *data2)
 	/* if it is not in kernel anymore, purge it */
 	ret = nfct_query(cpi->pgh, NFCT_Q_GET, ts->ct);
 	if (ret == -1 && errno == ENOENT) {
+		set_timestamp_from_ct(ts, ts->ct, STOP);
 		do_propagate_ct(upi, ts->ct, NFCT_T_DESTROY, ts);
 		hashtable_del(cpi->ct_active, &ts->hashnode);
 		nfct_destroy(ts->ct);
--
2.49.0

Re: [PATCH ulogd2] nfct: add flow end timestamp on hashtable purge

[Florian Westphal]

Corubba Smith <corubba@gmx.de> wrote:
> In polling mode during normal operation, as well as in event mode with
> hashtable when an overrun occurs, the hashtable is fully re-synced
> against conntrack. When removing flows from the hashtable that are no
> longer in conntrack, there is no way to get the actual end timestamp of
> the flow from conntrack because it is already gone. Since the last
> conntrack data in the hashtable for these flows will never contain an
> end timestamp in this case, set_timestamp_from_ct() will always fall
> back to using the current time, aka when the plugin determines that the
> flow disappeared from conntrack. That is only an approximation, but
> should be good enough; and certainly more accurate than no end timestamp
> at all.

Makes sense to me, I'll apply it later today unless there are
objections.