Connection count on Transports page do not match established connections count

[Vort]

When I compare amount of address:port pairs on http://127.0.0.1:7070/?page=transports page with amount of established connections as reported by OS, I see that Transports page misses some of connections.
Especially noticeable difference happens with Yggdrasil addresses (NTCP2v6), but NTCP2 have significant difference too.
I'm not sure if it's a bug, but it worth investigation in my opinion.

[r4sas]

Duplicate of #1551

[Vort]

Duplicate of #1551

No. Issue #1551 is about duplicate outgoing connections to the same nodes.
In this case, each IP:port pair is unique.

[r4sas]

i2pd/daemon/HTTPServer.cpp

Line 795 in 6c2aec8

if (it.second && it.second->IsEstablished () && endpoint.address ().is_v4 ())

[Vort]

I was not able to guess why you cited that line.
But I have to note one property of this problem:
Right after i2pd is launched, this problem is not reproducing.
It starts to show up after some time.
And looks like the longer uptime is, the more prominent problem is:
Amount of "lost" connections from my first post:
100*(1-385/413) = 7%
100*(1-9/16) = 44%
Same measurements now:
100*(1-316/375) = 16%
100*(1-7/16) = 56%

[simonvetter]

I've never noticed before but I'm seeing this as well : the Transports page consistently reports a lower number than actual TCP sockets in ESTABLISHED state, even if you force-refresh the page.
I see 143 NTCPv2 connections listed on the web interface vs 170 ESTABLISHED TCP sockets as we speak, on a router-only node (no socks/BOB/HTTP or otherwise client connections).

What I've found:

• waiting 1-2 minutes will make some of those established TCP sockets show up on the web interface. Could it be that those are indeed established TCP sockets, but aren't yet established/active from an NTCPv2 perspective ?
• if a node has both an active UDP (SSU, but maybe SSU2 as well, idk) association as well as an active TCP association, the NTCPv2 association isn't displayed (by active, I mean tcpdump does show traffic going both ways).
  If, later on, the SSU association is closed (disappears from the web interface, no UDP traffic anymore) but the TCP association stays active, the SSU association disappears from the web interface (as expected) and the NCTPv2 one stays hidden.

note: this node is ipv6-only, so no NAT trickery involved.

[Vort]

1-2 minutes

I doubt that i2p is that slow.

if a node has both an active UDP (SSU, but maybe SSU2 as well, idk) association as well as an active TCP association, the NTCPv2 association isn't displayed

I started i2pd without ssu and ssu2.
If nothing interrupts this test, I will post results later.

upd. Difference appeared earlier than I expected:
397 / 420 and 7 / 7
I'm reverting my config back to SSU2.

[Vort]

Fixed in 126dc0e.