We check at configure-time to see if IPV6_FLOWLABEL_MGR is defined
in <linux/in.6>, if it is we set a HAVE_FLOWLABEL CPP symbol to
turn on conditional compilation of the support for this feature.
Rather than checking for anything Linux-specific at configure-time,
see if TCP_CONGESTION is defined in <netinet/tcp.h> and if so define
a CPP variable HAVE_TCP_CONGESTION, which we then use to enable
conditional compilation of the code for this feature.
These macros were never used anywhere in iperf3 anyways, and
conflicted with macro definitions that were in FreeBSD's system
headers.
Bump copyright date and add a comment to inclusion guard while here.
Rather than doing checks for platforms that we believe support SCTP,
instead look for an indication (notably the presence of <netinet/sctp.h>)
that it's supported. This makes the conditionals for SCTP more obvious.
In addition, it opens up the possibility that SCTP might work on some
new OS that's not FreeBSD or Linux.
This change may force some additional build-time requirements on Linux,
such as lksctp-tools-devel on CentOS / Fedora or libsctp-dev on
Ubuntu.
Committing this first cut for review and to enable testing on multiple
platforms. So far this works correctly on Linux (SCTP support) and
MacOS (no SCTP support).
Squashed commit of the following:
commit 23ef0d047fb5396df671be9245f7872153fc299c
Author: Bruce A. Mah <bmah@es.net>
Date: Mon Apr 7 13:35:29 2014 -0700
Add a few API calls to the client-side example program so we can
exercise recently-added JSON-related functionality.
commit 5f8301e8d0380133d533da9b2e39ca4ac522e1c3
Author: Bruce A. Mah <bmah@es.net>
Date: Mon Apr 7 13:16:39 2014 -0700
Revert part of earlier change.
We still want to save the JSON for libiperf consumers that might want it,
but preserve the prior behavior of writing that JSON to stdout. This
maintains (roughly) the behavior of older libiperf, in which libiperf
consumers (such as the iperf3 executable) do not need to explicitly print
the JSON if that's all they're doing with it.
commit 173dcdb05867af00103205bfe39d1b71e18689e9
Author: Bruce A. Mah <bmah@es.net>
Date: Tue Mar 25 13:55:45 2014 -0700
Update manpage for newly-added library calls.
Bump document date while here.
Part of Issue #147.
commit 51a275de9463febc440d41cee9d971fcd381e01c
Author: Bruce A. Mah <bmah@es.net>
Date: Tue Mar 25 13:30:09 2014 -0700
Allow consumers of libiperf3 to get the JSON output for a just-completed test.
This changes the behavior of iperf_json_finish() so that it no longer
outputs JSON output, but saves the rendered output in a NUL-terminated
string buffer. After calling iperf_run_server() or iperf_run_client(),
the client application should check iperf_get_test_json_output() to see
if it returns a non-NULL pointer. If so, there is JSON data available
for it to print or otherwise consume. The buffer is automatically
deallocated when the containing iperf_test structure is deallocated
with iperf_free_test().
Also adds a new API call iperf_get_test_outfile() to find the output
FILE* structure.
Modifies the iperf3 application to use the new API. Users of iperf3
will not notice any functional change.
No effect in "normal" output mode (non-JSON).
iperf_parse_arguments(). Basically we need to initialize the
output stream in the iperf_test structure regardless of whether
iperf_parse_arguments() gets called; some programs (in particular
the programs in the examples/ directory and bwctl) don't do this
(and indeed should not need to).
This problem was introduced in the solution for Issue #119; the fix
needs to be merged to any codeline where fixes for Issue #119 go.
This works for both client and server side (in the case of the server,
either for daemon or non-daemon mode).
Consistifies a few places that were using printf instead of iprintf.
Fixes Issue 119.
Use --disable-static or --disable-shared to build only one flavor
of libraries.
Tested on MacOS, FreeBSD, and CentOS 6 Linux.
Resolves#146.
Originally submitted by: @i2aaron
This can happen if the user forces a particular output format that leads
to many digits (6 or more) being printed. The new buffer size is probably
larger than it needs to be, but better safe than sorry.
Fixes Issue 142.
This makes SCTP with default parameters work on CentOS 6; formerly
it was just using the TCP default (128KB) and failing with
a "message too long" error. It might be possible to fix this with
some manipulation of other default values, so that TCP and SCTP
can use the same default message size, but I haven't figure out
what this would be.
This ties up one loose end from Issue 131.
Note this option only has a long option flag; we're running out of
letters for short options.
Based heavily on a patch submitted in Issue 131 (SCTP support for
iperf); I added support for FreeBSD and did some other packaging and
documentation improvements.
We probably shouldn't tie SCTP support to looking specifically for
Linux or FreeBSD; we probably leave support enabled all the time if
possible, possibly with some configure-time checks.
We were computing and printing this in JSON output mode anyway; this
change just exposes this quantity in a human-friendly manner (better
than the first attempt at this) when doing normal output.
Resolves Issue 99 (Additional TCP_INFO items).
The bug and solution are very similar to Issue 126 (fixed in
d7e0c1445c0a). Basically a setsockopt(IPV6_V6ONLY) call had a bogus
level argument, but we never checked the return value so we never
noticed this.
As with the prior issue, the fix is to unbreak the setsockopt() call,
and add some error checking to detect future breakage.
This bug was on a codepath that only got called if non-default values
were set for the socket buffer size, the MSS, or the NODELAY parameter.
It might have affected some FreeBSD tests, but really only got noticed
when debugging some other code that was (probably) cut-and-pasted
from this code.
mapped_v4_to_regular_v4() committed the sin of doing strcpy(3) on
overlapping buffers. This caused an abort on MacOS X 10.9. Fix this
to use memcpy(3) instead, which handles overlapping buffers correctly.
Issue: 135 (Crash on OS X when using IP address)
Apparently older kernels don't support TCP_CONGESTION, so we can't
just test for defined(linux) to know if we can use this sockopt or not.
This change unbreaks the build on (notably) CentOS 5.
Mostly this change consists of adding FreeBSD-specific code to handle
this feature. The concepts and system calls are very similar to what's
already done for Linux. One difference is that on FreeBSD, the CPU
affinity mask is saved before -A processing and restored afterwards.
This causes a slight change to the function signatures for
iperf_setaffinity() and iperf_clearaffinity() (these functions
however are not documented as a part of the libiperf3 API).
Slightly improve some of the documentation for the -A command line
option, to hopefully stave off some of the questions about this
feature.
Mostly based on a submitted patch.
Issue: 128 (better error message for CPU affinity failure)
Submitted by: Susant Sahani <ssahani@redhat.com>
When the client process gets interrupted, both the client and server
dump out accumulated interval statistics, as well as a partial set of
summary statistics (basically each side dumps what it has, but without
the exchange of information that usually happens at the end of a
normal run).
If the server process gets interrupted, the server dumps out its
accumulated interval and summary statistics as above. The client does
this as well in the -R case, but exits with a "Broken pipe" in the non
-R case (this behavior was present all along; it was not introduced in
this change). More investigation will be needed to understand the
client behavior.
Bump copyright dates in a few places.
Issue: 132 (signal handler for API calls)
Discussed with: aaron@internet2.edu
In -R mode, the test consists of the server sending to the client
until the client tells it to stop by setting the test state to
TEST_END via the control socket. However once the client changes the
test state, it stopped reading the incoming test data from the server.
In many (but not all) scenarios this could result in the server
filling up its send window (thus blocking on writes) before the
TEST_END message arrived from the client. At this point the server
was hanging waiting for the client to drain its data connection(s),
and the client was waiting for the server to send a state change
message for EXCHANGE_RESULTS.
Bump copyright date while here.
This fix handles at least part of...
Issue: 129 (iperf3 hangs with -R and -Z flags)
Also remove a couple of places where we were saving and restoring errno
where we didn't need to.
Submitted by: Susant Sahani <ssahani@redhat.com>
Issue: 121 (TCP congestion control algorithm support for client)
(It remains in the JSON output.)
We have some issues we need to resolve about the formatting and
representation of this (and other future values that we might be
adding).
Rip out the tcpi_sacked support...it doesn't really keep a cumulative
total of SACKs received like we thought it did (it's instantaneous
state).
Convert tcpi_snd_cwnd (originally expressed in segments) to octets before
printing.
Re-work internal APIs for functions to get stuff out of tcp_info...rather
than doing a getsockopt() call per value, grab the values out of a
saved copy of the tcp_info structure (which we were getting in almost
every case anyway).
Issue: 99 (Additional TCP_INFO items)
(Formerly it was just accepting IPv6.)
The problem here was that FreeBSD by default wasn't allowing IPv4
mapped addresses on IPv6 sockets, whereas other platforms
(specifically Linux and OS X) both do permit this. We tried to turn
on mapped addresses via a setsockopt(IPV6_V6ONLY) call, but this call
was broken because the level argument was incorrect. We didn't know
about this because we never checked the return value.
Fix this by providing the correct argument to setsockopt(). Add some
error checking to this and one other setsockopt() call, so we at least
don't fail silently in similar situations.
Issue: 126 (FreeBSD: iperf3 -s only accepts IPv6
connections)
This functionality uses some setsockopt(2) calls that unfortunately
don't seem to have an analog on other platforms.
Slightly tweaked version of a patch that was...
Submitted by: ssahani@redhat.com
Issue: 40 (Option for setting Flow Label field in IPv6
header)
This lets us check timers every tenth second instead of every second,
so we can switch out of the more expensive select() mode even with
the default reporting interval of a second.
Possible related work still under consideration:
o Use syslog in daemon mode for output that would normally go to
stdout / stderr.
o Write a PID file.
This is basically the gist of Issue 105.
Also bumped package id from 3.0a4 to 3.0a5.
This changeset consists of a one-line edit to configure.ac, plus
about fifty kilolines of diffs to a bunch of other config files
generated by bootstrap.sh.
having it there may cause the select to return immediately every
time. Which is bad, m'kay?
Also, changed the coding idiom used to keep track of the maximum fd
in the fd sets, to be clearer.
The error numbers sent for SERVER_ERROR state were declared
as ints, and therefore could be 32 or 64 bits depending on
architecture. I changed them to be explicitly 32 bits.
This should be the last of these, I've checked out at every network
read/write call and they look ok.
And bumped the version to 3.0-RC5.
A couple more sizeof issues found and fixed. One of them is
actually another protocol change, but due to a fortuitous accident
it should remain compatible with older versions.
Detailed explanation: When a client attempts to connect to a server that
is already busy, the server is supposed to return ACCESS_DENIED as a
state value. It was doing so, but was writing it as an int, even though
state values are supposed to be signed chars. The client read the value
correctly as a signed char, getting one byte and throwing away the rest.
So why did this ever work? Because ACCESS_DENIED is the value -1, and
any byte of an int -1 equals a signed char -1. If ACCESS_DENIED had been
any other value, this would have been an opvious bug and would have long
since been fixed. As is, it stuck around working by accident until now.
test->state is an explicitly signed char, so the two routines that
manipulate it must use explicitly signed chars too.
One could argue that the two negative state values should have been
positive like the rest, but changing them now would be a protocol change.
On further reflection, last night's seemingly trivial change to
the JSON sending/receiving routines is actually a protocol change,
on some machines, and therefore merits a version number change.
and iperf_run_server, so that API users get it too. Also, call
iperf_errexit with an appropriate message, which in -J mode dumps
out any accumulated JSON data.
The user-visible parts are commented out or return a "not implemented
yet" error message. The other parts are harmless.
We'll come back to this once we figure out how exactly one sets
the Flow Label.