|
Revision tags: 3.11, 3.10.1, 3.10 |
|
| #
21581a72 |
| 22-Dec-2020 |
Bruce A. Mah <[email protected]> |
enh: Support SO_BINDTODEVICE (#1097)
This lets iperf work better with multi-homed machines and
VRF.
Fixes #1089.
Based on a patch by Ben Greear <[email protected]> via PR #817.
Co-au
enh: Support SO_BINDTODEVICE (#1097)
This lets iperf work better with multi-homed machines and
VRF.
Fixes #1089.
Based on a patch by Ben Greear <[email protected]> via PR #817.
Co-authored-by: Ben Greear <[email protected]>
show more ...
|
|
Revision tags: 3.9, 3.8.1, 3.8 |
|
| #
06e3f08d |
| 20-May-2020 |
Bruce A. Mah <[email protected]> |
fix(auth): Fix a potential buffer overflow in iperf3 client. This condition was only possible when configuration authentication via the libiperf API.
While here, also fix a few other sundry issues:
fix(auth): Fix a potential buffer overflow in iperf3 client. This condition was only possible when configuration authentication via the libiperf API.
While here, also fix a few other sundry issues:
* Remove arbitrary length limits on username and password.
* Improved error handling.
* Updated error messages for readability.
* Fixed minor typo in some identifiers.
Fixes #996.
show more ...
|
|
Revision tags: 3.7 |
|
| #
0778f04c |
| 13-Dec-2018 |
Boris Okunev <[email protected]> |
Bidirect mode implementation (#780)
Adds the `--bidir` flag to support simultaneous two-way tests.
Submitted by @LikHait. Fixes #201.
|
| #
d71efe5f |
| 22-Aug-2018 |
Bruce A. Mah <[email protected]> |
Fix a segmentation fault in verbose mode. (#784)
To reproduce, run the server as "iperf3 --server --verbose" and
run a client as "iperf3 --client localhost -reverse --parallel 2".
Fixes #778.
B
Fix a segmentation fault in verbose mode. (#784)
To reproduce, run the server as "iperf3 --server --verbose" and
run a client as "iperf3 --client localhost -reverse --parallel 2".
Fixes #778.
Based on https://github.com/Aquantia/iperf/commit/f1778271d2c6bed1dae09dccd33251
1b263f6871
show more ...
|
|
Revision tags: 3.6, 3.5, 3.4 |
|
| #
47450ad9 |
| 26-Jan-2018 |
Bruce A. Mah <[email protected]> |
Fix a server-side crash with --verbose and a client with multiple connections. (#696)
This was caused by a stale / invalid pointer reference that didn't even
make any sense in context anyway. Fixe
Fix a server-side crash with --verbose and a client with multiple connections. (#696)
This was caused by a stale / invalid pointer reference that didn't even
make any sense in context anyway. Fixes #686.
show more ...
|
|
Revision tags: 3.3, 3.2, 3.2rc1 |
|
| #
10e2cc24 |
| 03-May-2017 |
Bruce A. Mah <[email protected]> |
Fix various problems with summary statistics (#562)
* Untangle some problems with printing summary statistics.
There were (at least) two problems:
o The server cannot print summary statistics
Fix various problems with summary statistics (#562)
* Untangle some problems with printing summary statistics.
There were (at least) two problems:
o The server cannot print summary statistics as seen from the
client, because the server has to generate its summaries
before receiving any statistics from the client. This
shortcoming is somewhat hard-coded into the semantics of
messages on the control channel, and probably can't be easily
changed.
o UDP summary statistics for each stream were ambiguous in that
it wasn't clear whether they were intended to apply to the
sender or receiver.
To fix this, we split UDP summary statistics into two lines,
one for the sender side and one for the receiver side. This
hopefully eliminates any ambiguity about the statistics. On the
server, we don't attempt to print the (not very meaningful and
potentially misleading) statistics corresponding to the client.
Possible fix for #560.
* Try to report more accurate ending statistics.
Basically the client side was using only its measured test duration
to compute figures such as bitrate, but the server's test duration
could be different due to network delays/jitter. So we make sure
that the test durations (for each stream) are passed in the test
results and used appropriately when we print statistics for the
sender and receiver.
Towards #560, also this could help towards #238.
* Silence a warning over an uninitialized variable.
show more ...
|
| #
3021aef8 |
| 01-May-2017 |
Bruce A. Mah <[email protected]> |
Untangle some problems with printing summary statistics.
There were (at least) two problems:
o The server cannot print summary statistics as seen from the client, because the server has to generate
Untangle some problems with printing summary statistics.
There were (at least) two problems:
o The server cannot print summary statistics as seen from the client, because the server has to generate its summaries before receiving any statistics from the client. This shortcoming is somewhat hard-coded into the semantics of messages on the control channel, and probably can't be easily changed.
o UDP summary statistics for each stream were ambiguous in that it wasn't clear whether they were intended to apply to the sender or receiver.
To fix this, we split UDP summary statistics into two lines, one for the sender side and one for the receiver side. This hopefully eliminates any ambiguity about the statistics. On the server, we don't attempt to print the (not very meaningful and potentially misleading) statistics corresponding to the client.
Possible fix for #560.
show more ...
|
| #
a51045de |
| 20-Apr-2017 |
ralcini <[email protected]> |
Service Authentication (#517)
Add an optional mode that requires clients to authenticate with the server.
In this mode, clients need to provide a username and a password, which are checked agains
Service Authentication (#517)
Add an optional mode that requires clients to authenticate with the server.
In this mode, clients need to provide a username and a password, which are checked against a password file on the server. The authentication credentials are protected by an RSA public keypair...the encrypted credentials are sent along with the test parameters.
Operationally the use of this feature places the following additional requirements on the build and installation of iperf3:
o The presence of the OpenSSL headers and libraries to build iperf3, and the libraries available on the client and server at runtime.
o Generation of an RSA public keypair; the private part is used by the server and the public part must be distributed to the clients.
o Username/password pairs for all authorized users, to be stored in a file on the server.
o Loose time synchronization between the server and clients (to within approximately 30 seconds).
o Appropriate command-line flags given on the client and server.
Note that iperf3 can be built and run as before, without fulfilling any of these requirements.
Partial documentation for this feature is included in this commit. It is anticipated that additional documentation text and editing will follow this merge.
Submitted by @ralcini. First suggested by @codyhanson in pull request #242.
show more ...
|
|
Revision tags: 3.1.7, 3.1.6, 3.1.5, 3.1.4, 3.0.12, 3.1.3, 3.1.2, 3.1.1, 3.1, 3.1b3, 3.1b2, 3.1b1, 3.0.11, 3.0.10, 3.0.9, 3.0.8 |
|
| #
da9f046f |
| 29-Sep-2014 |
Bruce A. Mah <[email protected]> |
Update license and copyright text to conform to LBNL standards.
Note that the license remains a 3-clause BSD license; the only license changes were to add the name of the program and to add some pun
Update license and copyright text to conform to LBNL standards.
Note that the license remains a 3-clause BSD license; the only license changes were to add the name of the program and to add some punctuation.
show more ...
|
| #
a1861d5f |
| 15-Sep-2014 |
Bruce A. Mah <[email protected]> |
Rename locale.{c,h} to iperf_locale.{c,h} to avoid filename collision with system header <locale.h>.
This apparently fixes problems on an ARM build, but this was generally broken anyway. It's sligh
Rename locale.{c,h} to iperf_locale.{c,h} to avoid filename collision with system header <locale.h>.
This apparently fixes problems on an ARM build, but this was generally broken anyway. It's slightly amazing this didn't cause problems before; perhaps we never used <locale.h> before?
Addresses #203.
show more ...
|