Re: NEW: net/iperf3
On Tue, Sep 20, 2016 at 02:13:55AM +0100, Stuart Henderson wrote:
> On 2016/09/19 15:39, Jeremie Courreges-Anglas wrote:
> > 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?
This is my first Github-based port and it totally slipped my mind that
DISTNAME does not need to be set. :)
> > 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.
>
> OK with me.
>
> It might be worth defaulting to v4, but that can happen later.
Thank you for the feedback and ok's. I have imported the port including
jca@'s patches.
Here's an update to default to IPv4 and remove the unnecessary DISTNAME.
ok?
Index: Makefile
===
RCS file: /cvs/ports/net/iperf3/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile21 Sep 2016 01:12:57 - 1.1.1.1
+++ Makefile21 Sep 2016 01:51:36 -
@@ -3,8 +3,8 @@
COMMENT= tool to measure maximum achievable bandwidth on IP networks
V= 3.1.3
-DISTNAME= iperf-${V}
PKGNAME= iperf3-${V}
+REVISION= 0
GH_ACCOUNT=esnet
GH_PROJECT=iperf
Index: patches/patch-src_iperf_api_c
===
RCS file: /cvs/ports/net/iperf3/patches/patch-src_iperf_api_c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-src_iperf_api_c
--- patches/patch-src_iperf_api_c 21 Sep 2016 01:12:57 - 1.1.1.1
+++ patches/patch-src_iperf_api_c 21 Sep 2016 01:51:41 -
@@ -1,9 +1,20 @@
$OpenBSD: patch-src_iperf_api_c,v 1.1.1.1 2016/09/21 01:12:57 lteo Exp $
+Default to IPv4.
+
Missing initialization.
src/iperf_api.c.orig Mon Sep 19 14:27:01 2016
-+++ src/iperf_api.cMon Sep 19 14:27:03 2016
+--- src/iperf_api.c.orig Mon Jun 6 14:18:49 2016
src/iperf_api.cSun Sep 18 01:51:24 2016
+@@ -1839,7 +1839,7 @@ iperf_defaults(struct iperf_test *testp)
+ testp->stats_interval = testp->reporter_interval = 1;
+ testp->num_streams = 1;
+
+-testp->settings->domain = AF_UNSPEC;
++testp->settings->domain = AF_INET;
+ testp->settings->unit_format = 'a';
+ testp->settings->socket_bufsize = 0;/* use autotuning */
+ testp->settings->blksize = DEFAULT_TCP_BLKSIZE;
@@ -2323,7 +2323,7 @@ iperf_print_results(struct iperf_test *test)
struct iperf_stream *sp = NULL;
iperf_size_t bytes_sent, total_sent = 0;
Re: NEW: net/iperf3
On 2016/09/19 15:39, Jeremie Courreges-Anglas wrote: > 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. OK with me. It might be worth defaulting to v4, but that can happen later.
Re: NEW: net/iperf3
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
Re: NEW: net/iperf3
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 <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), 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 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. Lawrence
NEW: net/iperf3
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), 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 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. Lawrence iperf3-3.1.3.tar.gz Description: application/tar-gz
