Hi, 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 you. 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 it? 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 connection 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 :) Greetings, Antonio > 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 [EMAIL PROTECTED]
