We check at configure-time to see if IPV6_FLOWLABEL_MGR is defined
in <linux/in.6>, if it is we set a HAVE_FLOWLABEL CPP symbol to
turn on conditional compilation of the support for this feature.
Rather than checking for anything Linux-specific at configure-time,
see if TCP_CONGESTION is defined in <netinet/tcp.h> and if so define
a CPP variable HAVE_TCP_CONGESTION, which we then use to enable
conditional compilation of the code for this feature.
The bug and solution are very similar to Issue 126 (fixed in
d7e0c1445c0a). Basically a setsockopt(IPV6_V6ONLY) call had a bogus
level argument, but we never checked the return value so we never
noticed this.
As with the prior issue, the fix is to unbreak the setsockopt() call,
and add some error checking to detect future breakage.
This bug was on a codepath that only got called if non-default values
were set for the socket buffer size, the MSS, or the NODELAY parameter.
It might have affected some FreeBSD tests, but really only got noticed
when debugging some other code that was (probably) cut-and-pasted
from this code.
Apparently older kernels don't support TCP_CONGESTION, so we can't
just test for defined(linux) to know if we can use this sockopt or not.
This change unbreaks the build on (notably) CentOS 5.
Also remove a couple of places where we were saving and restoring errno
where we didn't need to.
Submitted by: Susant Sahani <ssahani@redhat.com>
Issue: 121 (TCP congestion control algorithm support for client)
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)
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.
The user-visible parts are commented out or return a "not implemented
yet" error message. The other parts are harmless.
We'll come back to this once we figure out how exactly one sets
the Flow Label.
one is the new -Z flag.
- Fixed potential bug in net.c's Nread and Nwrite routines. If they
had ever needed to loop they would have read/written the wrong address,
due to incorrect pointer arithmetic - sizeof(void) is not 1. Fix
was to change the type of the buffer pointer to char*, which also
meant adding casts to some callers.
- Better checking for conflicts between command-line flags - now they
should no longer be order-dependent.
- Added a new -Z / --zerocopy flag, to use a "zero copy" method of
sending data, such as sendfile(2) instead of the usual write(2).
- Renumbered error enum to make inserting new ones easier.
