I try to workout if - currently it would work, or - where and how to debug more:
I face - 2 interfacec - public internet (so, TLS + sRTP) is desired
and private - old infrastructure - i mus only use plain RTP
172.23.9.70 - private ip - from this endpoint of kamailio and rtpengine should send only basic RTP
172.23.210.75:5060 private - target for kamailio
1.2.3.24 obfuscated public IP (TLS + sRTP required)
kamailio 5.4.4 (x86_64/linux)
rtpengine -v Version: 11.1.1.4-1~bpo11+1
all i do …
[View More]is:
if (proto==TLS) {
rtpengine_manage("RTP/AVP ICE=remove replace-session-connection replace-origin pad-crypto ptime=20 codec-transcode-PCMA record-call=on allow-transcoding direction=external direction=internal record-call=on");
} else if ($ru =~ "transport=tls") {
rtpengine_manage("DTLS=on SRTP AVPF ICE=remove replace-session-connection replace-origin pad-crypto ptime=20 codec-transcode-PCMA record-call=on allow-transcoding direction=internal direction=external record-call=on media-address=1.2.3.24");
}
# 1.2.3.24 obfuscated public IP
172.23.210.75:5060 is in dispatch.cfg, as '11'
route[SBC_CORE] {
append_hf("X-My-SRTP: removed31337\r\n");
### i see this text in invtes from kamailio 172.23.9.70 towards 172.23.210.75:5060
### i see only RTP, so as expected
if (!ds_select_dst("11", "0")) {
xwarn("I:$var(i) DROP(DOWN!) FWD:$rm [$fU->$tU] [SBCVIP] to $du\n");
sl_send_reply("503", "Destination down");
exit;
}
what i did:
certificate is a paid one (the public party needs it)
TLS works
i deleted - entries in (not kamailo) cryptosuite that caused this:
13:08:05 localhost rtpengine[15140]: ERR: [51ad8758-b64d-4d2f-9fd0-41d03a38f74d]: [core] Failed to parse a=crypto attribute, ignoring: unknown crypto suite
Tried to search for any "ready" examples for this - only found old threads and - that this should be possible, but - no example for woking config.
what i see:
Jan 19 19:00:57 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000038 sec
Jan 19 19:00:58 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000036 sec
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] Closing call due to timeout
Jan 19 19:00:59 localhost rtpengine[17301]: DEBUG: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] Redis delete_async=0
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] Final packet stats:
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- Tag 'JVR5LTs', created 60:00 ago for branch ''
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- subscribed to ''
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- subscription for ''
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] ------ Media #1 (audio over RTP/SAVP) using unknown codec
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --------- Port 1.2.3.24:30136 <> 52.129.106.28:17030, SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --------- Port 1.2.3.24:30137 <> 52.129.106.28:17031 (RTCP), SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- Tag '', created 60:00 ago for branch ''
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- subscribed to 'JVR5LTs'
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- subscription for 'JVR5LTs'
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] ------ Media #1 (audio over RTP/AVP) using unknown codec
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --------- Port 172.23.9.70:30014 <> :0 , SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --------- Port 172.23.9.70:30015 <> :0 (RTCP), SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] Moved metadata file "/var/spool/rtpengine/tmp/rtpengine-meta-c17bab16-5eea-492e-b1c4-ac9387f3e265-7003946f152c6c8d.tmp" to "/var/spool/rtpengine/metadata"
Jan 19 19:00:59 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000828 sec
Jan 19 19:01:00 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000053 sec
route(SBC_CORE);
maybe any hint or - someone has working exmaple of kamailio config + rtpengine settings ?
i use only userspace daemon rtp forwarding (this is a test, dont need any performance here)
Thanks,
[View Less]
Hi all,
We're hitting an issue while integrating secure websockets in our existing SIP infrastructure using Kamailio.
When the registration comes in, it causes an entry in our AOR table, with ";transport=ws" appended.
When we want to send a message to this client (using t_relay), kamailio seems to take 'ws' as being *unsecure* websockets. In turn, this makes Kamailio try to send out the message using a TCP listener - while it should have picked the TLS listener.
There are some remarks in the …
[View More]sources about ws vs. wss, so i'm struggling to figure out where things go wrong. I've also created github issue #3340 with more details.
Any help would be appreciated. If this turns out to be a Kamailio bug, i'm happy to provide a patch.
[View Less]
Hello,
How can I setup Kamailio for failover on LCR ?
Currently my Kamailio 4.x works with lcr but doesn’t care about gateway status. I mean that if a gateway match rule , it sends the call through without check if the gateway is available an never try the next one if the first fail.
I’ve tried to implement inactivate_gw()
But I received error that lcr_id_avp is not defined. I’ve added the parameters to lcr module for Ping and enable defunc but I’m unable to get it working.
By the way I ‘…
[View More]ve trad that defunct is not a good practice as hacker sending malformed sip header can throw down the gateway.
So what is the good and working way to setup outbound call failover ?
Regards
Sebastien
[View Less]
Hello
We are currently using EVAPI to push messages into kamailio from a go app.
For the most part ift works without problems, messages get delivered into
the event route and we use it to update presence status.
Recently we started noticing delays on the evapi processing. After 500
requests x min the pid corresponding to the EVAPI dispatcher gets pegged at
100% CPU and processing of requests starts slowing down until in some cases
the connection just drops and we have to reconnect.
After that …
[View More]pid drops, the dispatcher goes back to working.
Unfortunately the error we get back is very generic and is not telling us
much
logger.go:39: ERR
Handler returned error (write tcp 127.0.0.1:48448->127.0.0.1:8228:
write: broken pipe)
This only happens on prod servers and with high load which makes it hard to
debug. There is no other slowness or increase of traffic or drop SIP
traffic, only evapi dispatcher at 100% and the EVAPI workers on idle.
Curious if anyone has run into this issue. We've tried different versions
(5.4 , 5.5 and 5.6) and it happens on all of them.
Any feedback appreciated !
Thanks !
[View Less]
Hello,
https://www.kamailio.org/docs/modules/devel/modules/tls says:
For OpenSSL (libssl) v1.1.x, it is required to preload 'openssl_mutex_shared' library shipped by Kamailio. For more details see
'src/modules/tls/utils/openssl_mutex_shared/README.md'.
'src/modules/tls/utils/openssl_mutex_shared/README.md says:
**IMPORTANT: the workaround of using this preloaded shared library is no longer
needed starting with Kamailio v5.3.0-pre1 (git master branch after September 14, 2019).
The code of …
[View More]this shared library has been included in the core of Kamailio and the
same behaviour is now achieved by default.**
This is a shared library required as a short term workaround for using Kamailio
with OpenSSL (libssl) v1.1. It has to be pre-loaded before starting Kamailio.
In v1.1, libssl does not allow setting custom locking functions, using internally
pthread mutexes and rwlocks, but they are not initialized with process shared
option (PTHREAD_PROCESS_SHARED), which can result in blocking Kamailio worker
processes.
Is preloading openssl_mutex_shared necessary for Kamailio 5.6 or is it not necessary?
If it is not necessary, why isn’t it removed from the source code?
Greetings
Дилян
[View Less]
Hello,
when I connect to Kamailio over websocket, according to the websocket protocol K. sends “HTTP/1.1 101 Switching Protocols” and K. logs:
17(18) DEBUG: websocket [ws_handshake.c:179]: ws_handle_handshake(): found Upgrade: websocket
17(18) DEBUG: websocket [ws_conn.c:195]: wsconn_add(): connection id [14]
17(18) DEBUG: websocket [ws_conn.c:213]: wsconn_add(): new wsc => […
[View More]0x7fcad6e10160], ref => [0]
17(18) DEBUG: websocket [ws_conn.c:233]: wsconn_add(): added to conn_table wsc => [0x7fcad6e10160], ref => [1]
17(18) DEBUG: sl [sl.c:310]: send_reply(): reply in stateless mode (sl)
17(18) DEBUG: <core> [core/msg_translator.c:162]: check_via_address(): (22.222.222.222, 22.222.222.222, 0)
17(18) DEBUG: <core> [core/tcp_main.c:1644]: _tcpconn_find(): found connection by id: 14
17(18) DEBUG: <core> [core/tcp_main.c:2528]: tcpconn_send_put(): send from reader (18 (17)), reusing fd
17(18) DEBUG: <core> [core/tcp_main.c:2763]: tcpconn_do_send(): sending...
17(18) DEBUG: <core> [core/tcp_main.c:2796]: tcpconn_do_send(): after real write: c= 0x7fcad6da7b38 n=238 fd=9
17(18) DEBUG: <core> [core/tcp_main.c:2797]: tcpconn_do_send(): buf=
17(18) DEBUG: <core> [core/parser/parse_fline.c:255]: parse_first_line(): bad request first line
17(18) DEBUG: <core> [core/parser/parse_fline.c:258]: parse_first_line(): at line 0 char 22:
17(18) DEBUG: <core> [core/parser/parse_fline.c:264]: parse_first_line(): parsed so far: HTTP/1.1 101 Switching
17(18) ERROR: <core> [core/parser/parse_fline.c:271]: parse_first_line(): parse_first_line: bad message (offset: 22)
17(18) DEBUG: <core> [core/parser/msg_parser.c:675]: parse_msg(): invalid message
17(18) ERROR: <core> [core/parser/msg_parser.c:749]: parse_msg(): ERROR: parse_msg: message=<HTTP/1.1 101 Switching Protocols
Sia: SIP/2.0/TLS 22.222.222.222:33776
Sec-WebSocket-Protocol: sip
Upgrade: websocket
Connection: upgrade
Sec-WebSocket-Accept: NeswoJX5ZQp7ER8hTKM5B3a3HDQ=
Content-Length: 0
>
17(18) ERROR: <core> [core/msg_translator.c:3256]: build_sip_msg_from_buf(): parsing failed
17(18) DEBUG: app_lua [app_lua_api.c:1924]: sr_kemi_lua_exit(): script exit call
17(18) DEBUG: app_lua [app_lua_api.c:789]: app_lua_run_ex(): ksr error call from Lua: ~~ksr~exit~~
17(18) DEBUG: app_lua [app_lua_mod.c:164]: sr_kemi_config_engine_lua(): execution of route type 513 with name [ksr_xhttp_event] returned
1
22.222.222.222 is my public address (the address of my router). It is not the IP-address of Kamailio.
While the returned address is not parseable in terms of SIP, it is a valid Websocket-answer message. This valid condition triggers logging an error,
but does not represent an error condition.
How can I avoid that the above non-error is logged as an error?
Thanks for your feedback
Дилян
[View Less]
Hi all,
I'm doing some experimenting with kamailio -- currently looking for a replacement of our existing (aging) SIP infrastructure.
One of the experiments that I'm doing is testing the dialog module's dlg_set_timeout function. The issue that I'm having is while I do see that kamailio is generating a BYE, and sends it out to the B-leg of the call properly, the BYE goes to a private address on the A-leg.
To Note:
- kamailio is behind a NAT (on AWS)
- both UA endpoints are remote and are both …
[View More]behind a NAT
- Not sure if this matters, but I do have the topos module enabled, though I see the same behavior regardless if it's enabled or not.
- Have set nathelpers (fix_nated_register, fix_nated_contact,etc...) which helps calls between endpoints and the endpoints themselves are able to send/receive BYEs when they generate them; however doesn't seem to help if kamailio locally generates the BYE.
The only thing I do see within my logs is when the BYE is being generated by kamailio, it uses the private IP of my UA and not public for the caller. Callee, the public address is referenced. If more information is needed, please let me know (just didn't want to spam my script/ logs). Thanks.
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: dialog [dlg_req_within.c:399]: send_bye(): sending BYE to caller
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:458]: t_uac_prepare(): next_hop=<sip:1000@10.0.0.47:38606;line=9k4wsgc9>
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:158]: dlg2hash(): hashid 40484
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:679]: parse_msg(): SIP Request:
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:680]: parse_msg(): method: <BYE>
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:682]: parse_msg(): uri: <sip:1000@10.0.0.47:38606;line=9k4wsgc9>
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:684]: parse_msg(): version: <SIP/2.0>
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Via] type 1
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_via.c:1300]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK42e9.4a962087000000000000000000000000.0>; state=16
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:557]: parse_headers(): this is the first via
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [To] type 3
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=ueisi99vbf
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=29
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): <To> [61]; uri=[sip:1000@fakedomain.com]
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body (44)[<sip:1000@fakedomain.com>], to tag (10)[ueisi99vbf]
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [From] type 4
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [CSeq] type 5
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <BYE>
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Call-ID] type 6
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Content-Length] type 12
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field(): content_length=0
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Max-Forwards] type 8
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of header
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=1132060721
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=29
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:1013]: tps_request_sent(): handling outgoing request (1, 1)
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:417]: tps_pack_message(): compacted headers - x_via1: [SIP/2.0/UDP <KAMAILIO PUBLIC IP>:5060;branch=z9hG4bK42e9.4a962087000000000000000000000000.0](85) - x_via2: [](0) - x_vbranch1: [z9hG4bK42e9.4a962087000000000000000000000000.0](46)
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:539]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [](0) - s_rr: [](0)
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:544]: tps_pack_message(): compacted headers - as_contact: [](0) - bs_contact: [](0)
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:1027]: tps_request_sent(): no x-uuid header - nothing to do
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/msg_translator.c:1799]: check_boundaries(): no multi-part body
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [topos_mod.c:567]: tps_msg_sent(): new outbound buffer generated
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:686]: send_prepared_request_impl(): uac: 0x7f22f94448e8 branch: 0 to 10.0.0.47:38606
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/onsend.c:50]: run_onsend(): required parameters are not available - ignoring
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: dialog [dlg_req_within.c:432]: send_bye(): BYE sent to caller
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: dialog [dlg_req_within.c:399]: send_bye(): sending BYE to callee
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:458]: t_uac_prepare(): next_hop=<sip:1001@<UA PUBLIC IP>:5066>Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:158]: dlg2hash(): hashid 40482
[View Less]
Hello,
I'm continuing investigations on Kamailio and stress test. Got it again in
the state where it's not accepting any new TCP/TLS connections (UDP still
works though), but all looks good from lsof/netnstat part, like system is
not reporting any zombie connections. Restart of Kamailio process helps
This time I got output of kamctl trap
Put it here: https://pastebin.com/iYrNZ8U9
kamailio --version
version: kamailio 5.6.2 (x86_64/linux) 54a9c1
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, …
[View More]USE_RAW_SOCKS, DISABLE_NAGLE,
USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC,
TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST,
HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024,
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 54a9c1
compiled on 14:01:01 Oct 18 2022 with gcc 4.8.5
It's statically linked with tlsa pointing on openssl-1.1.1q
Settings related to TLS are:
fork=yes
children=4
tcp_children=12
enable_tls=yes
tcp_accept_no_cl=yes
tcp_max_connections=63536
tls_max_connections=63536
tcp_accept_aliases=no
tcp_async=yes
tcp_connect_timeout=10
tcp_conn_wq_max=63536
tcp_crlf_ping=yes
tcp_delayed_ack=yes
tcp_fd_cache=yes
tcp_keepalive=yes
tcp_keepcnt=3
tcp_keepidle=30
tcp_keepintvl=10
tcp_linger2=30
tcp_rd_buf_size=80000
tcp_send_timeout=10
tcp_wq_blk_size=2100
tcp_wq_max=10485760
open_files_limit=63536
Can you please help to read gdb output and understand where I missed in
config?
Thanks in advance!
--
Best regards,
Ihor (Igor)
[View Less]