Re: [reSIProcate] WSS with AfterSocketCreationFunction causes core
Just some further things:
- I understand you have been trying WebSockets for some time, is this
the first time you tried WSS though? Or was WSS working successfully
before and now it is a regression?
- please also try testing with OpenSSL "s_client" or GnuTLS gnutls-cli -
for either of these tools, make sure you enable CRLF line endings,
enable TLSv1 and tell the tool about your root CA
e.g.
openssl s_client \
-connect test-ws.sip5060.net:443 \
-tls1 -crlf -debug -CAfile my-root-cert.pem
Once it connects, you should be able to paste a WebSocket message into
the console and get back some response.
If you have to try a new version of OpenSSL on RHEL/EPEL, you may not be
able to use the binary RPM from Fedora, I think you will need to
download the source package, tweak the spec file slightly and then
rpmbuild it.
On 24/06/13 22:03, Daniel Pocock wrote:
>
>
> I notice it refers to TLS error code 5 which is ERR_LIB_DH from
> openssl/err.h
>
> The next line seems to say the same thing:
>
> error:00000005:lib(0):func(0):DH lib
>
> I don't know the internals of TLS and OpenSSL in depth, but my first
> guesses:
>
> - it might be triggered by something in your cipher spec or other TLS
> settings - do you have any non-standard config for TLS init?
>
> - your server certificate - how did you generate it? Are you using a
> self-signed cert for testing?
>
> - your OpenSSL version - I think I remember you are on RHEL with EPEL -
> could you check the OpenSSL version and consider trying a version of
> OpenSSL from Fedora? EPEL doesn't always have the latest versions of
> things.
>
>
> On 22/06/13 20:07, Nathan Stratton wrote:
>> The fix allows reSIProcate to load the domain and certs and setup the WSS
>> port, however we are not able to establish a connection using JsSIP, just
>> to make sure it was not our issue or JsSIP, I also tested SIPML5 with repro
>> and get the the exact same error:
>>
>> INFO | 20130622-175949.893 | repro | RESIP:TRANSPORT | 140053934122752 |
>> ssl/TlsConnection.cxx:42 | Creating TLS connection for domain
>> proxy.exarionetworks.com [ V4 75.148.206.241:49755 WSS target
>> domain=unspecified mFlowKey=0 ] on 33
>> DEBUG | 20130622-175949.893 | repro | RESIP:TRANSPORT | 140053934122752 |
>> ssl/TlsConnection.cxx:49 | Trying to form TLS connection - acting as server
>> DEBUG | 20130622-175949.893 | repro | RESIP:TRANSPORT | 140053934122752 |
>> ssl/TlsConnection.cxx:82 | Not expecting client certificate
>> DEBUG | 20130622-175949.893 | repro | RESIP:TRANSPORT | 140053934122752 |
>> ConnectionBase.cxx:879 | Creating buffer for CONN_BASE: 0x7f60c8014950 [ V4
>> 75.148.206.241:49755 WSS target domain=unspecified mFlowKey=33 ]
>> INFO | 20130622-175949.893 | repro | RESIP:TRANSPORT | 140053934122752 |
>> ssl/TlsConnection.cxx:150 | TLS handshake starting (Server mode)
>> INFO | 20130622-175949.893 | repro | RESIP:TRANSPORT | 140053934122752 |
>> ssl/TlsConnection.cxx:161 | TLS connected
>> INFO | 20130622-175949.913 | repro | RESIP:TRANSPORT | 140053934122752 |
>> ssl/TlsConnection.cxx:244 | TLS connected
>> INFO | 20130622-175949.913 | repro | RESIP:TRANSPORT | 140053934122752 |
>> ssl/TlsConnection.cxx:587 | TLS sessions set up with TLSv1 TLSv1/SSLv3
>> AES256-SHA
>> DEBUG | 20130622-175949.913 | repro | RESIP:TRANSPORT | 140053934122752 |
>> ssl/TlsConnection.cxx:593 | No peer certificate in TLS connection
>> INFO | 20130622-175949.913 | repro | RESIP:TRANSPORT | 140053934122752 |
>> ssl/TlsConnection.cxx:275 | TLS handshake done for peer
>> ERR | 20130622-175949.913 | repro | RESIP:TRANSPORT | 140053934122752 |
>> ssl/TlsConnection.cxx:362 | Got TLS read ret=0 error=5
>> error:00000005:lib(0):func(0):DH lib
>> DEBUG | 20130622-175949.913 | repro | RESIP:TRANSPORT | 140053934122752 |
>> Connection.cxx:393 | Closing connection bytesRead=-1
>> DEBUG | 20130622-175949.913 | repro | RESIP:TRANSPORT | 140053934122752 |
>> ConnectionBase.cxx:104 | ConnectionBase::~ConnectionBase 0x7f60c8014950
>>
>>
>>
>> On Tue, Jun 18, 2013 at 1:32 PM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:
>>
>>> Fix seems fine to me. You've retained the transport() method in
>>> Transport.hxx so API users should not notice anything missing. I would
>>> remove the signatures from the other header files though to cleanup the
>>> code, instead of leaving them commented out.
>>>
>>> I like adding dummy certs.
>>>
>>> Scott
>>>
>>> On Tue, Jun 18, 2013 at 1:46 PM, Daniel Pocock <daniel@xxxxxxxxxxxxx>wrote:
>>>
>>>>
>>>>
>>>> I've just committed the variation of the fix removing virtual, but I'm
>>>> happy to revise this later if there are problems with it.
>>>>
>>>> I've also commented out the TLS and WSS parts of the test case because
>>>> they require certs - do you think we should include dummy certs in the
>>>> source tree or just script the openssl command to make them on the fly?
>>>> I've put the openssl command in a comment in the test case:
>>>>
>>>>
>>>> https://svn.resiprocate.org/viewsvn/resiprocate/main/resip/stack/test/testSocketFunc.cxx?view=markup#l37
>>>>
>>>>
>>>> On 18/06/13 19:14, Daniel Pocock wrote:
>>>>>
>>>>>
>>>>> On 18/06/13 15:13, Scott Godin wrote:
>>>>>> In InternalTransport::bind - we could access the transport type from
>>>> mTuple
>>>>>> instead - it is set in the constructor of each derived class before
>>>> bind is
>>>>>> called (from init()).
>>>>>>
>>>>>> if (mSocketFunc)
>>>>>> {
>>>>>> mSocketFunc(mFd, mTuple.getType(), __FILE__, __LINE__);
>>>>>> }
>>>>>
>>>>>
>>>>> Oddly enough, TlsTransport sets mTuple with this superclass constructor
>>>>> invocation (from TlsTransport.cxx):
>>>>>
>>>>> TlsBaseTransport(fifo, portNum, version, interfaceObj, security,
>>>>> sipDomain, sslType, transport(), socketFunc, compression,
>>>>> transportFlags, cvm, useEmailAsSIP)
>>>>>
>>>>>
>>>>> Notice it is calling the virtual function transport() to get the value?
>>>>>
>>>>> and in TcpTransport.cxx, it is slightly different, the constructor
>>>>> contains this call:
>>>>>
>>>>> mTuple.setType(transport());
>>>>>
>>>>> but that is still naughty too.
>>>>>
>>>>> What I'm now tempted to do is
>>>>>
>>>>> a) remove the virtual keyword from transport()'s prototype, and replace
>>>>> it with { return mTuple.getType(); }
>>>>>
>>>>> b) change all other superclass constructor invocations to have hardcoded
>>>>> transport IDs to that (a) doesn't lead to unpleasant recursion
>>>>>
>>>>>
>>>>>>
>>>>>> Scott
>>>>>>
>>>>>> On Mon, Jun 17, 2013 at 4:48 PM, Daniel Pocock <daniel@xxxxxxxxxxxxx>
>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 15/06/13 22:36, Vladimir Pavluk wrote:
>>>>>>>> Hi Daniel,
>>>>>>>>
>>>>>>>>> I've had a quick look at this
>>>>>>>>>
>>>>>>>>> I notice that in repro we call SipStack::addTransport( .. ) and we
>>>> don't
>>>>>>>>> set mSocketFunc
>>>>>>>>>
>>>>>>>>> In your test case, you use DialogUsageManager::addTransport( .. )
>>>> which
>>>>>>>>> just proxies the call to mStack.addTransport
>>>>>>>>>
>>>>>>>>> Do you definitely need to use the dum variation? I think it may be
>>>>>>>>> useful to have this test case under resip/stack and avoid the dum
>>>>>>>>> dependency if possible.
>>>>>>>> No matter whichever we use (and I think we actually use
>>>>>>>> SipStack::addTransport( .. ) in our app), it always cores.
>>>>>>>>
>>>>>>>>> Would you know if it cores for TLS, or only for WSS?
>>>>>>>> It does core for both (you can build the test program and make sure).
>>>>>>>>
>>>>>>>>> Could you possibly share a stack trace? You can exclude those
>>>> parts of
>>>>>>>>> the stack that are in your own code.
>>>>>>>> It aborts with "pure virtual function call" right on the line where
>>>> it
>>>>>>>> calls AfterSocketCreationFunction (we'll get back to you with more
>>>>>>>> precise stack trace).
>>>>>>>>
>>>>>>>
>>>>>>> I've adapted the test case and confirmed there is an issue (see below)
>>>>>>>
>>>>>>> The root cause is that it calls a pure virtual function,
>>>>>>> Transport::transport() during construction of an object of class
>>>>>>> TlsTransport
>>>>>>>
>>>>>>> I can confirm that this is definitely bad behavior. I hacked around
>>>> in
>>>>>>> this code a little bit to enable support for WSS, but not at this low
>>>>>>> level where the virtual function exists, so I don't believe it is a
>>>>>>> regression.
>>>>>>>
>>>>>>> Oddly, creating a TcpTransport invokes the same code path, it doesn't
>>>>>>> trigger this problem, but it is not safe for it to rely on the virtual
>>>>>>> function call during construction either.
>>>>>>>
>>>>>>> One option that comes to mind is that we can pass the transport type
>>>>>>> down from the constructor to make sure it is initialized. The other
>>>>>>> option is to defer initialisation until after construction.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> $ libtool --mode=execute gdb resip/stack/test/testSocketFunc
>>>>>>> GNU gdb (GDB) 7.4.1-debian
>>>>>>> Copyright (C) 2012 Free Software Foundation, Inc.
>>>>>>> License GPLv3+: GNU GPL version 3 or later
>>>>>>> <http://gnu.org/licenses/gpl.html>
>>>>>>> This is free software: you are free to change and redistribute it.
>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type "show
>>>> copying"
>>>>>>> and "show warranty" for details.
>>>>>>> This GDB was configured as "x86_64-linux-gnu".
>>>>>>> For bug reporting instructions, please see:
>>>>>>> <http://www.gnu.org/software/gdb/bugs/>...
>>>>>>> Reading symbols from
>>>>>>>
>>>>>>>
>>>> /home/daniel/ws/resiprocate/resiprocate-trunk.git/resip/stack/test/.libs/lt-testSocketFunc...done.
>>>>>>> (gdb) run
>>>>>>> Starting program:
>>>>>>>
>>>>>>>
>>>> /home/daniel/ws/resiprocate/resiprocate-trunk.git/resip/stack/test/.libs/lt-testSocketFunc
>>>>>>>
>>>>>>> [Thread debugging using libthread_db enabled]
>>>>>>> Using host libthread_db library
>>>> "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>>>>>> INFO | 20130617-221954.755 | | RESIP:DNS | 140737353914144 |
>>>>>>> dns/AresDns.cxx:394 | DNS initialization: using c-ares v1.9.1
>>>>>>> INFO | 20130617-221954.755 | | RESIP:DNS | 140737353914144 |
>>>>>>> dns/AresDns.cxx:403 | DNS initialization: found 1 name servers
>>>>>>> INFO | 20130617-221954.755 | | RESIP:DNS | 140737353914144 |
>>>>>>> dns/AresDns.cxx:409 | name server: 192.168.1.2
>>>>>>> INFO | 20130617-221954.760 | | RESIP:TRANSPORT | 140737353914144 |
>>>>>>> Connection.cxx:38 | Connection::Connection: new connection created to
>>>>>>> who: [ V4 0.0.0.0:0 UNKNOWN_TRANSPORT target domain=unspecified
>>>>>>> mFlowKey=0 ]
>>>>>>> pure virtual method called
>>>>>>> terminate called without an active exception
>>>>>>>
>>>>>>> Program received signal SIGABRT, Aborted.
>>>>>>> 0x00007ffff6185475 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>>>>>>> (gdb) bt
>>>>>>> #0 0x00007ffff6185475 in raise () from
>>>> /lib/x86_64-linux-gnu/libc.so.6
>>>>>>> #1 0x00007ffff61886f0 in abort () from
>>>> /lib/x86_64-linux-gnu/libc.so.6
>>>>>>> #2 0x00007ffff69da89d in __gnu_cxx::__verbose_terminate_handler() ()
>>>>>>> from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>>>>>>> #3 0x00007ffff69d8996 in ?? () from
>>>>>>> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>>>>>>> #4 0x00007ffff69d89c3 in std::terminate() () from
>>>>>>> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>>>>>>> #5 0x00007ffff69d94df in __cxa_pure_virtual () from
>>>>>>> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>>>>>>> #6 0x00007ffff7ab7d3e in resip::InternalTransport::bind
>>>> (this=0x696e80)
>>>>>>> at InternalTransport.cxx:147
>>>>>>> #7 0x00007ffff7afde98 in resip::TcpBaseTransport::init
>>>> (this=0x696e80)
>>>>>>> at TcpBaseTransport.cxx:82
>>>>>>> #8 0x00007ffff7b53559 in resip::TlsBaseTransport::TlsBaseTransport
>>>>>>> (this=0x696e80, fifo=..., portNum=<optimized out>, version=<optimized
>>>>>>> out>, interfaceObj=..., security=...,
>>>>>>> sipDomain=..., sslType=resip::SecurityTypes::TLSv1,
>>>>>>> transportType=resip::TLS, socketFunc=0x401230
>>>>>>> <afterSocketCreationFunction(int, int, char const*, int)>,
>>>> compression=...,
>>>>>>> transportFlags=0, cvm=resip::SecurityTypes::None,
>>>>>>> useEmailAsSIP=false) at ssl/TlsBaseTransport.cxx:46
>>>>>>> #9 0x00007ffff7b564a3 in resip::TlsTransport::TlsTransport
>>>>>>> (this=0x696e80, fifo=..., portNum=<optimized out>, version=<optimized
>>>>>>> out>, interfaceObj=..., security=..., sipDomain=...,
>>>>>>> sslType=resip::SecurityTypes::TLSv1, socketFunc=0x401230
>>>>>>> <afterSocketCreationFunction(int, int, char const*, int)>,
>>>>>>> compression=..., transportFlags=0, cvm=resip::SecurityTypes::None,
>>>>>>> useEmailAsSIP=false) at ssl/TlsTransport.cxx:35
>>>>>>> #10 0x00007ffff7af75f2 in resip::SipStack::addTransport
>>>>>>> (this=0x7ffffffb6660, protocol=resip::TLS, port=5061,
>>>> version=resip::V4,
>>>>>>> stun=resip::StunDisabled, ipInterface=...,
>>>>>>> sipDomainname=..., privateKeyPassPhrase=...,
>>>>>>> sslType=resip::SecurityTypes::TLSv1, transportFlags=0,
>>>>>>> cvm=resip::SecurityTypes::None, useEmailAsSIP=false) at
>>>> SipStack.cxx:359
>>>>>>> #11 0x000000000040105f in main () at testSocketFunc.cxx:41
>>>>>>> _______________________________________________
>>>>>>> resiprocate-devel mailing list
>>>>>>> resiprocate-devel@xxxxxxxxxxxxxxx
>>>>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>>>>
>>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> resiprocate-devel mailing list
>>> resiprocate-devel@xxxxxxxxxxxxxxx
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>
>>
>>
>>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel