Iperf 3.16 Windows build

[+BudMan MVC]

What the hell would of been nice to have been asked before putting out links to my site

https://github.com/esnet/iperf/commit/597d16a3567bb64d50c8d0f2882a0407a0f7d5d5

@CryptAnalystyour site would be a better link to mine..

[CryptAnalyst]

Glad to see this. You earned it.

[+BudMan MVC]

Thanks - but your work is so much more refined than mine... I will prob keep my copies going, just out of habit and it only takes a few minutes.  But someone was looking for iperf the other day on some other thread - and I just pointed them to your copies   Hope you don't mind..

But it was nice they threw in this thread as well...

 

[CryptAnalyst]

On 02/02/2023 at 19:05, BudMan said:

I will prob keep my copies going, just out of habit and it only takes a few minutes.

You should keep it going and continue the good work. Now it is mentioned in the official src repo as well.

 

On 02/02/2023 at 19:05, BudMan said:

But someone was looking for iperf the other day on some other thread - and I just pointed them to your copies   Hope you don't mind..

Not at all, it is for the community.

[+BudMan MVC]

New version 3.13 out

$ iperf3.exe -v
iperf 3.13 (cJSON 1.7.15)
CYGWIN_NT-10.0-19045 i9-win 3.4.6-1.x86_64 2023-02-14 13:23 UTC x86_64
Optional features available: CPU affinity setting, authentication, support IPv4 don't fragment

https://files.budman.pw/iperf3.13_64.zip

MD5: CE3AD0A3F1BFACDDCB8253BE0A5B4264
SHA-1: D7DB436A324EAE175148221F4036CF253627EEC7
SHA-256: 28AD4F9146B112FE4AAFC092042A1769F38E4031E6FE9C5790BFFE56B696028C

Looks like @CryptAnalystbeat me to the punch by like 22 minutes - wtf hahahahahha

Check his stuff out at

https://github.com/ar51an/iperf3-win-builds

He does a way more professional looking release, and has with openssl if you need/want it.

 

 

 

 

[userdocs]

Hello, specifically @BudMan @CryptAnalyst

Your recent efforts motivated to me get a working Github action based solution to building iperf3 via Cygwin and providing releases. Normally what happens is they release after so long I just built it myself or used your build and then never got around to it. Also Cygwin via an action is not exactly the easiest thing to get your head around, but fortunately me for me, I was half way there from my experience with another cool project. https://vegardit.github.io/cygwin-portable-installer/

I updated my main project here to host them along side the Linux binaries:

https://github.com/userdocs/iperf3-static

The bit you are interested in is here. I have made two workflows for you to reuse.

1: using an official GitHub action https://github.com/cygwin/cygwin-install-action (but don't assume this is the better method)

https://github.com/userdocs/iperf3-static/blob/master/.github/workflows/cygwin_action.yml

2: Using my customised Cygwin installer script https://github.com/userdocs/iperf3-static/blob/master/cygwin-installer.cmd

https://github.com/userdocs/iperf3-static/blob/master/.github/workflows/cygwin_cmd.yml

Here we can see my scripted method is faster and everything you need is in the dir relative you.

Ultimately though it's personal preference as they both used the same build script, by design.

https://github.com/userdocs/test/blob/main/build.sh

These files specific to these workflows

.github/workflows/cygwin_action.yml

.github/workflows/cygwin_cmd.yml

packages_openssl.cmd

packages_basic.cmd

build.sh

cygwin-installer.cmd

Links to builds:

Windows x64 no openssl

https://github.com/userdocs/iperf3-static/releases/latest/download/iperf3-amd64-win.zip

Windows x64 with openssl

https://github.com/userdocs/iperf3-static/releases/latest/download/iperf3-amd64-openssl-win.zip

I have credited you both, which i think is only fair.

https://github.com/userdocs/iperf3-static#credits-and-acknowledgements

Conclusion:

You can take the workflow of you choice and reuse it as you wish.

Some point soon i'll add a check for new released upstream and it can trigger builds within minutes of a new release being published, 100% automation unless something require manual intervention.

I can't really say a single approach method would be simper. I found my method more consistent and to work with than the official action but I have a highly customised installer.

But at least you can see how it can be done should you wish you expand on the idea.

[CryptAnalyst]

This workflow will not create iperf3 executable statically linked with openssl, which eliminates to bundle cygcrypto-1.1.dll & cygz.dll.

Something is not right with your cygwin installation/workflow. For dynamically linking with openssl you do not need to specify --with-openssl and hence in your workflow that sed cmd and OPENSSL_LIBS are redundant due to that.

[userdocs]

On 21/02/2023 at 13:09, CryptAnalyst said:

This workflow will not create iperf3 executable statically linked with openssl, which eliminates to bundle cygcrypto-1.1.dll & cygz.dll.

Something is not right with your cygwin installation/workflow. For dynamically linking with openssl you do not need to specify --with-openssl and hence in your workflow that sed cmd and OPENSSL_LIBS are redundant due to that.

 

I can assure you it's not the workflow that's the problem. It's me (it usually is)

Coming from an Alpine headspace I did not realise the libssl.dll.a and libcrypto.dll.a were not static, so i was bruting forcing an attempt to build statically where it just needs to be dynamic.

So essentially the configure of iperf3 is the issue, telling it to make a static bin and it can't find the static openssl libs. Current workflows will be fixed to not try to build static essentiality.

Which just leaves the static auth builds you made.

How are you linking the openssl build statically? (i assume you are compiling openssl and zlib from source)

Edited February 22, 2023 by userdocs

[userdocs]

It's done.

Workflows and build revised. https://github.com/userdocs/iperf3-static/actions/runs/4239050241

• A normal non openssl build.
• An openssl build statically linked against latest openssl (3.0.8)  and zlib-ng (1.2.13) 

[CryptAnalyst]

On 21/02/2023 at 19:43, userdocs said:

Coming from an Alpine headspace I did not realise the libssl.dll.a and libcrypto.dll.a were not static, so i was bruting forcing an attempt to build statically where it just needs to be dynamic.

.dll.a is just the import library that helps in linking with .dll

 

On 21/02/2023 at 19:43, userdocs said:

How are you linking the openssl build statically? (i assume you are compiling openssl and zlib from source)

Yes I do compile openssl for static linking but you already figured that out.

[userdocs]

If you want we can make a slighty more convential workflow for your repo?

Using the official cygwin action (for support and maintenence)

Using cygwin source code for openssl/ zlib

Replicatating your current deployment, except maybe the OS used to build as the runners use win server.

btw, has anyone used authentication and confirmed it works as intended? openssl has a hardcoded path to the certificates it looks for.

 

[CryptAnalyst]

On 23/02/2023 at 09:02, userdocs said:

If you want we can make a slighty more convential workflow for your repo?

Thank you. Really appreciate it. I have a local workflow in place that I use for few other repos as well. I build openssl from cygwin mingw openssl src.

BudMan

iperf3 released a new tag 3.13-mt1. Where mt stands for multithreaded release. Development of this release is done in new branch "mt". Just to let you know such that you can do a release for this one.

[+BudMan MVC]

Thanks I saw that .. Did you do a release for it, I hadn't gotten around to playing with it yet..  I am on their mailing list but hadn't look into it yet..

[CryptAnalyst]

Yes i did.

[+BudMan MVC]

3.14 is out

https://files.budman.pw/iperf3.14_64.zip

MD5: F2E950606D42EDC33BAEDC2A475791F7
SHA-1: DD1810A0A76A428274B45BBE97FDA8E026B3C552
SHA-256: A4D01475E70CB78352D1754A24A8DBF71DB848AF985CFAF5FB75D1E65F0FA664

 

[RRRobbo]

Hi there. I am new to Iperf and have been trying to use it to test the Trellix(McAfee) firewall logging. I need to prove to Trellix that it is a bit wrong. To do this, I have to get multiple programs running with the same UDP port open. So, I picked a port (51376) that was already open by another program (in this case Teams.exe) and ran this to get my iperf server service up:

iperf3 -s -p 51376

I then ran this 

iperf3 -u -c localhost -p 51376

But it does not work. I get this error:

iperf3: error - unable to read from stream socket: Resource temporarily unavailable

If I do not use the -u, it connects fine to TCP and I can see the server accepting it. I have found a google reference that suggests that UDP testing like this does not work well on machines with multiple nics, so maybe that is the issue, as I have several. I am doing all of this on my own PC. No others involved.

I am using the latest Iperf (many thanks for this btw)

Any other ideas?

[+BudMan MVC]

On 08/08/2023 at 10:08, RRRobbo said:

iperf3 -u -c localhost -p 51376

Localhost would almost always resolve to just 127.0.0.1

And pretty sure when you connect to pfsense and do a UDP test it actually connects via tcp first..

See how there is the syn and syn,ack talking to port, I duplicated your port and then udp test - to remote IP.. See it talks over tcp first before it starts sending the UDP traffic on that port.

 

 

[+BudMan MVC]

3.15 is out

https://files.budman.pw/iperf3.15_64.zip

CRC32: B9377873
MD5: 368FDF957DA41124515BC56131B014F4
SHA-1: D23EA253A73F24812087A05EAEC3C5E1653ADF63
SHA-256: 15BCAE86ED07FAFBB6CF0A91D5ECED2CEEE65077C05059927C707D87077D3618

 

 

[+BudMan MVC]

3.16 is out

Budman@I9-WIN C:\tools\iperf3.16_64
$ iperf3.exe -v
iperf 3.16 (cJSON 1.7.15)
CYGWIN_NT-10.0-19045 i9-win 3.4.10-1.x86_64 2023-11-29 12:12 UTC x86_64
Optional features available: CPU affinity setting, authentication, support IPv4 don't fragment, POSIX threads

https://files.budman.pw/iperf3.16_64.zip

CRC32: AA6A0862
MD5: 5F7F24A0BB135DDE38C6182A9F60D6D4
SHA-1: 2C24A2499A1EFECC0B7F592705CB460864FE6072
SHA-256: 52063FF7CC8570A86A0AAAEF8221370AFB4A4EE93ACA2029B7DF4BAAD7032B15

iperf-3.16 2023-11-30

• Notable user-visible changes

  • Multiple test streams started with -P/--parallel will now be serviced by different threads. This allows iperf3 to take advantage of multiple CPU cores on modern processors, and will generally result in significant throughput increases (PR #1591).

  • OpenSSL 3 is now detected at build time. If OpenSSL 3 is found, various older, deprecated, APIs will not be used. iperf3 will continue to work with OpenSSL 1.1.1. OpenSSL is used as a part of the iperf3 authentication functionality (Issue #1300, PR #1589).

  • The authorized users file used by the authentication functionality is now checked for accessibility much earlier during the program startup, as opposed to being checked near the start of a test (Issue #1583, PR #1585).