#317 Iperf 2.2.1: -u, -P and -R issue

[Marshall Porter]

iperf -s -i 1 -f m -t 40 -u
iperf -c 192.168.0.211 -u -P 4 -R -i 1 -f m -t 30 -b 144.4M

Iperf client with -u, -P and -R flags combined results in this message printed for seemingly all but 1 thread:

recvmsg failed: Connection refused

On Android, but not MacOS, client output additionally ends with:

FORTIFY: pthread_mutex_lock called on a destroyed mutex (0xb400007f2282f800) Aborted

TCP with -P and -R seems fine. UDP with just -P seems fine

[Robert McMahon]

This seems to be added in version 2.1.3. It works in 2.1.1.

Here is a commit to show the transfer id with the rcvmsg warning.

Note: This comment is probably incorrect. The core issue is a race on the server side. These tests or versions may not as easily expose the race but it's likely still there even in 2.1.1. The best solution for now is to use port ranges.

[Robert McMahon]

Issue is that the server side Listener isn't ready for a subsequent client thread's first packet. The server is sending an ICMP connection refused (seen via wireshark.) We'll need a retry mechanism similar to the TCP connect retry.

[Robert McMahon]

A workaround is to use port ranges. This eliminates the race.

src/iperf -c 192.168.1.35 -i 1  -b 10m  -R -u -p5001-5032

root@raspberrypi5:~# iperf -s -u -p5001-5032
------------------------------------------------------------
Server listening on UDP ports 5001-5032 with pid 28747
UDP buffer size:  208 KByte (default)
------------------------------------------------------------