Error "Unable to read from stream socket" in UDP reverse mode on iperf3 client

[RizziMau]

Context

I am using iperf3 in a product that tests the UDP data throughput of mobile networks.
Sometimes the iperf3 client fails at the beginning of the UDP transfer in reverse mode and reports the message
iperf3: error - unable to read from stream socket:

Versions of iperf3:
on the iperf client side: 3.16
on the iperf server side: 3.17

Hardware:
on the iperf client side: Samsung A52s
on the iperf server side: Server with Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz

Operating system:
on the iperf client side: Android 11
on the iperf server side: Ubuntu 22.04.4 LTS

Bug Report

Expected Behavior:
The client should not fail.

Actual Behavior:
The iperf3 client fails at the beginning of the UDP transfer in reverse mode.

The iperf3 client command (on the Android phone) is:
iperf3 --forceflush -c x.x.x.x -V -p 5208 -u -t 15 -i 5 -fK -4 -b 62500000 -l 1200 -P 4 -O 0 -R
(x.x.x.x is the IP address of the server)

Here below the iperf3 log in case of failure:

iperf 3.16
Linux localhost 5.4.86-qgki-22775054-abA528BXXU1AUK4 #1 SMP PREEMPT Fri Nov 5 16:50:52 KST 2021 aarch64
Control connection MSS 1298
Time: Mon, 17 Feb 2025 19:53:11 GMT
Connecting to host 83.103.115.246, port 5208
Reverse mode, remote host xxx.xxx.xxx.xxx is sending
      Cookie: o4kkpwwwof64csuhsr3nv2buvzdbyink34vj
      Target Bitrate: 62500000
[  5] local 10.115.179.92 port 35305 connected to xxx.xxx.xxx.xxx port 5208
[  7] local 10.115.179.92 port 42010 connected to xxx.xxx.xxx.xxx port 5208
[  9] local 10.115.179.92 port 45951 connected to xxx.xxx.xxx.xxx port 5208
iperf3: error - unable to read from stream socket: 

Steps to Reproduce:
It's not easy to reproduce this issue, as it depends on the state of the network connection.

The issue is not systematic and happens in case of congested data connection (iperf3 client is an Android phone with a LTE connection).

Here is the IP log:
TcRun_701281459_1_O_IP.Log.zip

From the IP log, it appears that the iperf3 client did not receive a response to the start request for some UDP streams and therefore it fails.
The server receives all requests and starts all four streams. In fact, the IP log shows that the client also receives the streams that were not acknowledged.
Therefore, theoretically, the Iperf3 client could understand that the stream was started but that it lost the first packets.

UDP transfer is not reliable, and therefore some packets may be lost. If the first packets are lost, Iperf3 should tolerate the loss and continue instead of failing.

[davidBar-On]

If the first packets are lost, Iperf3 should tolerate the loss and continue instead of failing.

This is an interesting suggestion. However, with the current iperf3 design it can work only if the ack (UDP_CONNECT_REPLY) to the last stream creation is lost (which is 100% for one stream test). E.g. in the logs sent the ack to the 4th stream creation was lost. This is because the server (and client) starts sending the test message only after all streams are created. It may be possible to repeat the ack few times, etc., but such changes are not easy, because the ack message is only 4 bytes while the messages are much longer.

From the log it seems that mainly the last UDP_CONNECT_REPLY is lost. This may be because in reverse mode, immediately after sending it the server starts sending the test messages which overload the interface. Therefore, it may be that adding a short delay between the streams creating and starting to send the message will solve this problem.

I have created this branch in my private repository which adds 200ms second sleep after all streams are accepted and before the test starts (the 200ms is just a guess that this is sufficient sleep time). Will you be able to try this version to see if it helps? (You can try different sleep times is the 200ms are not enough.) If it does help, I will submit it as a suggested change to iperf3.