sr-dev June 2024

sr-dev@lists.kamailio.org

14 participants
218 discussions

[kamailio/kamailio] extented haproxy protocol support (PR #3731)

by sergey-safarov

#### Pre-Submission Checklist - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist: - [ ] PR should be backported to stable branches - [x] Tested changes locally - [x] Related to issue #3667 #### Description Allow creating Record-Route and Via header using destination address and port in the haproxy protocol header. PR created behalf @ivanuschak You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3731 -- Commit Summary -- * core: extented haproxy protocol parser * rr: extented haproxy protocol suppport * path: extented haproxy protocol suppport * websocket: extented haproxy protocol suppport * siptrace: extented haproxy protocol suppport -- File Changes -- M src/core/forward.h (4) M src/core/msg_translator.c (137) M src/core/parser/msg_parser.h (1) M src/core/receive.c (6) M src/core/receive.h (3) M src/core/tcp_conn.h (1) M src/core/tcp_main.c (22) M src/core/tcp_read.c (20) M src/modules/path/path.c (2) M src/modules/rr/loose.c (4) M src/modules/rr/record.c (6) M src/modules/siptrace/siptrace.c (89) M src/modules/websocket/ws_frame.c (9) M src/modules/websocket/ws_handshake.c (3) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3731.patch https://github.com/kamailio/kamailio/pull/3731.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3731 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3731(a)github.com>

1 month

[kamailio/kamailio] ndb_redis: Error when receiving 'MOVED' response from redis-cluster with TLS (Issue #3894)

by uv-2722

### Description Hello, I am using ndb_redis module with TLS and redis-cluster. kamailio connects to the cluster endpoint when getting data, gets a 'MOVED' response and prints below error, it does not get data from the new host. ### Troubleshooting I have verified that I can connect to the cluster endpoint and the host in 'MOVED' using redis-cli on the system that kamailio is running on. I tried to connect to a self hosted cluster without TLS, it works as expected. It also works as expected with TLS and a single redis host. #### Reproduction Connect to a redis-cluster over TLS #### Log Messages  ``` 2024-06-25T20:48:53.626708963Z 2024-06-25 20:48:53.626584 3(17) NOTICE: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:437]: redisc_get_server(): Hash 31807 (ra) 2024-06-25T20:48:53.626710053Z 2024-06-25 20:48:53.626600 3(17) DEBUG: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:440]: redisc_get_server(): Entry 31807 (ra) 2024-06-25T20:48:53.626711073Z 2024-06-25 20:48:53.626636 3(17) NOTICE: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:444]: redisc_get_server(): Using entry 31807 (ra) 2024-06-25T20:48:53.626712073Z 2024-06-25 20:48:53.626651 3(17) DEBUG: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:1030]: redisc_exec(): rsrv->ctxRedis = 0x556b4456dc20 2024-06-25T20:48:53.626713073Z 2024-06-25 20:48:53.626667 3(17) DEBUG: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:1036]: redisc_exec(): rsrv->ctxRedis = 0x556b4456dc20 2024-06-25T20:48:53.626810463Z 2024-06-25 20:48:53.626762 3(17) DEBUG: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:896]: check_cluster_reply(): Redis replied: "MOVED 3667 testdbredis-masked-hostname.00000000001110000000.130-characters-long.00000000000011111111100000000.availability-zone.amazonaws.com:6379" 2024-06-25T20:48:53.626811523Z 2024-06-25 20:48:53.626777 3(17) DEBUG: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:904]: check_cluster_reply(): Port "6379" [4] => 6379 2024-06-25T20:48:53.626816413Z 2024-06-25 20:48:53.626793 3(17) DEBUG: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:914]: check_cluster_reply(): Host "testdbredis-masked-hostname.00000000001110000000.130-characters-long.000000…" [130] 2024-06-25T20:48:53.626846113Z 2024-06-25 20:48:53.626810 3(17) NOTICE: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:925]: check_cluster_reply(): Name of new connection: testdbredis-masked-hostname.00000000001110000000.130-characters-long.00000000000011111111100000000. 2024-06-25T20:48:53.626851443Z 2024-06-25 20:48:53.626827 3(17) NOTICE: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:437]: redisc_get_server(): Hash 968070864 (testdbredis-masked-hostname.00000000001110000000.130-characters-long.00000000000011111111100000000.) 2024-06-25T20:48:53.626896173Z 2024-06-25 20:48:53.626844 3(17) DEBUG: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:440]: redisc_get_server(): Entry 31807 (ra) 2024-06-25T20:48:53.626897503Z 2024-06-25 20:48:53.626861 3(17) NOTICE: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:450]: redisc_get_server(): No entry found. 2024-06-25T20:48:53.626955363Z 2024-06-25 20:48:53.626877 3(17) ERROR: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:947]: check_cluster_reply(): failed to print server spec string 2024-06-25T20:48:53.626957263Z 2024-06-25 20:48:53.626893 3(17) DEBUG: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:1115]: redisc_exec(): rpl->rplRedis->type:6 2024-06-25T20:48:53.626958443Z 2024-06-25 20:48:53.626908 3(17) ERROR: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:1117]: redisc_exec(): Redis error:MOVED 3667 testdbredis-masked-hostname.00000000001110000000.130-characters-long.00000000000011111111100000000.availability-zone.amazonaws.com:6379 ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.1 (x86_64/linux) 384843 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, 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, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_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: 384843 compiled on 19:05:30 Jun 25 2024 with gcc 12.2.0 ``` * Hiredis(v1.2.0) and hiredis-cluster(v0.13.0) are installed from source, both with ssl support. * **Operating System**:  ``` Debian 12 ``` ### Kamailio config snippet ``` loadmodule "ndb_redis.so" . . # ----- ndb_redis params ----- modparam("ndb_redis", "server", "name=ra;addr=cluster.testdbredis-masked-hostname.0000000011111111100000.availability-zone.amazonaws.com;port=6379;tls=1") modparam("ndb_redis", "init_without_redis", 1) modparam("ndb_redis", "cluster", 1) modparam("ndb_redis", "allow_dynamic_nodes", 1) modparam("ndb_redis", "ca_path", "/etc/ssl/certs") modparam("ndb_redis", "debug", 1) . . redis_cmd("ra", "HMGET usr_preferences:entry::%s:%s blocked", "$rU", "$fU", "r"); if($redis(r=>value[0]) == 1) { . } ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3894 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3894(a)github.com>

1 month

[kamailio/kamailio] db_redis: compile issues with TLS + redis-cluster (Issue #3893)

by uv-2722

1 month

[kamailio/kamailio] Usrloc keepalive: Not sending OPTIONS to UDP endpoints- 5.8.0 and 5.8.1 (Issue #3844)

by Luke Escudé

Running compiled Kamailio 5.8.1 (previously 5.8.0) on Debian 12 64-bit We're seeing an issue with UDP endpoints (this issue does not happen with TCP and TLS) where usrloc will not send OPTIONS packet keepalives. Here are all of our usrloc parameters: modparam("usrloc", "db_mode", 0) modparam("usrloc", "ka_domain", "SIPDOMAIN") #-- SIPDOMAIN is a fqdn modparam("usrloc", "ka_from", "sip:proxy-ping@SIPDOMAIN") modparam("usrloc", "ka_mode", 1) modparam("usrloc", "timer_interval", 20) #-- How often to qualify endpoints and clean mem tables? modparam("usrloc", "timer_procs", 4) modparam("usrloc", "ka_randomize", 10) modparam("usrloc", "use_domain", 0) modparam("usrloc", "server_id_filter", 1) modparam("usrloc", "ka_filter", 0) modparam("usrloc", "ka_timeout", 60) #-- How quickly to expire a contact if it does not reply to keepalive? modparam("usrloc", "matching_mode", 0) modparam("usrloc", "handle_lost_tcp", 1) modparam("usrloc", "close_expired_tcp", 1) modparam("usrloc", "desc_time_order", 1) modparam("usrloc", "hash_size", 14) It seems usrloc is not actually using timer_interval at all for UDP devices. However, it does seem to be sending OPTIONS every 20 seconds on TCP/TLS. (this is confirmed via packet capture on a SIP phone). -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3844 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3844(a)github.com>

1 month

[kamailio/kamailio] WIP pkg: RPM packaging add kamailio-tls_wolfssl subpackage (PR #3592)

by space88man

1 month

[kamailio/kamailio] ims_registrar_pcscf,ims_qos: added a parameter for trusting the bottom Via header on requests (PR #3891)

by Dragos Vingarzan

#### Pre-Submission Checklist    - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - Not yet - first let's see if the work is valid, then I'll recompose the whole work to satisfy this. Otherwise... if I need to fix something, it's too hard to work like this... - [ ] Each component has a single commit (if not, squash them into one commit) - ditto - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  Normally, the IMS P-CSCF should identify the clients (UEs) by the received IP address and ports on Rx. The current code is using a mix of that, plus using Contact and Via headers, with arguable potential security issues. This patch adds a new parameter to `ims_registrar_pcscf` and `ims_qos` modules, allowing for an optional outsource of the IPsec functionality to another element, which is also in charge of checking/enforcing correct UE Via header. The existing code is allowed to work as before, with the default value of the flag being towards that. List of functional changes: - `ims_qos` - added `trust_bottom_via` parameter - List of indirect changes: - default I-CSCF config example contained a questionable line which adds a `+` as a prefix in Request-URI. After way too much time wasted to figure out why the Diameter LIR has bogus SIP or TEL URI values in UserName AVP, I have discovered this. Seems like someone had just tel-URIs in their network, but otherwise the blind addition of this prefix makes no sense to me. - added a `str2ushort()` macro, since code was using some dangerous casting and macros with a larger type - List of non-functional fixes: - spelling in comments - comments at the end of line moved above the line they refer to; with just 80 columns code-formatting, commenting on the same line provides for some super weird and hard to read code, so IMHO should not be allowed (or ... much harder now... increase to 120 columns) - You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3891 -- Commit Summary -- * squashed work -- File Changes -- M misc/examples/ims/icscf/kamailio.cfg (4) M src/core/ut.h (36) M src/lib/ims/ims_getters.c (2) M src/modules/ims_icscf/location.c (10) M src/modules/ims_qos/ims_qos_mod.c (27) M src/modules/ims_qos/ims_qos_mod.h (1) M src/modules/ims_qos/rx_aar.h (4) M src/modules/ims_qos/rx_authdata.h (2) M src/modules/ims_qos/rx_avp.c (2) M src/modules/ims_qos/rx_avp.h (1) M src/modules/ims_registrar_pcscf/doc/ims_registrar_pcscf_admin.xml (39) M src/modules/ims_registrar_pcscf/ims_registrar_pcscf_mod.c (18) M src/modules/ims_registrar_pcscf/notify.c (2) M src/modules/ims_registrar_pcscf/save.c (78) M src/modules/ims_registrar_pcscf/service_routes.c (125) M src/modules/ims_registrar_pcscf/subscribe.c (75) M src/modules/ims_registrar_pcscf/subscribe.h (4) M src/modules/ims_usrloc_pcscf/udomain.c (4) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3891.patch https://github.com/kamailio/kamailio/pull/3891.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3891 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3891(a)github.com>

1 month

[kamailio/kamailio] performance regression related to new TCP connection tracking feature with a high number of connections (Issue #3759)

by Henning Westerholt

### Description On systems with a high number of TCP sessions there can be a significant performance regression observed, probably related to the newly added TCP connection tracking feature. ### Troubleshooting #### Reproduction No special configuration is necessary, just install the latest 5.7.x release, e.g. 5.7.3 on a production system with a lot of clients connected over TCP or TLS. You need to have a large number of clients connected to be able to observe the regression. For a high number of connections (e.g. more then 20.000 up to 30.000 connections) the Kamailio servers uses about 30% to 50% more CPU as with the old version. #### Debugging Data Two graphs were attached to this issue. The first shows the CPU load before (less load) and after the upgrade (increased load). The second is a flamegraph that shows that over 80% of the CPU time is spent in the newly added function tcp_connection_limit_srcip(). <img width="372" alt="cpu-load-before-after" src="https://github.com/kamailio/kamailio/assets/6481937/ec92c41b-25e2-4847-a4bc…"> ![flamegraph](https://github.com/kamailio/kamailio/assets/6481937/5c2e3982-2d5b-4acd-a774-bad8fa64bd0a) Most of the CPU time is spend in the TCP main process, as expected. #### Log Messages No special log messages could be observed. #### SIP Traffic ### Possible Solutions The TCP limit feature should probably be optimized to not cause such a large performance regression. It should be also possible to deactivate it completly and therefore getting a comparable performance as before the feature addition. ### Additional Information Kamailio 5.7.3 and probably also git master version. * **Operating System**: Debian 11, Debian 12 -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3759 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3759(a)github.com>

1 month, 1 week

[kamailio/kamailio] tcpops module event_route[tcp:closed] route block $conid is null (Issue #3767)

by liangbaolin

### Description During the process of using version 5.7.4 of Kamailio, I found that the $conid cannot be correctly obtained in the TCP: closed routing block of the TCP module event_route. I am certain that it is normal in version 5.4.8. ### Troubleshooting ``` pv [pv_core.c:2725]: pv_get_tcpconn_id() ``` #### Reproduction The test scenario initiated a register registration process for me, and after completing the disconnection of the TCP connection, triggered this event. #### Log Messages  ``` 2024-02-26T01:35:55.902002512Z 52(98) DEBUG: <core> [core/receive.c:635]: receive_msg(): cleaning up 2024-02-26T01:35:55.902034482Z 52(98) DEBUG: <core> [core/tcp_read.c:280]: tcp_read_data(): EOF on connection 0x7f99a1546a80 (state: 0, flags: c018) - FD 24, bytes 0, rd-flags 10000 ([12.0.1.6]:15821 -> [12.0.1.6]:5060)52(98) DEBUG: <core> [core/tcp_read.c:343]: tcp_read(): read 0 bytes: 2024-02-26T01:35:55.902051542Z 2024-02-26T01:35:55.902058282Z 52(98) DEBUG: <core> [core/tcp_read.c:1532]: tcp_read_req(): read= 0 bytes, parsed=0, state=0, error=1 2024-02-26T01:35:55.902063282Z 52(98) DEBUG: <core> [core/tcp_read.c:1534]: tcp_read_req(): last char=0x00, parsed msg= 2024-02-26T01:35:55.902069402Z 2024-02-26T01:35:55.902074032Z 52(98) DEBUG: <core> [core/tcp_read.c:1544]: tcp_read_req(): EOF 2024-02-26T01:35:55.902101372Z 52(98) DEBUG: <core> [core/io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0x559e8a029740, 24, -1, 0x10) fd_no=2 called 2024-02-26T01:35:55.902153162Z 52(98) DEBUG: <core> [core/tcp_read.c:1927]: handle_io(): removing from list 0x7f99a1546a80 id 2 fd 24, state 2, flags c018, main fd 134, refcnt 2 ([12.0.1.6]:15821 -> [12.0.1.6]:5060) 2024-02-26T01:35:55.902168112Z 52(98) DEBUG: <core> [core/tcp_read.c:1702]: release_tcpconn(): releasing con 0x7f99a1546a80, state -1, fd=24, id=2 ([12.0.1.6]:15821 -> [12.0.1.6]:5060) 2024-02-26T01:35:55.902173372Z 52(98) DEBUG: <core> [core/tcp_read.c:1705]: release_tcpconn(): extra_data (nil) 2024-02-26T01:35:55.902208402Z 83(129) DEBUG: <core> [core/tcp_main.c:3747]: handle_tcp_child(): reader response= 7f99a1546a80, -1 from 1 2024-02-26T01:35:55.902224742Z 83(129) DEBUG: <core> [core/tcp_main.c:3904]: handle_tcp_child(): case CONN_EOF tcp_emit_closed_event before 5 2024-02-26T01:35:55.902229802Z 83(129) DEBUG: <core> [core/tcp_main.c:3671]: tcp_emit_closed_event(): TCP closed event creation triggered (reason: 0) 2024-02-26T01:35:55.902318572Z 83(129) DEBUG: tcpops [tcpops.c:311]: tcpops_handle_tcp_closed(): received TCP closed event 2024-02-26T01:35:55.902331352Z 83(129) DEBUG: tcpops [tcpops.c:261]: tcpops_tcp_closed_run_route(): event reason id: 0 rt: 1 2024-02-26T01:35:55.902335132Z 83(129) ERROR: tcpops [tcpops.c:278]: tcpops_tcp_closed_run_route(): run_top_route() before tev->id: 2 2024-02-26T01:35:55.902480972Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 2 port 0 2024-02-26T01:35:55.902493872Z 83(129) DEBUG: pv [pv_core.c:2725]: pv_get_tcpconn_id(): no conid 2024-02-26T01:35:55.902498762Z 83(129) DEBUG: pv [pv_core.c:2726]: pv_get_tcpconn_id(): msg->rcv.proto_reserved1: 2 2024-02-26T01:35:55.902503592Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 2 port 0 2024-02-26T01:35:55.902508262Z 83(129) DEBUG: <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 111 2024-02-26T01:35:55.902513422Z 83(129) ERROR: <script>: tcp connection closed conid: (<null>), tcp(conid): <null>, Ri: 12.0.1.185, Rp: 5060 , si: 12.0.1.6 , sp: 15821 2024-02-26T01:35:55.902607692Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 2 port 0 2024-02-26T01:35:55.902625622Z 83(129) DEBUG: pv [pv_core.c:2725]: pv_get_tcpconn_id(): no conid 2024-02-26T01:35:55.902630672Z 83(129) DEBUG: pv [pv_core.c:2726]: pv_get_tcpconn_id(): msg->rcv.proto_reserved1: 2 2024-02-26T01:35:55.902635822Z 83(129) ERROR: tcpops [tcpops.c:280]: tcpops_tcp_closed_run_route(): run_top_route() after tev->id: 2 2024-02-26T01:35:58.777642759Z 41(87) DEBUG: ims_dialog [dlg_handlers.c:2026]: print_all_dlgs(): ********************41(87) DEBUG: ims_dialog [dlg_handlers.c:2027]: print_all_dlgs(): printing 65536 dialogs ``` #### SIP Traffic  ``` my test script block event_route[tcp:closed] { xlog("L_ERR", "$proto connection closed conid: ($conid), tcp(conid): $tcp(conid), Ri: $Ri, Rp: $Rp , si: $si , sp: $sp\n"); } file: src/modules/pv/pv_core.c int pv_get_tcpconn_id(struct sip_msg *msg, pv_param_t *param, pv_value_t *res) { ... if((con = tcpconn_get(msg->rcv.proto_reserved1, 0, 0, 0, 0)) == NULL) // return false { LM_DBG("no conid\n"); //additional custom log LM_DBG("msg->rcv.proto_reserved1: %d\n",msg->rcv.proto_reserved1); return pv_get_null(msg, param, res); } .... } file: src/core/tcp_main.c struct tcp_connection *tcpconn_lookup(int id, struct ip_addr *ip, int port, union sockaddr_union *local_addr, int try_local_port, ticks_t timeout) { ... if(unlikely(c == NULL)) { c = _tcpconn_find(id, ip, port, &local_ip, local_port); // retrun c == null } ... } struct tcp_connection *_tcpconn_find( int id, struct ip_addr *ip, int port, struct ip_addr *l_ip, int l_port) { ... if(likely(id)) { hash = tcp_id_hash(id); for(c = tcpconn_id_hash[hash]; c; c = c->id_next) { //tcpconn_id_hash find c is null #ifdef EXTRA_DEBUG LM_DBG("c=%p, c->id=%d, port=%d\n", c, c->id, c->rcv.src_port); print_ip("ip=", &c->rcv.src_ip, "\n"); #endif .... } inline static int tcpconn_try_unhash(struct tcp_connection *tcpconn) { ... _tcpconn_detach(tcpconn); //executed ... lock_release(&tcpconn->write_lock); ... } static inline void _tcpconn_detach(struct tcp_connection *c) { ... tcpconn_listrm(tcpconn_id_hash[c->id_hash], c, id_next, id_prev); //remove c ... } ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.7.4 (x86_64/linux) 9920d9-dirty flags: , EXTRA_DEBUGUSE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, 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, TLS_PTHREAD_MUTEX_SHARED 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: 9920d9 -dirty compiled on 09:59:52 Feb 26 2024 with gcc 7.5.0 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3767 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3767(a)github.com>

1 month, 1 week

[kamailio/kamailio] secsipid method to only validate signature without checking the rest of the header (Issue #3784)

by Ben Kaufman

### Description Currently secsipid has a method to sign arbitrary (json) data (`secsipid_sign`), however it has no converse method to check the signature. Currently, an attempt to check a `div` signature for example will yield a `-303` error (`SIPHdrInfo`). Rather than trying to have full parsing for every possible type of Identity header (which are likely to increase in variety), it would be good to simply check "is this signature valid by trusted key", possibly validating the `iat` timestamp as well, but without any other opinions on the header values. ### Expected behavior A feature to check only the signature of an identity header. #### Actual observed behavior Currently the `secsipid_check_` family of functions fails for non- `shaken` passport types. #### Debugging Data The following DIV identity header was generated by secsipid's `secsipid_sign()` function, so it should be possible to reverse this to validate the signature: ``` Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9kLm10c2VjLm1lL2QzYTkvQmZUeGJVTlozS1FMLnBlbSJ9.eyJkZXN0Ijp7InRuIjpbIjE2MTI1NTU0MzIxIl19LCJpYXQiOiIxNzEwMTY5MzQ1Iiwib3JpZyI6eyJ0biI6IjE1NTU3MzU5MzA5In0sImRpdiI6eyJ0biI6IjE5NTI1NTU5ODc2In19.-0QF6-u6zgAQNoAhdiETuhAu7FuRDzxmFch_cTdhcbeWvUZ60NQXxdPM-JucpOtFaEdn9wnFreAZ_6vZoc_Phg;info=<https://d.mtsec.me/d3a9/BfTxbUNZ3KQL.pem>;alg=ES256;ppt=div ``` ### Possible Solutions Because it's fairly straight forward to investigate the JWT, it's not necessary to try to account for every possible passport type, etc. The act of validating the signature is the complicated part, so a function that does only that would be convenient. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.7.4 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, 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, TLS_PTHREAD_MUTEX_SHARED 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: unknown compiled with gcc 12.2.0 ``` * **Operating System**: Currently alpine linux 3.19 in a docker container, but it should be pretty reproducible everywhere. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3784 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3784(a)github.com>

1 month, 1 week

Initial Support for CMake in Kamailio - Feedback Needed!

by Xenofon Karamanos

Hello all, I've started working on integrating CMake as a build system for the Kamailio. This is an initial step towards potentially offering CMake as an alternative to the current build system across the entire Kamailio project. Right now, the CMake configuration is quite basic and covers only the core module. It offers limited options described in Makefile.defs that are required to build the core module. Some notes regarding the definitions can be found also in the CMakelists.notes<https://github.com/kamailio/kamailio/compare/master...cmake#diff-4e8ba0f2d5…> that made the build failed and maybe it's good to remove from current Makefiles as well, if i am not wrong. Before we consider extending it to other modules and components, i would like some feedback whether you find it useful at all. You can find the initial CMake files in the cmake branch. Please take a look and feel free to share any feedback or suggestions. Your input will be much appreciated and nessecary if we want CMake as a build system. For anyone wanting to try and compile using cmake, here are some basic instructions on how to get you started. Checkout the cmake branch of kamailio repo. Create a new folder, let's call it build. mkdir build && cd build Then run CMake for the configuration cmake .. (you can also then use ccmake . for a visual of the offered options) Build and install using make make -j4 make install OR Build and install using cmake cmake --build . cmake --install . You can of course use the CMake variable CMAKE_INSTALL_PREFIX to change the installation paths as follows and of course other preprocessor defintions: cmake -DCMAKE_INSTALL_PREFIX=./kamailio-cmake -DUSE_TCP=0 .. This will install it in the build/kamailio-cmake folder but fails to build because USE_TCP is required for kamailio to build (Check CMakelists.notes). Thank you all for your continuous contributions and support. Looking forward to hearing your thoughts and insights. Best regards, Xenofon https://github.com/kamailio/kamailio/tree/cmake [https://repository-images.githubusercontent.com/15101579/2d895000-e695-11e9…]<https://github.com/kamailio/kamailio/tree/cmake> GitHub - kamailio/kamailio at cmake<https://github.com/kamailio/kamailio/tree/cmake> Kamailio - The Open Source SIP Server for large VoIP and real-time communication platforms - - GitHub - kamailio/kamailio at cmake github.com

1 month, 1 week

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev June 2024