* tcp state in conntrack destroy events @ 2017-01-17 19:46 Victor Julien 2017-01-17 21:28 ` Florian Westphal 0 siblings, 1 reply; 5+ messages in thread From: Victor Julien @ 2017-01-17 19:46 UTC (permalink / raw) To: Netfilter Development Mailing list Hi all, I was hoping to get the last TCP state in a conntrack destroy event, however it seems to be unavailable. Through libnetfilter_conntrack the value retrieved at ATTR_TCP_STATE is always 0. Using the conntrack command I see the same behavior: destroy doesn't have it (conntrack -E -e destroy -p tcp): [DESTROY] tcp 6 src=218.65.30.38 dst=192.168.178.254 sport=61063 dport=22 packets=11 bytes=820 src=192.168.0.123 dst=218.65.30.38 sport=22 dport=61063 packets=8 bytes=424 [ASSURED] mark=3 delta-time=77 update does (conntrack -E -e updates -p tcp): [UPDATE] tcp 6 120 FIN_WAIT src=192.168.0.53 dst=x.x.x.x sport=52958 dport=443 src=x.x.x.x dst=192.168.178.254 sport=443 dport=52958 [ASSURED] mark=3 Is this intentional? My goal is to create connection log that includes a hint about why the connection is gone. -- --------------------------------------------- Victor Julien http://www.inliniac.net/ PGP: http://www.inliniac.net/victorjulien.asc --------------------------------------------- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tcp state in conntrack destroy events 2017-01-17 19:46 tcp state in conntrack destroy events Victor Julien @ 2017-01-17 21:28 ` Florian Westphal 2017-01-17 21:39 ` Victor Julien 2017-01-17 23:23 ` Jarno Rajahalme 0 siblings, 2 replies; 5+ messages in thread From: Florian Westphal @ 2017-01-17 21:28 UTC (permalink / raw) To: Victor Julien; +Cc: Netfilter Development Mailing list Victor Julien <lists@inliniac.net> wrote: > I was hoping to get the last TCP state in a conntrack destroy event, > however it seems to be unavailable. > > Through libnetfilter_conntrack the value retrieved at ATTR_TCP_STATE is > always 0. > > Using the conntrack command I see the same behavior: > > destroy doesn't have it (conntrack -E -e destroy -p tcp): > > [DESTROY] tcp 6 src=218.65.30.38 dst=192.168.178.254 sport=61063 > dport=22 packets=11 bytes=820 src=192.168.0.123 dst=218.65.30.38 > sport=22 dport=61063 packets=8 bytes=424 [ASSURED] mark=3 delta-time=77 > > update does (conntrack -E -e updates -p tcp): > > [UPDATE] tcp 6 120 FIN_WAIT src=192.168.0.53 dst=x.x.x.x > sport=52958 dport=443 src=x.x.x.x dst=192.168.178.254 sport=443 > dport=52958 [ASSURED] mark=3 > > Is this intentional? My goal is to create connection log that includes a > hint about why the connection is gone. Yes, its intentional, see net/netfilter/nf_conntrack_netlink.c, there is a check for DESTROY that supresses most of the extra info: 682 if (events & (1 << IPCT_DESTROY)) { 683 if (ctnetlink_dump_acct(skb, ct, type) < 0 || 684 ctnetlink_dump_timestamp(skb, ct) < 0) 685 goto nla_put_failure; 686 } else { .. /* IPCT_PROTOINFO */ Pablo made this change in 7b621c1ea64a54f77b8a841b16dc4c9fee3ecf48, i guess the rationale was that clients aren't interested in this on DESTROY. Would be easy to change this. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tcp state in conntrack destroy events 2017-01-17 21:28 ` Florian Westphal @ 2017-01-17 21:39 ` Victor Julien 2017-01-17 23:23 ` Jarno Rajahalme 1 sibling, 0 replies; 5+ messages in thread From: Victor Julien @ 2017-01-17 21:39 UTC (permalink / raw) To: Netfilter Development Mailing list On 17-01-17 22:28, Florian Westphal wrote: > Victor Julien <lists@inliniac.net> wrote: >> I was hoping to get the last TCP state in a conntrack destroy event, >> however it seems to be unavailable. >> >> Through libnetfilter_conntrack the value retrieved at ATTR_TCP_STATE is >> always 0. >> >> Using the conntrack command I see the same behavior: >> >> destroy doesn't have it (conntrack -E -e destroy -p tcp): >> >> [DESTROY] tcp 6 src=218.65.30.38 dst=192.168.178.254 sport=61063 >> dport=22 packets=11 bytes=820 src=192.168.0.123 dst=218.65.30.38 >> sport=22 dport=61063 packets=8 bytes=424 [ASSURED] mark=3 delta-time=77 >> >> update does (conntrack -E -e updates -p tcp): >> >> [UPDATE] tcp 6 120 FIN_WAIT src=192.168.0.53 dst=x.x.x.x >> sport=52958 dport=443 src=x.x.x.x dst=192.168.178.254 sport=443 >> dport=52958 [ASSURED] mark=3 >> >> Is this intentional? My goal is to create connection log that includes a >> hint about why the connection is gone. > > Yes, its intentional, see > net/netfilter/nf_conntrack_netlink.c, there is a check for DESTROY > that supresses most of the extra info: > > 682 if (events & (1 << IPCT_DESTROY)) { > 683 if (ctnetlink_dump_acct(skb, ct, type) < 0 || > 684 ctnetlink_dump_timestamp(skb, ct) < 0) > 685 goto nla_put_failure; > 686 } else { > .. > /* IPCT_PROTOINFO */ > > Pablo made this change in 7b621c1ea64a54f77b8a841b16dc4c9fee3ecf48, > i guess the rationale was that clients aren't interested in this > on DESTROY. > > Would be easy to change this. > Would there be another way of achieving this goal? I mean other than tracking all updates and keeping a parallel conntrack in user space :) Maybe I wouldn't need all the TCP states and just a flag or something indicating a 'unclean' connection end would also work. Haven't been able to figure out all fields yet, but so far I haven't found what I was hoping for. -- --------------------------------------------- Victor Julien http://www.inliniac.net/ PGP: http://www.inliniac.net/victorjulien.asc --------------------------------------------- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tcp state in conntrack destroy events 2017-01-17 21:28 ` Florian Westphal 2017-01-17 21:39 ` Victor Julien @ 2017-01-17 23:23 ` Jarno Rajahalme 2017-01-17 23:47 ` Florian Westphal 1 sibling, 1 reply; 5+ messages in thread From: Jarno Rajahalme @ 2017-01-17 23:23 UTC (permalink / raw) To: Florian Westphal; +Cc: Victor Julien, Netfilter Development Mailing list > On Jan 17, 2017, at 1:28 PM, Florian Westphal <fw@strlen.de> wrote: > > Victor Julien <lists@inliniac.net> wrote: >> I was hoping to get the last TCP state in a conntrack destroy event, >> however it seems to be unavailable. >> >> Through libnetfilter_conntrack the value retrieved at ATTR_TCP_STATE is >> always 0. >> >> Using the conntrack command I see the same behavior: >> >> destroy doesn't have it (conntrack -E -e destroy -p tcp): >> >> [DESTROY] tcp 6 src=218.65.30.38 dst=192.168.178.254 sport=61063 >> dport=22 packets=11 bytes=820 src=192.168.0.123 dst=218.65.30.38 >> sport=22 dport=61063 packets=8 bytes=424 [ASSURED] mark=3 delta-time=77 >> >> update does (conntrack -E -e updates -p tcp): >> >> [UPDATE] tcp 6 120 FIN_WAIT src=192.168.0.53 dst=x.x.x.x >> sport=52958 dport=443 src=x.x.x.x dst=192.168.178.254 sport=443 >> dport=52958 [ASSURED] mark=3 >> >> Is this intentional? My goal is to create connection log that includes a >> hint about why the connection is gone. > > Yes, its intentional, see > net/netfilter/nf_conntrack_netlink.c, there is a check for DESTROY > that supresses most of the extra info: > > 682 if (events & (1 << IPCT_DESTROY)) { > 683 if (ctnetlink_dump_acct(skb, ct, type) < 0 || > 684 ctnetlink_dump_timestamp(skb, ct) < 0) > 685 goto nla_put_failure; > 686 } else { > .. > /* IPCT_PROTOINFO */ > > Pablo made this change in 7b621c1ea64a54f77b8a841b16dc4c9fee3ecf48, > i guess the rationale was that clients aren't interested in this > on DESTROY. > > Would be easy to change this. I have a use case where we want to log terminating connections, but only if a specific label bit is set. To do this, we currently have to listen to both create and destroy events and keep track of all the connections in the userspace to be able to correlate destroy event to the connection and from there to the labels. Would be nice if the destroy event included labels, so that we would not have to listen to create events nor keep a duplicate connection tracking table in userspace. Jarno > -- > To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tcp state in conntrack destroy events 2017-01-17 23:23 ` Jarno Rajahalme @ 2017-01-17 23:47 ` Florian Westphal 0 siblings, 0 replies; 5+ messages in thread From: Florian Westphal @ 2017-01-17 23:47 UTC (permalink / raw) To: Jarno Rajahalme Cc: Florian Westphal, Victor Julien, Netfilter Development Mailing list Jarno Rajahalme <jarno@ovn.org> wrote: > > > On Jan 17, 2017, at 1:28 PM, Florian Westphal <fw@strlen.de> wrote: > > > > Victor Julien <lists@inliniac.net> wrote: > >> I was hoping to get the last TCP state in a conntrack destroy event, > >> however it seems to be unavailable. > >> > >> Through libnetfilter_conntrack the value retrieved at ATTR_TCP_STATE is > >> always 0. > >> > >> Using the conntrack command I see the same behavior: > >> > >> destroy doesn't have it (conntrack -E -e destroy -p tcp): > >> > >> [DESTROY] tcp 6 src=218.65.30.38 dst=192.168.178.254 sport=61063 > >> dport=22 packets=11 bytes=820 src=192.168.0.123 dst=218.65.30.38 > >> sport=22 dport=61063 packets=8 bytes=424 [ASSURED] mark=3 delta-time=77 > >> > >> update does (conntrack -E -e updates -p tcp): > >> > >> [UPDATE] tcp 6 120 FIN_WAIT src=192.168.0.53 dst=x.x.x.x > >> sport=52958 dport=443 src=x.x.x.x dst=192.168.178.254 sport=443 > >> dport=52958 [ASSURED] mark=3 > >> > >> Is this intentional? My goal is to create connection log that includes a > >> hint about why the connection is gone. > > > > Yes, its intentional, see > > net/netfilter/nf_conntrack_netlink.c, there is a check for DESTROY > > that supresses most of the extra info: > > > > 682 if (events & (1 << IPCT_DESTROY)) { > > 683 if (ctnetlink_dump_acct(skb, ct, type) < 0 || > > 684 ctnetlink_dump_timestamp(skb, ct) < 0) > > 685 goto nla_put_failure; > > 686 } else { > > .. > > /* IPCT_PROTOINFO */ > > > > Pablo made this change in 7b621c1ea64a54f77b8a841b16dc4c9fee3ecf48, > > i guess the rationale was that clients aren't interested in this > > on DESTROY. > > > > Would be easy to change this. > > I have a use case where we want to log terminating connections, but only if a specific label bit is set. To do this, we currently have to listen to both create and destroy events and keep track of all the connections in the userspace to be able to correlate destroy event to the connection and from there to the labels. Would be nice if the destroy event included labels, so that we would not have to listen to create events nor keep a duplicate connection tracking table in userspace. Pablo isn't to blame, that was me :) When I added label support I simply did not consider this and only placed this in the non-destroy path. I have no objections to includte labels unconditionally, might as well also move secmark too. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-01-17 23:47 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-01-17 19:46 tcp state in conntrack destroy events Victor Julien 2017-01-17 21:28 ` Florian Westphal 2017-01-17 21:39 ` Victor Julien 2017-01-17 23:23 ` Jarno Rajahalme 2017-01-17 23:47 ` Florian Westphal
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).