Recommended Posts

Yeah just got this email few hours ago

unblocked.thumb.png.2f4122fb09f8ad18f0c1259da9d73b9a.png

 

Thanks for bringing to my attention @Marshall

 

And now virustotal scan shows clean on all 66, the eset listing is gone

scan.thumb.png.45eed021dbb8f6f788969787810af2df.png

 

  • Like 2

So I prettied up the dir listing, got rid of some old versions.  And enabled https for those that think everything should be https ;)

 

https://files.budman.pw

 

If anyone wants/needs version prior to 3.1.1 just let me know and can put it up.

  • 4 months later...

Added 3.3

 

Budman@I5-WIN D:\Iperf\iperf3.3_32
> iperf3.exe -v
iperf 3.3 (cJSON 1.5.2)
CYGWIN_NT-6.3-WOW i5-win 2.9.0(0.318/5/3) 2017-09-12 10:41 i686
Optional features available: authentication

 

Budman@I5-WIN D:\Iperf\iperf3.3_64
> iperf3.exe -v
iperf 3.3 (cJSON 1.5.2)
CYGWIN_NT-6.3 i5-win 2.9.0(0.318/5/3) 2017-09-12 10:18 x86_64
Optional features available: authentication

 

File: iperf3.3_64.zip
MD5: 49095ccb2442101d2a1ffc6213f3d1b9
SHA-256: 1fea7ae97b8ec5ab1c61ef1afcf7afd491d37ef41061a845f9bb8477425c66db

 

File: iperf3.3_32.zip
MD5: b6ad4c094a18196e0798e1a2825bc609
SHA-256: 919978ac0b574d7662d5b0e58174a6107002db96e7592929a9a28938516a2c5f

 

https://files.budman.pw/

 

 

 

  • 2 months later...

New 3.4 is out

 

Budman@I5-WIN D:\iperf3.4_64

> iperf3.exe -v
iperf 3.4 (cJSON 1.5.2)
CYGWIN_NT-6.3 i5-win 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64
Optional features available: CPU affinity setting, authenticatio

 

Budman@I5-WIN D:\iperf3.4_32
> iperf3.exe -v
iperf 3.4 (cJSON 1.5.2)
CYGWIN_NT-6.3-WOW i5-win 2.10.0(0.325/5/3) 2018-02-02 15:21 i686
Optional features available: authentication

 

https://files.budman.pw/iperf3.4_32.zip

MD5: 3b805d0895e7bb4d005429ed5859dd00
SHA-256: 82a933bbf96731a615ee5ae40bc1e6986ffcdd0b83c7c4e9cd024a996b3c0808
https://files.budman.pw/iperf3.4_64.zip

MD5: e4c0d2d8bda22ebbb710a9a65aacddf9
SHA-256: 7a3f83d211d22102d05dcf0eb24f4ff8cd3d9083aada9a27c88ba7ced0a0eccc

 

https://github.com/esnet/iperf/blob/master/RELEASE_NOTES

release notes

== iperf 3.4 2018-02-14 ==

* Notable user-visible changes

  * The -A (set processor affinity) command-line flag is now supported
    on Windows (#665).

  * iperf3 now builds on systems lacking a daemon(3) library call
    (#369).

  * A bug in time skew checking under authentication was fixed (#674).

  * IPv6 flow labels now work correctly with multiple parallel streams
    (#694).

  * The client no longer closes its control connection before sending
    end-of-test statistics to the server (#677). This fixes a
    regression introduced in iperf-3.2.

  * Sending output to stdout now makes errors go to stderr, as per
    UNIX convention (#695).

  * A server side crash in verbose output with a client running
    multiple parallel connections has been fixed (#686).

  * The --cport option can now be specified without the --bind option.
    Using the --cport option on Linux can eliminate a problem with
    ephemeral port number allocation that can make multi-stream iperf3
    tests perform very poorly on LAGG links.  Also, the --cport option
    now works on SCTP tests (#697).

* Notable developer-visible changes

  * iperf3 now builds on (some) macOS systems older than 10.7 (#607).

  * Some unused code and header inclusions were eliminated (#667,
    #668).  Also some code was cleaned up to eliminate (or at least
    reduce) compiler warnings (#664, #671).

  • 3 weeks later...

3.5 is out

 

== iperf 3.5 2018-03-02 ==

* Notable user-visible changes

  * iperf3 no longer counts data received after the end of a test in
    the bytecounts.  This fixes a bug that could, under some
    conditions, artificially inflate the transfer size and measured
    bitrate.  This bug was most noticeable on reverse direction
    transfers on short tests over high-latency or buffer-bloated
    paths.  Many thanks to @FuzzyStatic for providing access to a test
environment for diagnosing this issue (#692).

 

Budman@I5-WIN D:\iperf3.5_32
> iperf3.exe -v
iperf 3.5 (cJSON 1.5.2)
CYGWIN_NT-6.3-WOW i5-win 2.10.0(0.325/5/3) 2018-02-02 15:21 i686
Optional features available: authentication

 

Budman@I5-WIN D:\iperf3.5_64
> iperf3.exe -v
iperf 3.5 (cJSON 1.5.2)
CYGWIN_NT-6.3 i5-win 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64
Optional features available: CPU affinity setting, authentication

 

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

CRC32: 18962237
MD5: 840a2d5e0f81d8a6dc0d8be854caf61a
SHA-1: 1a18185c79645b082392dcd024b7e53900dc38bd
SHA-256: 94a0ec4e486904a6a8ebe390eca37871f47a097599908c3647d6ad1d0bbdff59
 

https://files.budman.pw/iperf3.5_32.zip

CRC32: 21d8a0eb
MD5: dd79fe69c86e62c780e45e6e0d2ec66d
SHA-1: 2c63c1f9ef35be23170869a6a7eb048241aa2f14
SHA-256: bf4b95a58e54ceda101e33b0b908c581df1ce4a217f233e1092dc3278572de43
 

  • 2 weeks later...

Yeah like anyone would care?  Its XP... Been dead OS for years and years...

https://www.microsoft.com/en-us/windowsforbusiness/end-of-xp-support

 

So April of 2014 - your talking 4 years ago.. What next you will want it to run in Dos 6.2? ;)

 

Sorry but I am not going to troubleshoot it.. These versions work on my 64 bit system, why I still do the 32 bit I don't really know - but it also runs on my 64 bit system..

 

Hint move to a current 64 bit windows ;)

  • 2 weeks later...

anyone encouters this new problem in newer versions!

 

I was running the latest windows version before from the official site (very old from 2016). It was working flawlessly except for udp mode. So i wanted to update and build the code by myself. It seemed to work for the first time, but the server immediatly crashes after the first connect, making a second connect impossible. 

 

I thought i made a bad build and downloaded several versions from here.. All are crashing after the first connect (which is successfull).

 

Oh and one thing i forgot. This only happens in "silent mode" server. If i start the server by myself via cmd, it will stay open. If i start the server from windows server (with no gui) the server crashes after one connect. 

 

Any hint/tip would be great! 

Edited by NoNeed4Mercy
missing information
50 minutes ago, NoNeed4Mercy said:

anyone encouters this new problem in newer versions!

 

I was running the latest windows version before from the official site (very old from 2016). It was working flawlessly except for udp mode. So i wanted to update and build the code by myself. It seemed to work for the first time, but the server immediatly crashes after the first connect, making a second connect impossible. 

 

I thought i made a bad build and downloaded several versions from here.. All are crashing after the first connect (which is successfull).

 

Oh and one thing i forgot. This only happens in "silent mode" server. If i start the server by myself via cmd, it will stay open. If i start the server from windows server (with no gui) the server crashes after one connect. 

 

Any hint/tip would be great! 

Delete my post! -D is working in newer versions for windows service! 

  • 2 months later...

Well might take me a bit to get this compiled running into an error

 

budman@i5-win /iperf-3.6
$ make
Making all in src
make[1]: Entering directory '/iperf-3.6/src'
make  all-am
make[2]: Entering directory '/iperf-3.6/src'
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.     -g -O2 -Wall -MT iperf_api.lo -MD -MP -MF .deps/iperf_api.Tpo -c -o iperf_api.lo iperf_api.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -g -O2 -Wall -MT iperf_api.lo -MD -MP -MF .deps/iperf_api.Tpo -c iperf_api.c  -DDLL_EXPORT -DPIC -o .libs/iperf_api.o
In file included from /usr/include/w32api/Windows.h:95:0,
                 from iperf_api.c:67:
/usr/include/openssl/ossl_typ.h:159:29: error: expected ‘)’ before numeric constant
 typedef struct X509_name_st X509_NAME;
                             ^
/usr/include/openssl/ossl_typ.h:207:33: error: expected ‘)’ before numeric constant
 typedef struct ocsp_response_st OCSP_RESPONSE;
                                 ^
make[2]: *** [Makefile:897: iperf_api.lo] Error 1
make[2]: Leaving directory '/iperf-3.6/src'
make[1]: *** [Makefile:665: all] Error 2
make[1]: Leaving directory '/iperf-3.6/src'
make: *** [Makefile:386: all-recursive] Error 1

budman@i5-win /iperf-3.6
$

Ok I got it working.. Have not had chance to fully test all features but it compiled

 

In the header file ossl_typ.h I made the change

#ifndef HEADER_OPENSSL_TYPES_H
# define HEADER_OPENSSL_TYPES_H

#include <limits.h>

#ifdef  __cplusplus
extern "C" {
#endif

# include <openssl/e_os2.h>

# include <windows.h>

 

https://files.budman.pw/iperf3.6_64bit.zip

CRC32: A9B23E64
MD5: 3530BD3C837EA146C8F98106FA94E395
SHA-1: 7E09239B207739714294A4EA1DA9C69623374740
SHA-256: DE958C4CF72DBC64DCBB42130BD466D9FD367E4519C5C3F78A6675CA87E12B7D

 

budman@i5-win /usr/local/bin
$ cygcheck iperf3.exe
Found: C:\cygwin64\usr\local\bin\iperf3.exe
C:\cygwin64\usr\local\bin\iperf3.exe
  C:\cygwin64\bin\cygwin1.dll
    C:\WINDOWS\system32\KERNEL32.dll
      C:\WINDOWS\system32\ntdll.dll
      C:\WINDOWS\system32\KERNELBASE.dll

 

C:\test\iperf3.6_64bit>iperf3.exe -v
iperf 3.6 (cJSON 1.5.2)
CYGWIN_NT-10.0 i5-win 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64
Optional features available: CPU affinity setting

 

  • 11 months later...

Ok got 3.7 compiled - had to do the same edit to ossl_typ.h as above

 

budman@i5-win /usr/local/bin
$ cygcheck iperf3.exe
Found: C:\cygwin64\usr\local\bin\iperf3.exe
C:\cygwin64\usr\local\bin\iperf3.exe
  C:\cygwin64\bin\cygwin1.dll
    C:\WINDOWS\system32\KERNEL32.dll
      C:\WINDOWS\system32\ntdll.dll
      C:\WINDOWS\system32\KERNELBASE.dll

budman@i5-win /usr/local/bin
budman@I5-WIN E:\output\iperf3.7_64
$ iperf3.exe -v
iperf 3.7 (cJSON 1.5.2)
CYGWIN_NT-10.0-18362 i5-win 3.0.7-338.x86_64 2019-04-30 18:08 UTC x86_64
Optional features available: CPU affinity setting

The --bidir option is working

budman@I5-WIN E:\output\iperf3.7_64
$ iperf3.exe -c 192.168.9.9 --bidir
warning: Ignoring nonsense TCP MSS -2146716416
Connecting to host 192.168.9.9, port 5201
[  5] local 192.168.9.100 port 53200 connected to 192.168.9.9 port 5201
[  7] local 192.168.9.100 port 53201 connected to 192.168.9.9 port 5201
[ ID][Role] Interval           Transfer     Bitrate
[  5][TX-C]   0.00-1.00   sec  56.6 MBytes   475 Mbits/sec
[  7][RX-C]   0.00-1.00   sec  99.3 MBytes   832 Mbits/sec
[  5][TX-C]   1.00-2.00   sec  42.0 MBytes   352 Mbits/sec
[  7][RX-C]   1.00-2.00   sec   112 MBytes   943 Mbits/sec
[  5][TX-C]   2.00-3.00   sec  52.2 MBytes   438 Mbits/sec
[  7][RX-C]   2.00-3.00   sec   112 MBytes   942 Mbits/sec
[  5][TX-C]   3.00-4.00   sec  56.2 MBytes   472 Mbits/sec
[  7][RX-C]   3.00-4.00   sec   112 MBytes   943 Mbits/sec
[  5][TX-C]   4.00-5.00   sec  58.8 MBytes   493 Mbits/sec
[  7][RX-C]   4.00-5.00   sec   112 MBytes   942 Mbits/sec
[  5][TX-C]   5.00-6.00   sec  24.2 MBytes   203 Mbits/sec
[  7][RX-C]   5.00-6.00   sec   112 MBytes   943 Mbits/sec
[  5][TX-C]   6.00-7.00   sec  53.0 MBytes   445 Mbits/sec
[  7][RX-C]   6.00-7.00   sec   112 MBytes   939 Mbits/sec
[  5][TX-C]   7.00-8.00   sec  69.0 MBytes   579 Mbits/sec
[  7][RX-C]   7.00-8.00   sec   112 MBytes   942 Mbits/sec
[  5][TX-C]   8.00-9.00   sec  26.1 MBytes   219 Mbits/sec
[  7][RX-C]   8.00-9.00   sec   112 MBytes   943 Mbits/sec
[  5][TX-C]   9.00-10.00  sec  62.2 MBytes   522 Mbits/sec
[  7][RX-C]   9.00-10.00  sec   112 MBytes   939 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID][Role] Interval           Transfer     Bitrate
[  5][TX-C]   0.00-10.00  sec   500 MBytes   420 Mbits/sec                  sender
[  5][TX-C]   0.00-10.00  sec   500 MBytes   420 Mbits/sec                  receiver
[  7][RX-C]   0.00-10.00  sec  1.09 GBytes   934 Mbits/sec                  sender
[  7][RX-C]   0.00-10.00  sec  1.08 GBytes   931 Mbits/sec                  receiver

iperf Done.

budman@I5-WIN E:\output\iperf3.7_64

 

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

 

CRC32: 13EB9AD9
MD5: 96C2C058B0128BEC346BD0D034D7B31E
SHA-1: 83978F54B7EDDA073CC4E865493AA6544862879A
SHA-256: 93FB4641810C06DE554E97FD4E6B44CEFBD8ECB8EA8CFEA3CC550B823C3E89CE

 

 

  • Like 2
  • 2 weeks later...

Thanks - stick around its good place!  So you were trying to compile it yourself and ran into that issue? And found this thread? Trying to recall where I found the fix myself, I am not any sort of guru at compiling stuff... But I get the basics and can follow instructions ;)

  • 3 months later...

@spanjokus Glad you found it and people are making use of it..  When next version comes out, will be posting here as well.  If you notice next release is out before I do - just mention my name here, and I will notice it for sure and post it up.

  • 4 months later...

there is upgraded version of Cygwin1.dll:

https://github.com/esnet/iperf/issues/960

and i quote: " There was a bug in the cygwin1.dll that limited the receive buffer size for TCP sends. This caps the throughput on all tools that use cygwin including iperf."

 

 maybe it's worth making an upgrade for your compilation?

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Posts

    • The sweet release of death has never looked more appealing.
    • Meh, just another dongle-haven downgrade compared to my Surface Pro 7+. Whenever I decide to upgrade in the next decade or so, it certainly won't be another microslop Surface with this enshitification trend they've been having after the Surface Pro 7+. Hopefully a future generation of the Framework 12 will be a real upgrade...
    • This could exactly be how our Sun ends but it's not as simple by Sayan Sen Image by Drew Rae via Pexels An international team led by Université de Montréal (University of Montreal) PhD student Érika Le Bourdais has found that the ancient white dwarf star LSPM J0207+3331 is still pulling in planetary debris, even though it has been cooling for about three billion years. White dwarfs are dense, Earth-sized stellar remnants left behind when Sun-like stars exhaust their nuclear fuel and shed their outer layers. The star, located 145 light-years away in the constellation Triangulum, is the oldest and coldest white dwarf known to have a surrounding disk of dust. The star was first spotted in 2019 by a citizen scientist through the Backyard Worlds: Planet 9 project. Its cool temperature immediately suggested that it was very old, since white dwarfs gradually lose heat over time. Using the W. M. Keck telescopes in Hawaii, astronomers later confirmed that the star shows infrared signals consistent with dust rings formed by asteroids breaking apart under its strong gravity. Such infrared excesses occur when a star emits more infrared light than expected, often because warm dust surrounding it absorbs and re-radiates energy. “This discovery challenges our understanding of planetary system evolution,” said Le Bourdais. “The fact that we still see planetary debris being accreted three billion years after the star became a white dwarf suggests that asteroids, comets, and even planets can remain in orbit around these stars for a very long time.” Spectroscopic analysis—a technique that studies light to identify the chemical elements present in an object—revealed thirteen heavy elements in the star’s atmosphere: sodium, magnesium, aluminium, silicon, calcium, titanium, chromium, manganese, iron, cobalt, nickel, copper, and strontium. Normally, heavy elements sink quickly in hydrogen-rich white dwarfs, making them hard to detect. “We expected to see only a few elements, but we found dozens!” explained Le Bourdais. The research paper adds more detail. The absence of carbon features suggests the debris came from a carbon-volatile-depleted source. The abundance pattern shows slight deficits of magnesium and silicon compared to iron but otherwise resembles Earth-like material. This points to a differentiated rocky body—one whose materials have separated into distinct layers such as a metallic core and rocky mantle—with a metallic core fraction higher than Earth’s. In other words, the star is accreting the remains of a large rocky object, similar in structure to Earth or the asteroid Vesta. “White dwarfs offer one of the only ways we can directly measure the composition of exoplanets,” said Patrick Dufour, co-author and professor at Université de Montréal. “When planetary debris come too close, they are torn apart by the star’s gravity and end up polluting its atmosphere, leaving a detailed chemical fingerprint of its composition.” The team also detected weak Ca II H & K line core emission, making this only the second known isolated polluted white dwarf to show this feature. These are specific spectral signatures produced by ionised calcium and can indicate unusual physical activity in a star’s upper atmosphere. The finding suggests that extra physical processes may be happening in or above the star’s upper atmosphere. The study stresses the importance of including heavy elements in model atmosphere calculations, since leaving them out can distort the inferred structure and lead to inaccurate stellar parameters. Earlier work suggested the star’s infrared excess came from two dust rings. The new analysis shows that a single silicate dust disk—a ring composed largely of rock-forming minerals rich in silicon and oxygen—can explain the observed signal at 11.6 μm, simplifying the picture of the system’s structure. The question of how debris ended up falling into the star so late remains open. One idea is that giant planets in the system slowly destabilised smaller bodies over billions of years. Another possibility is that a passing star disturbed the orbits of debris. “Future observations with the James Webb Space Telescope or archival data found in the European Space Agency’s Gaia mission could help distinguish between a planetary rearrangement and the gravitational effect of a close stellar encounter,” said John Debes, co-author and researcher at the Space Telescope Science Institute. Dufour noted that hydrogen-rich white dwarfs are the most common type, and the coolest among them are the oldest stars in the galaxy. “We didn't have the habit of looking for signs of accretion in them. This unique case motivates us to expand our search to more of these stars.” The findings show that even after billions of years, planetary systems can remain active and complex. Substantial accretion events—the gradual accumulation of surrounding material onto a celestial object—can still occur long after a star’s death, offering a rare window into the composition and fate of distant worlds. Source: University of Montreal, IOPScience This article was generated with some help from AI and reviewed by an editor. Under Section 107 of the Copyright Act 1976, this material is used for the purpose of news reporting. Fair use is a use permitted by copyright statute that might otherwise be infringing.
    • Doesn't DDG mainly use Bing?
  • Recent Achievements

    • One Year In
      MadMung0 earned a badge
      One Year In
    • Week One Done
      jefred earned a badge
      Week One Done
    • Apprentice
      JoeyNeo went up a rank
      Apprentice
    • Week One Done
      oliviaexpo earned a badge
      Week One Done
    • Week One Done
      eurospharma62 earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      480
    2. 2
      PsYcHoKiLLa
      228
    3. 3
      Skyfrog
      67
    4. 4
      FloatingFatMan
      56
    5. 5
      monterxz
      55
  • Tell a friend

    Love Neowin? Tell a friend!