I just built the iperf3 debian package from source and it duly puts it in the right place:

What happens if you then install iperf from the repo?

Which version of source code did you use? never mind, I’ve just read it properly.

Aaaaaand that’s nailed it. \o/

# which iperf
/usr/bin/iperf

# which iperf3
/usr/local/bin/iperf3

Though bizarrely it’s now telling me that the package can be removed with dpkg -r iperf-3.1 – where does it get that name from (ie, how do I make it just add / remove as iperf3)?

Are you sure you haven’t got another iperf3 in /usr/bin? which probably only reports the first one it finds.

There’s just iperf in /usr/bin. What difference would it make if there was?

Isn’t this the scenario that the designers of SNAP foresaw and just by pure chance Ubnuntu 16.04 includes the capability to run SNAPs

http://snapcraft.io/create/

When you did checkinstall, you should have named your package iperf3

like this
checkinstall --pkgname=iperf3 make install

then you can have

root@rextest2:/var/www/html/iperf-3.1.3# dpkg -l |grep iperf
ii iperf 2.0.5+dfsg1-2 amd64 Internet Protocol bandwidth measuring tool
ii iperf3 3.1.3-1 amd64 Package created with checkinstall 1.6.2


Oooh. Give me a sec.

Bingo! Perfect.

That’s brilliant, thank you.

(I’m now wondering whether that would’ve fixed the initial problem in the first place…)

Welcome.

I now have …
root@rextest2:/# which iperf
/usr/bin/iperf
root@rextest2:/# which iperf3
/usr/local/bin/iperf3


So I guess it would have solved your problem? The binaries both run and show the right version numbers anyway.

Assumes iperf 2 installed already in 16.04

$sudo snap install lcavassa-iperf

Logout, log back in

$lcavassa-iperf.iperf runs iperf v3.1.3

$iperf runs the original

For completeness,

dpkg -l | grep iperf
ii  iperf                                 2.0.5+dfsg1-2                            amd64        Internet Protocol bandwidth measuring tool
ii  iperf3                                3.1.4.M-1                                amd64        Maintel iperf3 build
ii  libiperf0:amd64                       3.1.3-1                                  amd64        Internet Protocol bandwidth measuring tool (runtime files)

Now installed into my image and working fine. Thanks again.

…out of interest, Cougar….

You mentioned that this is for a field-force of some kind (sounds like remote network testing/proving). You’ve managed to get them to run Linux of some kind?

Much hassle?

Yeah, it’s for our field-based installation engineers. There’s a broad spectrum when it comes to ability as you’d expect, and their networking skills and their PC skills have little bearing on each other. So some of them have taken to Linux like a duck to petrol for sure, whereas some have been really enthusiastic and offered great feedback / suggestions as to what else we could do with it.

Thing is, they still use Windows for day-to-day stuff. For the testing they boot off the USB pendrive, open a terminal, then they’re on a command-line where they run iperf commands following a guide. They save captures to a FAT32 partition on the pendrive which they can then frob about with back in Windows. So most of them aren’t really “using Linux” per sé.

TBH though, the forerunner to this was some nasty Knoppix live CD someone had cobbled together, so for those few who used the old one this solution is like someone’s taken away their Ford Ka and given them an Aston Martin.

Interesting. Good fix that; I used to have to deal with our field guys on a daily basis (network installs and latterly testing too) and the capacity of some of them to do way, way more than expected was always heartening- sometimes, jobs that looked like a multi-day fest could be done in 1 as your tech had already done all the prep. Gawd bless ’em!!!

For our field-based guys (this was a few years ago, mind) someone bought in a dedicated testing solution; this was a server in a DC, connected out to various VRF’s (this was all MPLS) via vlans (could do layer 3/4 stuff too) and would look at our records system to verify QoS details on circuits. The fieldies would then run the test from their windows machines, and the server would yes/no. It was nice as you could save the results as a web page and send to the customer as proof; billing could then commence.

It was made by IXIA and was a tremendous amount of money. It was fairly painless when we got it up and running, and the inventory lookup was nice (we used CRAMER for this), but I always felt it was overkill, as the field guys were all very competent, and iperf had worked for me in the past.

I miss those days…..

Cool. We’re heading that way I think but a lot of this is in its infancy, I’ve been in this role for about 12 months and before that it was largely left to stagnate (through no fault of my predecessor I should add, he’s one of those people who is always in massive demand by dint of him being too brilliant for his own good).

As for the pendrive, considering I knew very little about Linux when I started this little project, I’m pretty pleased with the end result (and I’ve learned a lot in the process). See the previous thread I linked to in the second post here.

I think it’s a pretty elegant solution over a persistent Live CD USB. The beauty of it is that the source is a VM, so I can easily back it up, spin it up to make system changes, apply updates, add features, then it’s just a single flat image file I can burn to USB. I’ve even got a process now where I can burn it from Windows, which suddenly makes it friendly for Linux-curious engineers who can download it from my OneDrive account and roll their own drives (and moreover, saves me having to re-burn umpteen drives at 20 minutes per stick every time there’s a major change).