[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/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:17 EST