Hi Christophe!

Can you please make the following test (with force_tcp_alias):
A*B register with TLS
A calls B
B sends 180 ringing, but does not pick up
kill client B (maybe there is a problem if the TLS connection gets lost during an ongoing transaction)
A cancels the call

thanks
klaus




Christophe Irles wrote:
Klauss,

Very good news with force_tcp_alias(), openser doesn't crash ! Even when the
client 2 un-register or is killed.

Please find in the attached ZIP file, openser and network traffic dump
without the used of the function "force_tcp_alias(") in two use case:
- client 2 unregistered
- client 2 is killed

Hope this helps,
Christophe

PS: If you want the miniSIP binary to reproduce the pb, please tell me (for
windows only ...)

-----Message d'origine-----
De : Klaus Darilion [mailto:[EMAIL PROTECTED] Envoyé : vendredi 24 novembre 2006 11:31
À : Christophe Irles
Cc : 'OpenSER_DEV'
Objet : Re: [Devel] Crash with openser 1.1.0 and TLS clients

Hi!

Can you please repeat this test with force_tcp_alias() (just after
route[]{).

This should cause only one connection to client 2.

Then kill again client 2. It will be interesting if there is again a crash.

thanks
klaus



Christophe Irles wrote:
Hi Klaus,

Please find in the attached file the network trace in this scenario:
Client 1 ([EMAIL PROTECTED]) registers on openser in SIP-TLS Then client 2 ([EMAIL PROTECTED]) registers too Client 1 calls client 2 Client 2 is killed => openser crash

Regards,
Christophe

-----Message d'origine-----
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Christophe Irles Envoyé : vendredi 24 novembre 2006 10:21 À : 'Klaus Darilion'
Cc : 'OpenSER_DEV'
Objet : RE: [Devel] Crash with openser 1.1.0 and TLS clients

Hi Klaus,

Thank for your inputs.

Server side - version:
        openser-1.1.0-tls
        openssl-0.9.7f-7.10

Client side - version:
        minisip r2891
        openssl-0.9.8b


About the buggy User Agent, to be sure to understand well, the pb comes from the line 55.
The ACK must be:
ACK sip:[EMAIL PROTECTED]:5060;transport=TCP SIP/2.0 Instead of:
ACK sip:[EMAIL PROTECTED]:5060 SIP/2.0 Is it correct ? I will send a mail to the minisip development team.

TLS Dump analysis:
- 3 SSL connections: I thought openssl will reuse the previous connections and not create a new one to send the INVITE to the second client. In this situtation the client 2 is never reached if he is behind a
NAT, isn't it ?
The problem is the same in TCP.

As soons as possible I will test again as you suggest with the all
traffic.
Thanks,
Christophe

-----Message d'origine-----
De : Klaus Darilion [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 24 novembre 2006 08:49 À : Christophe Irles Cc :
'OpenSER_DEV'
Objet : Re: [Devel] Crash with openser 1.1.0 and TLS clients

Hi Christophe!

Can you tell me the exact versions you use? openser, minisip, openssl (both o nminisip PCs and openser PC).

thanks
klaus


Christophe Irles wrote:
Ok I create again dump files with exactly the same scenario. I test them with wireshark successfully. Pb seems to come from the "txt"
extension.
The first dump file is based on SIP over TLS and the second is based on SIP over TCP.

As I said previously when using TLS, openser crash but not in TCP (same openser config, just a restart between each test)

I notice in these two dump files something strange: some packets send by openser are in UDP ! When they are send, the header "Record Route" is composed of two lines: the last with the correct transport set (TCP or TLS) but the first one wihtout this information ...

Hope this helps,
Christophe

-----Message d'origine-----
De : Klaus Darilion [mailto:[EMAIL PROTECTED]
Envoyé : mardi 21 novembre 2006 17:35 À : Christophe Irles Cc : 'OpenSER_DEV'
Objet : Re: [Devel] Crash with openser 1.1.0 and TLS clients

Hi!

I can't open the dump in ethereal. Maybe it was broken because it was named .txt. Can you please resend it as .cap? (or zip)

regards
klaus

Christophe Irles wrote:
Hi Klauss,

Since ssldump is working not so well I used this option in my config
file:
tls_ciphers_list="NULL"
I used tcpdump to have SIP messages as follow: tcpdump -vv -s 2000 -i eth0 port 5061 -w dump.txt (cf. attached file)

In this file, you will find this scenario:
- Device A (known as uri [EMAIL PROTECTED]) registered first - Device B (known as uri [EMAIL PROTECTED]) registered in second
- A calls B => communications is good (media is working)
- B hangup
- B unregistered => openser crash !

This scenario is the same as the test 3 describe in my previous mail
(cf.
below)

If you need more explanations or more debug output, please tell me.

I'm using openser-1.1.0-tls

Hope this helps,
Christophe
-----Message d'origine-----
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Christophe Irles Envoyé : vendredi 17 novembre 2006 17:24 À
: 'Klaus Darilion'
Cc : 'OpenSER_DEV'
Objet : RE: [Devel] Crash with openser 1.1.0 and TLS clients

Hi Klaus,

The context is: a minisip called A (uri:[EMAIL PROTECTED]) with TLS calls another minisip called B (uri:[EMAIL PROTECTED]) with TLS.
Always A registered first and B in second (the order is important)

Test 1:
A and B unregistered => no crash
I restart openser and minisip A and B devices (to be sure to have the same configuration in each test)

Test 2:
A calls B. Communication is good. A or B hang up (I test the both) A unregistered => openser is still working B unregistered => openser crash
!
I restart openser and minisip A and B devices

Test 3:
A calls B. Communication is good. A or B hang up (I test the both) B unregistered => openser crash !
I restart openser and minisip A and B devices

Test 4:
A calls B. Communication is good. A or B hang up (I test the both) B calls A. Communication is good. A or B hang up (I test the both) Calls made several times => Communications are always good A unregistered => openser is still working B unregistered => openser crash
!
I restart openser and minisip A and B devices

Test 5:
A calls B. Communication is good. A or B hang up (I test the both) B calls A. Communication is good. A or B hang up (I test the both) Calls made several times => Communications are good B unregistered =>
openser crash !
About ssldump, I need to compile it including the lib pcap. As soon as possible I will send you the entire dump.

Please find below some comments about some of your previous remarks.

Thanks,
Regards,
Christophe

-----Message d'origine-----
De : Klaus Darilion [mailto:[EMAIL PROTECTED]
Envoyé : mardi 14 novembre 2006 18:51 À : Christophe Irles Cc : OpenSER_DEV Objet : Re: [Devel] Crash with openser 1.1.0 and TLS clients

Christophe Irles wrote:
Hello,
Hi Christoph!

Who is closing the SSL connection - openser or minisip?
[Chris] minisip is closing the connection.

There are several things which look very strange:

Extract of the log file:
        19(26390) tls_close: Closing SSL connection
        19(26390) tls_update_fd: New fd is 42
        19(26390) INFO: signal 13 received
Why is there a signal 13 (SIGPIPE) ?
[Chris] I don't know ... But this occurs, each time the second minisip unregistered from openser

19(26390) tls_shutdown: First phase of 2-way handshake completed succesfuly
Looks like openser shuts down the SSL connection [Chris] Actually it's minisip

        19(26390) tls_tcpconn_clean: Entered
        19(26390) handle_tcp_child: reader response= b61c3f28, -2 from 2
Is openser reading from the closed SSL connection [Chris] I don't know
...
I'm compiling ssldump in order to have a dump with all packets

        19(26390) tcpconn_destroy: destroying connection 0xb61c3f28, flags
0002
        19(26390) tls_close: Closing SSL connection
Is this the same TLS connection which will bel closed again?
[Chris] It's the second one created by the other minisip device

        19(26390) tls_update_fd: New fd is 44
        19(26390) INFO: signal 13 received
19(26390) tls_shutdown: First phase of 2-way handshake completed succesfuly
If it would be the same SSL connection which will be closed here, there should not bee this message. Thus, I suspect there is another SSL connection open which will be closed here?
[Chris] It's the second one created by the other minisip device

        19(26390) tls_tcpconn_clean: Entered
*** glibc detected *** openser: free(): invalid pointer: 0x08788a38
Christophe - can you please provide a tcpdump (capture file) and ssldump too? If its big, send it to me privately.
[Chris] I'm working on it

regards
klaus


***
        ======= Backtrace: =========
        /lib/libc.so.6[0x1741e0]
        /lib/libc.so.6(__libc_free+0x77)[0x17472b]
        /lib/libssl.so.5(kssl_ctx_free+0x82)[0x9c8317]
        /lib/libssl.so.5(SSL_free+0x165)[0x9be03e]
        openser(tls_tcpconn_clean+0x46)[0x80e2cd6]
        openser(_tcpconn_rm+0x2f0)[0x8093bd0]
        openser[0x80943dc]
        openser[0x8098e63]
        openser[0x8097461]
        openser[0x8099a63]
        openser(tcp_main_loop+0x55b)[0x809a1db]
        openser(main_loop+0x8e0)[0x806cd20]
        openser(main+0x16bb)[0x806e77b]
        /lib/libc.so.6(__libc_start_main+0xdf)[0x125d7f]
        openser[0x8051111]
        ======= Memory map: ========
        00111000-00234000 r-xp 00000000 fd:02 289199     /lib/libc-2.3.6.so
        00234000-00236000 r-xp 00122000 fd:02 289199     /lib/libc-2.3.6.so


        Is this problem already corrected in the HEAD version of openSER ?
Is anyone has the same problem with TLS clients and openSER 1.1.0 ?

Thanks,
Christophe





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

_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
--
Klaus Darilion
nic.at


_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
--
Klaus Darilion
nic.at

--
Klaus Darilion
nic.at


_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel


--
Klaus Darilion
nic.at


--
Klaus Darilion
nic.at


_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel

Reply via email to