[SR-Users] Re: Depending on topoh.mask_key Kamailio cannot parse RURIs or modifies magically the SIP uri by changing some bytes in it (2)

2023-02-03 Thread Дилян Палаузов
Hello Henning,

thanks for your answer.  The symptoms are that the BYE cannot be handled 
properly, when the caller is behind websockets.

When the caller has established TLS connection, then BYE from caller is 
delivered properly to the TCP callee.

In December in this thread 
https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/thread/J5PHX5O6HVOZH5DMQZIQRJYHXMI3GXUQ/
 it
was again reported that with topoh just BYE does not work.  But it says nothing 
about websockets.

I enable system (normal) malloc/free by adding to src/Makefile.defs:

diff --git a/src/Makefile.defs b/src/Makefile.defs
index eb71d6cd0b..648102d63d 100644
--- a/src/Makefile.defs
+++ b/src/Makefile.defs
@@ -118,6 +118,8 @@ MEMMNG ?= 0
 # 0 - off (no-debug mode)
 # 1 - on (debug mode)
 MEMDBG ?= 1
+MEMPKG = sys
+MEMDBGSYS = 1
 
 VERSIONVAL = $(shell expr $(VERSION) \* 100 + $(PATCHLEVEL) \* 1000 + \
$(SUBLEVEL) )


kamailio -I prints:


Print out of kamailio internals
  Version: kamailio 5.6.3 (x86_64/linux) 641148
  Default config: /etc/kamailio/kamailio.cfg
  Default paths to modules: /lib64/kamailio/modules
  Compile flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, 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
  MAX_RECV_BUFFER_SIZE=262144
  MAX_URI_SIZE=1024
  BUF_SIZE=65535
  DEFAULT PKG_SIZE=8MB
  DEFAULT SHM_SIZE=64MB
  ADAPTIVE_WAIT_LOOPS=1024
  TCP poll methods: poll, epoll_lt, epoll_et, sigio_rt, select
  Source code revision ID: 641148 
  Compiled with: gcc 12.2.1
  Compiled architecture: x86_64
  Compiled on: 15:50:37 Feb  3 2023
Thank you for flying kamailio!


as the output includes Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY how can I 
know that the system malloc/free are used?

Running under valgrind shows no problems, so my changes to src/Makefile.defs 
might not trigger system malloc/free use.  Any suggestions?


To sum up:
- without TOPOH, there are no problems
- with TOPOH, caller is behind TLS, callee is TCP-connected, there are no 
problems
- with TOPOH, caller is behind websocket, calle is TCP-connected, there are 
problems: some bytes in the URL of the destination are replaced with
unprintable characters, or the R-URI is reported as unparsable (depending on 
the value of topoh.mask_key).

Moreover I have both loaded outbound-module and have configured the websocket 
provisions, when websockets is used without outbound.

As last speciality, the websocket client connects over secured-TLS (https/wss) 
to the webserver and the latter connects to Kamailio over insecure
HTTP/TCP.  That is the webclient includes Via:/WSS, but Kamailio adds 
transport=ws (not transport=wss).

Any hints?

Greetings
  Dilyan



-Original Message-
From: Henning Westerholt 
To: Kamailio (SER) - Users Mailing List 
Cc: Дилян Палаузов 
Subject: RE: [SR-Users] Depending on topoh.mask_key Kamailio cannot parse RURIs 
or modifies magically the SIP uri by changing some bytes in it (2)
Date: 02/02/2023 11:27:47 PM

Hello,

regarding shared memory, Kamailio uses usually shared memory, regardless of how 
many workers are configured.

About compiling Kamailio without its internal memory pool, its possible. This 
was discussed last month in a thread about memory performance, if I
remember correctly, on the list.

Cheers,

Henning

-- 
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

-Original Message-
From: Дилян Палаузов  
Sent: Wednesday, February 1, 2023 4:11 PM
To: Kamailio - Users Mailing List 
Subject: [SR-Users] Depending on topoh.mask_key Kamailio cannot parse RURIs or 
modifies magically the SIP uri by changing some bytes in it (2)

Hello,

does somebody has success, when using websockets and topoh?

If I run a single Kamailio process, I guess I do not need real shared memory.  
Can I adjust Kamailio somehow to use just malloc()/free() in this case,
so that debugging is easier?


As it turned out dns_cache_init=off leads to crashes - 
https://github.com/kamailio/kamailio/issues/3350 .  With dns_cache_init=on and
use_dns_cache=on, does not lead to reading invalid data.

Running Kamailio under valgrind:

When I do not set topoh.mask_key (so the default is used), for the yesterday 
mentioned workflow, for incoming packet:

18(19) ERROR:  [core/kemi.c:96]: sr_kemi_core_err(): ksr_sipdump_event 
1- sipdump:msg src 144.76.142.78:48294 dst 144.76.142.78:5060 ACK
sip:127.3.4.84;line=sr-n6iazhainwp1g6s5orj136tdouwy3etacsf73ejxgwvqp9e7zhkucrp-
gbeewrfl36313.0e3j4amxpworeiw.y1wlpagevs3eabw.3lz6tdcrtlh.cwobffzgzfwx37m.jlibmlzxczibv*
 SIP/2.0
Route: 

Route: 

Via: SIP/2.0/WSS lvqj9uhih64a.invalid;branch=z9hG4bK962314
Max-Forwards: 70
To: ;tag=5Ml7bJz
From: "Online https://sip.bapha.be"; ;tag=kab7lqjdgi
Call-ID: i7jjtim7h775c6vqqudg
CSeq

[SR-Users] topoh: th_mask_decode (th_mask_encode (x)) ≠ x

2023-02-03 Thread Дилян Палаузов
Hello,

after receiving

INVITE sip:test-gnome-ca...@bapha.be SIP/2.0
Via: SIP/2.0/WSS bapha.be;branch=z9hG4bK974100
Max-Forwards: 70
To: 
From: "Online https://sip.bapha.be"; ;tag=12q2efc423
Call-ID: fkhe8faq0fh80glmq59i
CSeq: 5622 INVITE
Contact: 
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: outbound
User-Agent: SIP.js/0.7.8
Content-Type: application/sdp
Content-Length: 1964

v=0
o=mozilla...THIS_IS_SDPARTA-99.0 8263261229339246488 0 IN IP4 0.0.0.0
s=-
…

kamailio calls 

th_mask_encode(
char *in = "sip:test-gnome-ca...@bapha.be;gr=urn:uuid:f2f5a3cf-a0fb-0047-be50-
740fb9bdc562;alias=87.118.146.153~60722~2>;+sip.instance=\"";+org.linphone.specs=\"conference/1.0,ephemeral/1.1,groupchat/1.1,groupchat/1.2,lime\n"\
"Content-Type: application/sdp and so on",
int ilen = 107,
str prefix = { .len = 23, .s ="sip:127.3.4.84;line=sr-" },
int *olen).

It returns olen=167, and the string "sip:127.3.4.84;line=sr-
if7s1mg7i36PNf0AbdwPpfzlbqWEpLzsSGItpLwyN39ZMY4t1mCTSd6DNo4LWdIOpfpPp5FLpUQscX63Kd47W5EPWO6sNL90pLgoW5p-1fzlSdzO25n3KoIk1vHkWXptc5wOeopsWO9-eo9*".

Then Kamailio forwards (sends):

Contact: 
;+sip.instance="";+org.linphone.specs="conference/1.0,ephemeral/1.1,groupchat/1.1,groupchat/1.2,lime"


which at some point leads to

ACK 
sip:127.3.4.84;line=sr-if7s1mg7i36pnf0abdwppfzlbqweplzssgitplwyn39zmy4t1mctsd6dno4lwdiopfppp5flpuqscx63kd47w5epwo6snl90plgow5p-
1fzlsdzo25n3koik1vhkwxptc5woeopswo9-eo9* SIP/2.0

and 

BYE 
sip:127.3.4.84;line=sr-if7s1mg7i36pnf0abdwppfzlbqweplzssgitplwyn39zmy4t1mctsd6dno4lwdiopfppp5flpuqscx63kd47w5epwo6snl90plgow5p-
1fzlsdzo25n3koik1vhkwxptc5woeopswo9-eo9* SIP/2.0

Below you can find th_test.c .  The functions th_mask_encode() and 
th_mask_decode() there are identical to the same functions in
src/modules/topoh/th_mask.c . main() provides some tests:

Passing «sip:test-gnome-ca...@bapha.be;gr=urn:uuid:f2f5a3cf-a0fb-0047-be50-
740fb9bdc562;alias=87.118.146.153~60472~2>;+sip.instance="";+org.linphone.specs="conference/1.0,ephemeral/1.1,groupchat/1.1,groupchat/1.2,lime»
 to th_mask_encode() returns

sip:127.3.4.84;line=sr-if7s1mg7i36PNf0AbdwPpfzlbqWEpLzsSGItpLwyN39ZMY4t1mCTSd6DNo4LWdIOpfpPp5FLpUQscX63Kd47W5EPWO6sNL90pLgoW5p-
1fzlSdzO25n3KoIk1vHkWXptc5wOeopsWXi-eo9*

(this is what Kamailio does send out).  Passing the last string to 
th_mask_decode() returns

sip:test-gnome-ca...@bapha.be;gr=urn:uuid:f2f5a3cf-a0fb-0047-be50-740fb9bdc562;alias=87.118.1

the ;alias= is incomplete, compared to the origin.


The above ACK leads to passing

"sr-if7s1mg7i36pnf0abdwppfzlbqweplzssgitplwyn39zmy4t1mctsd6dno4lwdiopfppp5flpuqscx63kd47w5epwo6snl90plgow5p-1fzlsdzo25n3koik1vhkwxptc5woeopswo9-eo9*
SIP/2.0\n"\
"Route: 
\n"\
"Route: 
\n"\

to th_mask_decode() and the result is 
callub.p.b;rn:s.d2lQg#cfa=bA07beQ7R409bcQ62;alac=87718*1P.15#~60R22~2 with the 
dots being unprintable
characters. (result is garbage).

I have seen that callub.p.b in the unparsable R-URI reports from Kamailio.

That is an indication that th_mask_decode() does not decode the Contact encoded 
by th_mask_encode() correctly.

Valgrind does not report improper memory usage.

Greetings
  Dilyan

gcc -g -o th-test ./th-test.c && ./th-test

th-test.c

#include 
#include 
#include 

#define TH_EB64I \

"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789.-"
char _th_EB64[65] = 
"EFvXIzGq94xKcW126gV5wCdYpNSbiM8enRUou7LmhajBlPtAsk-OQTf3H0DyrZ.J";
int _th_DB64[256];
char *_th_PD64 = "*";

struct str_ {
char* s; /**< Pointer to the first character of the string */
int len; /**< Length of the string */
};
typedef struct str_ str;

str prefix = { .len = 23, .s ="sip:127.3.4.84;line=sr-" };

char* th_mask_encode(char *in, int ilen, const str *prefix, int *olen);
char* th_mask_decode(char *in, int ilen, const str *prefix, int extra, int 
*olen);
char* th_mask_encode(char *in, int ilen, const str *prefix, int *olen)
{
char *out;
int  left;
int  idx;
int  i;
int  r;
char *p;
int  block;
*olen = (((ilen+2)/3)<<2) + 
((prefix!=NULL&&prefix->len>0)?prefix->len:0);
out = (char*)malloc((*olen+1)*sizeof(char));
if(out==NULL)
{
fprintf(stderr, "malloc error\n");
*olen = 0;
return NULL;
}
memset(out, 0, (*olen+1)*sizeof(char));
if(prefix!=NULL&&prefix->len>0)
memcpy(out, prefix->s, prefix->len);

p = out + (int)((prefix!=NULL&&prefix->len>0)?prefix->len:0);
for(idx=0; idx1)?2:left;

block = 0;
for(i=0, r=16; i<=left; i++, r-=8)
block += ((unsigned char)in[idx+i]) << r;

*(p++) = _th_EB64[(block >> 18) & 0x3f];
*(p++) = _th_EB64[(block >> 12) & 0x3f];
*(p++) = (left>0)?_th_EB64[(block >> 6) & 0x3f]:_th_PD64[0];
*(p++) = (left>1)?_th_EB64[block & 0x3f]:_th_PD64[0];
}

r

[SR-Users] no autocomplete for kamcmd for latest debian packages

2023-02-03 Thread Ovidiu Sas
Hello,

The latest debian packages are built without autocomplete for kamcmd.
Do we have the libreadline-dev package installed on the build machine?
I know that we have kamctl rpc  and kamcli, but if we are still
shipping kamcmd, it should have the autocomplete feature enabled.

Regards,
Ovidiu Sas

-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe: