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.
