At present the client makes the connection to the server before generating the data which sent to and measured at the server end. It would be nice if this could optionally be reversed such that a client could connect to the server and the data is then transferred from server to client.

This would allow use of iperf to test download when the client is behind a NAT gateway or similar (a common case for ADSL and other such ISP networks).

Isn't that what the -R flag does?

Its probably worth exploring various Firewall/NAT traversal options in the future.

changing summary lable

now -r / -d flag only start a server thead at an other port on client host

-R does enable "reverse" mode transfers from a server to a client. However it doesn't do anything with respect to opening up firewall ports or doing port forwarding on NAT boxes, which is the other part of the enhancement request.

Without making some fairly major changes to iperf3's use of the network (in particular, that would probably involve multiplexing control and data transfer on the same TCP connection, and I don't have a solution at all for UDP), I don't think we can do this.

I know there's are various heuristic ways of doing NAT traversal by injecting carefully crafted packets into the network, but I can't picture these fitting into iperf3 into any workable way.

I'm going to mark this as WontFix at this point, but it can be reopened if there is high demand and if we figure out a practical way to do it.

so sorry~

Could you explain why iperf cannot use existing connection initiated from client behind NAT to test both upload and download? I don't understand what is the reason to open new UDP or TCP connection in downlink test (when using -d or -r option).

This issue tracker is deprecated. Please do not post new issues or issue comments here. Instead, please use the issue tracker at:

https://github.com/esnet/iperf/issues

Thanks.