Firewall/NAT traversal options
Closed this issue · 10 comments
GoogleCodeExporter commented
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).
Original issue reported on code.google.com by Michael....@gmail.com on 12 Jul 2013 at 12:10
GoogleCodeExporter commented
Isn't that what the -R flag does?
Original comment by jef.posk...@gmail.com on 12 Jul 2013 at 2:01
GoogleCodeExporter commented
Its probably worth exploring various Firewall/NAT traversal options in the
future.
Original comment by bltier...@es.net on 23 Jul 2013 at 6:01
- Added labels: Milestone-future
GoogleCodeExporter commented
changing summary lable
Original comment by bltier...@es.net on 23 Jul 2013 at 6:04
- Changed title: Firewall/NAT traversal options
GoogleCodeExporter commented
Original comment by bltier...@es.net on 23 Jul 2013 at 6:05
GoogleCodeExporter commented
now -r / -d flag only start a server thead at an other port on client host
Original comment by liweihu...@gmail.com on 11 Aug 2013 at 10:01
GoogleCodeExporter commented
Original comment by bltier...@es.net on 18 Dec 2013 at 10:40
GoogleCodeExporter commented
-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.
Original comment by bmah@es.net on 22 Jan 2014 at 12:40
- Changed state: WontFix
GoogleCodeExporter commented
so sorry~
Original comment by liweihu...@gmail.com on 22 Jan 2014 at 12:58
GoogleCodeExporter commented
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).
Original comment by radoslaw...@gmail.com on 8 Apr 2014 at 2:07
GoogleCodeExporter commented
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.
Original comment by bmah@es.net on 8 Apr 2014 at 4:53