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 f1e62c8d484a57cefb5ecbfcf8d1887b6f4fb220.
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.
This enhancement will automatic check and test the changes done. It will improve the testing capability of component as build can be tested at every pull request before commit.
To enable this feature , you will have to login in https://travis-ci.org/. using github account
and enable the travis feature for the iperf library.
Many other github projects use this feature. Hope it will help iperf too.
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
