<div>We can decode the wireshark traces by loading the serverkey.pem of proxy and sip server in wireshark ->edit->prefrences->ssl.</div>
<div>format is like below.</div>
<div>21.21.27.210,5061,sip,C:\serverkey.pem;41.41.0.230,5061,sip,C:\serverkey.pem;</div>
<div> </div>
<div>The important point is, </div>
<div>1. The wireshark traces needs to be collected from the beginning of TCP and TLS negotiation between endpoints and phone .</div>
<div>2. The phone shall be configured with local port other than 5061.</div>
<div> </div>
<div> </div>
<div>In case TCP it reads the available data in the socket buffer and parse it.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Thanks</div>
<div>Jijo</div>
<div> </div>
<div> </div>
<div>On Mon, Jan 25, 2010 at 10:14 AM, Klaus Darilion <span dir="ltr"><<a href="mailto:klaus.mailinglists@pernau.at">klaus.mailinglists@pernau.at</a>></span> wrote:<br></div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Really strange. btw: how do you manage to decode the SSL payload in Wireshark?<br><br>regards<br>klaus<br>
<br>Jijo Jose schrieb:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">Hi Klaus,<br> Sorry for sending the screenshot..<br> In the 2nd record, i see 2 CRLF at the end of sip message.<br> 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.<br>
Thanks<br>Jijo<br><br></div>
<div>
<div></div>
<div class="h5">On Mon, Jan 25, 2010 at 3:43 AM, Klaus Darilion <<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a> <mailto:<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a>>> wrote:<br>
<br> Hi Jijo!<br><br> - Next time, please do not send a screenshot, but the pcap file (if<br> it would contain private data, send it privately)<br><br> - the screenshot shows the first message, but more interesting is<br>
the second message<br><br> - which version of Kamailio do you use (kamailio -V)? You mentioned<br> that you compared the codebase between 1.4 and 1.1 - why? Doesn't<br> 1.1 show this behavior?<br><br> regards<br>
Klaus<br><br> Jijo Jose schrieb:<br><br><br> Thanks for the response.<br> The SIP server is reading only the first record(first sip<br> message), the _tls_read() function's log shows the length of<br>
first sip message which is matching with length of first record<br> in wireshark.. This means SSL_read returns only the first record.<br> I did the test using TCP which is working fine as it is reading<br>
two sip messages on a single read.<br> Please find the log and attached print screen of wireshark traces.<br> Jan 22 20:41:37 REGS-1a0240 openser[936]: io_wait_loop_sigio_rt:<br> siginfo: signal=35 (35), si_code=1, si_band=0x41, si_fd=37<br>
Jan 22 20:41:37 REGS-1a0240 openser[936]: TCPCONN: handle_io:<br> fd map 0x1011d73c (37): {37, 2, 0x30294da0}<br> Jan 22 20:41:37 REGS-1a0240 openser[936]: tls_update_fd: New fd<br> is 37<br> Jan 22 20:41:37 REGS-1a0240 openser[936]: _tls_read: 559 bytes read<br>
Jan 22 20:41:37 REGS-1a0240 openser[936]: read= 559 bytes,<br> parsed=559, state=4, error=1<br> Jan 22 20:41:37 REGS-1a0240 openser[936]: tcp_read_req: last<br> char=0x0A, parsed msg= BYE<br> sip:551138175007@21.21.81.11:6061;transport=tls SIP/2.0^M To:<br>
SIP5007_TLS_SIMPLEX <<a href="mailto:sip%3A551138175007@41.41.0.230" target="_blank">sip:551138175007@41.41.0.230</a><br> <mailto:<a href="mailto:sip%253A551138175007@41.41.0.230" target="_blank">sip%3A551138175007@41.41.0.230</a>><br>
<mailto:<a href="mailto:sip%253A551138175007@41.41.0.230" target="_blank">sip%3A551138175007@41.41.0.230</a><br></div></div> <mailto:<a href="mailto:sip%25253A551138175007@41.41.0.230" target="_blank">sip%253A551138175007@41.41.0.230</a>>>>;tag=91c2c894c0^M
<div class="im"><br> From:<br> <sip:551138175008@41.41.0.230:5061;transport=tls>;tag=snl_G84KdX4MLT^M<br> Call-ID: 0ad3e453326a4160^M CSeq: 1 BYE^M Route:<br> <sip:21.21.27.10:5061;transport=tls;ftag=91c2c894c0;lr=on>^M<br>
Via: SIP/2.0/TLS<br> 41.41.0.230:5061;branch=z9hG4bK_brancha_41.41.0.230_KonTU5DMPx^M<br> Accept-Language: en;q=0.0^M Allow: REGISTER, INVITE, ACK, BYE,<br> CANCEL, NOTIFY, REFER^M Date: Fri, 22 Jan 2010 20:41:36 GMT ^M<br>
Max-Forwards: 69^M Content-Length: 0^M ^M Jan 22 20:41:37<br> REGS-1a0240 openser[936]: tcp_read_req: end of header part<br><br> Jan 22 20:41:37 REGS-1a0240 openser[936]: - received from: port 5061<br> Jan 22 20:41:37 REGS-1a0240 openser[936]: - received from: ip<br>
41.41.0.230<br> Jan 22 20:41:37 REGS-1a0240 openser[936]: tcp_read_req: headers:<br> BYE sip:551138175007@21.21.81.11:6061;transport=tls SIP/2.0^M<br> To: SIP5007_TLS_SIMPLEX <<a href="mailto:sip%3A551138175007@41.41.0.230" target="_blank">sip:551138175007@41.41.0.230</a><br>
<mailto:<a href="mailto:sip%253A551138175007@41.41.0.230" target="_blank">sip%3A551138175007@41.41.0.230</a>><br> <mailto:<a href="mailto:sip%253A551138175007@41.41.0.230" target="_blank">sip%3A551138175007@41.41.0.230</a><br>
</div> <mailto:<a href="mailto:sip%25253A551138175007@41.41.0.230" target="_blank">sip%253A551138175007@41.41.0.230</a>>>>;tag=91c2c894c0^M
<div>
<div></div>
<div class="h5"><br> From:<br> <sip:551138175008@41.41.0.230:5061;transport=tls>;tag=snl_G84KdX4MLT^M<br> Call-ID: 0ad3e453326a4160^M CSeq: 1 BYE^M Route:<br> <sip:21.21.27.10:5061;transport=tls;ftag=91c2c894c0;lr=on>^M<br>
Via: SIP/2.0/TLS<br> 41.41.0.230:5061;branch=z9hG4bK_brancha_41.41.0.230_KonTU5DMPx^M<br> Accept-Language: en;q=0.0^M Allow: REGISTER, INVITE, ACK, BYE,<br> CANCEL, NOTIFY, REFER^M Date: Fri, 22 Jan 2010 20:41:36 GMT ^M<br>
Max-Forwards: 69^M Content-Length: 0^M ^M .<br><br> Jan 22 20:41:37 REGS-1a0240 openser[936]: tcp_read_req:<br> content-length= 0<br> Jan 22 20:41:37 REGS-1a0240 openser[936]: tcp_read_req: body:<br>
Jan 22 20:41:37 REGS-1a0240 openser[936]: calling<br> receive_msg(0x30294e14, 559, )<br> Jan 22 20:41:37 REGS-1a0240 openser[936]: SIP Request:<br> Jan 22 20:41:37 REGS-1a0240 openser[936]: method: <BYE><br>
Jan 22 20:41:37 REGS-1a0240 openser[936]: uri: <sip:551138175007@21.21.81.11:6061;transport=tls><br> Jan 22 20:41:37 REGS-1a0240 openser[936]: version: <SIP/2.0><br> Thanks<br>
Jijo<br><br><br> On Sun, Jan 24, 2010 at 5:53 AM, Klaus Darilion<br> <<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a><br> <mailto:<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a>><br>
<mailto:<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a><br> <mailto:<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a>>>> wrote:<br>
<br> I would verify if the received fragment really contains 2<br> complete<br> SIP messages (e.g. 2xCRLF at the end of the SIP headers and if<br> Content-Length header is correct).<br><br>
For debugging, TLS is PITA.<br><br> Maybe the SIP server shows the same behavior when using TCP.<br> Otherwise you can try to configure the NULL:CIPHER on both<br> servers -<br> then you see the plaintext SIP message in the TLS packets.<br>
<br> regards<br> klaus<br><br> Jijo Jose wrote:<br><br> Hi All,<br> We have a SIP server which enabled NAGLE algorithm and<br> proxy as<br> openser ver 1.1<br>
SIP Server send a TLS multiple records( 2 SIP messages) in a<br> packet to openser. Openser is reading only the first record(<br> first SIP message). The second TLS record(sip message) is<br>
read<br> only when the next message recieved by openser from the<br> SIP Server.<br> I would like to know anybody observed this issue. I have<br> compared the codebase of kamailio 1.4 and openser 1.1 but<br>
didin't find any diffrence for TLS.<br> I have looked at the API _tls_read() in openser which is<br> same<br> as that of kamilio.<br> Don't we need to use SSL_pending() after SSL_read() to<br>
verify<br> any buffer is left in the SSL layer ?<br> Do you think is it due to the poll method error? The poll<br> method we use is POLL_SIGIO_RT<br> Please let me know your comments.<br>
Thanks in advance.<br> Jijo<br><br><br> ------------------------------------------------------------------------<br><br> _______________________________________________<br>
Kamailio (OpenSER) - Users mailing list<br> <a href="mailto:Users@lists.kamailio.org" target="_blank">Users@lists.kamailio.org</a><br> <mailto:<a href="mailto:Users@lists.kamailio.org" target="_blank">Users@lists.kamailio.org</a>><br>
</div></div> <mailto:<a href="mailto:Users@lists.kamailio.org" target="_blank">Users@lists.kamailio.org</a> <mailto:<a href="mailto:Users@lists.kamailio.org" target="_blank">Users@lists.kamailio.org</a>>>
<div class="im"><br><br> <a href="http://lists.kamailio.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.kamailio.org/cgi-bin/mailman/listinfo/users</a><br> <a href="http://lists.openser-project.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.openser-project.org/cgi-bin/mailman/listinfo/users</a><br>
<br><br><br><br><br> ------------------------------------------------------------------------<br><br><br></div></blockquote></blockquote></div><br>