I have in config:
modparam("sanity", "uri_checks", 3) /* RURI, From */
and then config call sanity_check() on incoming requests:
if (!sanity_check()) { xnotice("Request from <$var(src_ip)> has invalid syntax\n"); exit; };
When incoming request has:
From: sipp sip:@192.168.255.95:5062;tag=1
no notice is printed to syslog.
From RFC 3261:
SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ] userinfo = ( user / telephone-subscriber ) [ ":" password ] "@" user = 1*( unreserved / escaped / user-unreserved )
My understanding of that is that there needs to be at least one character before @ sign.
-- Juha
The implementation didn't seem to parse the From URI in deep, I pushed a commit to master branch to do it. However, I am not sure if parse uri is detecting the missing user value, test and if not, I will look at it further.
Cheers, Daniel
On 14.03.22 07:57, Juha Heinanen wrote:
Juha Heinanen writes:
I have in config:
modparam("sanity", "uri_checks", 3) /* RURI, From */
Forgot to mention that config has also this:
modparam("sanity", "default_checks", 1024) /* parse uri's */
-- Juha
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Daniel-Constantin Mierla writes:
The implementation didn't seem to parse the From URI in deep, I pushed a commit to master branch to do it. However, I am not sure if parse uri is detecting the missing user value, test and if not, I will look at it
I tried to test by first building latest master, but build failed on Debian 11:
CC (gcc) [sip-proxy] core/mem/q_malloc.o core/mem/q_malloc.c: In function 'qm_malloc_init_pkg_manager': core/mem/q_malloc.c:1211:15: error: 'qm_report' undeclared (first use in this function); did you mean 'mem_report'? 1211 | ma.xreport = qm_report; | ^~~~~~~~~ | mem_report
I don't have any q_malloc related defines and the build has worked earlier.
-- Juha
That's strange, the compilation via github actions showed everything fine:
* https://github.com/kamailio/kamailio/actions
And on my macos dev platform it compiled and runs fine -- tested even now.
Anyhow, I exposed the new qm function in the headers file, can you fetch again master and try?
Cheers, Daniel
On 14.03.22 11:25, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
The implementation didn't seem to parse the From URI in deep, I pushed a commit to master branch to do it. However, I am not sure if parse uri is detecting the missing user value, test and if not, I will look at it
I tried to test by first building latest master, but build failed on Debian 11:
CC (gcc) [sip-proxy] core/mem/q_malloc.o core/mem/q_malloc.c: In function 'qm_malloc_init_pkg_manager': core/mem/q_malloc.c:1211:15: error: 'qm_report' undeclared (first use in this function); did you mean 'mem_report'? 1211 | ma.xreport = qm_report; | ^~~~~~~~~ | mem_report
I don't have any q_malloc related defines and the build has worked earlier.
-- Juha
Daniel-Constantin Mierla writes:
That's strange, the compilation via github actions showed everything fine:
Which OS platform is that using?
Anyhow, I exposed the new qm function in the headers file, can you fetch again master and try?
Now fails at load:
LD (gcc) [sip-proxy] sip-proxy /usr/bin/ld: core/mem/q_malloc.o: in function `qm_malloc_init_pkg_manager': ./src/core/mem/q_malloc.c:1211: undefined reference to `qm_report' /usr/bin/ld: core/mem/q_malloc.o: in function `qm_shm_report': ./src/core/mem/q_malloc.c:1409: undefined reference to `qm_report' collect2: error: ld returned 1 exit status
-- Juha
The actions file indicates bullseye and side for gcc and clang:
* https://github.com/kamailio/kamailio/actions/runs/1979948025/workflow#L25
Have you triggered a clean build? Do you build with the default make options or do you set other compile time flags?
Cheers, Daniel
On 14.03.22 12:01, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
That's strange, the compilation via github actions showed everything fine:
Which OS platform is that using?
Anyhow, I exposed the new qm function in the headers file, can you fetch again master and try?
Now fails at load:
LD (gcc) [sip-proxy] sip-proxy /usr/bin/ld: core/mem/q_malloc.o: in function `qm_malloc_init_pkg_manager': ./src/core/mem/q_malloc.c:1211: undefined reference to `qm_report' /usr/bin/ld: core/mem/q_malloc.o: in function `qm_shm_report': ./src/core/mem/q_malloc.c:1409: undefined reference to `qm_report' collect2: error: ld returned 1 exit status
-- Juha
Daniel-Constantin Mierla writes:
Have you triggered a clean build? Do you build with the default make options or do you set other compile time flags?
The build is clean (I use cowbuilder sandbox). I turned on verbose build. Below both compile and load commands are visible.
What is it that is missing from load? In which lib should qm_report be available?
-- Juha
gcc -funroll-loops -Wcast-align -m64 -minline-all-stringops -falign-loops -ftree-vectorize -fno-strict-overflow -mtune=generic -pthread -DKSR_PTHREAD_MUTEX_SHARED -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -g -ffile-prefix-map=/build/opensipg-sip-proxy-5.6=. -fstack-protector-strong -Wformat -Werror=format-security -DVERSION_NODATE -DNAME='"sip-proxy"' -DVERSION='"5.6.0-0b25"' -DARCH='"x86_64"' -DOS='linux_' -DOS_QUOTED='"linux"' -DCOMPILER='"gcc 10.2.1"' -D__CPU_x86_64 -D__OS_linux -DVERSIONVAL=5006000 -DCFG_DIR='"/etc/sip-proxy/"' -DSHARE_DIR='"/usr/share/sip-proxy/"' -DRUN_DIR='"/run/sip-proxy"' -DPKG_MALLOC -DSHM_MMAP -DDNS_IP_HACK -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLOCKLIST -DUSE_NAPTR -DWITH_XAVP -DMEM_JOIN_FREE -DMEM_JOIN_FREE -DF_MALLOC -DQ_MALLOC -DTLSF_MALLOC -DUSE_TLS -DTLS_HOOKS -DUSE_CORE_STATS -DSTATISTICS -DMALLOC_STATS -DUSE_SCTP -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_SCHED_SETSCHEDULER -DHAVE_IP_MREQN -DHAVE_EPOLL -DHAVE_SIGIO_RT -DSIGINFO64_WORKARROUND -DUSE_FUTEX -DHAVE_SELECT -c core/cfg.tab.c -o core/cfg.tab.o -MMD -MP gcc -g -m64 -Wl,-O2 -Wl,-E -Wl,-z,relro -pthread -rdynamic "-ldl" -Wl,-Bsymbolic-functions main.o core/action.o core/async_task.o core/atomic_ops.o core/basex.o core/bit_count.o core/bit_scan.o core/cfg_core.o core/cfg_parser.o core/core_cmd.o core/counters.o core/crc.o core/daemonize.o core/data_lump.o core/data_lump_rpl.o core/dns_cache.o core/dns_func.o core/dprint.o core/dset.o core/dst_blocklist.o core/endianness.o core/error.o core/events.o core/flags.o core/fmsg.o core/forward.o core/hash_func.o core/id.o core/io_wait.o core/ip_addr.o core/kemi.o core/local_timer.o core/lock_ops.o core/locking.o core/lvalue.o core/mod_fix.o core/modparam.o core/msg_translator.o core/nonsip_hooks.o core/onsend.o core/pass_fd.o core/ppcfg.o core/proxy.o core/pt.o core/pv_core.o core/pvapi.o core/qvalue.o core/raw_listener.o core/raw_sock.o core/re.o core/receive.o core/resolve.o core/route.o core/route_struct.o core/rpc_lookup.o core/rvalue.o core/script_cb.o core/sctp_core.o core/select.o core/select_buf.o core/select_core.o core/shm_init.o core/signals.o core/sip_msg_clone.o core/sock_ut.o core/socket_info.o core/sr_compat.o core/sr_module.o core/srapi.o core/str.o core/str_list.o core/strutils.o core/stun.o core/switch.o core/tcp_main.o core/tcp_options.o core/tcp_read.o core/tcp_stats.o core/timer.o core/timer_proc.o core/tls_hooks.o core/tsend.o core/udp_server.o core/usr_avp.o core/ut.o core/ver.o core/xavp.o core/mem/dl_malloc.o core/mem/f_malloc.o core/mem/ll_malloc.o core/mem/memtest.o core/mem/pkg.o core/mem/q_malloc.o core/mem/sf_malloc.o core/mem/shm.o core/mem/tlsf_malloc.o core/parser/hf.o core/parser/msg_parser.o core/parser/parse_addr_spec.o core/parser/parse_allow.o core/parser/parse_body.o core/parser/parse_content.o core/parser/parse_cseq.o core/parser/parse_date.o core/parser/parse_disposition.o core/parser/parse_diversion.o core/parser/parse_event.o core/parser/parse_expires.o core/parser/parse_fline.o core/parser/parse_from.o core/parser/parse_hname2.o core/parser/parse_identity.o core/parser/parse_identityinfo.o core/parser/parse_methods.o core/parser/parse_nameaddr.o core/parser/parse_option_tags.o core/parser/parse_param.o core/parser/parse_ppi_pai.o core/parser/parse_privacy.o core/parser/parse_refer_to.o core/parser/parse_require.o core/parser/parse_retry_after.o core/parser/parse_rpid.o core/parser/parse_rr.o core/parser/parse_sipifmatch.o core/parser/parse_subscription_state.o core/parser/parse_supported.o core/parser/parse_to.o core/parser/parse_uri.o core/parser/parse_via.o core/parser/parser_f.o core/parser/digest/digest.o core/parser/digest/digest_parser.o core/parser/digest/param_parser.o core/parser/contact/contact.o core/parser/contact/parse_contact.o core/parser/sdp/sdp.o core/parser/sdp/sdp_helpr_funcs.o core/rand/cryptorand.o core/rand/fastrand.o core/rand/isaac/rand.o core/rand/fortuna/fortuna.o core/rand/fortuna/random.o core/crypto/md5.o core/crypto/md5utils.o core/crypto/rijndael.o core/crypto/sha256.o core/crypto/shautils.o core/cfg/cfg.o core/cfg/cfg_ctx.o core/cfg/cfg_script.o core/cfg/cfg_select.o core/cfg/cfg_struct.o core/utils/srjson.o core/utils/sruid.o core/utils/tmrec.o core/lex.yy.o core/cfg.tab.o -ldl -lresolv -lm -o sip-proxy /usr/bin/ld: core/mem/q_malloc.o: in function `qm_malloc_init_pkg_manager': ./src/core/mem/q_malloc.c:1211: undefined reference to `qm_report' /usr/bin/ld: core/mem/q_malloc.o: in function `qm_shm_report': ./src/core/mem/q_malloc.c:1409: undefined reference to `qm_report' collect2: error: ld returned 1 exit status make[2]: *** [Makefile.rules:191: sip-proxy] Error 1
The qm_report() is in the core.
I noticed the lack of -DDBG_SR_MEMORY, which is on by default, but not in your compile log -- this could be the reason.
On 14.03.22 12:35, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Have you triggered a clean build? Do you build with the default make options or do you set other compile time flags?
The build is clean (I use cowbuilder sandbox). I turned on verbose build. Below both compile and load commands are visible.
What is it that is missing from load? In which lib should qm_report be available?
-- Juha
gcc -funroll-loops -Wcast-align -m64 -minline-all-stringops -falign-loops -ftree-vectorize -fno-strict-overflow -mtune=generic -pthread -DKSR_PTHREAD_MUTEX_SHARED -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -g -ffile-prefix-map=/build/opensipg-sip-proxy-5.6=. -fstack-protector-strong -Wformat -Werror=format-security -DVERSION_NODATE -DNAME='"sip-proxy"' -DVERSION='"5.6.0-0b25"' -DARCH='"x86_64"' -DOS='linux_' -DOS_QUOTED='"linux"' -DCOMPILER='"gcc 10.2.1"' -D__CPU_x86_64 -D__OS_linux -DVERSIONVAL=5006000 -DCFG_DIR='"/etc/sip-proxy/"' -DSHARE_DIR='"/usr/share/sip-proxy/"' -DRUN_DIR='"/run/sip-proxy"' -DPKG_MALLOC -DSHM_MMAP -DDNS_IP_HACK -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLOCKLIST -DUSE_NAPTR -DWITH_XAVP -DMEM_JOIN_FREE -DMEM_JOIN_FREE -DF_MALLOC -DQ_MALLOC -DTLSF_MALLOC -DUSE_TLS -DTLS_HOOKS -DUSE_CORE_STATS -DSTATISTICS -DMALLOC_STATS -DUSE_SCTP -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_SCHED_SETSCHEDULER -DHAVE_IP_MREQN -DHAVE_EPOLL -DHAVE_SIGIO_RT -DSIGINFO64_WORKARROUND -DUSE_FUTEX -DHAVE_SELECT -c core/cfg.tab.c -o core/cfg.tab.o -MMD -MP gcc -g -m64 -Wl,-O2 -Wl,-E -Wl,-z,relro -pthread -rdynamic "-ldl" -Wl,-Bsymbolic-functions main.o core/action.o core/async_task.o core/atomic_ops.o core/basex.o core/bit_count.o core/bit_scan.o core/cfg_core.o core/cfg_parser.o core/core_cmd.o core/counters.o core/crc.o core/daemonize.o core/data_lump.o core/data_lump_rpl.o core/dns_cache.o core/dns_func.o core/dprint.o core/dset.o core/dst_blocklist.o core/endianness.o core/error.o core/events.o core/flags.o core/fmsg.o core/forward.o core/hash_func.o core/id.o core/io_wait.o core/ip_addr.o core/kemi.o core/local_timer.o core/lock_ops.o core/locking.o core/lvalue.o core/mod_fix.o core/modparam.o core/msg_translator.o core/nonsip_hooks.o core/onsend.o core/pass_fd.o core/ppcfg.o core/proxy.o core/pt.o core/pv_core.o core/pvapi.o core/qvalue.o core/raw_listener.o core/raw_sock.o core/re.o core/receive.o core/resolve.o core/route.o core/route_struct.o core/rpc_lookup.o core/rvalue.o core/script_cb.o core/sctp_core.o core/select.o core/select_buf.o core/select_core.o core/shm_init.o core/signals.o core/sip_msg_clone.o core/sock_ut.o core/socket_info.o core/sr_compat.o core/sr_module.o core/srapi.o core/str.o core/str_list.o core/strutils.o core/stun.o core/switch.o core/tcp_main.o core/tcp_options.o core/tcp_read.o core/tcp_stats.o core/timer.o core/timer_proc.o core/tls_hooks.o core/tsend.o core/udp_server.o core/usr_avp.o core/ut.o core/ver.o core/xavp.o core/mem/dl_malloc.o core/mem/f_malloc.o core/mem/ll_malloc.o core/mem/memtest.o core/mem/pkg.o core/mem/q_malloc.o core/mem/sf_malloc.o core/mem/shm.o core/mem/tlsf_malloc.o core/parser/hf.o core/parser/msg_parser.o core/parser/parse_addr_spec.o core/parser/parse_allow.o core/parser/parse_body.o core/parser/parse_content.o core/parser/parse_cseq.o core/parser/parse_date.o core/parser/parse_disposition.o core/parser/parse_diversion.o core/parser/parse_event.o core/parser/parse_expires.o core/parser/parse_fline.o core/parser/parse_from.o core/parser/parse_hname2.o core/parser/parse_identity.o core/parser/parse_identityinfo.o core/parser/parse_methods.o core/parser/parse_nameaddr.o core/parser/parse_option_tags.o core/parser/parse_param.o core/parser/parse_ppi_pai.o core/parser/parse_privacy.o core/parser/parse_refer_to.o core/parser/parse_require.o core/parser/parse_retry_after.o core/parser/parse_rpid.o core/parser/parse_rr.o core/parser/parse_sipifmatch.o core/parser/parse_subscription_state.o core/parser/parse_supported.o core/parser/parse_to.o core/parser/parse_uri.o core/parser/parse_via.o core/parser/parser_f.o core/parser/digest/digest.o core/parser/digest/digest_parser.o core/parser/digest/param_parser.o core/parser/contact/contact.o core/parser/contact/parse_contact.o core/parser/sdp/sdp.o core/parser/sdp/sdp_helpr_funcs.o core/rand/cryptorand.o core/rand/fastrand.o core/rand/isaac/rand.o core/rand/fortuna/fortuna.o core/rand/fortuna/random.o core/crypto/md5.o core/crypto/md5utils.o core/crypto/rijndael.o core/crypto/sha256.o core/crypto/shautils.o core/cfg/cfg.o core/cfg/cfg_ctx.o core/cfg/cfg_script.o core/cfg/cfg_select.o core/cfg/cfg_struct.o core/utils/srjson.o core/utils/sruid.o core/utils/tmrec.o core/lex.yy.o core/cfg.tab.o -ldl -lresolv -lm -o sip-proxy /usr/bin/ld: core/mem/q_malloc.o: in function `qm_malloc_init_pkg_manager': ./src/core/mem/q_malloc.c:1211: undefined reference to `qm_report' /usr/bin/ld: core/mem/q_malloc.o: in function `qm_shm_report': ./src/core/mem/q_malloc.c:1409: undefined reference to `qm_report' collect2: error: ld returned 1 exit status make[2]: *** [Makefile.rules:191: sip-proxy] Error 1
Daniel-Constantin Mierla writes:
The qm_report() is in the core.
Yes, it is defined in the same file q_malloc.c where it is referenced. Weird that ld does not find it.
I noticed the lack of -DDBG_SR_MEMORY, which is on by default, but not in your compile log -- this could be the reason.
Yes, I have turned memory debugger off:
# Turn off memory debuging sed -i -e 's/MEMDBG ?= 1/MEMDBG ?= 0/' $SRC_DIR/src/Makefile.defs
but why would it matter?
-- Juha
I pushed a commit for it. The new function was defined only when memory debug was on.
Daniel
On 14.03.22 13:02, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
The qm_report() is in the core.
Yes, it is defined in the same file q_malloc.c where it is referenced. Weird that ld does not find it.
I noticed the lack of -DDBG_SR_MEMORY, which is on by default, but not in your compile log -- this could be the reason.
Yes, I have turned memory debugger off:
# Turn off memory debuging sed -i -e 's/MEMDBG ?= 1/MEMDBG ?= 0/' $SRC_DIR/src/Makefile.defs
but why would it matter?
-- Juha
Daniel-Constantin Mierla writes:
I pushed a commit for it. The new function was defined only when memory debug was on.
Thanks, now build succeeded, but the malformed From URI was not detected by sanity_check().
The sipp scenario that I use in the test is below. The reason why I started to wonder about this is that I have seen attackers using it.
-- Juha
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE scenario SYSTEM "sipp.dtd">
<!-- sipp test.tutpro.com:5060 -s test -sf options-test.xml -m 1 -t t1 -->
<scenario name="Options"> <send> <![CDATA[ OPTIONS sip:[service]@test.tutpro.com SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] Max-Forwards: 70 To: <sip:[service]@test.tutpro.com> From: sipp <sip:@[local_ip]:[local_port]>;tag=[call_number] Call-ID: [call_id] CSeq: 1 OPTIONS Contact: <sip:sipp@[local_ip]:[local_port]> Accept: application/sdp Content-Length: 0 ]]> </send>
<recv response="200" rtd="true"> </recv>
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/> <CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
Just pushed a commit trying to catch this case. Can you test and see if works?
Cheers, Daniel
On 14.03.22 13:31, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I pushed a commit for it. The new function was defined only when memory debug was on.
Thanks, now build succeeded, but the malformed From URI was not detected by sanity_check().
The sipp scenario that I use in the test is below. The reason why I started to wonder about this is that I have seen attackers using it.
-- Juha
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<!-- sipp test.tutpro.com:5060 -s test -sf options-test.xml -m 1 -t t1 -->
<scenario name="Options"> <send> <![CDATA[ OPTIONS sip:[service]@test.tutpro.com SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] Max-Forwards: 70 To: <sip:[service]@test.tutpro.com> From: sipp <sip:@[local_ip]:[local_port]>;tag=[call_number] Call-ID: [call_id] CSeq: 1 OPTIONS Contact: <sip:sipp@[local_ip]:[local_port]> Accept: application/sdp Content-Length: 0 ]]> </send>
<recv response="200" rtd="true"> </recv>
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/> <CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
Daniel-Constantin Mierla writes:
Just pushed a commit trying to catch this case. Can you test and see if works?
Unfortunately not catching the wrong From URI yet.
-- Juha
config:
modparam("sanity", "default_checks", 1024) modparam("sanity", "uri_checks", 3) /* RURI, From */ modparam("sanity", "autodrop", 0)
if (!sanity_check()) { xnotice("Request from <$var(src_ip)> has invalid syntax\n"); exit; };
test:
OPTIONS sip:test@test.tutpro.com SIP/2.0 Via: SIP/2.0/TCP 192.168.255.95:5062;branch=z9hG4bK-2974924-1-0 Max-Forwards: 70 To: sip:test@test.tutpro.com From: sipp sip:@192.168.255.95:5062;tag=1 Call-ID: 1-2974924@192.168.255.95 CSeq: 1 OPTIONS Contact: sip:sipp@192.168.255.95:5062 Accept: application/sdp Content-Length: 0
Try again with a fresh master, let's see if this time catches it.
Daniel
On 15.03.22 09:56, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Just pushed a commit trying to catch this case. Can you test and see if works?
Unfortunately not catching the wrong From URI yet.
-- Juha
config:
modparam("sanity", "default_checks", 1024) modparam("sanity", "uri_checks", 3) /* RURI, From */ modparam("sanity", "autodrop", 0)
if (!sanity_check()) { xnotice("Request from <$var(src_ip)> has invalid syntax\n"); exit; };
test:
OPTIONS sip:test@test.tutpro.com SIP/2.0 Via: SIP/2.0/TCP 192.168.255.95:5062;branch=z9hG4bK-2974924-1-0 Max-Forwards: 70 To: sip:test@test.tutpro.com From: sipp sip:@192.168.255.95:5062;tag=1 Call-ID: 1-2974924@192.168.255.95 CSeq: 1 OPTIONS Contact: sip:sipp@192.168.255.95:5062 Accept: application/sdp Content-Length: 0
Daniel-Constantin Mierla writes:
Try again with a fresh master, let's see if this time catches it.
I tried, but still not catching the invalid from URI. I added some more debug:
modparam("sanity", "default_checks", 1024) modparam("sanity", "uri_checks", 3) /* RURI, From */ modparam("sanity", "autodrop", 0)
if (!sanity_check()) { xnotice("Request from <$var(src_ip)> has invalid syntax\n"); exit; } else { xinfo("$rm <$ru> from <$fu> is OK\n"); };
and got to syslog:
Mar 15 12:11:38 /usr/bin/sip-proxy[2998746]: INFO: OPTIONS sip:test@test.tutpro.com from sip:@192.168.255.95:5062 is OK
-- Juha
Can you double check that latest version is used for testing?
You can also run with debug=3 and provide the logs printed by core and sanity module.
Daniel
On 15.03.22 11:13, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Try again with a fresh master, let's see if this time catches it.
I tried, but still not catching the invalid from URI. I added some more debug:
modparam("sanity", "default_checks", 1024) modparam("sanity", "uri_checks", 3) /* RURI, From */ modparam("sanity", "autodrop", 0)
if (!sanity_check()) { xnotice("Request from <$var(src_ip)> has invalid syntax\n"); exit; } else { xinfo("$rm <$ru> from <$fu> is OK\n"); };and got to syslog:
Mar 15 12:11:38 /usr/bin/sip-proxy[2998746]: INFO: OPTIONS sip:test@test.tutpro.com from sip:@192.168.255.95:5062 is OK
-- Juha
Daniel-Constantin Mierla writes:
Can you double check that latest version is used for testing?
It is the latest version.
You can also run with debug=3 and provide the logs printed by core and sanity module.
The log is below. Could it be that uri_checks value 3 are not correct, i.e., that there is a bug in README?
I'm just wondering, since the log does not have line:
get_hdr_field(): <From>
-- Juha
Mar 15 14:58:42 /usr/bin/sip-proxy[3043887]: DEBUG: <core> [core/ip_addr.c:571]: print_ip(): tcpconn_new: new tcp connection: 192.168.255.95 Mar 15 14:58:42 /usr/bin/sip-proxy[3043887]: DEBUG: <core> [core/tcp_main.c:1216]: tcpconn_new(): on port 37775, type 2, socket 59 Mar 15 14:58:42 /usr/bin/sip-proxy[3043887]: DEBUG: <core> [core/tcp_main.c:1548]: tcpconn_add(): hashes: 2713:680:331, 9 Mar 15 14:58:42 /usr/bin/sip-proxy[3043887]: DEBUG: <core> [core/io_wait.h:374]: io_watch_add(): processing io_watch_add(0x561ddaad2bc0, 59, 2, 0x7f5239bc16a0) - fd_no=52 Mar 15 14:58:42 /usr/bin/sip-proxy[3043887]: DEBUG: <core> [core/io_wait.h:599]: io_watch_del(): DBG: io_watch_del (0x561ddaad2bc0, 59, -1, 0x0) fd_no=53 called Mar 15 14:58:42 /usr/bin/sip-proxy[3043887]: DEBUG: <core> [core/tcp_main.c:4545]: handle_tcpconn_ev(): sending to child, events 1 Mar 15 14:58:42 /usr/bin/sip-proxy[3043887]: DEBUG: <core> [core/tcp_main.c:4187]: send2child(): checking per-socket generic workers (3043875/20..3043882/27) [tcp:192.168.255.95:5060] Mar 15 14:58:42 /usr/bin/sip-proxy[3043887]: DEBUG: <core> [core/tcp_main.c:4215]: send2child(): selected tcp worker idx:0 proc:20 pid:3043875 for activity on [tcp:192.168.255.95:5060], 0x7f5239bc16a0 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/tcp_read.c:1735]: handle_io(): received n=8 con=0x7f5239bc16a0, fd=11 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/tcp_read.c:1533]: tcp_read_req(): content-length=0 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/receive.c:136]: sip_check_fline(): first line indicates a SIP request Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:677]: parse_msg(): SIP Request: Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:678]: parse_msg(): method: <OPTIONS> Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:680]: parse_msg(): uri: sip:test@test.tutpro.com Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:682]: parse_msg(): version: <SIP/2.0> Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Via] type 1 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_via.c:1300]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-3044756-1-0>; state=16 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:557]: parse_headers(): this is the first via Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Max-Forwards] type 8 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [To] type 3 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=10 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): <To> [28]; uri=[sip:test@test.tutpro.com] Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body (28)[sip:test@test.tutpro.com#015#012], to tag (0)[] Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [From] type 4 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Call-ID] type 6 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [CSeq] type 5 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <OPTIONS> Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/receive.c:387]: receive_msg(): --- received sip message - request - call-id: [1-3044756@192.168.255.95] - cseq: [1 OPTIONS] Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/receive.c:259]: ksr_evrt_pre_routing(): event route core:pre-routing not defined Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/receive.c:469]: receive_msg(): preparing to run routing scripts... Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: sanity [sanity.c:758]: check_parse_uris(): check_parse_uris entered Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: sanity [sanity.c:762]: check_parse_uris(): parsing ruri Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: sanity [sanity.c:776]: check_parse_uris(): looking up From header Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=1 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=29 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: sanity [sanity.c:837]: check_parse_uris(): check_parse_uris passed Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: sanity [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 1 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: INFO: OPTIONS sip:test@test.tutpro.com from sip:@192.168.255.95:5062 is OK
Strange! The next log message indicates that it gets to From URI check:
Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: sanity [sanity.c:776]: check_parse_uris(): looking up From header
But for what so ever reason is not triggering a failure, it needs to dig in ...
Daniel
On 15.03.22 14:07, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Can you double check that latest version is used for testing?
It is the latest version.
You can also run with debug=3 and provide the logs printed by core and sanity module.
The log is below. Could it be that uri_checks value 3 are not correct, i.e., that there is a bug in README?
I'm just wondering, since the log does not have line:
get_hdr_field(): <From>
-- Juha
Mar 15 14:58:42 /usr/bin/sip-proxy[3043887]: DEBUG: <core> [core/ip_addr.c:571]: print_ip(): tcpconn_new: new tcp connection: 192.168.255.95 Mar 15 14:58:42 /usr/bin/sip-proxy[3043887]: DEBUG: <core> [core/tcp_main.c:1216]: tcpconn_new(): on port 37775, type 2, socket 59 Mar 15 14:58:42 /usr/bin/sip-proxy[3043887]: DEBUG: <core> [core/tcp_main.c:1548]: tcpconn_add(): hashes: 2713:680:331, 9 Mar 15 14:58:42 /usr/bin/sip-proxy[3043887]: DEBUG: <core> [core/io_wait.h:374]: io_watch_add(): processing io_watch_add(0x561ddaad2bc0, 59, 2, 0x7f5239bc16a0) - fd_no=52 Mar 15 14:58:42 /usr/bin/sip-proxy[3043887]: DEBUG: <core> [core/io_wait.h:599]: io_watch_del(): DBG: io_watch_del (0x561ddaad2bc0, 59, -1, 0x0) fd_no=53 called Mar 15 14:58:42 /usr/bin/sip-proxy[3043887]: DEBUG: <core> [core/tcp_main.c:4545]: handle_tcpconn_ev(): sending to child, events 1 Mar 15 14:58:42 /usr/bin/sip-proxy[3043887]: DEBUG: <core> [core/tcp_main.c:4187]: send2child(): checking per-socket generic workers (3043875/20..3043882/27) [tcp:192.168.255.95:5060] Mar 15 14:58:42 /usr/bin/sip-proxy[3043887]: DEBUG: <core> [core/tcp_main.c:4215]: send2child(): selected tcp worker idx:0 proc:20 pid:3043875 for activity on [tcp:192.168.255.95:5060], 0x7f5239bc16a0 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/tcp_read.c:1735]: handle_io(): received n=8 con=0x7f5239bc16a0, fd=11 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/tcp_read.c:1533]: tcp_read_req(): content-length=0 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/receive.c:136]: sip_check_fline(): first line indicates a SIP request Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:677]: parse_msg(): SIP Request: Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:678]: parse_msg(): method: <OPTIONS> Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:680]: parse_msg(): uri: sip:test@test.tutpro.com Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:682]: parse_msg(): version: <SIP/2.0> Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Via] type 1 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_via.c:1300]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-3044756-1-0>; state=16 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:557]: parse_headers(): this is the first via Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Max-Forwards] type 8 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [To] type 3 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=10 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): <To> [28]; uri=[sip:test@test.tutpro.com] Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body (28)[sip:test@test.tutpro.com#015#012], to tag (0)[] Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [From] type 4 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Call-ID] type 6 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [CSeq] type 5 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <OPTIONS> Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/receive.c:387]: receive_msg(): --- received sip message - request - call-id: [1-3044756@192.168.255.95] - cseq: [1 OPTIONS] Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/receive.c:259]: ksr_evrt_pre_routing(): event route core:pre-routing not defined Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/receive.c:469]: receive_msg(): preparing to run routing scripts... Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: sanity [sanity.c:758]: check_parse_uris(): check_parse_uris entered Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: sanity [sanity.c:762]: check_parse_uris(): parsing ruri Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: sanity [sanity.c:776]: check_parse_uris(): looking up From header Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=1 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=29 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: sanity [sanity.c:837]: check_parse_uris(): check_parse_uris passed Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: sanity [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 1 Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: INFO: OPTIONS sip:test@test.tutpro.com from sip:@192.168.255.95:5062 is OK
Daniel-Constantin Mierla writes:
Strange! The next log message indicates that it gets to From URI check:
Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: sanity [sanity.c:776]: check_parse_uris(): looking up From header
But for what so ever reason is not triggering a failure, it needs to dig in ...
I made another test, this time with From URI sip:^@192.168.255.95:5062 and that too was accepted, although ^ character is not allowed in user field:
INFO: OPTIONS sip:test@test.tutpro.com from sip:^@192.168.255.95:5062 is OK
-- Juha
The SIP parser was designed on purpose to be loosely in order to be able to fix broken SIP traffic. Without this "feature", making the parser very strict and dropping the traffic, Kamailio won't be that useful. I have been
But there are config functions in textops, siputils, ... or regexp options to be as stricter as you want.
Not the author, but the sanity module seems also designed around the format, not the content of the parts, relying mainly on parser.
Cheers, Daniel
On 15.03.22 16:42, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Strange! The next log message indicates that it gets to From URI check:
Mar 15 14:58:42 /usr/bin/sip-proxy[3043875]: DEBUG: sanity [sanity.c:776]: check_parse_uris(): looking up From header
But for what so ever reason is not triggering a failure, it needs to dig in ...
I made another test, this time with From URI sip:^@192.168.255.95:5062 and that too was accepted, although ^ character is not allowed in user field:
INFO: OPTIONS sip:test@test.tutpro.com from sip:^@192.168.255.95:5062 is OK
-- Juha
On 15.03.22 18:46, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Not the author, but the sanity module seems also designed around the format, not the content of the parts, relying mainly on parser.
OK, but the missing userpart before @ is a format thing?
It is, that's why I tried to sort it out, but somehow I missed where it fails to detect it. Maybe tomorrow I will be able to spend more time, this afternoon was busy.
Meanwhile, if you need it, you should be able to catch it with a regexp.
Cheers, Daniel
Daniel-Constantin Mierla writes:
Meanwhile, if you need it, you should be able to catch it with a regexp.
This is not urgent. Just noticed these kind of attacks:
Mar 13 00:07:23 /usr/bin/sip-proxy[555670]: INFO: INVITE sip:+920004536967279@example.com by untrusted sip:@192.168.0.1 from <213.202.225.40>
and thought that perhaps there exists some kind of security issue.
-- Juha
Here is q_malloc.c complilation:
gcc -funroll-loops -Wcast-align -m64 -minline-all-stringops -falign-loops -ftree-vectorize -fno-strict-overflow -mtune=generic -pthread -DKSR_PTHREAD_MUTEX_SHARED -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -g -ffile-prefix-map=/build/opensipg-sip-proxy-5.6=. -fstack-protector-strong -Wformat -Werror=format-security -DVERSION_NODATE -DNAME='"sip-proxy"' -DVERSION='"5.6.0-0b25"' -DARCH='"x86_64"' -DOS='linux_' -DOS_QUOTED='"linux"' -DCOMPILER='"gcc 10.2.1"' -D__CPU_x86_64 -D__OS_linux -DVERSIONVAL=5006000 -DCFG_DIR='"/etc/sip-proxy/"' -DSHARE_DIR='"/usr/share/sip-proxy/"' -DRUN_DIR='"/run/sip-proxy"' -DPKG_MALLOC -DSHM_MMAP -DDNS_IP_HACK -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLOCKLIST -DUSE_NAPTR -DWITH_XAVP -DMEM_JOIN_FREE -DMEM_JOIN_FREE -DF_MALLOC -DQ_MALLOC -DTLSF_MALLOC -DUSE_TLS -DTLS_HOOKS -DUSE_CORE_STATS -DSTATISTICS -DMALLOC_STATS -DUSE_SCTP -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_SCHED_SETSCHEDULER -DHAVE_IP_MREQN -DHAVE_EPOLL -DHAVE_SIGIO_RT -DSIGINFO64_WORKARROUND -DUSE_FUTEX -DHAVE_SELECT -c core/mem/q_malloc.c -o core/mem/q_malloc.o -MMD -MP
-- Juha
I suspect that no check in done on From URI, since also this passes the test:
INFO: OPTIONS sip:test@test.tutpro.com from sip:@192.168.255.95#5062 is OK
Host must be followed by ; or :, not #.
-- Juha
I pushed another commit. I tested a few cases:
sipexer -vl 3 -from-uri "sip:@127.0.0.1"
sipexer -vl 3 -from-uri "sip:@127.0.0.1#123"
sipexer -vl 3 -from-uri "sip:a@127.0.0.1#123"
All fail the uri parser. Before, the #123 was not caught because of the parser state for "sip:@..." case.
Daniel
On 16.03.22 07:12, Juha Heinanen wrote:
I suspect that no check in done on From URI, since also this passes the test:
INFO: OPTIONS sip:test@test.tutpro.com from sip:@192.168.255.95#5062 is OK
Host must be followed by ; or :, not #.
-- Juha
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Daniel-Constantin Mierla writes:
I pushed another commit. I tested a few cases:
Which commit was it? I just built latest master and these were the new commits that git pull found:
pdating d4af130477..dad4431726 Fast-forward src/core/resolve.c | 2 +- src/core/socket_info.c | 1 + src/modules/db_berkeley/km_bdb_val.c | 8 ++++---- src/modules/db_redis/redis_dbase.c | 2 +- src/modules/db_text/doc/db_text.cfg | 2 +-
Then I run the test and it did not fail:
INFO: OPTIONS sip:test@test.tutpro.com from sip:@192.168.255.95:5062 is OK
Are you using the same config?
modparam("sanity", "default_checks", 1024) modparam("sanity", "uri_checks", 3) /* RURI, From */ modparam("sanity", "autodrop", 0)
if (!sanity_check()) { xnotice("Request from <$var(src_ip)> has invalid syntax\n"); exit; } else { xinfo("$rm <$ru> from <$fu> is OK\n"); };
-- Juha
Just noticed that the previous git push failed for what so ever reason -- I did it again and now the commit should be in the repo.
Daniel
On 16.03.22 14:47, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I pushed another commit. I tested a few cases:
Which commit was it? I just built latest master and these were the new commits that git pull found:
pdating d4af130477..dad4431726 Fast-forward src/core/resolve.c | 2 +- src/core/socket_info.c | 1 + src/modules/db_berkeley/km_bdb_val.c | 8 ++++---- src/modules/db_redis/redis_dbase.c | 2 +- src/modules/db_text/doc/db_text.cfg | 2 +-
Then I run the test and it did not fail:
INFO: OPTIONS sip:test@test.tutpro.com from sip:@192.168.255.95:5062 is OK
Are you using the same config?
modparam("sanity", "default_checks", 1024) modparam("sanity", "uri_checks", 3) /* RURI, From */ modparam("sanity", "autodrop", 0)
if (!sanity_check()) { xnotice("Request from <$var(src_ip)> has invalid syntax\n"); exit; } else { xinfo("$rm <$ru> from <$fu> is OK\n"); };-- Juha
-
Daniel-Constantin Mierla -
Juha Heinanen