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@21.21.81.11:6061;transport=tls SIP/2.0^M To: SIP5007_TLS_SIMPLEX <sip:551138175007@41.41.0.230sip%3A551138175007@41.41.0.230>;tag=91c2c894c0^M From: sip:551138175008@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@21.21.81.11:6061;transport=tls SIP/2.0^M To: SIP5007_TLS_SIMPLEX <sip:551138175007@41.41.0.230sip%3A551138175007@41.41.0.230>;tag=91c2c894c0^M From: sip:551138175008@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@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@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 http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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@21.21.81.11:6061;transport=tls SIP/2.0^M To: SIP5007_TLS_SIMPLEX <sip:551138175007@41.41.0.230 mailto:sip%3A551138175007@41.41.0.230>;tag=91c2c894c0^M From: sip:551138175008@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@21.21.81.11:6061;transport=tls SIP/2.0^M To: SIP5007_TLS_SIMPLEX <sip:551138175007@41.41.0.230 mailto:sip%3A551138175007@41.41.0.230>;tag=91c2c894c0^M From: sip:551138175008@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@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@pernau.at mailto:klaus.mailinglists@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> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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@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@21.21.81.11:6061;transport=tls SIP/2.0^M To: SIP5007_TLS_SIMPLEX <sip:551138175007@41.41.0.230sip%3A551138175007@41.41.0.230<mailto: sip%3A551138175007@41.41.0.230 sip%253A551138175007@41.41.0.230>>;tag=91c2c894c0^M From: sip:551138175008@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@21.21.81.11:6061;transport=tls SIP/2.0^M To: SIP5007_TLS_SIMPLEX <sip:551138175007@41.41.0.230sip%3A551138175007@41.41.0.230<mailto: sip%3A551138175007@41.41.0.230 sip%253A551138175007@41.41.0.230>>;tag=91c2c894c0^M From: sip:551138175008@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@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@pernau.at mailto:klaus.mailinglists@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> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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@pernau.at mailto:klaus.mailinglists@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@21.21.81.11:6061;transport=tls SIP/2.0^M To: SIP5007_TLS_SIMPLEX <sip:551138175007@41.41.0.230 <mailto:sip%3A551138175007@41.41.0.230> <mailto:sip%3A551138175007@41.41.0.230 <mailto:sip%253A551138175007@41.41.0.230>>>;tag=91c2c894c0^M From: <sip:551138175008@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@21.21.81.11:6061;transport=tls SIP/2.0^M To: SIP5007_TLS_SIMPLEX <sip:551138175007@41.41.0.230 <mailto:sip%3A551138175007@41.41.0.230> <mailto:sip%3A551138175007@41.41.0.230 <mailto:sip%253A551138175007@41.41.0.230>>>;tag=91c2c894c0^M From: <sip:551138175008@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@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@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@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 ------------------------------------------------------------------------
We can decode the wireshark traces by loading the serverkey.pem of proxy and sip server in wireshark ->edit->prefrences->ssl. format is like below. 21.21.27.210,5061,sip,C:\serverkey.pem;41.41.0.230,5061,sip,C:\serverkey.pem;
The important point is, 1. The wireshark traces needs to be collected from the beginning of TCP and TLS negotiation between endpoints and phone . 2. The phone shall be configured with local port other than 5061.
In case TCP it reads the available data in the socket buffer and parse it.
In case of TLS, the SSL_read() read only one record at time. So in case of multiple records i believe the 2nd record is stored in the SSL buffer. So i think we need to use SSL_pending() after the SS_read() to find any pending data. If any pending data, read the pending buffer.
Thanks Jijo
On Mon, Jan 25, 2010 at 10:14 AM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:
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@pernau.at mailto:klaus.mailinglists@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@21.21.81.11:6061;transport=tls SIP/2.0^M To: SIP5007_TLS_SIMPLEX <sip:551138175007@41.41.0.230sip%3A551138175007@41.41.0.230 <mailto:sip%3A551138175007@41.41.0.230sip%253A551138175007@41.41.0.230
<mailto:sip%3A551138175007@41.41.0.230<sip%253A551138175007@41.41.0.230> <mailto:sip%253A551138175007@41.41.0.230<sip%25253A551138175007@41.41.0.230>>>>;tag=91c2c894c0^M From: <sip:551138175008@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@21.21.81.11:6061;transport=tls SIP/2.0^M To: SIP5007_TLS_SIMPLEX <sip:551138175007@41.41.0.230sip%3A551138175007@41.41.0.230 <mailto:sip%3A551138175007@41.41.0.230sip%253A551138175007@41.41.0.230
<mailto:sip%3A551138175007@41.41.0.230<sip%253A551138175007@41.41.0.230> <mailto:sip%253A551138175007@41.41.0.230<sip%25253A551138175007@41.41.0.230>>>>;tag=91c2c894c0^M From: <sip:551138175008@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@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@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@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