Stuart Henderson <> 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.


> On 17 September 2016 3:19:45 p.m. Lawrence Teo <> wrote:
>> net/iperf is at 2.0.5 and no longer maintained; its website
>> ( now directs users to iperf3 instead.
>> A description of iperf3 is available at the top of their main
>> non-github site at -- 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
>> (,

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.

Attachment: iperf3.tgz
Description: Binary data

jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply via email to