This question has come up a few times, so even though iperf3
doesn't officially support any Windows platform, I'm putting
this in here. Thanks to @ijspzpt for the references.
Addresses #590 and possibly #546.
This addresses a problem where the --tos parameter would incorrectly
"stick" on the server, causing wrong TOS values to be inserted into
packets during --reverse tests. Fixes#639.
Avoid walking off the end of an array when trying to format a number larger than 1000T.
Motivated by #641, as reported by @shingchuang, but slightly
reimplemented.
Two fixes for a warning for possibly-too-large UDP packets.
1. Make sure we have a valid TCP MSS on the path when comparing
the UDP block size.
2. Fix a redundant "warning".
This should fix a bug observed on Windows but not (so far) on any
UNIX-like platforms. Fixes#604.
1. Make sure we have a valid TCP MSS on the path when comparing
the UDP block size.
2. Fix a redundant "warning".
This should fix a bug observed on Windows but not (so far) on any
UNIX-like platforms. Fixes#608.
Don't make OpenSSL detection error out unless --with-openssl explicitly given.
This fixes the out-of-the-box build on macOS, which doesn't include
headers, etc. for OpenSSL by default. The configure script still
errors out if the user specifies a --with-openssl flag but for some
reason the build host's OpenSSL is broken or can't be used.
* Regen.
* fix: now --without-openssl configure flags works
enh: if openssl support is required and no valid installation is found, now it raise an error
* enh: added warning if building without openssl (iperf_auth disabled)
This is mostly a cosmetic fix...due to timing differences or
interference from data packets, it is possible that the server
will have a very small last measurement window, possibly with
no data transferred. This looks odd (although it's not incorrect)
and we'd like to eliminate these. If there's an interval
(presumably it'd be the last measurement interval) less than
10% of the length of a standard measurement/reporting interval,
and there are no bytes transferred in the interval, then suppress
printing the results and don't add them to the grand total.
* Towards issue #457. Try to not count the sequence number
gaps resulting from out-of-order packets as actual losses.
* Put all of the UDP diagnostic output behind the --debug flag.
Attempt to fix some brokenness in -F from #301.
In some work related to #125, we introduced a bug in which
chunks of a file being read for the -F option were not
completely sent, particularly with TCP sockets. We attempt
to fix this by detecting cases in which not all data passed
to a socket could be actually sent (for example due to full
socket buffers) and preserving that data for future send
iterations.
The ending statistics in the "diskfile" JSON structure were
wrong, and did not properly distinguish between sender-side
and receiver-side statistics. This has been fixed (at least
for the client side).
Specifically mention in the manpage that "iperf -F" is not
a file transfer tool.
Improve the compatibility of iperf_api.h with C++ so that libiperf can more easily be used with C++ programs.
This involves function declarations as extern "C" and inclusion of a couple of more headers (which arguably improves the C use case).
* s/bandwidth/bitrate/ in user-facing places. Towards #583.
iperf3 has long misused terminology; bandwidth is a measure of
capacity. iperf3 measures bitrate or throughput. We standardize
on "bitrate" because it begins with the same letter as "bandwidth"
(to match the -b command-line option).
User-facing output mentioning "bandwidth" now uses "bitrate".
The long command-line option for -b (--bandwidth) is now --bitrate
(--bandwidth is transparently accepted for backward compatibility).
A few places in documentation that talk about bandwidth as a
measured value have been reworded to use bitrate or throughput.
There are a number of places in code where variables are still
called "bandwidth". We leave these alone for now.
A mention of "bandwidth" in the test parameters JSON also needs
to remain unchanged to avoid breaking compatibility. However,
the test results JSON never used the term "bandwidth" in
the first place.
* s/bandwidth/throughput in one place in RPM description. Towards #583.
