(Formerly it was just accepting IPv6.)
The problem here was that FreeBSD by default wasn't allowing IPv4
mapped addresses on IPv6 sockets, whereas other platforms
(specifically Linux and OS X) both do permit this. We tried to turn
on mapped addresses via a setsockopt(IPV6_V6ONLY) call, but this call
was broken because the level argument was incorrect. We didn't know
about this because we never checked the return value.
Fix this by providing the correct argument to setsockopt(). Add some
error checking to this and one other setsockopt() call, so we at least
don't fail silently in similar situations.
Issue: 126 (FreeBSD: iperf3 -s only accepts IPv6
connections)
These go to a new section that might be merged with the prior 3.0.0
section pending a release engineering discussion.
Also fix a typo: s/vebose/verbose/
This functionality uses some setsockopt(2) calls that unfortunately
don't seem to have an analog on other platforms.
Slightly tweaked version of a patch that was...
Submitted by: ssahani@redhat.com
Issue: 40 (Option for setting Flow Label field in IPv6
header)
This lets us check timers every tenth second instead of every second,
so we can switch out of the more expensive select() mode even with
the default reporting interval of a second.
Possible related work still under consideration:
o Use syslog in daemon mode for output that would normally go to
stdout / stderr.
o Write a PID file.
This is basically the gist of Issue 105.
Also bumped package id from 3.0a4 to 3.0a5.
This changeset consists of a one-line edit to configure.ac, plus
about fifty kilolines of diffs to a bunch of other config files
generated by bootstrap.sh.
having it there may cause the select to return immediately every
time. Which is bad, m'kay?
Also, changed the coding idiom used to keep track of the maximum fd
in the fd sets, to be clearer.
The error numbers sent for SERVER_ERROR state were declared
as ints, and therefore could be 32 or 64 bits depending on
architecture. I changed them to be explicitly 32 bits.
This should be the last of these, I've checked out at every network
read/write call and they look ok.
And bumped the version to 3.0-RC5.
A couple more sizeof issues found and fixed. One of them is
actually another protocol change, but due to a fortuitous accident
it should remain compatible with older versions.
Detailed explanation: When a client attempts to connect to a server that
is already busy, the server is supposed to return ACCESS_DENIED as a
state value. It was doing so, but was writing it as an int, even though
state values are supposed to be signed chars. The client read the value
correctly as a signed char, getting one byte and throwing away the rest.
So why did this ever work? Because ACCESS_DENIED is the value -1, and
any byte of an int -1 equals a signed char -1. If ACCESS_DENIED had been
any other value, this would have been an opvious bug and would have long
since been fixed. As is, it stuck around working by accident until now.
test->state is an explicitly signed char, so the two routines that
manipulate it must use explicitly signed chars too.
One could argue that the two negative state values should have been
positive like the rest, but changing them now would be a protocol change.
On further reflection, last night's seemingly trivial change to
the JSON sending/receiving routines is actually a protocol change,
on some machines, and therefore merits a version number change.
