sr-dev December 2011

sr-dev@lists.kamailio.org

32 participants
230 discussions

[tracker] Comment added: textopsx:msg_apply_changes() can corrupt incoming TCP message buffer
by sip-router 05 Dec '11

05 Dec '11

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#185 - textopsx:msg_apply_changes() can corrupt incoming TCP message buffer User who did this - Hugh Waite (hugh.waite) ---------- I have applied your latest patch to our 3.2 branch and cannot recreate the corruption issue with msg_apply_changes(). Thanks Daniel! ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=185#comment454 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

git:master: modules_k/siputils: faster implementation of is_uri_user_e164 test
by Juha Heinanen 04 Dec '11

04 Dec '11

Module: sip-router Branch: master Commit: 1226a51d817481e6ebde455e10e0949987fe45e9 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=1226a51… Author: Juha Heinanen <jh(a)tutpro.com> Committer: Juha Heinanen <jh(a)tutpro.com> Date: Sun Dec 4 13:42:16 2011 +0200 modules_k/siputils: faster implementation of is_uri_user_e164 test --- modules_k/siputils/checks.c | 14 ++++++++++---- 1 files changed, 10 insertions(+), 4 deletions(-) diff --git a/modules_k/siputils/checks.c b/modules_k/siputils/checks.c index 52db0ae..eb04e50 100644 --- a/modules_k/siputils/checks.c +++ b/modules_k/siputils/checks.c @@ -494,14 +494,20 @@ int w_is_uri_user_e164(struct sip_msg* _m, char* _sp, char* _s2) int is_uri_user_e164(struct sip_msg *msg, str *uri) { - struct sip_uri puri; + char *chr; + str user; - if (parse_uri(uri->s, uri->len, &puri) < 0) { + chr = memchr(uri->s, ':', uri->len); + if (chr == NULL) { LM_ERR("parsing URI failed\n"); return -1; - } + }; + user.s = chr + 1; + chr = memchr(user.s, '@', uri->len - (user.s - uri->s)); + if (chr == NULL) return -1; + user.len = chr - user.s; - return e164_check(&(puri.user)); + return e164_check(&user); } /*

1 0

why sip_msg is passed to is_uri_user_e164?
by Juha Heinanen 04 Dec '11

04 Dec '11

while doing a faster version of is_uri_user_e164, i noticed that the code had been recently changed. in particular, struct sip_msg is now passed as argument to int is_uri_user_e164(struct sip_msg* msg, str *uri); why is that, because the function makes no reference to msg? can i remove it? -- juha

1 0

[tracker] Comment added: Crash if t_release() is executed after t_relay_to(), when this last returns -1
by sip-router 02 Dec '11

02 Dec '11

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#184 - Crash if t_release() is executed after t_relay_to(), when this last returns -1 User who did this - Daniel-Constantin Mierla (miconda) ---------- It can detect, but we don't do it :-), since people like this kind of 'trick' from time to time. In 1.x, there was -C option which did this strict checking, perhaps we should add it back. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=184#comment453 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] Comment added: textopsx:msg_apply_changes() can corrupt incoming TCP message buffer
by sip-router 02 Dec '11

02 Dec '11

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#185 - textopsx:msg_apply_changes() can corrupt incoming TCP message buffer User who did this - Daniel-Constantin Mierla (miconda) ---------- I went for a different approach, cloning the content from TCP stream in a local buffer before calling receive_msg() -- this will ensure same behavior as for udp and sctp. Topoh module does also changes in the buffer, so this solution should make all safe, without touching textopsx, topoh or tm. Had no time/environment for test quickly, if you can do it and report if all is fine, then will great and will speed up backporting. Here is the link to commit in master branch: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=6ebd0a6… ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=185#comment452 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

git:master: core/tcp: clone received message over tcp in local buffer
by Daniel-Constantin Mierla 02 Dec '11

02 Dec '11

Module: sip-router Branch: master Commit: 6ebd0a6bf1cbacf73f45ff42d368f22304bff11b URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=6ebd0a6… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Dec 2 13:05:55 2011 +0100 core/tcp: clone received message over tcp in local buffer - receive_msg() got pointer inside tcp stream as rcv buffer, linking it to msg->buf, but there are places where the content of msg->buf is changed (topoh, msg_apply_changes) which can result in corruption of tcp stream content - added a wrapper function receive_tcp_msg() to clone the content and have same behaviour as for udp or sctp - reported by Hugh Waite, FS#185 --- tcp_read.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 files changed, 59 insertions(+), 3 deletions(-) diff --git a/tcp_read.c b/tcp_read.c index 1ba6cbb..c180301 100644 --- a/tcp_read.c +++ b/tcp_read.c @@ -848,6 +848,62 @@ skip: } +/** + * @brief wrapper around receive_msg() to clone the tcpbuf content + * + * When receiving over TCP, tcpbuf points inside the TCP stream buffer, but during + * processing of config, msg->buf content might be changed and may corrupt + * the content of the stream. Safer, make a clone of buf content in a local + * buffer and give that to receive_msg() to link to msg->buf + */ +int receive_tcp_msg(char* tcpbuf, unsigned int len, struct receive_info* rcv_info) +{ +#ifdef DYN_BUF + char *buf = NULL; +#else + static char *buf = NULL; + static unsigned int bsize = 0; +#endif + int blen; + + /* min buffer size is BUF_SIZE */ + blen = len; + if(blen < BUF_SIZE) + blen = BUF_SIZE; + +#ifdef DYN_BUF + buf=pkg_malloc(blen+1); + if (buf==0) { + LM_ERR("could not allocate receive buffer\n"); + return -1; + } +#else + /* allocate buffer when needed + * - no buffer yet + * - existing buffer too small (min size is BUF_SIZE - to accomodate most + * of SIP messages; expected larger for HTTP/XCAP) + * - existing buffer too large (e.g., we got a too big message in the past, + * let's free it) + * + * - also, use system memory, not to eat from PKG (same as static buffer + * from PKG pov) + */ + if(buf==NULL || bsize < blen || blen < bsize/2) { + if(buf!=NULL) + free(buf); + buf=malloc(blen+1); + if (buf==0) { + LM_ERR("could not allocate receive buffer\n"); + return -1; + } + bsize = blen; + } +#endif + + memcpy(buf, tcpbuf, len); + buf[len] = '\0'; + return receive_msg(buf, len, rcv_info); +} int tcp_read_req(struct tcp_connection* con, int* bytes_read, int* read_flags) { @@ -932,7 +988,7 @@ again: /* if we are here everything is nice and ok*/ resp=CONN_RELEASE; #ifdef EXTRA_DEBUG - DBG("calling receive_msg(%p, %d, )\n", + DBG("receiving msg(%p, %d, )\n", req->start, (int)(req->parsed-req->start)); #endif /* rcv.bind_address should always be !=0 */ @@ -970,12 +1026,12 @@ again: if (unlikely(req->state==H_HTTP11_CHUNK_FINISH)){ /* http chunked request */ req->body[req->content_len] = 0; - ret = receive_msg(req->start, + ret = receive_tcp_msg(req->start, req->body + req->content_len - req->start, &con->rcv); }else #endif - ret = receive_msg(req->start, req->parsed-req->start, + ret = receive_tcp_msg(req->start, req->parsed-req->start, &con->rcv); if (unlikely(ret < 0)) {

1 0

[tracker] Comment added: Crash if t_release() is executed after t_relay_to(), when this last returns -1
by sip-router 02 Dec '11

02 Dec '11

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#184 - Crash if t_release() is executed after t_relay_to(), when this last returns -1 User who did this - Iñaki Baz Castillo (ibc) ---------- Hi Daniel, let me a question: Theorically Kamailio should fail to start if t_release() is called from any block but REQUEST_ROUTE: {"t_release", w_t_release, 0, 0, REQUEST_ROUTE}, So I assume that, during Kamailio startup, it can not detect whether a function in a route[x] block could be called from another kind of block (i.e. failure_route[x]), am I right? Thanks a lot. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=184#comment451 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 closed: Kamailio 3.2.1 Dialog Crash
by sip-router 02 Dec '11

02 Dec '11

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#186 - Kamailio 3.2.1 Dialog Crash User who did this - Daniel-Constantin Mierla (miconda) Reason for closing: Fixed More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=186 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] Comment added: Kamailio 3.2.1 Dialog Crash
by sip-router 02 Dec '11

02 Dec '11

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#186 - Kamailio 3.2.1 Dialog Crash User who did this - Daniel-Constantin Mierla (miconda) ---------- Ok, I will close this one, reopen if appears again. Jasmin, I will change the log level for that message. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=186#comment450 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 closed: Crash if t_release() is executed after t_relay_to(), when this last returns -1
by sip-router 02 Dec '11

02 Dec '11

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#184 - Crash if t_release() is executed after t_relay_to(), when this last returns -1 User who did this - Daniel-Constantin Mierla (miconda) Reason for closing: Fixed Additional comments about closing: In master and soon in 3.2 - reopen if still an issue. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=184 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
...
16
17
18
19
20
21
22
23
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev December 2011