--reverse option not working properly in combination with --blockcount

[PatrikMosko]

Context

• Version of iperf3:
  iperf3-3.7-3.fc32.x86_64

• Hardware:
  Lenovo ThinkPad T470S

• Operating system (and distribution, if any):
  Fedora >= 31 (I think f30 build doesn't have this issue)

• Other relevant information (for example, non-default compilers,
  libraries, cross-compiling, etc.):
  uname: Linux gdpr 5.5.13-200.fc31.x86_64 setting of window size should be explicit #1 SMP Wed Mar 25 21:55:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Bug Report

Server is stuck in a loop when in --reverse mode along with option --blockcount|-k.

• Steps to Reproduce

1. iperf3 -sD --port 5201
2. iperf3 -c 127.0.0.1 -p 5201 -T'client' -R -k 50

• Expected Behavior
  client: Connecting to host 127.0.0.1, port 5201
  client: Reverse mode, remote host 127.0.0.1 is sending
  client: [ 5] local 127.0.0.1 port 51568 connected to 127.0.0.1 port 5201
  client: [ ID] Interval Transfer Bitrate
  client: [ 5] 0.00-0.00 sec 6.25 MBytes 19.1 Gbits/sec
  client: - - - - - - - - - - - - - - - - - - - - - - - - -
  client: [ ID] Interval Transfer Bitrate Retr
  client: [ 5] 0.00-0.04 sec 7.50 MBytes 1.51 Gbits/sec 2 sender
  client: [ 5] 0.00-0.00 sec 6.25 MBytes 19.1 Gbits/sec receiver
  client:
  client: iperf Done.

• Actual Behavior
  client: Connecting to host 127.0.0.1, port 5201
  client: Reverse mode, remote host 127.0.0.1 is sending
  client: [ 5] local 127.0.0.1 port 53008 connected to 127.0.0.1 port 5201
  client: [ ID] Interval Transfer Bitrate
  client: [ 5] 0.00-1.00 sec 3.26 GBytes 28.0 Gbits/sec
  client: [ 5] 1.00-2.00 sec 3.65 GBytes 31.4 Gbits/sec
  client: [ 5] 2.00-3.00 sec 3.44 GBytes 29.5 Gbits/sec
  client: [ 5] 3.00-4.00 sec 3.61 GBytes 31.0 Gbits/sec
  client: [ 5] 4.00-5.00 sec 3.54 GBytes 30.4 Gbits/sec
  ^Cclient: [ 5] 5.00-5.96 sec 3.44 GBytes 30.7 Gbits/sec
  client: - - - - - - - - - - - - - - - - - - - - - - - - -
  client: [ ID] Interval Transfer Bitrate
  client: [ 5] 0.00-5.96 sec 0.00 Bytes 0.00 bits/sec sender
  client: [ 5] 0.00-5.96 sec 20.9 GBytes 30.2 Gbits/sec receiver
  iperf3: interrupt - the client has terminated

• Actual Behavior (--verbose & --debug)
  client: iperf 3.7
  client: client: Linux hostname ...some irrelevant text here...
  Control connection MSS 32768
  send_parameters:
  {
  "tcp": true,
  "omit": 0,
  "time": 0,
  "blockcount": 50,
  "parallel": 1,
  "reverse": true,
  "len": 131072,
  "pacing_timer": 1000,
  "title": "client",
  "client_version": "3.7"
  }
  client: Time: Tue, 10 Mar 2020 22:40:46 GMT
  client: Connecting to host 127.0.0.1, port 5201
  client: Reverse mode, remote host 127.0.0.1 is sending
  client: Cookie: uwzmemndwggiu74qhjqsazwnyesfrnrv2lfv
  client: TCP MSS: 32768 (default)
  SNDBUF is 16384, expecting 0
  RCVBUF is 131072, expecting 0
  Congestion algorithm is cubic
  client: [ 5] local 127.0.0.1 port 41970 connected to 127.0.0.1 port 5201
  client: Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 50 blocks to send, tos 0
  tcpi_snd_cwnd 10 tcpi_snd_mss 32768 tcpi_rtt 7
  interval_len 1.000037 bytes_transferred 3332339799
  interval forces keep
  client: [ ID] Interval Transfer Bitrate
  client: [ 5] 0.00-1.00 sec 3.10 GBytes 26.7 Gbits/sec
  tcpi_snd_cwnd 10 tcpi_snd_mss 32768 tcpi_rtt 7
  interval_len 0.999996 bytes_transferred 3296731944
  interval forces keep
  client: [ 5] 1.00-2.00 sec 3.07 GBytes 26.4 Gbits/sec
  tcpi_snd_cwnd 10 tcpi_snd_mss 32768 tcpi_rtt 7
  interval_len 1.000163 bytes_transferred 3492806656
  interval forces keep
  client: [ 5] 2.00-3.00 sec 3.25 GBytes 27.9 Gbits/sec
  tcpi_snd_cwnd 10 tcpi_snd_mss 32768 tcpi_rtt 7
  interval_len 0.999966 bytes_transferred 3524657152
  interval forces keep
  client: [ 5] 3.00-4.00 sec 3.28 GBytes 28.2 Gbits/sec
  ...
  client: [ 5] 400.00-400.55 sec 1.79 GBytes 27.8 Gbits/sec
  client: - - - - - - - - - - - - - - - - - - - - - - - - -
  client: Test Complete. Summary Results:
  client: [ ID] Interval Transfer Bitrate
  client: [ 5] 0.00-400.55 sec 0.00 Bytes 0.00 bits/sec sender
  client: [ 5] 0.00-400.55 sec 1.38 TBytes 30.3 Gbits/sec receiver
  client: rcv_tcp_congestion cubic
  iperf3: interrupt - the client has terminated

[PatrikMosko]

Another observation:
when used with --bitrate, ie. 1000[b], it sends first batch of packet/s and then it just hangs, not sending/receiving anything, even though it expects something.

*command used:
iperf3 -c 127.0.0.1 -p 5201 -T'client' --bitrate 2000 -k 1 -R

*output
client: Connecting to host 127.0.0.1, port 5201
client: Reverse mode, remote host 127.0.0.1 is sending
client: [ 5] local 127.0.0.1 port 45276 connected to 127.0.0.1 port 5201
client: [ ID] Interval Transfer Bitrate
client: [ 5] 0.00-1.00 sec 128 KBytes 1.05 Mbits/sec
client: [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
client: [ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
client: [ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
client: [ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
client: [ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec
^Cclient: - - - - - - - - - - - - - - - - - - - - - - - - -
client: [ ID] Interval Transfer Bitrate
client: [ 5] 0.00-6.10 sec 0.00 Bytes 0.00 bits/sec sender
client: [ 5] 0.00-6.10 sec 128 KBytes 172 Kbits/sec receiver
iperf3: interrupt - the client has terminated

[bmah888]

In the past there has been some brokenness associated with --reverse/-R. I wonder if this is more of the same.

[bmah888]

See #761, which might or might not be related.

[davidBar-On]

I also have the problem that -n and -k don't work in reverse mode, using a version I built on Ubuntu VM under Windows 10 from a clone of version 3.7+. The -t option does work in reverse mode. It may be that the problem is with the master git branch.

I checked that the server properly receives the values for either -t, -n, -k parameters. For the -t, create_server_timers() properly sets tmr_create(... test->duration + test->omit + grace_period ...).

However, I don't see handling of the -n and -k limitations in the server's side. The client does check these limitations in iperf_run_client():

	    /* Is the test done yet? */
if ((!test->omitting) &&
    ((test->duration != 0 && test->done) ||
    (test->settings->bytes != 0 && test->bytes_sent >= test->settings->bytes) ||
    (test->settings->blocks != 0 && test->blocks_sent >= test->settings->blocks))) {

On the other hand, iperf_run_server() does not include such check of the bytes and blockscount limitations for the reverse mode. Also, as the above iperf_run_client() code is checking for the sent bytes/blocks, it does not apply to the reverse mode (it may have worked if in reverse mode the check was for the received bytes/blocks).

Can it be that the right code of either iperf_run_server() or iperf_run_client() are not in the master branch?

[bmah888]

OK I just ran into this problem while testing something else. The problem is that the ending conditions in iperf_run_client() don't take reverse mode into account for -n or -k. (Note that the client side is the one that determines when the test is done, regardless of whether it's sending or receiving data.)

So I think that in the snippet of code posted by @davidBar-On in the comment immediately above, we need to check for whether the client is sending or receiving and then check, for example, test->bytes_sent vs. test->bytes_received appropriately. Same for blocks. This makes the check kind of ugly and convoluted, but so is this mess of various options.

Reverse mode works for time-based tests because time->duration and test->done are updated in the same way on the client if its sending or receiving.