Really strange. btw: how do you manage to decode the SSL payload in Wireshark?

regards
klaus

Jijo Jose schrieb:
Hi Klaus,
Sorry for sending the screenshot.. In the 2nd record, i see 2 CRLF at the end of sip message. I'm using openser 1.1, I just verified kamailio 1.4 to see any changes in the TLS module. The code base for TLS in openser 1.1 and kamailio 1.4 is same. Thanks
Jijo

On Mon, Jan 25, 2010 at 3:43 AM, Klaus Darilion <klaus.mailingli...@pernau.at <mailto:klaus.mailingli...@pernau.at>> wrote:

    Hi Jijo!

    - Next time, please do not send a screenshot, but the pcap file (if
    it would contain private data, send it privately)

    - the screenshot shows the first message, but more interesting is
    the second message

    - which version of Kamailio do you use (kamailio -V)? You mentioned
    that you compared the codebase between 1.4 and 1.1 - why? Doesn't
    1.1 show this behavior?

    regards
    Klaus

    Jijo Jose schrieb:


        Thanks for the response.
         The SIP server is reading only the first record(first sip
        message), the _tls_read() function's log shows the length of
        first sip message which is matching with length of first record
        in wireshark.. This means SSL_read returns only the first record.
        I did the test using TCP which is working fine as it is reading
        two sip messages on a single read.
         Please find the log and attached print screen of wireshark traces.
Jan 22 20:41:37 REGS-1a0240 openser[936]: io_wait_loop_sigio_rt:
        siginfo: signal=35 (35), si_code=1, si_band=0x41, si_fd=37
        Jan 22 20:41:37 REGS-1a0240 openser[936]: TCPCONN: handle_io:
         fd map 0x1011d73c (37): {37, 2, 0x30294da0}
        Jan 22 20:41:37 REGS-1a0240 openser[936]: tls_update_fd: New fd
        is 37
        Jan 22 20:41:37 REGS-1a0240 openser[936]: _tls_read: 559 bytes read
        Jan 22 20:41:37 REGS-1a0240 openser[936]: read= 559 bytes,
        parsed=559, state=4, error=1
        Jan 22 20:41:37 REGS-1a0240 openser[936]: tcp_read_req: last
        char=0x0A, parsed msg= BYE
        sip:551138175...@21.21.81.11:6061;transport=tls SIP/2.0^M To:
        SIP5007_TLS_SIMPLEX  <sip:551138175...@41.41.0.230
        <mailto:sip%3a551138175...@41.41.0.230>
        <mailto:sip%3a551138175...@41.41.0.230
        <mailto:sip%253a551138175...@41.41.0.230>>>;tag=91c2c894c0^M
        From:
        <sip:551138175...@41.41.0.230:5061;transport=tls>;tag=snl_G84KdX4MLT^M
        Call-ID: 0ad3e453326a4160^M CSeq: 1 BYE^M Route:
        <sip:21.21.27.10:5061;transport=tls;ftag=91c2c894c0;lr=on>^M
        Via: SIP/2.0/TLS
        41.41.0.230:5061;branch=z9hG4bK_brancha_41.41.0.230_KonTU5DMPx^M
        Accept-Language: en;q=0.0^M Allow: REGISTER, INVITE, ACK, BYE,
        CANCEL, NOTIFY, REFER^M Date: Fri, 22 Jan 2010 20:41:36 GMT ^M
        Max-Forwards: 69^M Content-Length: 0^M ^M Jan 22 20:41:37
        REGS-1a0240 openser[936]: tcp_read_req: end of header part

        Jan 22 20:41:37 REGS-1a0240 openser[936]: - received from: port 5061
        Jan 22 20:41:37 REGS-1a0240 openser[936]: - received from: ip
        41.41.0.230
        Jan 22 20:41:37 REGS-1a0240 openser[936]: tcp_read_req: headers:
        BYE sip:551138175...@21.21.81.11:6061;transport=tls SIP/2.0^M
        To: SIP5007_TLS_SIMPLEX  <sip:551138175...@41.41.0.230
        <mailto:sip%3a551138175...@41.41.0.230>
        <mailto:sip%3a551138175...@41.41.0.230
        <mailto:sip%253a551138175...@41.41.0.230>>>;tag=91c2c894c0^M
        From:
        <sip:551138175...@41.41.0.230:5061;transport=tls>;tag=snl_G84KdX4MLT^M
        Call-ID: 0ad3e453326a4160^M CSeq: 1 BYE^M Route:
        <sip:21.21.27.10:5061;transport=tls;ftag=91c2c894c0;lr=on>^M
        Via: SIP/2.0/TLS
        41.41.0.230:5061;branch=z9hG4bK_brancha_41.41.0.230_KonTU5DMPx^M
        Accept-Language: en;q=0.0^M Allow: REGISTER, INVITE, ACK, BYE,
        CANCEL, NOTIFY, REFER^M Date: Fri, 22 Jan 2010 20:41:36 GMT ^M
        Max-Forwards: 69^M Content-Length: 0^M ^M .

        Jan 22 20:41:37 REGS-1a0240 openser[936]: tcp_read_req:
        content-length= 0
        Jan 22 20:41:37 REGS-1a0240 openser[936]: tcp_read_req: body:
        Jan 22 20:41:37 REGS-1a0240 openser[936]: calling
        receive_msg(0x30294e14, 559, )
        Jan 22 20:41:37 REGS-1a0240 openser[936]: SIP Request:
        Jan 22 20:41:37 REGS-1a0240 openser[936]:  method:  <BYE>
Jan 22 20:41:37 REGS-1a0240 openser[936]: uri: <sip:551138175...@21.21.81.11:6061;transport=tls>
        Jan 22 20:41:37 REGS-1a0240 openser[936]:  version: <SIP/2.0>
         Thanks
        Jijo


         On Sun, Jan 24, 2010 at 5:53 AM, Klaus Darilion
        <klaus.mailingli...@pernau.at
        <mailto:klaus.mailingli...@pernau.at>
        <mailto:klaus.mailingli...@pernau.at
        <mailto:klaus.mailingli...@pernau.at>>> wrote:

           I would verify if the received fragment really contains 2
        complete
           SIP messages (e.g. 2xCRLF at the end of the SIP headers and if
           Content-Length header is correct).

           For debugging, TLS is PITA.

           Maybe the SIP server shows the same behavior when using TCP.
           Otherwise you can try to configure the NULL:CIPHER on both
        servers -
           then you see the plaintext SIP message in the TLS packets.

           regards
           klaus

           Jijo Jose wrote:

               Hi All,
                We have a SIP server which enabled NAGLE algorithm and
        proxy as
               openser ver 1.1
                SIP Server send a TLS multiple records( 2 SIP messages) in a
               packet to openser. Openser is reading only the first record(
               first SIP message). The second TLS record(sip message) is
        read
               only when the next message recieved by openser from the
        SIP Server.
                 I would like to know anybody observed this issue.  I have
               compared the codebase of kamailio 1.4 and openser 1.1 but
               didin't find any diffrence for TLS.
                I have looked at the API _tls_read() in openser which is
        same
               as that of kamilio.
                Don't we need to use SSL_pending() after SSL_read() to
        verify
               any buffer is left in the SSL layer ?
                Do you think is it due to the poll method error? The poll
               method we use is POLL_SIGIO_RT
                Please let me know your comments.
                Thanks in advance.
                Jijo


------------------------------------------------------------------------

               _______________________________________________
               Kamailio (OpenSER) - Users mailing list
               Users@lists.kamailio.org
        <mailto:Users@lists.kamailio.org>
        <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>

               http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users





        ------------------------------------------------------------------------



_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

Reply via email to