[SR-Users] TLS module not initialized in 4.3.3, worked in 4.1.5

Sebastian Damm damm at sipgate.de
Fri Nov 13 14:16:18 CET 2015


Hi Daniel,

yes, we see this message.

Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG: <core>
[sr_module.c:959]: init_mod(): tls
Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: WARNING: tls
[tls_mod.c:287]: mod_init(): tls support is disabled (set enable_tls=1 in
the config to enable it)
Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG: <core>
[main.c:2520]: main(): Expect (at least) 30 kamailio processes in your
process list

Okay, then the message right at the beginning probably just irritated us.
But as you can see, we have set enable_tls=1 (previously and in the
documentation it was set to 'yes'), but it still doesn't get enabled.

Any more ideas?

Best Regards,
Sebastian

On Fri, Nov 13, 2015 at 12:32 PM, Daniel-Constantin Mierla <
miconda at gmail.com> wrote:

> Hello,
>
> if you start with debug=3, do you see the message:
>
> DEBUG: <core> [sr_module.c:959]: init_mod(): tls
>
> Cheers,
> Daniel
>
>
> On 13/11/15 12:17, Sebastian Damm wrote:
>
> Hello,
>
> we just updated one kamailio server from 4.1.5 to 4.3.3, and although the
> config file is correct and kamailio starts up, it doesn't initialize TLS
> and says " tls support enabled, but no tls engine  available (forgot to
> load the tls module?)"
>
> In the log I see:
>
> Old shutdown (last lines):
> Nov 13 11:44:38 lasola /usr/sbin/kamailio[15890]: DEBUG: <core>
> [mem/shm_mem.c:235]: shm_mem_destroy(): destroying the shared memory lock
> Nov 13 11:44:41 lasola /usr/sbin/kamailio[14818]: ERROR: <core>
> [tcp_read.c:271]: tcp_read_data(): error reading: Connection reset by peer
> (104)
> Nov 13 11:44:41 lasola /usr/sbin/kamailio[14818]: ERROR: <core>
> [tcp_read.c:1296]: tcp_read_req(): ERROR: tcp_read_req: error reading
>
> New startup (first lines):
> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG: <core>
> [daemonize.c:583]: set_core_dump(): core dump limits set to
> 18446744073709551615
> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: WARNING: <core>
> [main.c:2475]: main(): tls support enabled, but no tls engine  available
> (forgot to load the tls module?)
> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: WARNING: <core>
> [main.c:2476]: main(): disabling tls...
> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG: <core>
> [async_task.c:88]: async_task_init(): start initializing asynk task
> framework
> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG: <core>
> [sr_module.c:959]: init_mod(): xmlrpc
> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG: <core>
> [sr_module.c:689]: find_mod_export_record(): find_export_record: found
> <bind_sl> in module sl [/usr/lib/x86_64-linux-gnu/kamailio/modules//sl.so]
> Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG: <core>
> [sr_module.c:959]: init_mod(): sl
>
> In our config file we have the following lines for TLS (pretty late, after
> all other module loading and after most parameters):
>
> #!ifdef ENABLETLS
> loadmodule "tls.so"
>
> modparam("tls", "private_key", "/etc/ssl/private/my.kamailio-key.pem")
> modparam("tls", "certificate", "/etc/ssl/certs/my.kamailio.crt")
> #!ifdef TLS_CA_CHAIN
> # Maybe we want to use a chain to the CA
> modparam("tls", "ca_list", "/etc/ssl/certs/my.ca-bundle.crt")
> #!endif
> enable_tls=1
> listen=tls:1.2.3.4:5061
> #!endif
>
> After starting up, kamailio listens on port 5060, but not on port 5061. In
> version 4.1.1, this config worked without a problem.
>
> Has anybody seen this before? the tls module is there and available, it
> doesn't say anything about "cannot load module", and it is only a warning
> message. I'm also wondering, why this message is the first after starting
> the server. From config I would expect that sl, tm and all the other
> modules should be initialized before tls.
>
> Best Regards,
> Sebastian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20151113/3767b19e/attachment.html>


More information about the sr-users mailing list