Description

The comparison logic in tmrec_match() fails to properly evaluate equivalence conditions, as shown below:

int check_byxxx(tmrec_t *_trp, ac_tm_t *_atp)
{
	...
	if(_trp->bymonth) {
			for(i = 0; i < _trp->bymonth->nr; i++) {
				if(_atp->t.tm_mon
						== (_trp->bymonth->xxx[i] * _trp->bymonth->req[i] + 12)
								% 12)
					break;
			}
	...

Troubleshooting

Reproduction

Rule string: "20250403T100000|PT14H|weekly|20250425T000000|2|-1WE, -2WE|16|||4"

Date time: 20250416T190000

Expected output: MATCH

Actual output: NOT MATCH

Debugging Data

((lldb) p _trp->bymonth->xxx[0]
(int) 4
(lldb) p _trp->bymonth->req[0]
(int) 1
(lldb) p _atp->t.tm_mon
(int) 3
(lldb) p _trp->bymonth->nr
(int) 1

Log Messages

(paste your log messages here)

SIP Traffic

(paste your sip traffic here)

Possible Solutions

The tm_mon field in the tm struct uses a 0-11 range (January=0), while the parameter follows a 1-12 convention (January=1) as documented in the tmrec module's README. Therefore, we should first decrement the value of _trp->bymonth->xxx[i] by 1 for proper conversion.

Additional Information

version: kamailio 6.1.0-dev0 (x86_64/Darwin) 9f24f1-dirty
flags: , EXTRA_DEBUGUSE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, 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, select, kqueue.
id: 9f24f1 dirty
compiled on 11:59:55 Apr 16 2025 with AppleClang 17.0.0.17000013
Darwin yintiliangdeMacBook-Pro19.local 24.2.0 Darwin Kernel Version 24.2.0: Fri Dec  6 18:41:43 PST 2024; root:xnu-11215.61.5~2/RELEASE_X86_64 x86_64


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <kamailio/kamailio/issues/4214@github.com>

intliang created an issue (kamailio/kamailio#4214)

Description

The comparison logic in tmrec_match() fails to properly evaluate equivalence conditions, as shown below:

int check_byxxx(tmrec_t *_trp, ac_tm_t *_atp)
{
	...
	if(_trp->bymonth) {
			for(i = 0; i < _trp->bymonth->nr; i++) {
				if(_atp->t.tm_mon
						== (_trp->bymonth->xxx[i] * _trp->bymonth->req[i] + 12)
								% 12)
					break;
			}
	...

Troubleshooting

Reproduction

Rule string: "20250403T100000|PT14H|weekly|20250425T000000|2|-1WE, -2WE|16|||4"

Date time: 20250416T190000

Expected output: MATCH

Actual output: NOT MATCH

Debugging Data

((lldb) p _trp->bymonth->xxx[0]
(int) 4
(lldb) p _trp->bymonth->req[0]
(int) 1
(lldb) p _atp->t.tm_mon
(int) 3
(lldb) p _trp->bymonth->nr
(int) 1

Log Messages

(paste your log messages here)

SIP Traffic

(paste your sip traffic here)

Possible Solutions

The tm_mon field in the tm struct uses a 0-11 range (January=0), while the parameter follows a 1-12 convention (January=1) as documented in the tmrec module's README. Therefore, we should first decrement the value of _trp->bymonth->xxx[i] by 1 for proper conversion.

Additional Information

version: kamailio 6.1.0-dev0 (x86_64/Darwin) 9f24f1-dirty
flags: , EXTRA_DEBUGUSE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, 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, select, kqueue.
id: 9f24f1 dirty
compiled on 11:59:55 Apr 16 2025 with AppleClang 17.0.0.17000013
Darwin yintiliangdeMacBook-Pro19.local 24.2.0 Darwin Kernel Version 24.2.0: Fri Dec  6 18:41:43 PST 2024; root:xnu-11215.61.5~2/RELEASE_X86_64 x86_64


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <kamailio/kamailio/issues/4214@github.com>