From: Tomasz Pala <gotar@polanet.pl>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH ulogd] log NAT events using IPFIX
Date: Wed, 13 Dec 2023 13:27:08 +0100 [thread overview]
Message-ID: <20231213122708.GD18912@polanet.pl> (raw)
In-Reply-To: <20231212184413.GA2168@polanet.pl>
[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]
The flow.end field for NEW connections has a value of 0.
However it seems that the flowEnd* IPFIX are commonly interpreted as
"last seen" timestamps.
From https://www.iana.org/assignments/ipfix/ipfix.xhtml:
153 flowEndMilliseconds The absolute timestamp of the last packet of this Flow.
It's not clear whether "last packet" should be read as "final/closing packet",
but with this field carrying a value of 0 the nfdump doesn't handle the
flowStartMilliseconds value as well.
Moreover, NF_NETLINK_CONNTRACK_UPDATE events also set flow.end to
timestamp of last packet _seen_, with the connection being still
established (UPDATEd connection is on-going per-se, until DESTROY).
The actual state of the flow, i.e. it's termination, should be read
directly from event type (firewallEvent/natEvent fields), not derived
from flowEnd* having non-zero value.
Therefore, when flow.end is not set, make it equal to flow.start, as
initiating packet and the last one are the same.
As this change is only 1 line, I've left the remaining notes and comments here.
--
Tomasz Pala <gotar@pld-linux.org>
[-- Attachment #2: ulogd2-last_seen.patch --]
[-- Type: text/plain, Size: 3741 bytes --]
diff --color '--palette=ad=1;38;5;155:de=1;38;5;205:hd=1;36:ln=35;1;3' -U5 -ru ddd/ulogd2/input/flow/ulogd_inpflow_NFCT.c ./input/flow/ulogd_inpflow_NFCT.c
--- ddd/input/flow/ulogd_inpflow_NFCT.c 2023-12-13 12:14:03.137497479 +0100
+++ aaa/input/flow/ulogd_inpflow_NFCT.c 2023-12-13 10:12:46.267523061 +0100
@@ -244,21 +244,20 @@
.flags = ULOGD_RETF_NONE,
.name = "orig.raw.pktlen",
.ipfix = {
.vendor = IPFIX_VENDOR_IETF,
.field_id = IPFIX_octetTotalCount,
- /* FIXME: this could also be octetDeltaCount */
},
},
{
.type = ULOGD_RET_UINT64,
.flags = ULOGD_RETF_NONE,
.name = "orig.raw.pktcount",
.ipfix = {
.vendor = IPFIX_VENDOR_IETF,
.field_id = IPFIX_packetTotalCount,
- /* FIXME: this could also be packetDeltaCount */
+ /* FIXME: this could also be egressUnicastPacketTotalCount */
},
},
{
.type = ULOGD_RET_IPADDR,
.flags = ULOGD_RETF_NONE,
@@ -309,21 +308,20 @@
.flags = ULOGD_RETF_NONE,
.name = "reply.raw.pktlen",
.ipfix = {
.vendor = IPFIX_VENDOR_IETF,
.field_id = IPFIX_octetTotalCount,
- /* FIXME: this could also be octetDeltaCount */
},
},
{
.type = ULOGD_RET_UINT64,
.flags = ULOGD_RETF_NONE,
.name = "reply.raw.pktcount",
.ipfix = {
.vendor = IPFIX_VENDOR_IETF,
.field_id = IPFIX_packetTotalCount,
- /* FIXME: this could also be packetDeltaCount */
+ /* FIXME: this could also be ingressUnicastPacketTotalCount */
},
},
{
.type = ULOGD_RET_UINT8,
.flags = ULOGD_RETF_NONE,
diff --color '--palette=ad=1;38;5;155:de=1;38;5;205:hd=1;36:ln=35;1;3' -U5 -ru ddd/ulogd2/output/ipfix/ulogd_output_IPFIX.c ./output/ipfix/ulogd_output_IPFIX.c
--- ddd/output/ipfix/ulogd_output_IPFIX.c 2023-12-13 12:14:03.137497479 +0100
+++ aaa/output/ipfix/ulogd_output_IPFIX.c 2023-12-13 11:59:52.652179788 +0100
@@ -488,19 +566,21 @@
data->saddr.s_addr = ikey_get_u32(&pi->input.keys[InIpSaddr]);
data->daddr.s_addr = ikey_get_u32(&pi->input.keys[InIpDaddr]);
data->tsaddr.s_addr = ikey_get_u32(&pi->input.keys[InTIpSaddr]);
data->tdaddr.s_addr = ikey_get_u32(&pi->input.keys[InTIpDaddr]);
+ /* TODO: send full uint64_t */
data->packets = htonl((uint32_t) (ikey_get_u64(&pi->input.keys[InRawInPktCount])
+ ikey_get_u64(&pi->input.keys[InRawOutPktCount])));
data->bytes = htonl((uint32_t) (ikey_get_u64(&pi->input.keys[InRawInPktLen])
+ ikey_get_u64(&pi->input.keys[InRawOutPktLen])));
start = (uint64_t)ikey_get_u32(&pi->input.keys[InFlowStartSec]) *1000 + ikey_get_u32(&pi->input.keys[InFlowStartUsec])/1000;
end = (uint64_t)ikey_get_u32(&pi->input.keys[InFlowEndSec]) *1000 + ikey_get_u32(&pi->input.keys[InFlowEndUsec])/1000;
data->start_low = htonl((uint32_t)(start & 0xFFFFFFFFUL));
data->start_high = htonl(start >> 32);
+ if (!end) end = start; /* end timestamp seems to be commonly read as "last seen" timestamp */
data->end_low = htonl((uint32_t)(end & 0xFFFFFFFFUL));
data->end_high = htonl(end >> 32);
if (GET_FLAGS(pi->input.keys, InL4SPort) & ULOGD_RETF_VALID) {
data->sport = htons(ikey_get_u16(&pi->input.keys[InL4SPort]));
diff --color '--palette=ad=1;38;5;155:de=1;38;5;205:hd=1;36:ln=35;1;3' -U5 -ru ddd/ulogd2/README ./README
--- ddd/README 2023-12-13 12:10:38.503561734 +0100
+++ aaa/README 2023-12-10 19:58:55.735776260 +0100
@@ -1,9 +1,9 @@
Userspace logging daemon for netfilter/iptables
-Project Homepage: http://www.gnumonks.org/projects/ulogd
-Mailinglist: http://lists.gnumonks.org/mailman/listinfo/ulogd/
+Project Homepage: https://www.netfilter.org/projects/ulogd/
+Mailinglist: https://marc.info/?l=netfilter
This is just a short README, pleaes see the more extensive documentation
in the doc/ subdirectory.
===> IDEA
next prev parent reply other threads:[~2023-12-13 12:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-10 20:17 [PATCH ulogd] log NAT events using IPFIX Tomasz Pala
2023-12-12 13:47 ` Pablo Neira Ayuso
2023-12-12 18:44 ` Tomasz Pala
2023-12-12 19:45 ` Tomasz Pala
2023-12-12 20:08 ` Tomasz Pala
2023-12-13 11:49 ` Tomasz Pala
2023-12-13 11:29 ` Tomasz Pala
2023-12-13 12:27 ` Tomasz Pala [this message]
2023-12-13 23:42 ` Tomasz Pala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231213122708.GD18912@polanet.pl \
--to=gotar@polanet.pl \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.