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
