Stuart Henderson <s...@spacehopper.org> writes: > Hi, I'd strongly prefer a new port for this and keep the existing one as > there are quite a few devices with built-in copies of iperf 2.
Seconded. > On 17 September 2016 3:19:45 p.m. Lawrence Teo <l...@openbsd.org> wrote: > >> net/iperf is at 2.0.5 and no longer maintained; its website >> (http://iperf.sourceforge.net) now directs users to iperf3 instead. >> >> A description of iperf3 is available at the top of their main >> non-github site at http://software.es.net/iperf/ -- the summary is that >> iperf3 is a rewritten iperf that is not backwards compatible with iperf. >> The installed binary name has also changed; it is now "bin/iperf3" >> instead of "bin/iperf". >> >> I have attached the new net/iperf3 port for review. >> >> Note: Due to the way iperf3 uses IPV6_V6ONLY >> (https://github.com/esnet/iperf/issues/196), I don't quite understand why adding #ifdefs here helps. It should just be a soft error. >> iperf3 can only listen >> on IPv6 or IPv4 but not both when you start it in server mode. If you >> would like to use it in server mode with IPv4, you will need to run: >> >> iperf3 -4 -s sigh :) >> Some questions: >> >> 1. Is it preferable to introduce a new port or update the existing >> net/iperf port? I lean towards introducing a new port because of the >> backwards incompatibility, and the situation is similar to >> security/p0f and security/p0f3. >> >> 2. If it's preferable to introduce a new port, should the old net/iperf >> port be removed? >> >> Last but not least, thanks to jca@ for prodding me about this. :) ;) >> Thoughts and reviews welcome. No need to set DISTNAME in Makefile, did you want to make it explicit? The port looks and works fine here, ok jca@. I added a few patches for the visible warnings, the %llu one matters the most I'd say. Updated tarball below.
iperf3.tgz
Description: Binary data
-- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
