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
