On 5/07/2014 9:12 AM, Kurt Roeckx wrote:
> On Sat, Jul 05, 2014 at 08:13:04AM -0400, Eric Covener wrote:
>> On Sat, Jul 5, 2014 at 7:37 AM, Kurt Roeckx <k...@roeckx.be> wrote:
>>> Does anybody have an idea why it's trying to do that, and why we
>>> shouldn't just do SO_REUSEADDR the first time? Was there some
>>> OS that maybe did strange things when trying to use SO_REUSEADDR
>>> and it was already in use?
>> FWLIW: I've seen this pattern in some other proprietary software,
>> where they try hard to not set SO_REUSEADDR unless it appears needed
>> due to a bind failure. But whatever they were working around, it is
>> detrimental to modern Linux where the outgoing TIME_WAIT socket has to
>> also have been opened with SO_REUSEADDR for the reuse to be allowed.
> man socket(7) documents that behavior on Linux. They also say that
> you ussually don't notice it because most things always set
> SO_REUSEADDR. So it seems to me like the behavior of that piece
> of code will at least don't do what you want it to do on Linux so
> other than being weird it looks like an other reason to just drop
> it.
If you have SO_REUSEADDR set and a listener already in place you will
start a new listener and who gets the incoming connections is not well
defined.
You need to determine if this is just a time-wait socket stopping the
bind or there is a listener in place. That is the semantics being
handled in the code.
See crypto/bio/bss_acpt.c where the bind_mode is "documented" in a comment:
/* If 0, it means normal, if 1, do a connect on bind failure,
* and if there is no-one listening, bind with SO_REUSEADDR.
* If 2, always use SO_REUSEADDR. */
Setting SO_REUSEADDR on always will not result in what you are expecting ...
Tim.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
