Handle interrupted tests (server)

[terrancewong]

When a test is accidentally interrupted, e.g.

• unplugging client cable
• client disassociating from Wi-Fi
• kill -9 the client,

server will stuck in previous test and no longer handles new connections indefinitely.

and client always error:

iperf3: error - the server is busy running a test. try again later

Is it possible to handle this situation, Without manually kill the server and relaunch?

Tried but failed:

• --rcv-timeout 15000 and/or --snd-timeout 15000
• --idle-timeout 15

[davidBar-On]

server will stuck in previous test and no longer handles new connections indefinitely.

What was the test duration? Currently the main thread of the server is not aware of the problem with the client, but it should terminate the test about 40 seconds after the test was expected to be completed. I..e. if the test was for 10 seconds then in this case the server should terminate it 50 seconds after it started. Did you wait enough time to see if that happens?

[terrancewong]

server does not take -t argument.

Server side:

# iperf3 --server --interval 10 --rcv-timeout=5000 --snd-timeout=5000      
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from <CLIENT_IP>, port 41848
[  5] local <SERVER_IP> port 5201 connected to 10.2.4.30 port 41860
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-10.01  sec   345 MBytes   289 Mbits/sec    4   1.41 KBytes       
[  5]  10.01-20.01  sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
[  5]  20.01-30.01  sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
[  5]  30.01-40.01  sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
[  5]  40.01-50.01  sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
iperf3: error - select failed: Bad file descriptor
-----------------------------------------------------------
Server listening on 5201 (test #2)
-----------------------------------------------------------
Accepted connection from 10.2.4.30, port 48706
[  5] local 10.2.4.17 port 5201 connected to 10.2.4.30 port 48716
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.01  sec   193 MBytes   162 Mbits/sec                  
iperf3: error - idle timeout for receiving data
-----------------------------------------------------------
Server listening on 5201 (test #3)
-----------------------------------------------------------

Client side command for (test #1)

iperf3 -c <SERVER_IP> -R --snd-timeout 15000 -t 15

and disassociate Wifi after 5 sec.

Client side command for (test # 2)

iperf3 -c <SERVER_IP> -t 15

also disassociate Wifi after 5 sec.

I'm confused, about how 3 timeouts work. Seemingly -c ip -R works differently from only -c IP. And --snd-timeout has no effects with client side -R

[terrancewong]

update

server side --idle-timeout does not work for -R test either.

Server some how takes clients' "-t" as a final timeout. But my scenario is, client may run very long tests, say 1hr, and the server should fail and restart listening after a reasonable timeout, say 15sec.

[davidBar-On]

Server some how takes clients' "-t" as a final timeout.

At the start of a test the client sent the server the test duration (the -t value). The server sets a timeout for 40 seconds after the test should end for cases like this.

... client may run very long tests, say 1hr, and the server should fail and restart listening after a reasonable timeout, say 15sec.

This is a known iperf3 issue since its 3.16 multi-thread version. The sending/receiving data thread terminates when the client terminates, but the main thread does not know about that. PR #1654 suggests a solution for this problem, but is was not merged (yet).

--snd-timeout has no effects with client side -R

In this case the --snd-timeout should be set for the server.

[davidBar-On]

... client may run very long tests, say 1hr, and the server should fail and restart listening after a reasonable timeout, say 15sec.

@terrancewong actually there is a workaround for this problem, using the server --cntl-ka option to set the control channel keepalive. E.g., setting --cntl-ka=10/3/3 for the server should terminate the test within 20 seconds (up to 10 secs for the first failed keepalive message + 3*3 secs). Can you try to see if that works when WiFi is disassociate?