iperf3: error - control socket has closed unexpectedly (iperf 3.17.1 ) on Debian 12.7

[HenrikWahsner]

• Version of iperf3:
  Server: iperf 3.17.1 (cJSON 1.7.15)
  Client: iperf 3.17.1 (cJSON 1.7.15)

• Hardware:
  Server: ARMv7 VM Running Debian
  Client VM AMD64

• Operating system (and distribution, if any):
  Server: Debian 12.7
  Client: Debian 12.7

Bug Report

Client 15.137.211.151
Server 15.137.211.152

Both systems are connected via LAN on the same switch.

When I run the test for the first time, I get an error message:

root@gj-inst-w10-amd64:~# iperf3 --client 15.137.211.152 --get-server-output --bitrate 1M --interval 1 --time 10 --len 0 --parallel 4 --bidir
Connecting to host 15.137.211.152, port 5201
[  5] local 15.137.211.151 port 45090 connected to 15.137.211.152 port 5201
[  7] local 15.137.211.151 port 45100 connected to 15.137.211.152 port 5201
[  9] local 15.137.211.151 port 45116 connected to 15.137.211.152 port 5201
[ 11] local 15.137.211.151 port 45128 connected to 15.137.211.152 port 5201
[ 13] local 15.137.211.151 port 45144 connected to 15.137.211.152 port 5201
[ 15] local 15.137.211.151 port 45148 connected to 15.137.211.152 port 5201
[ 17] local 15.137.211.151 port 45164 connected to 15.137.211.152 port 5201
[ 19] local 15.137.211.151 port 45172 connected to 15.137.211.152 port 5201
iperf3: error - control socket has closed unexpectedly
root@gj-inst-w10-amd64:~#

If I run it right after again, all is working fine, here the last lines:

[ 13][RX-C]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec    0             sender
[ 13][RX-C]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec                  receiver
[ 15][RX-C]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec    0             sender
[ 15][RX-C]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec                  receiver
[ 17][RX-C]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec    0             sender
[ 17][RX-C]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec                  receiver
[ 19][RX-C]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec    0             sender
[ 19][RX-C]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec                  receiver
[SUM][RX-C]   0.00-10.00  sec  5.00 MBytes  4.19 Mbits/sec    0             sender
[SUM][RX-C]   0.00-10.00  sec  5.00 MBytes  4.19 Mbits/sec                  receiver

iperf Done.

I have attached a trace of the server side. In the first failing test one side is resetting in the middle of the connection.

I can reproduce it every time. If there is more time between 2 tests ( more than around 3 minutes) then the first test is failing again. If I run many test after the previous test ended all is fine, if there is less time between tests

iperf.zip

EDIT: I found out, that this only happens with option --bidir If I don't use this option, the test is Running as expected.

[davidBar-On]

Can you try running tests using different options combinations? E.g., using UDP; not using bi-directional (remove the --bidir)and trying client to server or server to client (-R); using only one stream (remove the --parallel); etc.

[HenrikWahsner]

I found out, that this only happens with option --bidir If I don't use this option, the test is Running as expected.

However, I will do further testing

[davidBar-On]

According to the WIreshark log, per lines 55-77, the server starts sending packet to the reverse streams but do not receive acks (ports 58472/58488/58498/58500 - lines 55-61), receives and acks 58520 (lines 61-71), receives but do not ack 58436 (lines 72-76), and then the server(?) resets 58420/58436 (lines 77-78). Later other steams are reset.

It would be useful to see the Wireshark log on the client side, since it is not clear who initiates the streams reset (may be the client, server or even the switch). Also, running both server and client with the -d -V options and sending both outputs (--logfile can be used) can also be useful.

One more suggesting for testing. Try using different --parallel values, starting from 1, to see if the number of parallel streams have an effect on the issue.