up to now the error message is still the same - thats the last lines of
repeater before the repeat thread crashes

Server: bytesReceived: 1024 / bytesSent: 1024 / sumS: 1022335
Server: bytesReceived: 1024 / bytesSent: 1024 / sumS: 1023359
Server: bytesReceived: 1024 / bytesSent: 1024 / sumS: 1024383
Server: bytesReceived: 1024 / bytesSent: 1024 / sumS: 1025407
Server: bytesReceived: 1024 / bytesSent: 1024 / sumS: 1026431
Server: bytesReceived: 903 / bytesSent: 903 / sumS: 1027334
4409:error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected
message:s3_pkt.c:1053:SSL alert number 10

Thats the EXACT error message the repeat thread prints. (It has not
changed since my first mail)

When sniffing the traffic with wireshark on the clientside I can see,
that the client is sending 'SSLv3: Encrypted Alert / Alert 21 (0x15)' to
the repeater.
If wireshark misinterpret the message or whatever - thats the last
message which is sent from the client to the repeater.
I do not know why I get SSL alert number 10 though I sniff alert 21
with wireshark but what I describe is consistent and true.
If you want to see the wireshark dump or something else I can give it to
Perhaps the client implementation (matrixssl) sends the TLS message 21
in an SSLv3 packet. Because in the standard there is no error 21 defined
in SSLv3 openssl makes an alert number 10 - unexpected_message out of

Let me describe why I started using SSL_pending at all:
The server connects to the repeater first. After connection I use
SSL_set_fd() / SSL_accept to set up the ssl. Then the server sends the
char 'S' and a id. After that the 'SSL' - pointer to the server
hangs in a bookkeeping tree (id points to a struct which contains the
pointer to the SSL - struct and some other information). But after
sending the ID, the server sends another 12 bytes of data which should
be read in the repeat thread at all.
When the client connects he send an 'C' (for Client) and the an Id (the
id he want to be connected with). In the tree I search for this id, get
the SSL pointer to the server and start the repat thread with both
handles. Without the SSL_pending() select blocked forever. First I had
no idea why till I found SSL_pending function which returned 12 when I
called it at repeat startup. My conclusion was that ssl lib already read
the data which came from the server (there was enough time till the
client connected) and wrote it to a buffer in the lib => no more to read
on the socket itself and select blocked forearch because the client
waits for these 12 bytes.
How shall I handle this? Use a goto to jump directly in the ssl_read
from the server?

Thanks a lot for your time - I hope I fixed it soon


> Okay. SSLv3 is different from TLSv1.0. And you really, really,
> REALLY need to give the correct error. Your original message said it
> was alert number 10, not alert 21.
> Alert 21 is not specified in SSLv3 (see
> http://www.freesoft.org/CIE/Topics/ssl-draft/3-SPEC.HTM for the alert
> definitions, section 7.4 and 7.4.2). It is specified in TLSv1 (RFC
> 2246), though, and is decryption_failed. See
> ftp://ftp.rfc-editor.org/in-notes/rfc2246.txt for the specification.
> If there is data available for SSL_read() to read on the socket,
> select() will tell you. You should not use SSL_pending for the task,
> for the reason that David mentioned. You should realize that it's
> possible for SSL_read() to return 0 even in the event that there is
> data available on the socket, and it's also possible for it to return
> -1 with SSL_ERROR_WANT_WRITE -- a partial packet might have been
> delivered, or it might just be a renegotiation with no user data
> available. Either way, you should structure your code to call
> SSL_read() on any descriptor that select() says has pending data, and
> only then if you actually have any application data in there should
> you try to copy anything to the other side of the proxied pair.
> Remove the call to SSL_pending() -- just let the library deal with its
> internal bookkeeping, and make your code a little more naïve.
> Remember, SSL_read() returns the number of bytes it read from the
> stream. If it's 0, then there's no user data, even if it did need to
> do a renegotiation. In that case, just continue; your select() loop
> without trying to complete copying of a 0-length buffer. And it can
> return -1/SSL_ERROR_WANT_* at any time (if the auto-retry option isn't
> set).
> -Kyle H

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org