27 Feb
2019
27 Feb
'19
2:26 p.m.
Hello,
I believe this issue is related -
https://github.com/kamailio/kamailio/issues/1172. We encountered the
problem before and the solution is to link kamailio-tls-modules with
libssl1.0.X instead of libssl1.1.
On 27/02/2019 13:23, Jurijs Ivolga wrote:
Hi,
Just to add that in my case I had a problem when after some period of
time with a lot of TLS clients(100k+) I got a lot of TCP connections
in CLOSE_WAIT state. When connections in CLOSE_WAIT state hit more
then 1k, then kamailio stopped to receive traffic via TLS,
nevertheless UDP at same time worked fine. From my point of view it
looked like there was issue somewhere on Linux side, cause Kamailio
never got anything... At least this is what I remember... I still plan
to work on it someday. :) And if I will find out, I'll let you know.
Jurijs
On Wed, Feb 27, 2019 at 1:13 PM Kristijan Vrban <vrban.lkml(a)gmail.com
<mailto:vrban.lkml@gmail.com>> wrote:
when is strace to the kamailio process that is attached to the tcp
port. it get sporadic this:
[], 46, 5000) = 0
epoll_wait(17, [{EPOLLIN, {u32=2692971064, u64=139924137540152}}],
46, 5000) = 1
accept(14, {sa_family=AF_INET, sin_port=htons(59766),
sin_addr=inet_addr("xxx.xx.xxx.xxx")}, [28->16]) = 275
fcntl(275, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(275, F_SETFL, O_RDWR|O_NONBLOCK) = 0
epoll_ctl(17, EPOLL_CTL_ADD, 275, {EPOLLIN|EPOLLRDHUP,
{u32=2692977328, u64=139924137546416}}) = 0
epoll_wait(17, [{EPOLLIN, {u32=2692977328, u64=139924137546416}}],
47, 5000) = 1
epoll_ctl(17, EPOLL_CTL_DEL, 275, 0x7ffdae44ee4c) = 0
recvmsg(53, {msg_namelen=0}, MSG_DONTWAIT) = -1 EAGAIN (Resource
temporarily unavailable)
recvfrom(56, 0x7ffdae44ed90, 16, MSG_DONTWAIT, NULL, NULL) = -1 EAGAIN
(Resource temporarily unavailable)
sendmsg(56, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\210ku\230B\177\0\0", iov_len=8}], msg_iovlen=1,
msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET,
cmsg_type=SCM_RIGHTS, cmsg_data=[275]}], msg_controllen=20,
msg_flags=0}, 0) = 8
epoll_wait(17,
But that's all, no further processing by kamailio.
Am Mi., 27. Feb. 2019 um 11:53 Uhr schrieb Kristijan Vrban
<vrban.lkml(a)gmail.com <mailto:vrban.lkml@gmail.com>>:
Hi kamailios,
i have a creepy situation with v5.2.1 stable Kamilio. After a day or
so, Kamailio stop to process incoming SIP traffic via TCP. The
incoming TCP network packages get TCP-ACK from the OS (Debian 9,
4.18.0-15-generic-Linux) but Kamailio does not show any
processing for
the SIP-Traffic incoming via TCP. No logs,
nothing. While
traffic via
UDP is working just totally fine.
When i look via command "netstat -ntp" is see, that the Recv-Q get
bigger and bigger. e.g.:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program
name tcp 4566 0 172.17.217.12:5060 <http://172.17.217.12:5060>
xxx.xxx.xxx.xxx:57252 ESTABLISHED
31347/kamailio
After Kamailio restart, all is working fine again for a day. We have
maybe 10-20 devices online via TCP and low call volume (1-2 call per
minute). The only settings for tcp we have is "tcp_delayed_ack=no"
How to could we debug this situation? Again, no error, no warings in
the log. Just nothing.
Kristijan
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users