[Kamailio-Users] Fwd: TLS Multiple records not read
Klaus Darilion
klaus.mailinglists at pernau.at
Mon Jan 25 16:14:48 CET 2010
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.mailinglists at pernau.at <mailto:klaus.mailinglists at 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:551138175007 at 21.21.81.11:6061;transport=tls SIP/2.0^M To:
> SIP5007_TLS_SIMPLEX <sip:551138175007 at 41.41.0.230
> <mailto:sip%3A551138175007 at 41.41.0.230>
> <mailto:sip%3A551138175007 at 41.41.0.230
> <mailto:sip%253A551138175007 at 41.41.0.230>>>;tag=91c2c894c0^M
> From:
> <sip:551138175008 at 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:551138175007 at 21.21.81.11:6061;transport=tls SIP/2.0^M
> To: SIP5007_TLS_SIMPLEX <sip:551138175007 at 41.41.0.230
> <mailto:sip%3A551138175007 at 41.41.0.230>
> <mailto:sip%3A551138175007 at 41.41.0.230
> <mailto:sip%253A551138175007 at 41.41.0.230>>>;tag=91c2c894c0^M
> From:
> <sip:551138175008 at 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:551138175007 at 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.mailinglists at pernau.at
> <mailto:klaus.mailinglists at pernau.at>
> <mailto:klaus.mailinglists at pernau.at
> <mailto:klaus.mailinglists at 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 at lists.kamailio.org
> <mailto:Users at lists.kamailio.org>
> <mailto:Users at lists.kamailio.org <mailto:Users at lists.kamailio.org>>
>
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
More information about the sr-users
mailing list