Announcement

Collapse
No announcement yet.

SSL connection

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    For other purpose than above I tried to implement a SSL connection to a PC application. When trying to connect to the PC application (like in the sslclient sample), the XPort tells me about a SSL error:

    "sslcli.c: SSL connection error: 9001"

    It's probably a bug in my application, but error code 9001 does not help a lot to me.

    So again the question: is there a list of the possible error codes and their description?

    (XPort-Pro with Evolution V5.2.0.0 R22)

    EDIT: I found out, that SSLConnection_open() needs the casted value of "sock", not the pointer. Well, now the syslog says: "sslcli.c: SSL connection error: 9002". What does this mean?
    Last edited by TESK; 01-05-2011, 02:34 PM.

    Comment


    • #17
      Transport errors

      The 9000 range codes are transport errors:
      9000 - Null pointer
      9001 - Send failure
      9002 - Receive failure

      Generally, you will see send or receive failure if the connection has been rejected, closed or timed out.

      Also, look in your TLOG, as there could be some clues there.

      Comment


      • #18
        Thanks for your fast response.

        The syslog only tells me about the "9002 error". So I used the network sniffer to find out more about the reason for it. The TCP connection gets opened and ACK'ed twice. The problem seems to be the "Client hello message" (TLS handshake).

        The XPort device sends following TCP data (hex): 16 0302 003b
        • 0x16 -> record type: handshake
        • 0x0302 -> Version: TLS1.1
        • 0x003b -> Length of the data section: 59 Bytes


        Well all right... but there are no 59 data bytes. The TCP data gets ACK'ed, but the connection gets reset by the PC within this TCP package causing the SSL negitiation to fail.

        I also sniffed some successful SSL negotiations, because I do not know the SSL protocol in detail. But there were always more data after the "data length field". Any ideas about that? Do I have to wait until the XPort sends more data or is there a misconfiguration of my certificates etc.?

        Comment


        • #19
          SSL over TCP

          SSL runs over TCP. It sends the header with one "send" call, then the body with a second "send" call. So if the first is being sent but not the second, it means that something is happening at the TCP layer that is blocking the send or closing the session. Perhaps you can forward a Wireshark trace through your FAE, and make sure to tell us where in the trace you are seeing this behavior.

          Comment


          • #20
            Scook, did you receive my email? I've sent it on 10.01.2011 to my FAE with the note to forward it. Unfortunately, I have not received any answer yet.

            Comment


            • #21
              Email?

              No, I have not heard anything more. Perhaps I did not recognize it? I get many requests per day, but in this thread there is not yet enough information to go on.

              Comment


              • #22
                I still have the Wireshark file. So please send an email to me (to the email address of my forum account) and I will forward the network trace to you. Otherwise, please give me your email address via PM...

                Comment


                • #23
                  Wireshark

                  How about if you zip your Wireshark file so you can attach it here on the forum?

                  Comment


                  • #24
                    The Wireshark file "SSL_dump.pcap" shows the very beginning SSL conversation between a XPort-Pro device (IP 192.168.2.11) and the PC (192.168.2.2). For testing purposes, the PC runs a SSL server using the OpenSSL library.

                    - Msg. no. 4 to 6 shows the opening of the TCP connection from XPort to the PC with double ACK
                    - After syslog entry "Processing SSL..." (msg. no. 8), "SSLconnect()" gets called
                    - Msg. no. 9 contains the first 5 bytes of the "client hello" message (gets ACKed by PC)
                    - The client application on the PC shows a failure from the OpenSSL library (communication error; not visible in the trace); maybe because of the incomplete "client hello". Therefore the socket gets closed by the PC (msg. no. 11)

                    Any suggestions?
                    Attached Files

                    Comment


                    • #25
                      Server problem?

                      The trace shows
                      1) Our device does not try to send any more data after the initial header is sent.
                      2) The SSL server is disconnecting (RST) just 47 msec after it acks that header.

                      My desk tests with a working SSL tunnel between two devices starts out the same. Our device sends the second packet, containing the data, after about 800 msec.

                      So it looks like the connection is broken because your SSL server shuts it down first, even though the header is properly formed.

                      This behavior with multiple packets is not new, and since TCP is stream oriented, it anyway provides no assurances that a single SSL record is carried entirely in a single TCP packet.

                      Bottom line, this appears to be a problem on your SSL server.

                      Comment

                      Working...
                      X