iperf 3.7 error: Resource temporarily unavailable

[kunal14kapoor]

I am facing an issue while binding a port looks to be the issue. I am using ueransim and trying to benchmark the bandwidth using iperf3. I am continuously getting below error : { "start": { "connected": [], "version": "iperf 3.7", "system_info": "Linux 29a1e56b8b73 5.15.0-1051-aws https://github.com/esnet/iperf/issues/56~20.04.1-Ubuntu SMP Tue Nov 28 15:43:31 UTC 2023 x86_64" }, "intervals": [], "end": { }, "error": "error - unable to connect to server: Resource temporarily unavailable" }

[davidBar-On]

Some questions:

1. The title say "iperf3.1.3" but the issue body say "version": "iperf 3.7",. Is it an error in the title?
2. What is the iperf version running on the server?
3. What is the machine the server is running on? What is its OS? Is it the same as the client?
4. What was the client iperf3 command ("iperf3 -c ......")? What was the server iperf3 command ("iperf3 -s ........")?

[kunal14kapoor]

Yes @davidBar-On, accidentally wrote 3.1.3. I am facing this issue with 3.7.

2. iperf version on both client and server is 3.7.
3. I am using two ubuntu machines which are located on AWS. ubuntu version is also same. both the machines are identical.
4. iperf client command : iperf3 -B eth0 -c -p 5201 -u -M 1360
5. iperf server command : iperf3 -s

[davidBar-On]

Thanks for the info. Just to make sure, I assume that this iperf3 test usually works o.k., and only sometimes you get the error. Is this correct?

Assuming the above is correct, probably the error is in the call to connect() function. As explained in the man page, the EAGAIN errno ("Resource temporarily unavailable") happens when temporarily resources are missing. Currently, iperf3 does not handle such cases, i.e. it does not retry connecting. If this is the case, then the solution is probably to do the retry in a shell script.

[kunal14kapoor]

Thanks for sharing the info about the intermittent issue but this is a persistent issue and we have never seen any packet transfer in this case.

The actual description of the issue goes like this : We have containerized the UERANSIM using docker and when run a script to spawn a UE which eventually created a new tunnel interface to connect to the internet via 5G core. We are trying to benchmark the 5G-core bandwidth performance where we are using iperf3. This works fine when the UERANSIM is non-containerized and we can see the packets between client and server.

[davidBar-On]

I assume that the issue is related to some kind of NAT (IP address translation) that is need because of the additional network layer added by the container. iperf3 connection is done using TCP, so either the TCP sync message did not get to the server, or more probable, the ack was sent to the wrong client address. If this is the problem, then Wireshark or tcpdump (on each end) can be used to determine the address used in the messages.

Also, I don't know much about Docker containers networking, but I see that a container can started using --network="host" to run it using the host's networking stack. That may get around the issue.

[kunal14kapoor]

Thanks @davidBar-On for adding another possibility to it but the only thing I am thinking about is how ping is working if there is an issue with the networking? Also just wanted to share that we are using network mode as macvlan in the deployment .

[davidBar-On]

ping and TCP use different methods for sending identifying the source address for sending back the acks, as ping uses IP's ICMP and TCP runs over IP. Also, the routers, etc. may included different solution to support the ICMP and TCP acks.

It seems that to further evaluate the issue, it should be known whether the server received the iperf3 TCP SYN message or whether the problem is sending the SYN ack back (see for example RFC-5508 about ICMP NAT traversal). For that, tools such Wireshark or tcpdump should be used.

It may also help using traceroute (which also use ICMP) to understand the difference between the client to server routing with and without using a container.