tcp state in conntrack destroy events

tcp state in conntrack destroy events

[Victor Julien]

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
---------------------------------------------

Re: tcp state in conntrack destroy events

[Florian Westphal]

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.

Re: tcp state in conntrack destroy events

[Victor Julien]

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
---------------------------------------------

Re: tcp state in conntrack destroy events

[Jarno Rajahalme]

> 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

Re: tcp state in conntrack destroy events

[Florian Westphal]

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.