Ignore nonsensical TCP MSS when trying to compute the default UDP packet size. This fix seems to be primarily needed for Windows systems, but it's a good bit of sanity checking to do in any case.
This fixes a problem described in issue #623 where the PID file
opened by a running instance of iperf3 could be overwritten /
deleted by a subsequent invocation of iperf3.
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.
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.
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.
* Add configurable timeout for the setup of the control connection.
This is specified using the new --connect-timeout option, with an
integer parameter in ms. The iperf3 client will wait for this
amount of time for the setup of the control connection to the
server. If this option is not given, the OS default for TCP
connection setup is used. Specifying a smaller connection timeout
allows faster detection of a down / unresponsive iperf3 server.
The implementation uses a variation on the timeout_connect()
function from OpenBSD's netcat utility.
Fixes#216.
For the case of multiple TCP streams, compute the grand total
summaries using the appropriate times for the sender and receiver
ends.
Add some divide-by-zero checks.
On the server side, only print the side of the grand total lines
where we have data. (This follows the behavior of the other
end-of-test output lines.)
Fix a minor (compared to all the other problems) bug with
UDP output printing the wrong ending timestamp.
Recent code changes require the server to send the start and end
timestamps for a test, so that the client can accurately compute
statistics for the sender side of a test. iperf 3.1 and 3.0
servers won't do this, so if this information isn't passed back
in the results at the end of a test, we fall back to using the
client's timestamps. The results might not match what's displayed
on the server, but this is basically what iperf 3.1 and earlier
did anyway.
Fixes#574.
Keep track of UDP packets sent/received and use appropriately.
We were using the number of UDP packets seen on the server
(regardless of whether it was the sender or receiver) for
computing loss percentages, etc. This caused confusion in the
case that the last UDP packet doesn't make it to the server
before the test finishes (or if a packet gets lost), because
the client and server had different ideas of how many packets were
sent (OK) and we used the wrong number when computing statistics.
This fix changes the human-readable output to make more sense.
It doesn't change the JSON output. That needs some more review.
I'm reluctant to make structural changes to the JSON output,
because other programs rely on that format.
We also need to investigate whether the last UDP packet can be
still in flight when the test ends (per hypothesis), and if so
what we should do about this.
We apply similar fixes for human-readable summaries for multi-stream UDP tests.
The fixes are similar to those already done for the stream
summary statistics, but these cover a type of output that's only
done if there is more than one stream.
Adjust the JSON computations / output to do a better job of figuring
out the total number of packets sent.
We really need to disentangle the computation and output formatting,
these two operations shouldn't be mixed together like this.
Fixes#252.
We now reject all invalid format characters given as the
argument to the -f/--format flag. All valid characters are now
documented in the usage message and manual page.
Towards #566.
Commit 5ab2132c (PR #551) fixed, among other things, a memory
leak. The solution, however, causes a hazard where a free() of
an invalid pointer can corrupt the heap. We've observed this
fairly repeatably while running the test_commands.sh script on
CentOS 7.
To remedy this, we NULL out a pointer after the object it
pointed to has been free-d, just like a number of other similar
objects.
* Add --pacing-timer option to allow tuning of -b timers.
These control the granularity of the timer and hence burstiness
of iperf3's sends. The default is 1ms (1000), which is the default
starting with iperf 3.2. Follow-on to the commit in #460.
* Update manpage and release notes for --pacing-timer.
These values show up in the start structure as sock_bufsize (requested
size), sndbuf_actual (actual SO_SNDBUF value) and rcvbuf_actual (actual
SO_RCVBUF value). These values are available for both TCP and UDP.
Both client and server emit these values in their JSON output for their
respective sides, but don't exchange them.
Towards #558.
* 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.
On FreeBSD, unlike Linux (and NetBSD?) snd_cwnd is expressed in
octets instead of segments. Hilarity ensued when we erroneously
multiplied by snd_mss and integer overflows occureed.
Possible fix for #465, #475, #338. Testing from FreeBSD users
appreciated.
* fix Wstrict-prototypes warnings found by clang
also fix usage_long() call
Signed-off-by: Gabriel Ganne <gabriel.ganne@enea.com>
* fix Wunreachable-code-break warnings found by clang
Signed-off-by: Gabriel Ganne <gabriel.ganne@enea.com>
* fix Wshadow warnings found by clang
Signed-off-by: Gabriel Ganne <gabriel.ganne@enea.com>
* fix Wmissing-noreturn warning found by clang
Signed-off-by: Gabriel Ganne <gabriel.ganne@enea.com>
* ix memory leak found by clang
Signed-off-by: Gabriel Ganne <gabriel.ganne@enea.com>
* fix Wmisleading-indentation warnings raised by gcc-6
Signed-off-by: Gabriel Ganne <gabriel.ganne@enea.com>
* fix warning: Value stored to 'ptr' during its initialization is never read found by clang
Signed-off-by: Gabriel Ganne <gabriel.ganne@enea.com>
* fix warning: The left operand of '>' is a garbage value found by clang
Signed-off-by: Gabriel Ganne <gabriel.ganne@enea.com>
* fix memory leak in global cleanup
Signed-off-by: Gabriel Ganne <gabriel.ganne@enea.com>
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.
Change the internal command-line option code for --dscp from the literal
'5' to a constant defined as OPT_DSCP.
Add manpage text for --dscp option.
Tweak help text for --dscp (while here, fix problem in --tos text).
Using a command line adding dscp (instead of tos) you can:
--dscp EF,CS1,etc.
--dscp 0x08
--dscp 63
These will provide the correct shifted left 2 tos value for these, and
for people that think in terms of dscp values, this is a goodness.
Having this option available lets an enduser clearly distinguish between
an old version of iperf with a non-working --tos facility, vs a
version where it works, with something saner that lets just specify
the dscp.
I did not come up with a good -? option for it, and used -5 internally.
algorithm isn't available on the server. This can happen
if the client and server machines have different sets of
congestion control algorithms loaded in kernel modules, etc.
If the requested algorithm isn't available on the server, then
print a warning on the server side, but otherwise continue to
run the test.
Towards #549.
This is an attempt to avoid server-side crashes/exits when the
client abruptly closes its control connection, as found in some
testing for #549.
Fixes#550.
* Include stdint.h in files where its types are used
Signed-off-by: Moritz Kick <f1rebird@users.noreply.github.com>
* Fix type of len parameter passed to getsockopt
getsockopt expects socklen_t instead of int as its fifth argument
Signed-off-by: Moritz Kick <f1rebird@users.noreply.github.com>
* Remove unnecassary includes of netinet/tcp.h
also cleanup the second include of stdint.h in main.c
This commit fixes#331 and is a replacement for #344.
Signed-off-by: Moritz Kick <f1rebird@users.noreply.github.com>
* Remove unused hstrerror(), bad nanosleep() message in configure.ac (#503)
* Remove dead code involving h_errno and hstrerror()
h_errno was formerly set as a side effect of a failed
gethostbyname(3) call, but this function has been
deprecated.
This fixes a problem observed on FreeBSD and macOS where the MTU on
the loopback interface is larger than the default socket buffer size.
We adjusted the socket buffer size upwards to match the UDP payload
size, but that's apparently not enough and we ended up dropping packets.
This is bad. Add a 1KB fudge factor, which seesm to avoid this problem.
Affects UDP tests only, not TCP or SCTP.
Part of #496.
(cherry picked from commit d76198944d210e8a575747d3ddbee41a886a10c9)
Signed-off-by: Bruce A. Mah <bmah@es.net>
* Dynamically determine an appropriate default UDP send size.
We use the TCP MSS for the control connection as the default UDP
sending length, if the --length parameter is not specified for a
UDP test. This computation replaces the former hard-coded 8K
default, which was way too large for non-jumbo-frame Ethernet
networks.
The concept for this solution was adapted from nuttcp. The
iperf3 implementation is pretty easy since we already were
getting the MSS for the control connection anyway (although we
needed to get it slightly earlier in the setup process to be
useful).
Towards issue #496.
While here, s/int/socklen_t/ in one place to fix a compile warning,
and bump a few copyright dates.
* Warn if doing a UDP test and the socket buffer isn't big enough.
This is surprisingly an issue on FreeBSD and macOS, where the MTU
over the loopback interface is actually larger than the default
UDP socket buffer size. In these cases, doing a UDP test over the
loopback interface (with the new UDP defaults) will fail unless a
smaller --length or a larger --window size is set explicitly.
Linux has larger UDP socket buffers by default (much larger than the
largest possible MTU), but even in the case that the socket buffers
are too small to hold an MTU-sized send, the kernel seems to do the
send correctly anyway.
Still working towards a good solution for issue #496.
* Further refinement on UDP buffer size settings.
If the default buffer size on a UDP test can't hold a packet,
then increase the buffer size to be large enough to hold one
packet payload. (If the buffer size was explicitly set, but too
small to hold a packet payload, then warn but don't change the
buffer size.)
Minor code refactoring to...factor out some common code into
a new iperf_udp_buffercheck() function.
Still working towards issue #496.
* First try to fix pacing issues. Code compiles, lightly run-tested.
Make --bandwidth only control application-level pacing, refecting
behavior of iperf 3.1.2 and earlier.
Add a new --fq-rate that controls only FQ-based per-socket pacing.
A given test can use application-level pacing, FQ pacing, both,
or neither.
Deprecate the --no-fq-socket-pacing option; specifying this generates
a warning and is equivalent to --fq-rate=0.
Towards issue #467 and related to issue #325.
* Move --fq-rate in the help text to be just below --b, tweak wording.
* Sigh. One more tweak on help text.
Some day I probably need to review and rewrite the whole thing.
Still working towards #467.
This reverts commit f1e62c8d48.
Right idea, but it turns out to be a pretty high-impact change.
Need to rethink this, maybe with a more intelligent implementation
that checks the interface (or path?) MTU.
with default parameters.
A UDP payload of 1452, plus an 8-byte UDP header, plus a 40-byte IPv6
header, results in a 1500 byte IP packet. The IPv4 header is smaller
at 20 bytes.
It was therefore possible to have multiple levels of pacing happening,
which resulted in very nicely smoothed traffic, but wasn't really
the original design.
Do pacing correctly in iperf_check_throttle() and remove a hack in
iperf_send() where we were explicitly checking for the type of
pacing, but didn't really need to.
It turns out that with UDP and only-FQ pacing, iperf3 sends and throws
packets on the floor as fast as it can. This isn't really desirable,
and probably not what was wanted in a test anyway, so if we're not
doing TCP tests, force the use of application-level pacing.
On Linux it's possible to set the socket buffer to one size but
(correctly it seems) get back some larger size up to 2x what you
asked for (see tcp(7)).
While here, make related debugging output more useful.
Fixes (again) #356.
First, realize that we've been setting the congestion control (CC)
algorithm unnecessarily; rather than doing it for all listening or
connecting sockets, do it just for those sockets that are being used
for TCP test streams.
Record the CC algorithm in use (this handles the case where a CC algorithm
hasn't been specified), and have the client and server exchange this
information.
Report the CC algorithms that were used (note that it's theoretically
possible for the two ends of the test to be using different algorithms,
if no algorithm was explicitly specified and the two end hosts have
different defaults, or if one side allows setting the CC algorithm and
the other doesn't).
Committing to a branch to make it easier to test this code on a
wider combination of systems.
When a test in in progress and the client completely disappears, both the control socket and the stream sockets are left around forever. Patch modified from another patch submitted by mkall to add closing of the data stream sockets.
malformed JSON string was passed on the control channel. This issue,
present in the cJSON library, was already fixed upstream, so was
addressed here in iperf3 by importing a newer version of cJSON (plus
local ESnet modifications).
Discovered and reported by Dave McDaniel, Cisco Talos.
Based on a patch by @dopheide-esnet, with input from @DaveGamble.
Cross-references: TALOS-CAN-0164, ESNET-SECADV-2016-0001,
CVE-2016-4303
commit 2dc03630a736be2ae9f64823aabb5776e7074c2a
Merge: 61e325c 0da552c
Author: Bruce A. Mah <bmah@es.net>
Date: Thu May 26 09:40:58 2016 -0700
Merge branch 'master' into issue-325
commit 61e325c5d0a4e7a9823221ce507db0f478fc98b5
Merge: 227992f ccbcee6
Author: Bruce A. Mah <bmah@es.net>
Date: Thu May 26 11:09:54 2016 -0400
Merge branch 'issue-325' of github.com:esnet/iperf into issue-325
Conflicts:
src/iperf3.1
commit 227992f366e7f4895b6762011576ba22a42a752e
Author: Bruce A. Mah <bmah@es.net>
Date: Thu May 26 11:07:01 2016 -0400
Don't set SO_MAX_PACING_RATE if the rate is 0. Also tweak some help text.
Towards #325, in response to feedback from @bltierney.
commit ccbcee6366d50ec632fc00eb11fde8a886f8febe
Author: Bruce A. Mah <bmah@es.net>
Date: Tue May 24 09:19:41 2016 -0700
Fix manpage formatting for consistency.
commit 90ac5a9ce09bd746ca5f943a8226ab864da3ebf8
Author: Bruce A. Mah <bmah@es.net>
Date: Tue May 24 12:14:16 2016 -0400
Add some documentation for fair-queueing per-socket pacing.
For #325.
commit 5571059870f7aefefb574816de70b6406848888f
Author: Bruce A. Mah <bmah@es.net>
Date: Tue May 24 11:55:44 2016 -0400
Change the fair-queueing socket pacing logic in response to feedback.
By default, on platforms where per-socket pacing is available, it
will be used. If not available, iperf3 will fall back to application-
level pacing.
The --no-fq-socket-pacing option can be used to forcibly disable
fair-queueing per-socket pacing. (The earlier --socket-pacing option
has been removed.)
Tested on CentOS 7, more testing on other platforms is required to
be sure it didn't break the old application-level pacing behavior.
For #325.
commit 3e3f506fe9f375a5771c9e3ddfe8677c1a7146e7
Merge: 50a379e 3b23112
Author: Bruce A. Mah <bmah@es.net>
Date: Tue May 24 09:54:39 2016 -0400
Merge branch 'master' into issue-325
commit 50a379eddfa89d1313d2aeeb62a6fbc82f00ea17
Author: Bruce A. Mah <bmah@es.net>
Date: Sat Apr 16 02:55:42 2016 -0400
Regen.
commit 200d3fe3917b3d298bdf52a0bde32c47cf2727b0
Author: Bruce A. Mah <bmah@es.net>
Date: Sat Apr 16 02:41:32 2016 -0400
Checkpoint for initial work on #325 to add socket pacing.
This works only on Linux and depends on the availability of
the SO_MAX_PACING_RATE socket option and the fq queue discipline.
Use --socket-pacing to use SO_MAX_PACING_RATE instead of the
default iperf3 user-level rate limiting; in either case, the
--bandwidth parameter controls the desired rate.
Lightly tested with both --tcp and --udp, normal and --reverse.
Real testing requires analysis of packet timestamps between
multiple hosts.
In file iperf_util.c:
Function 'va_start' is called at line:327. But, 'va_end' is not called before returning from function 'iperf_json_printf()' at line:352 and line:355.
The va_end performs cleanup for the argp object initialized by a call to va_start. If va_end is not called before a function that calls va_start returns, the behavior is undefined.
Applied Fix: added va_end before returning from the function.
DEREF_AFTER_NULL: pointer ‘test’ at line:77 is passed as an argument to function iperf_delete_pidfile(), in which it is dereferenced at iperf_api.c:2832.
Pointer ‘test’ can be NULL and dereferencing a NULL pointer causes seg-fault.
Applied Fix: pointer ‘test’ is checked for NULL before passing it to function iperf_delete_pidfile().
* Add fix for #412
This prevents negative loss counters with UDP when omit is used
* Track the original start time and bytes omitted. This allows the
throttle function to work after the omit timer fires. This is
a fix for issue #419.
* Remove changes to switch the bandwidth to received instead of sent bandwidth
* Roll back bandwidth sent vs received changes
This caused by a combination of the iperf3 build somehow using
the system queue.h on FreeBSD 11 (possibly only on this platform)
and TAILQ_END not being defined in the system queue.h.
Expanding the TAILQ_END macro to NULL seems to solve the problem.
Submitted by: @rbgarga
This was causing some headaches for code trying to parse JSON.
Also revise a prior partial fix that hard-coded 100% loss for the
case of zero packets.
Partially fixes#278.
Merge candidate for 3.0 and 3.1 bugfix branches.
Exit with non-zero exit code if server mode has too many errors.
Properly detect complain about non-numeric arguments to -A, -L, and -S.
Implement range checks for argument to -S.
Fixes#316.
Fix segfault in signal handler on the server if a signal arrives at the "wrong" time.
The change causes the signal handler to use a stack context whose lifetime should be valid the entire time the signal handler is active.
Fixes#257, #258.
The case where we should have been binding the client sockets to
ephemeral ports at a specific address for parallel tests was broken.
Fixes#239
Submitted by: @jfitzgibbon
Solaris implements an (older?) version of the API for SCTP_MAXSEG,
which takes an integer argument rather than a struct sctp_assoc_val.
We need to test for that and handle it appropriately. There are some
signs it doesn't even work correctly if we do this, so quietly ignore
errors that happen if the OS complains it's unsupported.
Also, Solaris doesn't support SCTP_DISABLE_FRAGMENTS even though it
defines the preprocessor symbol for this. Rather than aborting when
we try to unsuccessfully unset this option, just ignore the error.
Lightly tested with SCTP over IPv6 on localhost.
Contains an alternate implementation of previously-submitted patches
to set the maximum segment size and no-delay options.
As a result of this change, SCTP functionality on Linux will generally
require the libsctp library (on CentOS and similar distributions this
is provided by the lksctp-tools RPM).
Part of #131.
Submitted by: Bruce Simpson <bs48@st-andrews.ac.uk>
The problem is that the new byte-ordering macros adopted on master
don't support CentOS 5 because they assumed that any Linux system had
endian(3) support. CentOS 6 (and presumably newer) do, but CentOS 5
doesn't.
So instead we only do glibc endian(3) support if we're on a system
with glibc 2.9 or higher (which is when this functionality was
introduced).
For any other platform that we don't detect (which now includes older
glibc such as CentOS 5), bring back our homebrewed htonll and ntohll
implementation from iperf 3.0.x.
Fixes#224.
Primarily useful for bwctl integration, this is enabled with the -1
and/or --one-off flags.
Fixes#230, based on a patch by @i2aaron.
Signed-off-by: Bruce A. Mah <bmah@es.net>
Add timeout to the UDP socket. Without it client would block infinitely
if creating a control connection succeeds, but UDP packets are dropped
by firewall.
size.
This appears to be necessary on some long, high-bandwidth paths
to get sane results, either by reducing packet loss or by somehow
allowing the sending host of a test to go faster.
Fixes#219.
This value is available on the sender side, expressed in
microseconds. It's available in the JSON output.
In the JSON output we also output the maximum observed RTT
per-stream. Note that since the observation interval is many times
the RTT, it's not clear how good this value would be at capturing the
largest computed RTT value over the lifetime of each stream.
While here, also determine the maximum observed snd_cwnd value over
the lifetime of each stream.
This all works pretty well on Linux, but on FreeBSD (which should
theoretically be supported) we don't do a good job of supporting the
tcp_info structure. We need to make this code a lot more portable,
rather than just assuming the world of platforms is "Linux"
vs. "everything else". Fixing this requires some rearchitecting of
the way that we retrieve, compute, and print statistics.
Part of a fix for #215.
For UDP over IPv4, this is the maximum IPv4 packet size (65535) minus
the size of the IPv4 and UDP headers, arriving at 65507.
In theory for a system implementing IPv6 jumbogram support, there is
no maximum packet size for UDP. In practice we've observed with
CentOS 5 a limitation of 65535 - 8, which is dictated by the size
field in the UDP header (it has a maximum value of 65535, but needs
to count both payload and header bytes, thus subtracting off the 8
bytes for the UDP header).
We take the most conservative approach and use the 65507 value
for UDP / IPv4.
This is (I believe) the last part of issue #212.
We need this to permit a UDP receiving iperf3 server to listen on its
control channel.
The fix for non-blocking sockets basically makes sure that if we do a
read on a non-blocking sockets, but there's no data, the UDP processing
code does *not* try to do the normal protocol packet processing on the
non-existent packet.
This is part of an ongoing fix for issue #212 but also should have been
a part of the fix for issue #125.
This can happen if the server gets into a weird state (see the test
cases for reproducing issue #212). We need to do a couple of checks
to make sure we're not dereferencing NULL pointers (yay C).
While here, also fix up a couple of related output glitches, where
in this case we can emit some invalid JSON (NaN values, such as what
you get if there's a division by zero, are not valid JSON).
Part of a fix in progress for #212.
Also if we try to compile on an unsupported platform, emit some code
in portable_endian.h that at least has a chance of compiling, rather
than erroring out right away.
For #191.
Fixed compilation error in src/cjson.c observed in Visual Studio 2013.
This problem didn't cause breakage on any other platform, but this change should have been present anyway.
(cherry picked from commit dd2968f21e641945026db4bbdf02b3c13f833d74)
Signed-off-by: Bruce A. Mah <bmah@es.net>
When running multiple parallel streams, the specified port number
is incremented for each successive stream.
Signed-off-by: Kevin Constantine <kevin.constantine@gmail.com>
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.
UDP tests store a packet sequence number in the packets to detect loss
and ordering issues. This sequence number is a 32-bit signed integer,
which can wrap during very long-running UDP tests. This change adds
an option (defaulting to off) which uses a 64-bit unsigned integer to
store this quantity in the packet. The option is specified on the
client side; the server must support this feature for proper
functioning (older servers will interoperate with newer clients, as
long as --udp-counters-64-bit is not used).
The default might be changed in a future version of iperf3.
As a part of this change, the client sends its version string to the
server in the parameter block.
Uses a public-domain compatibility shim for 64-bit byte order
conversions. There are probably some additional platforms that need
to be supported, in particular Solaris. We might add some
configure-time checks to only enable this feature on platforms where
we can support the byte-order conversions.
This change is not well-tested.
Towards issue #191.
By design, an iperf3 server only runs one test at a time. New
connections from other clients (during an existing test) are
rejected. A problem is that the server code that rejects the test
tries (for some reason) to read the cookie from the client, even
though it's going to reject the connection anyway.
A way to break an existing test is: With a test running, make a TCP
connection to the server's control port (this can easily be done with
a telnet client). The server will hang in a blocking read call trying
to read the cookie from a non-existent client, while the test is
essentially frozen.
The fix is to remove the attempted read of the cookie.
Fixes#202.
We support using k, m, and g as suffices on input values. In most
cases these are 2-based suffixes (i.e. K == 1024) because they are
sizes of objects. In the case of rates, we need to use 10-based
suffices (i.e. K == 1000).
We do this by implementing (using copy-and-paste) a unit_atof_rate()
subroutine that parses strings similarly to unit_atof but using
10-based suffices instead.
Fixes#173.
When we do TCP tests and specify the socket buffer size, MSS, or
TCP no delay option, the iperf3 server destroys the socket it was
using to listen for the control connection and opens up a new
listening socket for the test's data connections. This is (I think)
to make sure that the data connections all have the correct TCP
parameters.
When we re-create the listening socket, we also need to go through
the binding logic again (with all of the address family selectiion,
etc. goop). The bug fixes that were a part of issue #193 need to
be ported to this code as well.
This problem only affects TCP tests, because for other protocols,
the listening socket for data cannot be the same listening sock as
for the control connection.
While here, add some comments so anybody trying to understand this
code will have an easier time.
Based on patch by: @i2aaron
setsockopt(3) returns an error if passing 0 to this option (which
we do if no address family is specified when we bind to the wildcard
address, say by invoking "iperf3 -s" with no other options). This
is because OpenBSD explicitly does not support IPv4-mapped addresses,
so even though the IPV6_V6ONLY socket options exists, it only works
with a non-zero argument.
Fixes#196.
Should fix#177, in which compilation failed on older Solaris systems
that didn't have it. This is a different approach than a patch
suggested in that issue.
Weakly regression-tested on other platforms (test this by specifying
-6, -4, or neither to the server when binding to the wildcard address,
and seeing if a client can connect with various of -6, -4, or neither).
On CentOS 6 and MacOS, if no address family was specified, we'd
get back an IPv4 address from getaddrinfo(3), with the result that
we couldn't accept IPv6 connections in the default server configuration.
There was an earlier attempt at fixing this problem that caused
Issue #193. This change is a follow-up fix to that issue.
While here, put lots of comments around the fix so we remember
why we're doing these shenanigans.
If specifying -B with an IPv4 literal address or with an FQDN that
resolved to an IPv4 address, but we had not explicitly specified an
address family with -4, we failed to set up the socket correctly
because we assumed binding to an IPv6 address, and instead (after some
error spewage) wound up binding to wildcard address.
The fix in this commit has multiple parts: First, if the address
family hasn't been explictly specified, don't force AF_INET6 in the
hints to getaddrinfo(3). AF_UNSPEC should generate the correct
(according to RFC 6724) behavior.
Second, iperf_reset_test() should not discard members that were passed
from command-line parameters, because that alters the behavior of the
iperf3 when it tries to recreate the listening socket. In the failure
situation described in this issue (and possibly other as well), the
value of -B gets discarded, so on subsequent attempts to set up the
listening socket it just binds to the wildcard address.
While here, fix on-line help related to the -B option to match
reality.
Note that we're not completely in compliance with RFC 6724, which
states that we should actually try all of the addresses in returned by
getaddrinfo(3), rather than just the first one.
Fixes Issue #193.
The various "connected" structures were just dumped into the "start"
structure. This caused problems if there were multiple connections
(i.e. multiple parallel streams), because the "connected" structures
would overwrite themselves. Instead, make these structures members
of a "connected" array.
This is technically an incompatible API change, but the prior behavior
was unusable.
Discovered and fix suggested by: @i2aaron
An open(2) call had two arguments instead of the required three.
While here, replace a hard-coded mode in a different open(2) call
with symbolic constants for readability.
Fixes#183.
Submitted by @ssahani.
retrieve (most of) the output emitted by the server.
If the server was invoked with the --json flag, the output will be in
JSON, otherwise it will be in the human-readable format.
If the client was invoked with the --json flag, the output will be
contained within the JSON output structure, otherwise it will be
appended (in whatever format) to the bottom of the human-readable
output.
Because of the sequencing of the output generation and display, the
server-side output includes only the starting output, interval
statistics and summaries, but not the overall summaries. (The overall
summaries were already displayed in the client's output.)
Towards issue #160.
Only do -Wall by default if on GCC (or something that looks like
GCC, such as clang/llvm).
Turn on -Werror so we can get some better error-checking, but
we also need -Wno-deprecated-declarations at least for MacOS,
because daemon(3) is deprecated starting with MacOS 10.5.
Fixes#174 (I think).
Submitted by: @marksolaris
This definitely affected FreeBSD, which breaks POSIX.1 by not
setting CLOCKS_PER_SEC to 1000000 (see clock(3)). At this point
I can't tell if any other platforms were affected by this.
transfer.
Note that the sender can either be the client or the server depending
on whether --reverse is used.
This fixes some problems with UDP transfers getting severely confused
and (wrongly) complaining about packets arriving out of order.
Related to issue #125.
algorithm selection) option to work on FreeBSD for free, starting with
FreeBSD 9. Update various documentation places to note this. One
specifies the congestion algorithm in the same was on Linux, although
the names of the algorithms are (at least in the general case) different.
"sysctl net.inet.tcp.cc" on FreeBSD provides a list of available
algorithms, which are implemented as loadable kernel modules.
Rename the --linux-congestion long option to --congestion (retaining
the old option as a deprecated synonym).
not including it.
To fix this required us to change config.h to iperf_config.h (to
avoid potential filename collisions with this generic name). Then
iperf.h could include this.
Adjust the existing header file inclusions to track this, and also
canonicalize their inclusion to be at the top of *.c files.
As with several other recent commits, don't check explicitly for an
OS platform, but rather detect the various API bits that are used
to implement CPU affinity setting.
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).
