sr-dev June 2011

sr-dev@lists.kamailio.org

32 participants
167 discussions

git:master: dns: case insensitive check for NAPTR record flags
by Andrei Pelinescu-Onciul 11 Jun '11

11 Jun '11

Module: sip-router Branch: master Commit: 12dc828d8677da81de4c5198ec5862dd9ee1c477 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=12dc828… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Sat Jun 11 10:38:10 2011 +0200 dns: case insensitive check for NAPTR record flags The NAPTR records flags where not checked in case insensitive mode. Records with the 'S' flags where ignored ('s' was expected). Closes: FS#135 Reported-by: Inaki Baz Castillo ibc aliax net --- resolve.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/resolve.c b/resolve.c index a106315..782c15a 100644 --- a/resolve.c +++ b/resolve.c @@ -1017,7 +1017,7 @@ char naptr_get_sip_proto(struct naptr_rdata* n) proto=-1; - if ((n->flags_len!=1) || (*n->flags!='s')) + if ((n->flags_len!=1) || ((*n->flags | 0x20 )!='s')) return -1; if (n->regexp_len!=0) return -1;

1 0

[tracker] Task changed: NAPTR records are retrieved but fully ignored
by sip-router 11 Jun '11

11 Jun '11

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has been changed. The changes are listed below. For full information about what has changed, visit the URL and click the History tab. FS#135 - NAPTR records are retrieved but fully ignored User who did this: Iñaki Baz Castillo (ibc) Task details edited: ------- By doing several tests I'm pretty sure that kamailio 3.2.0-dev5 performs NAPTR query but ignores its results. Kamailio (deb package) has USE_NAPTR flag: version: kamailio 3.2.0-dev5 (x86_64/linux) cb30d9 flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: cb30d9 compiled on 23:08:36 Jun 10 2011 with gcc 4.5.2 Kamailio DNS related parateres (according to the doc they are correct in order to do complete NAPTR/SRV stuf): dns_try_ipv6=no dns_retr_time=1 dns_retr_no=2 dns_servers_no=2 dns_srv_lb=yes dns_try_naptr=yes dns_use_search_list=no dns_search_full_match=no use_dns_cache=yes dns_cache_init=yes use_dns_failover=yes dns_tls_preference=1 dns_tcp_preference=1 dns_udp_preference=1 dns_sctp_preference=1 My Kamailio listens into UDP and TCP. The config file just does a t_relay(), no more. Kamailio receives a request with RURI "sip:qweqwe@naptr-test2.oversip.net" (no transport param, neither port). The existing DNS NAPTR records for such domain "naptr-test2.oversip.net" are: ~# host -t naptr naptr-test2.oversip.net naptr-test2.oversip.net has NAPTR record 10 50 "S" "SIP+D2U" "" _sip._udp.lalala.oversip.net. Please note that the domain in the 'replacement' field of the NAPTR record is not "_sip._udp.naptr-test2.oversip.net", but "_sip._udp.lalala.oversip.net" (perfectly valid according to RFC 3261). Kamailio processes the request, performs a NAPTR query for domain "naptr-test2.oversip.net", receives the DNS response, but makes no usage of it. Instead it behaves as if no NAPTR record(s) exist and go to next DNS step by querying DNS SRV "_sip._udp.naptr-test2.oversip.net" (which does not exist, neither there is a DNS A record for it) so it fails and replies 478 'Unresolvable destination (478/TM)'. I attach a tcpdump capture (exported to TXT) of the DNS queries performed by Kamailio. Kamailio logs say: DEBUG: <core> [parser/msg_parser.c:630]: SIP Request: DEBUG: <core> [parser/msg_parser.c:632]: method: <MESSAGE> DEBUG: <core> [parser/msg_parser.c:634]: uri: <sip:qweqwe@naptr-test2.oversip.net> DEBUG: <core> [parser/msg_parser.c:636]: version: <SIP/2.0> DEBUG: <core> [parser/parse_via.c:1287]: Found param type 232, <branch> = <z9hG4bK1784ca8c0f4fc-1>; state=6 DEBUG: <core> [parser/parse_via.c:1287]: Found param type 235, <rport> = <n/a>; state=6 DEBUG: <core> [parser/parse_via.c:1287]: Found param type 253, <kaka2> = <n/a>; state=6 DEBUG: <core> [parser/parse_via.c:1287]: Found param type 253, <KAKA3> = <%61lice>; state=9 DEBUG: <core> [parser/parse_via.c:2343]: parse_via: next_via DEBUG: <core> [parser/parse_via.c:2300]: end of header reached, state=2 DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via DEBUG: <core> [receive.c:146]: After parse_msg... DEBUG: <core> [receive.c:187]: preparing to run routing scripts... DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=1 , global msg id=0 , T on entrance=0xffffffffffffffff DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=9 DEBUG: <core> [parser/msg_parser.c:187]: DEBUG: get_hdr_field: <T> [19]; uri=[sip:ibc@aliax.net] DEBUG: <core> [parser/msg_parser.c:189]: DEBUG: to body [sip:ibc@aliax.net#015#012] DEBUG: <core> [parser/msg_parser.c:167]: get_hdr_field: cseq <Cseq>: <914577526> <MESSAGE> DEBUG: <core> [parser/msg_parser.c:201]: DEBUG: get_hdr_body : content_length=11 DEBUG: <core> [parser/msg_parser.c:103]: found end of header DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=33819, isACK=0 DEBUG: tm [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed DEBUG: tm [t_lookup.c:711]: DEBUG: t_lookup_request: no transaction found DEBUG: tm [t_hooks.c:374]: DBG: trans=0x7fe5add5f038, callback type 1, id 0 entered DEBUG: <core> [dns_cache.c:567]: dns_hash_find(naptr-test2.oversip.net(23), 35), h=1000 DEBUG: <core> [resolve.c:924]: get_record: skipping 0 NS (p=0x827f62, end=0x827f62) DEBUG: <core> [resolve.c:940]: get_record: parsing 0 ARs (p=0x827f62, end=0x827f62) DEBUG: <core> [dns_cache.c:1777]: dns_get_related(0x7fe5add61318 (naptr-test2.oversip.net, 35), 35, *(nil)) (0) DEBUG: <core> [dns_cache.c:870]: dns_cache_add: adding naptr-test2.oversip.net(23) 35 (flags=0) at 1000 DEBUG: <core> [dns_cache.c:567]: dns_hash_find(_sip._udp.naptr-test2.oversip.net(33), 33), h=565 DEBUG: <core> [resolve.c:727]: get_record: lookup(_sip._udp.naptr-test2.oversip.net, 33) failed DEBUG: <core> [dns_cache.c:895]: dns_cache_mk_bad_entry(_sip._udp.naptr-test2.oversip.net, 33, 60, 1) DEBUG: <core> [dns_cache.c:828]: dns_cache_add: adding _sip._udp.naptr-test2.oversip.net(33) 33 (flags=1) at 565 DEBUG: <core> [dns_cache.c:3236]: dns_srv_resolve_ip("_sip._udp.naptr-test2.oversip.net", 0, 0), ret=-5, ip= DEBUG: <core> [dns_cache.c:567]: dns_hash_find(naptr-test2.oversip.net(23), 1), h=1000 DEBUG: <core> [resolve.c:727]: get_record: lookup(naptr-test2.oversip.net, 1) failed The same can be demostrated by sending a request with RURI "sip:1234@oversip.net" to Kamailio. NAPTR records for "oversip.net" domain are: ~# host -t naptr oversip.net oversip.net has NAPTR record 20 50 "S" "SIP+D2U" "" _sip._udp.oversip.net. oversip.net has NAPTR record 40 50 "S" "SIP+D2S" "" _sip._sctp.oversip.net. oversip.net has NAPTR record 50 50 "S" "SIPS+D2S" "" _sips._sctp.oversip.net. oversip.net has NAPTR record 5 50 "S" "SIPS+D2T" "" _sips._tcp.oversip.net. oversip.net has NAPTR record 10 50 "S" "SIP+D2T" "" _sip._tcp.oversip.net. As you can see, the preferred order is TLS, TCP and UDP (ignoring SCTP). Kamailio performs the NAPTR query, but then always queries DNS SRV _sip._udp.oversip.net. Note that, as demostrated above, I don't think it does it because it chooses UDP from the list of NAPTR records, but because it just fully ignores NAPTR records (if it wasn't ignore NAPTR records but always chose UDP, then in the above case it would query "DNS SRV _sip._udp.lalala.oversip.net" rather than "DNS SRV _sip._udp.naptr-test2.oversip.net"). ------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=135 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[tracker] Task opened: NAPTR records are retrieved but fully ignored (Attachment added)
by sip-router 11 Jun '11

11 Jun '11

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Iñaki Baz Castillo (ibc) Attached to Project - sip-router Summary - NAPTR records are retrieved but fully ignored Task Type - Bug Report Category - dns / dns cache Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - Linux Severity - Medium Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - By doing several tests I'm pretty sure that kamailio 3.2.0-dev5 performs NAPTR query but ignores its results. Kamailio (deb package) has USE_NAPTR flag: <pre> version: kamailio 3.2.0-dev5 (x86_64/linux) cb30d9 flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: cb30d9 compiled on 23:08:36 Jun 10 2011 with gcc 4.5.2 </pre> Kamailio DNS related parateres (according to the doc they are correct in order to do complete NAPTR/SRV stuf): <pre> dns_try_ipv6=no dns_retr_time=1 dns_retr_no=2 dns_servers_no=2 dns_srv_lb=yes dns_try_naptr=yes dns_use_search_list=no dns_search_full_match=no use_dns_cache=yes dns_cache_init=yes use_dns_failover=yes dns_tls_preference=1 dns_tcp_preference=1 dns_udp_preference=1 dns_sctp_preference=1 </pre> My Kamailio listens into UDP and TCP. The config file just does a t_relay(), no more. Kamailio receives a request with RURI "sip:qweqwe@naptr-test2.oversip.net" (no transport param, neither port). The existing DNS NAPTR records for such domain "naptr-test2.oversip.net" are: <pre> ~# host -t naptr naptr-test2.oversip.net naptr-test2.oversip.net has NAPTR record 10 50 "S" "SIP+D2U" "" _sip._udp.lalala.oversip.net. </pre> Please note that the domain in the 'replacement' field of the NAPTR record is not "_sip._udp.naptr-test2.oversip.net", but "_sip._udp.lalala.oversip.net" (perfectly valid according to RFC 3261). Kamailio processes the request, performs a NAPTR query for domain "naptr-test2.oversip.net", receives the DNS response, but makes no usage of it. Instead it behaves as if no NAPTR record(s) exist and go to next DNS step by querying DNS SRV "_sip._udp.naptr-test2.oversip.net" (which does not exist, neither there is a DNS A record for it) so it fails and replies 478 'Unresolvable destination (478/TM)'. I attach a tcpdump capture (exported to TXT) of the DNS queries performed by Kamailio. Kamailio logs say: <pre> DEBUG: <core> [parser/msg_parser.c:630]: SIP Request: DEBUG: <core> [parser/msg_parser.c:632]: method: <MESSAGE> DEBUG: <core> [parser/msg_parser.c:634]: uri: <sip:qweqwe@naptr-test2.oversip.net> DEBUG: <core> [parser/msg_parser.c:636]: version: <SIP/2.0> DEBUG: <core> [parser/parse_via.c:1287]: Found param type 232, <branch> = <z9hG4bK1784ca8c0f4fc-1>; state=6 DEBUG: <core> [parser/parse_via.c:1287]: Found param type 235, <rport> = <n/a>; state=6 DEBUG: <core> [parser/parse_via.c:1287]: Found param type 253, <kaka2> = <n/a>; state=6 DEBUG: <core> [parser/parse_via.c:1287]: Found param type 253, <KAKA3> = <%61lice>; state=9 DEBUG: <core> [parser/parse_via.c:2343]: parse_via: next_via DEBUG: <core> [parser/parse_via.c:2300]: end of header reached, state=2 DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via DEBUG: <core> [receive.c:146]: After parse_msg... DEBUG: <core> [receive.c:187]: preparing to run routing scripts... DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=1 , global msg id=0 , T on entrance=0xffffffffffffffff DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=9 DEBUG: <core> [parser/msg_parser.c:187]: DEBUG: get_hdr_field: <T> [19]; uri=[sip:ibc@aliax.net] DEBUG: <core> [parser/msg_parser.c:189]: DEBUG: to body [sip:ibc@aliax.net#015#012] DEBUG: <core> [parser/msg_parser.c:167]: get_hdr_field: cseq <Cseq>: <914577526> <MESSAGE> DEBUG: <core> [parser/msg_parser.c:201]: DEBUG: get_hdr_body : content_length=11 DEBUG: <core> [parser/msg_parser.c:103]: found end of header DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=33819, isACK=0 DEBUG: tm [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed DEBUG: tm [t_lookup.c:711]: DEBUG: t_lookup_request: no transaction found DEBUG: tm [t_hooks.c:374]: DBG: trans=0x7fe5add5f038, callback type 1, id 0 entered DEBUG: <core> [dns_cache.c:567]: dns_hash_find(naptr-test2.oversip.net(23), 35), h=1000 DEBUG: <core> [resolve.c:924]: get_record: skipping 0 NS (p=0x827f62, end=0x827f62) DEBUG: <core> [resolve.c:940]: get_record: parsing 0 ARs (p=0x827f62, end=0x827f62) DEBUG: <core> [dns_cache.c:1777]: dns_get_related(0x7fe5add61318 (naptr-test2.oversip.net, 35), 35, *(nil)) (0) DEBUG: <core> [dns_cache.c:870]: dns_cache_add: adding naptr-test2.oversip.net(23) 35 (flags=0) at 1000 DEBUG: <core> [dns_cache.c:567]: dns_hash_find(_sip._udp.naptr-test2.oversip.net(33), 33), h=565 DEBUG: <core> [resolve.c:727]: get_record: lookup(_sip._udp.naptr-test2.oversip.net, 33) failed DEBUG: <core> [dns_cache.c:895]: dns_cache_mk_bad_entry(_sip._udp.naptr-test2.oversip.net, 33, 60, 1) DEBUG: <core> [dns_cache.c:828]: dns_cache_add: adding _sip._udp.naptr-test2.oversip.net(33) 33 (flags=1) at 565 DEBUG: <core> [dns_cache.c:3236]: dns_srv_resolve_ip("_sip._udp.naptr-test2.oversip.net", 0, 0), ret=-5, ip= DEBUG: <core> [dns_cache.c:567]: dns_hash_find(naptr-test2.oversip.net(23), 1), h=1000 DEBUG: <core> [resolve.c:727]: get_record: lookup(naptr-test2.oversip.net, 1) failed </pre> The same can be demostrated by sending a request with RURI "sip:1234@oversip.net" to Kamailio. NAPTR records for "oversip.net" domain are: <pre> ~# host -t naptr oversip.net oversip.net has NAPTR record 20 50 "S" "SIP+D2U" "" _sip._udp.oversip.net. oversip.net has NAPTR record 40 50 "S" "SIP+D2S" "" _sip._sctp.oversip.net. oversip.net has NAPTR record 50 50 "S" "SIPS+D2S" "" _sips._sctp.oversip.net. oversip.net has NAPTR record 5 50 "S" "SIPS+D2T" "" _sips._tcp.oversip.net. oversip.net has NAPTR record 10 50 "S" "SIP+D2T" "" _sip._tcp.oversip.net. </pre> As you can see, the preferred order is TLS, TCP and UDP (ignoring SCTP). Kamailio performs the NAPTR query, but then always queries DNS SRV _sip._udp.oversip.net. Note that, as demostrated above, I don't think it does it because it chooses UDP from the list of NAPTR records, but because it just fully ignores NAPTR records (if it wasn't ignore NAPTR records but always chose UDP, then in the above case it would query "DNS SRV _sip._udp.lalala.oversip.net" rather than "DNS SRV _sip._udp.naptr-test2.oversip.net"). One or more files have been attached. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=135 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[tracker] Assignee added: NAPTR records are retrieved but fully ignored
by sip-router 11 Jun '11

11 Jun '11

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#135 - NAPTR records are retrieved but fully ignored User who did this - Iñaki Baz Castillo (ibc) http://sip-router.org/tracker/index.php?do=details&task_id=135 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

Again about return code when start action fails
by Iñaki Baz Castillo 10 Jun '11

10 Jun '11

Hi, let me reopen this discussion about status code of the init script (kamailio master process which runs daemonized main process). I'm pretty sure that lot time ago, when I submitted a commit for daemonice.c (including a PIPE to comunicate main process with master process) it did work as expected. This is, if I set a listen address in which my system cannot bind, I got error status code (1) when running kamailio in daemonized mode (/etc/init.d/kamailio start returned error). Later I know there were some changes about such code, not sure which ones as I didn't inspect them. However thinkgs don't work at all in 3.1.2 (or they work bad, as in Kamailio <= 1.5). Basically I set a wrong listen address (not a local address), so kamailio fails to start, but the init script returns 0 (OK). This is making crazy my HeartBeat systems. Kamailio logs: init script return code: ------------------------------------- ~# /etc/init.d/kamailio start ; echo "*** status code: $?" Starting kamailio: kamailioloading modules under /usr/lib/kamailio/modules_k:/usr/lib/kamailio/modules Listening on udp: X.X.X.X [X.X.X.X]:5060 tcp: X.X.X.X [X.X.X.X]:5060 Aliases: *: xxxxxx.xxxxxx.xx:* . *** status code: 0 ------------------------------------- kamailio log: ------------------------------------- ERROR: <core> [udp_server.c:400]: ERROR: udp_init: bind(7, 0x8e53f4, 16) on X.X.X.X: Cannot assign requested address ------------------------------------ Could I know which is the expected behaviour (about return codes) in latest version of Kamailio? Thanks a lot. -- Iñaki Baz Castillo <ibc(a)aliax.net>

1 3

git:master: pkg/kamailio/deb: lot of love to debian init scripts.
by I�aki Baz Castillo 10 Jun '11

10 Jun '11

Module: sip-router Branch: master Commit: cb30d96052a4ccf7ce9fec627785313cb13bc442 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=cb30d96… Author: Iñaki Baz Castillo <ibc(a)aliax.net> Committer: Iñaki Baz Castillo <ibc(a)aliax.net> Date: Fri Jun 10 19:17:25 2011 +0200 pkg/kamailio/deb: lot of love to debian init scripts. - init scripts under debian/, lenny/, lucid/ and squeeze/ unified. - fixed a bug in restart action: now it waits until kamailio has been stopped (using --retry 5 option in start-stop-daemon) rather than waiting an artificial fixed second (which is not enough when using memdbg/memlog causing kamailio not to start again). - some text formatting. - more LSB compliant (status codes). --- pkg/kamailio/deb/debian/kamailio.init | 299 ++++++++++++++++++-------------- pkg/kamailio/deb/lenny/kamailio.init | 284 +++++++++++++++++++----------- pkg/kamailio/deb/lucid/kamailio.init | 284 +++++++++++++++++++----------- pkg/kamailio/deb/squeeze/kamailio.init | 288 ++++++++++++++++++++----------- 4 files changed, 720 insertions(+), 435 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=cb3…

1 0

Debian/Ubuntu init scripts are out of date
by Iñaki Baz Castillo 10 Jun '11

10 Jun '11

Hi, there are 4 init scripts for debian and ubuntu under pkg/kamailio/deb/ folder. Most of them are different: sip-router/pkg/kamailio/deb$ ls -lrt */kamailio.init -rw-r--r-- 1 ibc ibc 4,8K 2011-04-27 13:47 debian/kamailio.init -rw-r--r-- 1 ibc ibc 4,2K 2011-06-01 01:22 lucid/kamailio.init -rw-r--r-- 1 ibc ibc 4,2K 2011-06-01 01:22 lenny/kamailio.init -rw-r--r-- 1 ibc ibc 4,2K 2011-06-09 17:02 squeeze/kamailio.init Is it ok if I try to unify all of them? -- Iñaki Baz Castillo <ibc(a)aliax.net>

1 1

git:3.1: debugger: safety check for pid list
by Daniel-Constantin Mierla 10 Jun '11

10 Jun '11

Module: sip-router Branch: 3.1 Commit: e23e5140bc90627ee7c4e15580cde037e3fefc11 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=e23e514… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Jun 10 11:19:44 2011 +0200 debugger: safety check for pid list - some event route blocks can be executed before all children initialization and the internal pid list structure is not created, disable debugging in this case (cherry picked from commit 35ef4b0d8f85f1e902e0d99d513f311ebd39bc6d) --- modules/debugger/debugger_api.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/modules/debugger/debugger_api.c b/modules/debugger/debugger_api.c index 5b4ff58..7fbfd0d 100644 --- a/modules/debugger/debugger_api.c +++ b/modules/debugger/debugger_api.c @@ -240,7 +240,7 @@ int dbg_cfg_trace(void *data) a = (struct action *)srevp[0]; msg = (struct sip_msg *)srevp[1]; - if(a==NULL || msg==NULL) + if(a==NULL || msg==NULL || _dbg_pid_list==NULL) return 0; an = dbg_get_action_name(a);

1 0

git:master: debugger: safety check for pid list
by Daniel-Constantin Mierla 10 Jun '11

10 Jun '11

Module: sip-router Branch: master Commit: 35ef4b0d8f85f1e902e0d99d513f311ebd39bc6d URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=35ef4b0… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Jun 10 11:19:44 2011 +0200 debugger: safety check for pid list - some event route blocks can be executed before all children initialization and the internal pid list structure is not created, disable debugging in this case --- modules/debugger/debugger_api.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/modules/debugger/debugger_api.c b/modules/debugger/debugger_api.c index 5b4ff58..7fbfd0d 100644 --- a/modules/debugger/debugger_api.c +++ b/modules/debugger/debugger_api.c @@ -240,7 +240,7 @@ int dbg_cfg_trace(void *data) a = (struct action *)srevp[0]; msg = (struct sip_msg *)srevp[1]; - if(a==NULL || msg==NULL) + if(a==NULL || msg==NULL || _dbg_pid_list==NULL) return 0; an = dbg_get_action_name(a);

1 0

[tracker] Comment added: Gentoo ebuild/pkg
by sip-router 09 Jun '11

09 Jun '11

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#134 - Gentoo ebuild/pkg User who did this - Claudio Furrer (caio) ---------- I don't think that keeping two ebuild specs, one for kamailio, and the other for ser, will be useful. Two packages, double mainterniship, common parameters, same Makefile, same source package.. hum.. I don't really undertand yet if sip-router project goal is to unify both branches or if we must treat it as a separated devel lines, kamailio or ser. Maybe it's a large ebuild and have many conditions to check whatever is a K or S flavour, but want to be adjusted to the Makefile. Regarding the k specific groups, you're right, I see them now, I'm going to add them. There is also a bit of work to be done about the "exclude" conditions. Thank you for you advice. It helps to make a better ebuild. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=134#comment220 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

← Newer
1
...
9
10
11
12
13
14
15
16
17
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev June 2011