Iperf 3.18 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 03/02/2023 at 00:05, BudMan said:

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

Expand  

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

 

  On 03/02/2023 at 00: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..

Expand  

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.

Expand  

 

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 22/02/2023 at 00: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.

Expand  

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

 

  On 22/02/2023 at 00:43, userdocs said:

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

Expand  

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 14:02, userdocs said:

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

Expand  

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 15:08, RRRobbo said:

iperf3 -u -c localhost -p 51376

Expand  

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).

 

[+BudMan MVC]

Well 3.17 is out, but it says 3.16+ ?

Budman@I9-WIN G:\iperf3.17_64
$ iperf3.exe -v
iperf 3.16+ (cJSON 1.7.15)
CYGWIN_NT-10.0-19045 i9-win 3.5.3-1.x86_64 2024-04-03 17:25 UTC x86_64
Optional features available: CPU affinity setting, authentication, support IPv4 don't fragment, POSIX threads

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

CRC32: F6D8E2A8
MD5: 03E0ED0BF5E9A52CC22BDEBF9681BE81
SHA-1: 370D1B1896990CD2BA3806FD609185D2F977EDB8
SHA-256: C1AB63DE610D73779D1003753F8DCD3FAAE0B6AC5BE1EAF31BBF4A1D3D2E3356

iperf-3.17 2024-05-10

Notable user-visible changes

• BREAKING CHANGE: iperf3's authentication features, when used with OpenSSL prior to 3.2.0, contain a vulnerability to a side-channel timing attack. To address this flaw, a change has been made to the padding applied to encrypted strings. This change is not backwards compatible with older versions of iperf3 (before 3.17). To restore the older (vulnerable) behavior, and hence backwards-compatibility, use the --use-pkcs1-padding flag. The iperf3 team thanks Hubert Kario from RedHat for reporting this issue and providing feedback on the fix. (CVE-2024-26306)(PR#1695)
• iperf3 no longer changes its current working directory in --daemon mode. This results in more predictable behavior with relative paths, in particular finding key and credential files for authentication. (PR#1672)
• A new --json-stream option has been added to enable a streaming output format, consisting of a series of JSON objects (for the start of the test, each measurement interval, and the end of the test) separated by newlines (#444, #923, #1098).
• UDP tests now work correctly between different endian hosts (#1415).
• The --fq-rate parameter now works for --reverse tests (#1632, PR#1667).
• The statistics reporting interval is now available in the --json start test object (#1663).
• A negative time test duration is now properly flagged as an error (IS#1662 / PR#1666).

Notable developer-visible changes

• Fixes have been made to better (unofficially) support builds on Android (#1641 / #1651) and VxWorks (#1595).
• iperf3 now builds correctly on architectures without native support for 64-bit atomic types, by linking with the libatomic library (#1611).

 

$ iperf3 -c 192.168.10.10 -V                                                                               
iperf 3.16+                                                                                                
CYGWIN_NT-10.0-19045 i9-win 3.5.3-1.x86_64 2024-04-03 17:25 UTC x86_64                                     
Control connection MSS 1460                                                                                
Time: Fri, 10 May 2024 23:28:44 GMT                                                                        
Connecting to host 192.168.10.10, port 5201                                                                
      Cookie: vcvit4yasx22maqwd2pghqokr3ksjagjspcx                                                         
      TCP MSS: 1460 (default)                                                                              
[  5] local 192.168.10.9 port 43749 connected to 192.168.10.10 port 5201                                   
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test, tos 0     
[ ID] Interval           Transfer     Bitrate                                                              
[  5]   0.00-1.02   sec   288 MBytes  2.37 Gbits/sec                                                       
[  5]   1.02-2.01   sec   284 MBytes  2.39 Gbits/sec                                                       
[  5]   2.01-3.01   sec   282 MBytes  2.37 Gbits/sec                                                       
[  5]   3.01-4.01   sec   284 MBytes  2.37 Gbits/sec                                                       
[  5]   4.01-5.01   sec   281 MBytes  2.37 Gbits/sec                                                       
[  5]   5.01-6.00   sec   282 MBytes  2.37 Gbits/sec                                                       
[  5]   6.00-7.01   sec   286 MBytes  2.37 Gbits/sec                                                       
[  5]   7.01-8.02   sec   283 MBytes  2.37 Gbits/sec                                                       
[  5]   8.02-9.02   sec   283 MBytes  2.37 Gbits/sec                                                       
[  5]   9.02-10.01  sec   281 MBytes  2.37 Gbits/sec                                                       
- - - - - - - - - - - - - - - - - - - - - - - - -                                                          
Test Complete. Summary Results:                                                                            
[ ID] Interval           Transfer     Bitrate                                                              
[  5]   0.00-10.01  sec  2.77 GBytes  2.37 Gbits/sec                  sender                               
[  5]   0.00-10.02  sec  2.76 GBytes  2.37 Gbits/sec                  receiver                             
CPU Utilization: local/sender 12.1% (2.2%u/9.9%s), remote/receiver 72.8% (3.1%u/69.7%s)                    
rcv_tcp_congestion cubic                                                                                   
                                                                                                           
iperf Done.                                                                                                

 

[+BudMan MVC]

ok they release a 3.17.1

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

CRC32: 6311D9F3
MD5: FCA5170E2CDBB469A880C3E7AAEFCCC8
SHA-1: 2F16012B6F0373522B084B16BBA634B010A4BCC0
SHA-256: A36D8A6284C3097D74E61B3DB5FF45EF08D77494F17E34900C73D69DA94E3810

[aflurko]

There is a branch version of iperf3.17.1+ with working udp bidirect test under windows https://github.com/davidBar-On/iperf/tree/issues-472-1161-cygwin-parallel-udp-stearms can someone try to compile it?

[Mindovermaster Global Moderator]

  On 01/10/2024 at 19:44, aflurko said:

windows https://github.com/davidBar-On/iperf/tree/issues-472-1161-cygwin-parallel-udp-stearms can someone try to compile it?

Expand  

@BudMan

[userdocs]

  On 01/10/2024 at 19:44, aflurko said:

There is a branch version of iperf3.17.1+ with working udp bidirect test under windows https://github.com/davidBar-On/iperf/tree/issues-472-1161-cygwin-parallel-udp-stearms can someone try to compile it?

Expand  

 

@aflurko you can try these https://github.com/userdocs/iperf3-static/actions/runs/11298286562

[aflurko]

Unfortunately, your compilation does not work in UDP --bidir test, it behaves like the main branch (both windows and linux version). I just managed to do a local compilation in cygwin and this version worked. I have no idea why, unless you accidentally cloned the wrong branch?
working version - windows (cygwin):

 git clone --single-branch --branch issues-472-1161-cygwin-parallel-udp-stearms https://github.com/davidBar-On/iperf.git iperf3
 cd iperf3/
 ./bootstrap.sh
 ./configure --enable-static --enable-static-bin --disable-shared --prefix=`pwd`/output --without-openssl
 make
 make install

and linux:

 ./configure --enable-static-bin --disable-shared "LDFLAGS=--static" --prefix=`pwd`/output --without-openssl

I am testing linux as client, windows as server