* ulogd packet based logging with CT info @ 2021-08-15 14:23 Blažej Krajňák 2021-08-15 14:31 ` Pablo Neira Ayuso 0 siblings, 1 reply; 16+ messages in thread From: Blažej Krajňák @ 2021-08-15 14:23 UTC (permalink / raw) To: netfilter Hello, is there any way to enable packet based logging to XML but with connection tracking information included? Thanks Blažej Krajňák ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ulogd packet based logging with CT info 2021-08-15 14:23 ulogd packet based logging with CT info Blažej Krajňák @ 2021-08-15 14:31 ` Pablo Neira Ayuso 2021-08-15 16:23 ` Blažej Krajňák 0 siblings, 1 reply; 16+ messages in thread From: Pablo Neira Ayuso @ 2021-08-15 14:31 UTC (permalink / raw) To: Blažej Krajňák; +Cc: netfilter On Sun, Aug 15, 2021 at 04:23:51PM +0200, Blažej Krajňák wrote: > Hello, > > is there any way to enable packet based logging to XML but with > connection tracking information included? From the example ulogd2 configuration file in the tree: http://git.netfilter.org/ulogd2/tree/ulogd.conf.in#n77 # this is a stack for flow-based logging via XML #stack=ct1:NFCT,xml1:XML ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ulogd packet based logging with CT info 2021-08-15 14:31 ` Pablo Neira Ayuso @ 2021-08-15 16:23 ` Blažej Krajňák 2021-08-17 14:42 ` Blažej Krajňák 0 siblings, 1 reply; 16+ messages in thread From: Blažej Krajňák @ 2021-08-15 16:23 UTC (permalink / raw) To: Pablo Neira Ayuso; +Cc: netfilter ne 15. 8. 2021 o 16:31 Pablo Neira Ayuso <pablo@netfilter.org> wrote > > From the example ulogd2 configuration file in the tree: > > http://git.netfilter.org/ulogd2/tree/ulogd.conf.in#n77 > > # this is a stack for flow-based logging via XML > #stack=ct1:NFCT,xml1:XML At first, thank you for fast response. Of course I saw this example, but I have situation, where I need to know packet details (pktlen, mac, ifindex) along with information of conntrack entry which this packet triggered. I modified one of the libnetfilter_log example utilities to print both (packet and conntrack) information together. https://drive.google.com/file/d/1wx_LAjH57czHyFwTBSUvSnOkMchWEiiq/view?usp=sharing Is there any way to do the same in ulogd? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ulogd packet based logging with CT info 2021-08-15 16:23 ` Blažej Krajňák @ 2021-08-17 14:42 ` Blažej Krajňák 2021-08-17 15:05 ` Fatih USTA 2021-08-18 7:22 ` Pablo Neira Ayuso 0 siblings, 2 replies; 16+ messages in thread From: Blažej Krajňák @ 2021-08-17 14:42 UTC (permalink / raw) To: Pablo Neira Ayuso; +Cc: netfilter Hello Pablo, I'm just rewriting input plugin ulog_inppkt_NFLOG.c to include conntrack params. I successfully included CT flags from enum ip_conntrack_status (assured, reply seen, ...) and CT state and direction from NFULA_CT_INFO. However, in NFULA_CT few counters from enum nf_conntrack_attr are still 0 value. For ex. ATTR_TIMESTAMP_START / STOP and ATTR_ORIG/REPL_COUNTER_PACKETS/BYTES. Is it normal, or am I missing some bug at parsing? ne 15. 8. 2021 o 18:23 Blažej Krajňák <blazej.krajnak@gmail.com> napísal(a): > > ne 15. 8. 2021 o 16:31 Pablo Neira Ayuso <pablo@netfilter.org> wrote > > > > From the example ulogd2 configuration file in the tree: > > > > http://git.netfilter.org/ulogd2/tree/ulogd.conf.in#n77 > > > > # this is a stack for flow-based logging via XML > > #stack=ct1:NFCT,xml1:XML > > At first, thank you for fast response. Of course I saw this example, > but I have situation, where I need to know packet details (pktlen, > mac, ifindex) along with information of conntrack entry which this > packet triggered. > I modified one of the libnetfilter_log example utilities to print both > (packet and conntrack) information together. > https://drive.google.com/file/d/1wx_LAjH57czHyFwTBSUvSnOkMchWEiiq/view?usp=sharing > > Is there any way to do the same in ulogd? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ulogd packet based logging with CT info 2021-08-17 14:42 ` Blažej Krajňák @ 2021-08-17 15:05 ` Fatih USTA 2021-08-17 15:06 ` Blažej Krajňák 2021-08-18 7:22 ` Pablo Neira Ayuso 1 sibling, 1 reply; 16+ messages in thread From: Fatih USTA @ 2021-08-17 15:05 UTC (permalink / raw) To: Blažej Krajňák; +Cc: Pablo Neira Ayuso, netfilter 0 Hi Did you enable sysctl parameters. sysctl -w nf_conntrack_acct=1 sysctl -w nf_conntrack_timestamp=1 On 8/17/21, Blažej Krajňák <blazej.krajnak@gmail.com> wrote: > Hello Pablo, > > I'm just rewriting input plugin ulog_inppkt_NFLOG.c to include > conntrack params. I successfully included CT flags from enum > ip_conntrack_status (assured, reply seen, ...) and CT state and > direction from NFULA_CT_INFO. > > However, in NFULA_CT few counters from enum nf_conntrack_attr are > still 0 value. For ex. ATTR_TIMESTAMP_START / STOP and > ATTR_ORIG/REPL_COUNTER_PACKETS/BYTES. > Is it normal, or am I missing some bug at parsing? > > ne 15. 8. 2021 o 18:23 Blažej Krajňák <blazej.krajnak@gmail.com> > napísal(a): >> >> ne 15. 8. 2021 o 16:31 Pablo Neira Ayuso <pablo@netfilter.org> wrote >> > >> > From the example ulogd2 configuration file in the tree: >> > >> > http://git.netfilter.org/ulogd2/tree/ulogd.conf.in#n77 >> > >> > # this is a stack for flow-based logging via XML >> > #stack=ct1:NFCT,xml1:XML >> >> At first, thank you for fast response. Of course I saw this example, >> but I have situation, where I need to know packet details (pktlen, >> mac, ifindex) along with information of conntrack entry which this >> packet triggered. >> I modified one of the libnetfilter_log example utilities to print both >> (packet and conntrack) information together. >> https://drive.google.com/file/d/1wx_LAjH57czHyFwTBSUvSnOkMchWEiiq/view?usp=sharing >> >> Is there any way to do the same in ulogd? > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ulogd packet based logging with CT info 2021-08-17 15:05 ` Fatih USTA @ 2021-08-17 15:06 ` Blažej Krajňák 0 siblings, 0 replies; 16+ messages in thread From: Blažej Krajňák @ 2021-08-17 15:06 UTC (permalink / raw) To: Fatih USTA; +Cc: Pablo Neira Ayuso, netfilter ut 17. 8. 2021 o 17:05 Fatih USTA <fatihusta86@gmail.com> napÃsal(a): > Hi > Did you enable sysctl parameters. > > sysctl -w nf_conntrack_acct=1 > sysctl -w nf_conntrack_timestamp=1 > Yes, both are enabled. conntrack -L displays counters and delta-time correctly. u_int32_t pkts = nfct_get_attr_u32(ct, ATTR_ORIG_COUNTER_PACKETS ); printf(" Packet counter: %d", ntohs(pkts)); printf(" (%s)\n", strerror(errno)); returns 0 (No data available) I'm attaching draft-work of module to check. https://drive.google.com/file/d/1KouPKrrANvOihBuQH8Uwslk3pBkmP95q/view?usp=sharing I'm not sure about parsing static inline int interp_packet(struct ulogd_pluginstance *upi, uint8_t pf_family, struct nflog_data *ldata) { struct ulogd_key *ret = upi->output.keys; struct nfulnl_msg_packet_hdr *ph = nflog_get_msg_packet_hdr(ldata); ....... retb = nflog_nlmsg_parse(ph, attrs); if (retb != MNL_CB_OK) { printf("something went wrong"); printf(" (%s)\n", strerror(errno)); return retb; } nfg = mnl_nlmsg_get_payload(ph); print_nfct(nfg->nfgen_family, attrs[NFULA_CT_INFO], attrs[NFULA_CT], ret); ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ulogd packet based logging with CT info 2021-08-17 14:42 ` Blažej Krajňák 2021-08-17 15:05 ` Fatih USTA @ 2021-08-18 7:22 ` Pablo Neira Ayuso 2021-08-18 10:06 ` Blažej Krajňák 1 sibling, 1 reply; 16+ messages in thread From: Pablo Neira Ayuso @ 2021-08-18 7:22 UTC (permalink / raw) To: Blažej Krajňák; +Cc: netfilter [-- Attachment #1: Type: text/plain, Size: 631 bytes --] On Tue, Aug 17, 2021 at 04:42:12PM +0200, Blažej Krajňák wrote: > Hello Pablo, > > I'm just rewriting input plugin ulog_inppkt_NFLOG.c to include > conntrack params. I successfully included CT flags from enum > ip_conntrack_status (assured, reply seen, ...) and CT state and > direction from NFULA_CT_INFO. Great. > However, in NFULA_CT few counters from enum nf_conntrack_attr are > still 0 value. For ex. ATTR_TIMESTAMP_START / STOP and > ATTR_ORIG/REPL_COUNTER_PACKETS/BYTES. > Is it normal, or am I missing some bug at parsing? You need this kernel patch to add this information to nfnetlink_queue, compile-tested only. [-- Attachment #2: x.patch --] [-- Type: text/x-diff, Size: 1065 bytes --] diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c index eb35c6151fb0..0677531ce8db 100644 --- a/net/netfilter/nf_conntrack_netlink.c +++ b/net/netfilter/nf_conntrack_netlink.c @@ -2669,6 +2669,8 @@ ctnetlink_glue_build_size(const struct nf_conn *ct) + nla_total_size(0) /* CTA_HELP */ + nla_total_size(NF_CT_HELPER_NAME_LEN) /* CTA_HELP_NAME */ + ctnetlink_secctx_size(ct) + + ctnetlink_acct_size(ct) + + ctnetlink_timestamp_size(ct) #if IS_ENABLED(CONFIG_NF_NAT) + 2 * nla_total_size(0) /* CTA_NAT_SEQ_ADJ_ORIG|REPL */ + 6 * nla_total_size(sizeof(u_int32_t)) /* CTA_NAT_SEQ_OFFSET */ @@ -2726,6 +2728,10 @@ static int __ctnetlink_glue_build(struct sk_buff *skb, struct nf_conn *ct) if (ctnetlink_dump_protoinfo(skb, ct, false) < 0) goto nla_put_failure; + if (ctnetlink_dump_acct(skb, ct, IPCTNL_MSG_CT_GET) < 0 || + ctnetlink_dump_timestamp(skb, ct) < 0) + goto nla_put_failure; + if (ctnetlink_dump_helpinfo(skb, ct) < 0) goto nla_put_failure; ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: ulogd packet based logging with CT info 2021-08-18 7:22 ` Pablo Neira Ayuso @ 2021-08-18 10:06 ` Blažej Krajňák 2021-08-18 11:52 ` Pablo Neira Ayuso 0 siblings, 1 reply; 16+ messages in thread From: Blažej Krajňák @ 2021-08-18 10:06 UTC (permalink / raw) To: Pablo Neira Ayuso; +Cc: netfilter st 18. 8. 2021 o 9:23 Pablo Neira Ayuso <pablo@netfilter.org> napÃsal(a): > You need this kernel patch to add this information to nfnetlink_queue, > compile-tested only. Hey Pablo, patch is working like a charm. Thank you! Now I see timestamps and packets/bytes counters in JSON output correctly. At the end I will post customized input plugin for everyone. The last thing I want to ask is what's correct way to get attrs[NFULA_CT] from struct nfulnl_msg_packet_hdr *ph = nflog_get_msg_packet_hdr(ldata); Now I use the following code which is working but throwing random errors "something went wrong (Numerical result out of range)" I'm mixing struct nfulnl_msg_packet_hdr with const struct nlmsghdr *nlh struct nfulnl_msg_packet_hdr *ph = nflog_get_msg_packet_hdr(ldata); struct nlattr *attrs[NFULA_MAX + 1] = { NULL }; int retb; retb = nflog_nlmsg_parse(ph, attrs); if (retb != MNL_CB_OK) { printf("something went wrong"); printf(" (%s)\n", strerror(errno)); return retb; } ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ulogd packet based logging with CT info 2021-08-18 10:06 ` Blažej Krajňák @ 2021-08-18 11:52 ` Pablo Neira Ayuso 2021-08-18 20:06 ` Blažej Krajňák 0 siblings, 1 reply; 16+ messages in thread From: Pablo Neira Ayuso @ 2021-08-18 11:52 UTC (permalink / raw) To: Blažej Krajňák; +Cc: netfilter Hi Blažej, On Wed, Aug 18, 2021 at 12:06:40PM +0200, Blažej Krajňák wrote: > st 18. 8. 2021 o 9:23 Pablo Neira Ayuso <pablo@netfilter.org> napísal(a): > > You need this kernel patch to add this information to nfnetlink_queue, > > compile-tested only. > > Hey Pablo, > patch is working like a charm. Thank you! Now I see timestamps and > packets/bytes counters in JSON output correctly. > At the end I will post customized input plugin for everyone. > > The last thing I want to ask is what's correct way to get > > attrs[NFULA_CT] > > from > > struct nfulnl_msg_packet_hdr *ph = nflog_get_msg_packet_hdr(ldata); > > > Now I use the following code which is working but throwing random > errors "something went wrong (Numerical result out of range)" I'm > mixing struct nfulnl_msg_packet_hdr with const struct nlmsghdr *nlh That might be a bug in nflog_nlmsg_parse(): maybe nflog_parse_attr_cb() is finding a mismatch in the datatype of the attribute payload. Could you have a look at what attribute is hitting this error? > struct nfulnl_msg_packet_hdr *ph = nflog_get_msg_packet_hdr(ldata); > struct nlattr *attrs[NFULA_MAX + 1] = { NULL }; > int retb; > > retb = nflog_nlmsg_parse(ph, attrs); > if (retb != MNL_CB_OK) { > printf("something went wrong"); > printf(" (%s)\n", strerror(errno)); > return retb; > } ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ulogd packet based logging with CT info 2021-08-18 11:52 ` Pablo Neira Ayuso @ 2021-08-18 20:06 ` Blažej Krajňák 2021-08-19 10:16 ` Pablo Neira Ayuso 0 siblings, 1 reply; 16+ messages in thread From: Blažej Krajňák @ 2021-08-18 20:06 UTC (permalink / raw) To: Pablo Neira Ayuso; +Cc: netfilter I'm really confused from searching a bug. Getting nf_conntrack via nflog_nlmsg_parse(ph, attrs); is (I think) bad because ph parameter must be nlmsghdr not nfulnl_msg_packet_hdr So different way. I added new getters to libnetfilter_log.c: struct nf_conntrack *nflog_get_ct(struct nflog_data *nfad) { return nfnl_get_pointer_to_data(nfad->nfa, NFULA_CT, struct nf_conntrack); } uint32_t nflog_get_ct_info(struct nflog_data *nfad) { return ntohs(nfnl_get_data(nfad->nfa, NFULA_CT_INFO, uint32_t)); } nflog_get_ct_info works correctly. But from nflog_get_ct I'm unable to read anything. struct nf_conntrack *ct = nflog_get_ct(ldata); printf("test value %" PRIu64 " /n", ct->timestamp.start); is returning random numbers. What am I missing? How to properly parse output of nflog_get_ct to be able to use for ex. nfct_get_attr_u32? st 18. 8. 2021 o 13:52 Pablo Neira Ayuso <pablo@netfilter.org> napísal(a): > > Hi Blažej, > > On Wed, Aug 18, 2021 at 12:06:40PM +0200, Blažej Krajňák wrote: > > st 18. 8. 2021 o 9:23 Pablo Neira Ayuso <pablo@netfilter.org> napísal(a): > > > You need this kernel patch to add this information to nfnetlink_queue, > > > compile-tested only. > > > > Hey Pablo, > > patch is working like a charm. Thank you! Now I see timestamps and > > packets/bytes counters in JSON output correctly. > > At the end I will post customized input plugin for everyone. > > > > The last thing I want to ask is what's correct way to get > > > > attrs[NFULA_CT] > > > > from > > > > struct nfulnl_msg_packet_hdr *ph = nflog_get_msg_packet_hdr(ldata); > > > > > > Now I use the following code which is working but throwing random > > errors "something went wrong (Numerical result out of range)" I'm > > mixing struct nfulnl_msg_packet_hdr with const struct nlmsghdr *nlh > > That might be a bug in nflog_nlmsg_parse(): maybe > nflog_parse_attr_cb() is finding a mismatch in the datatype of the > attribute payload. > > Could you have a look at what attribute is hitting this error? > > > struct nfulnl_msg_packet_hdr *ph = nflog_get_msg_packet_hdr(ldata); > > struct nlattr *attrs[NFULA_MAX + 1] = { NULL }; > > int retb; > > > > retb = nflog_nlmsg_parse(ph, attrs); > > if (retb != MNL_CB_OK) { > > printf("something went wrong"); > > printf(" (%s)\n", strerror(errno)); > > return retb; > > } ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ulogd packet based logging with CT info 2021-08-18 20:06 ` Blažej Krajňák @ 2021-08-19 10:16 ` Pablo Neira Ayuso 2021-08-19 14:05 ` Blažej Krajňák 0 siblings, 1 reply; 16+ messages in thread From: Pablo Neira Ayuso @ 2021-08-19 10:16 UTC (permalink / raw) To: Blažej Krajňák; +Cc: netfilter On Wed, Aug 18, 2021 at 10:06:40PM +0200, Blažej Krajňák wrote: > I'm really confused from searching a bug. > > Getting nf_conntrack via nflog_nlmsg_parse(ph, attrs); is (I think) > bad because ph parameter must be nlmsghdr not nfulnl_msg_packet_hdr Right, nflog_nlmsg_parse() should take the nlh parameter. > So different way. I added new getters to libnetfilter_log.c: > > struct nf_conntrack *nflog_get_ct(struct nflog_data *nfad) > { > return nfnl_get_pointer_to_data(nfad->nfa, NFULA_CT, struct nf_conntrack); > } This will not work (as you noticed). The kernel does not store a struct in the NFULA_CT attribute. Better to stick to use nflog_nlmsg_parser(), my suggestion is: #1 msg_cb() provides struct nfgenmsg *nfmsg, you could retrieve the nlmsg from there since the nlmsghdr comes before nfgenmsg: struct nlmsghdr *nlh; nlh = (struct nlmsghdr *)((void *)nfg - sizeof(*nlh)); err = nflog_nlmsg_parse(nlh, attrs); if (err < 0) ... error path #2 once you have access to attrs[NFULA_CT], from there on: struct nf_conntrack *ct; ct = nfct_new(); if (!ct) ... error path err = nfct_nlmsg_parse(nlh, ct); if (err < 0) ... error path Then, you get the pointer to conntrack object. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ulogd packet based logging with CT info 2021-08-19 10:16 ` Pablo Neira Ayuso @ 2021-08-19 14:05 ` Blažej Krajňák 2021-08-19 17:03 ` Pablo Neira Ayuso 0 siblings, 1 reply; 16+ messages in thread From: Blažej Krajňák @ 2021-08-19 14:05 UTC (permalink / raw) To: Pablo Neira Ayuso; +Cc: netfilter št 19. 8. 2021 o 12:16 Pablo Neira Ayuso <pablo@netfilter.org> napísal(a): > > Better to stick to use nflog_nlmsg_parser(), my suggestion is: > > #1 msg_cb() provides struct nfgenmsg *nfmsg, you could retrieve the nlmsg > from there since the nlmsghdr comes before nfgenmsg: > > struct nlmsghdr *nlh; > > nlh = (struct nlmsghdr *)((void *)nfg - sizeof(*nlh)); > > err = nflog_nlmsg_parse(nlh, attrs); > if (err < 0) > ... error path > > #2 once you have access to attrs[NFULA_CT], from there on: > > struct nf_conntrack *ct; > > ct = nfct_new(); > if (!ct) > ... error path > > err = nfct_nlmsg_parse(nlh, ct); > if (err < 0) > ... error path > > Then, you get the pointer to conntrack object. Great, your suggestions perfectly work. Thank you. Little later I will post complete code to everyone. Could it be useful to prepare patch to add this to ulogd2? As new input plugin or as a upgrade to inppkt_UFLOG? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ulogd packet based logging with CT info 2021-08-19 14:05 ` Blažej Krajňák @ 2021-08-19 17:03 ` Pablo Neira Ayuso [not found] ` <CAMEa=f=wHTwJX6CjgOROcStTgDo-TdU6jb2xtpmNi=coHuPboA@mail.gmail.com> 2021-09-02 22:28 ` Ken-ichirou MATSUZAWA 0 siblings, 2 replies; 16+ messages in thread From: Pablo Neira Ayuso @ 2021-08-19 17:03 UTC (permalink / raw) To: Blažej Krajňák; +Cc: netfilter On Thu, Aug 19, 2021 at 04:05:41PM +0200, Blažej Krajňák wrote: > št 19. 8. 2021 o 12:16 Pablo Neira Ayuso <pablo@netfilter.org> napísal(a): > > > > Better to stick to use nflog_nlmsg_parser(), my suggestion is: > > > > #1 msg_cb() provides struct nfgenmsg *nfmsg, you could retrieve the nlmsg > > from there since the nlmsghdr comes before nfgenmsg: > > > > struct nlmsghdr *nlh; > > > > nlh = (struct nlmsghdr *)((void *)nfg - sizeof(*nlh)); > > > > err = nflog_nlmsg_parse(nlh, attrs); > > if (err < 0) > > ... error path > > > > #2 once you have access to attrs[NFULA_CT], from there on: > > > > struct nf_conntrack *ct; > > > > ct = nfct_new(); > > if (!ct) > > ... error path > > > > err = nfct_nlmsg_parse(nlh, ct); > > if (err < 0) > > ... error path > > > > Then, you get the pointer to conntrack object. > > Great, your suggestions perfectly work. Thank you. > Little later I will post complete code to everyone. Thanks. > Could it be useful to prepare patch to add this to ulogd2? I think so, yes. > As new input plugin or as a upgrade to inppkt_UFLOG? Better if you integrate it into the existing plugin. Please, go ahead post it for review, it might just need a few iterations before it gets merged into master. Thanks. ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <CAMEa=f=wHTwJX6CjgOROcStTgDo-TdU6jb2xtpmNi=coHuPboA@mail.gmail.com>]
* Re: ulogd packet based logging with CT info [not found] ` <CAMEa=f=wHTwJX6CjgOROcStTgDo-TdU6jb2xtpmNi=coHuPboA@mail.gmail.com> @ 2021-08-21 13:03 ` Blažej Krajňák 2021-08-21 16:21 ` Blažej Krajňák 0 siblings, 1 reply; 16+ messages in thread From: Blažej Krajňák @ 2021-08-21 13:03 UTC (permalink / raw) To: Pablo Neira Ayuso; +Cc: netfilter I'm not sure if previous message was delivered to the list members (I don't see it on web archive). So once again: št 19. 8. 2021 o 19:03 Pablo Neira Ayuso <pablo@netfilter.org> napísal(a): > > Better if you integrate it into the existing plugin. > > Please, go ahead post it for review, it might just need a few > iterations before it gets merged into master. > > Thanks. Okay, I will prepare my first ever patch to open source world :) I just found an another strange behaviour of conntrack. I'm mirroring port on switch and mirrored data are coming to Linux server. That port on server is in bridge. In nftables I created table bridge filter with some CT rule to enable connection tracking on bridge. As I found I had to add another dummy interface to bridge, because conntrack was not working at all, if just one port in bridge. Now I see conntrack entries but all of them as UNREPLIED and just one way byte/packet counters are increasing (see attachment). Is it because the both ways are coming to server on the same port? Any easy workaround? https://drive.google.com/file/d/1-aIXA13IicHcKHIaxkC1Hz2tRckU3YDm/view?usp=sharing ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ulogd packet based logging with CT info 2021-08-21 13:03 ` Blažej Krajňák @ 2021-08-21 16:21 ` Blažej Krajňák 0 siblings, 0 replies; 16+ messages in thread From: Blažej Krajňák @ 2021-08-21 16:21 UTC (permalink / raw) To: Pablo Neira Ayuso; +Cc: netfilter so 21. 8. 2021 o 15:03 Blažej Krajňák <blazej.krajnak@gmail.com> napísal(a): > I just found an another strange behaviour of conntrack. I'm mirroring > port on switch and mirrored data are coming to Linux server. That port > on server is in bridge. In nftables I created table bridge filter with > some CT rule to enable connection tracking on bridge. > As I found I had to add another dummy interface to bridge, because > conntrack was not working at all, if just one port in bridge. > Now I see conntrack entries but all of them as UNREPLIED and just one > way byte/packet counters are increasing (see attachment). Is it > because the both ways are coming to server on the same port? Any easy > workaround? I just figure it out. Switch was sending one way of traffic tagged with vlan. And also I had to turn off bridge MAC addresses learning (a.k.a ageing to 0). Now it works. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ulogd packet based logging with CT info 2021-08-19 17:03 ` Pablo Neira Ayuso [not found] ` <CAMEa=f=wHTwJX6CjgOROcStTgDo-TdU6jb2xtpmNi=coHuPboA@mail.gmail.com> @ 2021-09-02 22:28 ` Ken-ichirou MATSUZAWA 1 sibling, 0 replies; 16+ messages in thread From: Ken-ichirou MATSUZAWA @ 2021-09-02 22:28 UTC (permalink / raw) To: Pablo Neira Ayuso, Blažej Krajňák; +Cc: netfilter Hi, On 08/19, Pablo Neira Ayuso wrote: > On Thu, Aug 19, 2021 at 04:05:41PM +0200, Blažej Krajňák wrote: > > Could it be useful to prepare patch to add this to ulogd2? > > I think so, yes. > > > As new input plugin or as a upgrade to inppkt_UFLOG? > > Better if you integrate it into the existing plugin. May I follow up on this? thanks, ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2021-09-02 22:28 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-15 14:23 ulogd packet based logging with CT info Blažej Krajňák 2021-08-15 14:31 ` Pablo Neira Ayuso 2021-08-15 16:23 ` Blažej Krajňák 2021-08-17 14:42 ` Blažej Krajňák 2021-08-17 15:05 ` Fatih USTA 2021-08-17 15:06 ` Blažej Krajňák 2021-08-18 7:22 ` Pablo Neira Ayuso 2021-08-18 10:06 ` Blažej Krajňák 2021-08-18 11:52 ` Pablo Neira Ayuso 2021-08-18 20:06 ` Blažej Krajňák 2021-08-19 10:16 ` Pablo Neira Ayuso 2021-08-19 14:05 ` Blažej Krajňák 2021-08-19 17:03 ` Pablo Neira Ayuso [not found] ` <CAMEa=f=wHTwJX6CjgOROcStTgDo-TdU6jb2xtpmNi=coHuPboA@mail.gmail.com> 2021-08-21 13:03 ` Blažej Krajňák 2021-08-21 16:21 ` Blažej Krajňák 2021-09-02 22:28 ` Ken-ichirou MATSUZAWA
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.