regardless of whether this gets fixed (it was broken before, davem fixed
it in the 2.0.3x series last time), from a portability point of view you
should assume SO_LINGER is broken everywhere. it's also broken in various
versions of the BSD networking stack which is what lots of other stacks
are based on.
i describe what we do in apache in the perf-tuning docs
<http://www.apache.org/docs/misc/perf-tuning.html> search for linger.
you don't need to use alarm(), we do something that's essentially
select/poll based in apache-2.0 source (but it's not there until 2.0a3).
i dunno why, but in my very crude tests years ago it was faster to do it
apache's way than to let the kernel do it.
i'm not sure, but i assume that mod_ssl or apache-ssl perform the same
thing for the underlying ssl socket.
-dean
On Thu, 20 Apr 2000, Howard Chu wrote:
> [I originally sent this to the linux-net mailing list but it's not getting
> much response over there. The problem still exists, even in 2.3.99-5.]
>
> Sorry if this is a well-known problem; I searched the archives for this
> list and only found two relevant references, both from 1997. I am using
> OpenLDAP and OpenSSL on various systems including Linux 2.2.{5,13} kernels.
> I set SO_LINGER on the slapd's listening sockets, because I want to make
> sure that any error alerts generated by the SSL library are propagated
> to the client when slapd tears down a connection. So far, this only
> works on the first accept'd socket.
>
> The scenario - my slapd is configured to require client certificates on
> SSL connections. If the client's certificate is expired, the SSL_accept
> call fails. Along the way, the SSL library sends an alert message to the
> client, with the "certificate expired" error code. But, slapd close's the
> socket as soon as the SSL_accept call returns. The first time I start up
> slapd and connect with an expired certificate, the error message shows
> up at the client. On all subsequent attempts, the connection is torn
> down before the alert gets transmitted. I have verified (inserting
> getsockopt & printf) that the SO_LINGER option is still set with my
> original values on the socket, it just isn't being honored by the kernel.
> I have a workaround (using select with a 2/100th second delay before calling
> close) that allows the error to get through, but this is ugly, and I think
> it introduces an unnecessary throughput restriction. (Even though slapd is
> multithreaded, the list of connections it manages is locked at this point,
> so the delay means the server cannot service other incoming connections.)
>
> The behavior is also dependent on the relative speed of the connection
> between the client and the server. Clients connecting thru the loopback
> address, and clients on the same wire as the server all have this problem.
> However, if the server sits across a slow network link, usually the alert
> gets through successfully.
>
> I have examined some more recent kernel sources (2.3.xx, 2.3.29) but I
> haven't seen much that makes sense here yet. Does anyone recognize this
> problem, and do you know if it has been fixed in any particular release?
>
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:18 EST