Regressions after PR#235

[gnosek]

Describe the bug

PR#235 introduces significant changes in how fd names are updated. This introduces a bunch of regressions in our test suite (and is also a bug, regardless).

One facet of these changes, when reading a random capture (created with an ancient version of the libs):

 229 01:17:31.397768066 0 test_ipv6_clien (19747) < sendto res=6 data=Testme
 230 01:17:31.397768649 0 test_ipv6_clien (19747) > connect fd=3(<6u>::1:38255->::1:2345)
 231 01:17:31.397771971 0 test_ipv6_clien (19747) < connect res=0 tuple=::1:38255->2001:4860:4860::8888:53
-232 01:17:31.397772681 0 test_ipv6_clien (19747) > sendto fd=3(<6u>::1:38255->2001:4860:4860::8888:53) size=6 tuple=NULL
+232 01:17:31.397772681 0 test_ipv6_clien (19747) > sendto fd=3(<6u>::1:38255->::1:53) size=6 tuple=NULL
 233 01:17:31.397773899 0 test_ipv6_clien (19747) < sendto res=-111(ECONNREFUSED) data=
 234 01:17:31.397793823 0 test_ipv6_clien (19747) > write fd=2 size=23
 235 01:17:31.397798513 0 test_ipv6_clien (19747) < write res=23 data=ERR=Connection refused.
 236 01:17:31.397800165 0 test_ipv6_clien (19747) > switch next=6 pgft_maj=0 pgft_min=77 vm_size=4220 vm_rss=632 vm_swap=0
-237 01:17:31.399166996 0 test_ipv6_clien (19747) > sendto fd=3(<6u>::1:38255->2001:4860:4860::8888:53) size=6 tuple=::1:38255->::1:2345
+237 01:17:31.399166996 0 test_ipv6_clien (19747) > sendto fd=3(<6u>::1:38255->::1:53) size=6 tuple=::1:38255->::1:2345
 238 01:17:31.399186231 0 test_ipv6_clien (19747) < sendto res=6 data=Testme
 239 01:17:31.399192834 0 test_ipv6_clien (19747) > exit_group
 240 01:17:31.399230657 0 test_ipv6_clien (19747) > procexit status=0

The fd in question hasn't been updated with the remote endpoint (2001:4860:4860::8888:53) after the connect exit event.

How to reproduce it

The easiest is to use a driver that doesn't return the connection tuple from connect(), i.e. from before PR#235, but also two connect()s on the same (presumably UDP-only socket) trigger this bug.

[LucaGuerra]

Hey @gnosek , thanks for tracking this in issue in the very straightforward networking code in sinsp :D

I'm trying to understand the cases that make this fail:

• libs versions prior to or after new(libsinsp,libscap): Support full argument retrieval on both entry and exit for some syscalls #235 : two connect()s on the same socket (presumably UDP only) : what is supposed to happen?
• a capture file that was captured with a version prior to PR#235 ingested by libs after PR#235 : the fd is not updated while it clearly should be
• a driver from a version prior to PR#235 connected to the current libs version : the fd is not updated while it should be

Any other failing cases that you can identify? Especially if they involve failures with the latest drivers and latest libs.

[Stringy]

This may be related to #253 which fixed similarly described behaviour of the fd not updating when it should

[LucaGuerra]

All bugs captured by this issue were fixed some time ago. We can close this I think.

[Andreagit97]

Thank you all, since it's solved I close it