sr-dev June 2010

sr-dev@lists.kamailio.org

26 participants
164 discussions

git:andrei/tcp_tls_changes: tcp: force eof after read if write side hangup

by Andrei Pelinescu-Onciul

Module: sip-router Branch: andrei/tcp_tls_changes Commit: 28e313250503d6f8d06ebab15c8421c40e7f0fe4 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=28e3132… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Sun Jun 20 19:40:55 2010 +0200 tcp: force eof after read if write side hangup Even if POLLRDHUP is not supported, but we detected a write side close (POLLHUP) or an error (POLLERR) or such an event was previously detected by tcp_main (F_CONN_EOF_SEEN), force connection closing after reading all the data in the socket buffer. In this case we can close() after the first short read and we save an extra system call (a read() that returns 0). --- tcp_read.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/tcp_read.c b/tcp_read.c index 4881844..2d42cb9 100644 --- a/tcp_read.c +++ b/tcp_read.c @@ -1011,13 +1011,13 @@ repeat_1st_read: con, con->id, atomic_get(&con->refcnt)); goto read_error; } + read_flags=(( #ifdef POLLRDHUP - read_flags=(((events & POLLRDHUP) | + (events & POLLRDHUP) | +#endif /* POLLRDHUP */ + (events & (POLLHUP|POLLERR)) | (con->flags & (F_CONN_EOF_SEEN|F_CONN_FORCE_EOF))) && !(events & POLLPRI))? RD_CONN_FORCE_EOF: 0; -#else /* POLLRDHUP */ - read_flags=0; -#endif /* POLLRDHUP */ #ifdef USE_TLS repeat_read: #endif /* USE_TLS */

14 years, 6 months

git:andrei/tcp_tls_changes: tls: deal with internal openssl buffering

by Andrei Pelinescu-Onciul

Module: sip-router Branch: andrei/tcp_tls_changes Commit: 0d8b211d146dad87a5751928b44c6f791352559a URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=0d8b211… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Sun Jun 20 18:58:58 2010 +0200 tls: deal with internal openssl buffering SSL_read() will not only buffer data internally (behaviour exacerbated by setting readahead to 1), but will also return the decrypted data on a record basis (even if readahead is 1 and it has read several records, it will return only the decrypted data from the current record). SSL_pending() can be used to see if there is more data buffered internally only if readaahead is not set and if the SSL_read() returned because it did not have enough space in the output buffer (it's useless for any other case because it returns the bytes in the current record that can be retrieved immediately and hence if SSL_read() stopped at a record boundary it will return 0). The solution is to repeat the SSL_read() call until the output buffer is completely filled or error (repeat it even if it did consume the whole input, it could still have the data buffered internally). In the case when the output buffer is completely filled, the entire tls_read_f() call should be retried as soon as more space becomes available (set RD_CONN_REPEAT_READ). Fixes read data delayed until the next packet arrives or possible lost reads (if no other data is sent and part of the previous data is buffered inside openssl). --- modules/tls/tls_server.c | 178 +++++++++++++++++++++++++++++++++------------ modules/tls/tls_server.h | 1 - 2 files changed, 130 insertions(+), 49 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=0d8…

14 years, 6 months

git:andrei/tcp_tls_changes: tcp: don' t reset read_flags on RD_CONN_REPEAT_READ

by Andrei Pelinescu-Onciul

Module: sip-router Branch: andrei/tcp_tls_changes Commit: 21b8cf904aa6abe20d930385bf912ccf66666341 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=21b8cf9… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Sun Jun 20 19:20:12 2010 +0200 tcp: don't reset read_flags on RD_CONN_REPEAT_READ Allow flags value propagation between tcp_read*() that asked to be repeated (RD_CONN_REPEAT_READ). This allows an optimization in the tls read code: when repeating a tls_read, don't try a tcp read syscall if the previous attempt did get the whole socket receive buffer (RD_CONN_SHORT_READ) or detected EOF (use only the buffered data if any). --- tcp_read.c | 16 ++++++++-------- 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/tcp_read.c b/tcp_read.c index 441521f..4881844 100644 --- a/tcp_read.c +++ b/tcp_read.c @@ -137,8 +137,8 @@ static ticks_t tcp_reader_prev_ticks; * RD_CONN_FORCE_EOF. * RD_CONN_REPEAT_READ - the read should be repeated immediately * (used only by the tls code for now). - * Note: RD_CONN_SHORT_READ & RD_CONN_EOF must be cleared - * before calling this function. + * Note: RD_CONN_SHORT_READ & RD_CONN_EOF _are_ not cleared internally, + * so one should clear them before calling this function. * @return number of bytes read, 0 on EOF or -1 on error, * on EOF it also sets c->state to S_CONN_EOF. * (to distinguish from reads that would block which could return 0) @@ -955,14 +955,14 @@ again: con, con->id, atomic_get(&con->refcnt)); goto con_error; } -#ifdef USE_TLS -repeat_1st_read: -#endif /* USE_TLS */ /* if we received the fd there is most likely data waiting to * be read => process it first to avoid extra sys calls */ read_flags=((con->flags & (F_CONN_EOF_SEEN|F_CONN_FORCE_EOF)) && !(con->flags & F_CONN_OOB_DATA))? RD_CONN_FORCE_EOF :0; +#ifdef USE_TLS +repeat_1st_read: +#endif /* USE_TLS */ resp=tcp_read_req(con, &n, &read_flags); if (unlikely(resp<0)){ /* some error occured, but on the new fd, not on the tcp @@ -1011,9 +1011,6 @@ repeat_1st_read: con, con->id, atomic_get(&con->refcnt)); goto read_error; } -#ifdef USE_TLS -repeat_read: -#endif /* USE_TLS */ #ifdef POLLRDHUP read_flags=(((events & POLLRDHUP) | (con->flags & (F_CONN_EOF_SEEN|F_CONN_FORCE_EOF))) @@ -1021,6 +1018,9 @@ repeat_read: #else /* POLLRDHUP */ read_flags=0; #endif /* POLLRDHUP */ +#ifdef USE_TLS +repeat_read: +#endif /* USE_TLS */ resp=tcp_read_req(con, &ret, &read_flags); if (unlikely(resp<0)){ read_error:

14 years, 6 months

[ openser-Bugs-3018979 ] SIP UA can't receive 500(Internal Server Error)

by SourceForge.net

Bugs item #3018979, was opened at 2010-06-21 12:08 Message generated for change (Comment added) made by klaus_darilion You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=3018979&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: xhu xhu (xhujohnson) Assigned to: Nobody/Anonymous (nobody) Summary: SIP UA can't receive 500(Internal Server Error) Initial Comment: SIP UA can't receive 500(Internal Server Error) after sending the REGISTER request with the equal CSeq header field value to the last value of CSeq or lower than the number. The details can be seen as follows: 1 Test topology: NUT(REG && PX) UA11 UA12 DNS | | | | IP : 3ffe:501:ffff:50::50 3ffe:501:ffff:1::1 3ffe:501:ffff:2::2 3ffe:501:ffff:4::1 aor-uri : ss.under.test.com UA11(a)under.test.com UA12(a)under.test.com contact-uri : UA11(a)node.under.test.com UA12(a)node11.under.test.com 2 tcpdump file can be seen in "SIP Registrar- REGISTER request with the equal CSeq value to or lower than the last value of CSeq" attachment 3 openser configuration file can be seen in "openser.cfg" attachment ---------------------------------------------------------------------- >Comment By: Klaus Darilion (klaus_darilion) Date: 2010-06-21 13:07 Message: As far as I know there are some CSeq checks. But I think there is a short time intervall were the same CSeq is allowed to handle retransmissions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=3018979&group_…

14 years, 6 months

[ openser-Bugs-3018975 ] SIPv6 UA can't receive a 423 (Interval Too Brief) response

by SourceForge.net

Bugs item #3018975, was opened at 2010-06-21 11:55 Message generated for change (Comment added) made by klaus_darilion You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=3018975&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: xhu xhu (xhujohnson) Assigned to: Nobody/Anonymous (nobody) Summary: SIPv6 UA can't receive a 423 (Interval Too Brief) response Initial Comment: SIPv6 UA can't receive a 423 (Interval Too Brief) response from openser-1.3.4-12.fc13.i686 SIPv6 Registrar Server when expiration of a REGISTER request is less than a registrar-configured minimum.The details can be seen as follows. Is it a bug or can be resolved by modifying configuration file? 1 Test topology: NUT(REG && PX) UA11 UA12 DNS | | | | IP : 3ffe:501:ffff:50::50 3ffe:501:ffff:1::1 3ffe:501:ffff:2::2 3ffe:501:ffff:4::1 aor-uri : ss.under.test.com UA11(a)under.test.com UA12(a)under.test.com contact-uri : UA11(a)node.under.test.com UA12(a)node11.under.test.com 2 the tcpdump file can be seen in "SIP Registrar- Expiration of REGISTER request less than a registrar-configured minimum" attachment 3 openser-1.3.4-12 configuration file can be seen in openser.cfg attachment. I have added the following block into the openser.cfg " modparam("registrar", "default_expires", 3600) modparam("registrar", "min_expires", 60) " ---------------------------------------------------------------------- >Comment By: Klaus Darilion (klaus_darilion) Date: 2010-06-21 13:04 Message: Hi! 1. Openser 1.3 is rather old and not supported anymore. Anyway, the behavior has not changed in newer versions. 2. Openser/Kamailio/sip-router does not have an implicit mechanism to send 423 - it uses a different approach. It just overrides the user-provided expires value and set a different one. Take a look at the 200 OK response - the Contact header has a different expire value (660) then the requested one (30). 3. if you really need 423, you have to script it. e.g. in Kamilio 3.0 Syntax: if ($hdr[Expires] < 3600) { append_to_reply("Min-Expires: 3600\r\n"); sl_send_reply("423","Intervall to short"); exit; } 4. For such discussions please use the kamailio mailing list ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=3018975&group_…

14 years, 6 months

[ openser-Bugs-3018979 ] SIP UA can't receive 500(Internal Server Error)

by SourceForge.net

Bugs item #3018979, was opened at 2010-06-21 18:08 Message generated for change (Tracker Item Submitted) made by xhujohnson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=3018979&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: xhu xhu (xhujohnson) Assigned to: Nobody/Anonymous (nobody) Summary: SIP UA can't receive 500(Internal Server Error) Initial Comment: SIP UA can't receive 500(Internal Server Error) after sending the REGISTER request with the equal CSeq header field value to the last value of CSeq or lower than the number. The details can be seen as follows: 1 Test topology: NUT(REG && PX) UA11 UA12 DNS | | | | IP : 3ffe:501:ffff:50::50 3ffe:501:ffff:1::1 3ffe:501:ffff:2::2 3ffe:501:ffff:4::1 aor-uri : ss.under.test.com UA11(a)under.test.com UA12(a)under.test.com contact-uri : UA11(a)node.under.test.com UA12(a)node11.under.test.com 2 tcpdump file can be seen in "SIP Registrar- REGISTER request with the equal CSeq value to or lower than the last value of CSeq" attachment 3 openser configuration file can be seen in "openser.cfg" attachment ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=3018979&group_…

14 years, 6 months

[ openser-Bugs-3018975 ] SIPv6 UA can't receive a 423 (Interval Too Brief) response

by SourceForge.net

Bugs item #3018975, was opened at 2010-06-21 17:55 Message generated for change (Tracker Item Submitted) made by xhujohnson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=3018975&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: xhu xhu (xhujohnson) Assigned to: Nobody/Anonymous (nobody) Summary: SIPv6 UA can't receive a 423 (Interval Too Brief) response Initial Comment: SIPv6 UA can't receive a 423 (Interval Too Brief) response from openser-1.3.4-12.fc13.i686 SIPv6 Registrar Server when expiration of a REGISTER request is less than a registrar-configured minimum.The details can be seen as follows. Is it a bug or can be resolved by modifying configuration file? 1 Test topology: NUT(REG && PX) UA11 UA12 DNS | | | | IP : 3ffe:501:ffff:50::50 3ffe:501:ffff:1::1 3ffe:501:ffff:2::2 3ffe:501:ffff:4::1 aor-uri : ss.under.test.com UA11(a)under.test.com UA12(a)under.test.com contact-uri : UA11(a)node.under.test.com UA12(a)node11.under.test.com 2 the tcpdump file can be seen in "SIP Registrar- Expiration of REGISTER request less than a registrar-configured minimum" attachment 3 openser-1.3.4-12 configuration file can be seen in openser.cfg attachment. I have added the following block into the openser.cfg " modparam("registrar", "default_expires", 3600) modparam("registrar", "min_expires", 60) " ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=3018975&group_…

14 years, 6 months

bug in topoh mudule ?

by jerome.marchet＠orange-ftgroup.com

14 years, 6 months

[tracker] Comment added: presence_xml with db_postgres

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#77 - presence_xml with db_postgres User who did this - Andrey A Berekelya (bandry) ---------- Yes. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=77#comment88 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.

14 years, 6 months

[tracker] Comment added: presence_xml with db_postgres

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#77 - presence_xml with db_postgres User who did this - Klaus Darilion (klaus3000) ---------- Aha. So the problem is when reading BLOB from DB, not when storing BLOB to DB, correct? ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=77#comment87 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.

14 years, 6 months

← Newer
1
...
5
6
7
8
9
10
11
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev June 2010