Thanks. your suggestions worked!
Amit.

On Thu, Jan 3, 2013 at 5:15 PM, Klaus Darilion <klaus.mailinglists@pernau.at> wrote:
Ups.


On 03.01.2013 15:11, Klaus Darilion wrote:
How much traffic do you want to send?

When does the problem happen? At which message size does it happen?

I just wonder that the normal options which works for us do not work for
you and t
and the problem is code related.

1. Check if Kamailio really uses the buffer size you have configured (via sercmd config framework):
# kamctl sercmd cfg.get tcp rd_buf_size

2. Test on which message size the problems start. Attached is a perl script which allows you to generate OPTIONS messages with a specified message size, e.g:

# ./send-tcp-message.pl 127.0.0.1:5060 2048


regards
Klaus


regards
Klaus

On 03.01.2013 14:21, Amit Elbaz wrote:
I increased tcp_rd_buf_size, but it did not help.
I don't think this is the problem.

In tcp_read.c:
int tcp_read(struct tcp_connection *c, int* flags)
{
int bytes_free, bytes_read;
struct tcp_req *r;
int fd;

r=&c->req;
fd=c->fd;
bytes_free=r->b_size- (int)(r->pos - r->buf);
if (unlikely(bytes_free==0)){
LOG(L_ERR, "ERROR: tcp_read: buffer overrun, dropping\n");
r->error=TCP_REQ_OVERRUN;
return -1;
}

how to i increase r->b_size ?

Thanks for you help, Amit.

On Wed, Jan 2, 2013 at 6:51 PM, Klaus Darilion
<klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>
wrote:

    Hi!

    -b is the receive buffer of the socket in the OS (for UDP tweaking,
    I do not know if this is relevant for TCP), so not related to this
    problem as this problem happens inside Kamailio.

    Actually 15K is rather small, really strange that you get errors.
    So, I did some tests:

    1. tcp_rd_buf_size must be increased. The documentation is bad as it
    meantions "TCP datagram" but actually means the maximum size of SIP
    (or HTTP) message that can be received.

    2. tcp_rd_buf_size is internally limited to 16MBytes. If you need
    more, you have to change the code in:
    tcp_options.c:  { "rd_buf_size", CFG_VAR_INT | CFG_ATOMIC, 512,
    16777216,  0,         0,

    3. If you use real large message you may need to increase the
    private memory, and if you forward it with tm module, also the
    shared memory.

    regards
    Klaus


    Am 02.01.2013 13:59, schrieb Amit Elbaz:
    this still does not solve the problem.
    I've also tried running Kamailio with *-b 32768* option.

    here are the logs:

    Jan  2 14:54:24 debdev kamailio[2580 <tel:%5B2580>]: ERROR: <core>
    [tcp_read.c:344]: ERROR: tcp_read: buffer overrun, dropping
    Jan  2 14:54:24 debdev kamailio[2580 <tel:%5B2580>]: ERROR: <core>
    [tcp_read.c:1127]: ERROR: tcp_read_req: error reading

    Thanks for your help.

    On Wed, Jan 2, 2013 <tel:2013> at 1:17 PM, Andrew Pogrebennyk
    <apogrebennyk@sipwise.com <mailto:apogrebennyk@sipwise.com>> wrote:

        Hi,
        you may try changing the tcp_rd_buf_size and tcp_conn_wq_max:

http://www.kamailio.org/wiki/cookbooks/3.3.x/core#tcp_conn_wq_max

        And since this in development mailing list I'd like to point
        at what
        seem an iaccuracy in documentation: several options refer to
        the core
        parameter called tcp_write_buf, which isn't described in the
        cookbook:

        tcp_conn_wq_max
        Maximum bytes queued for write allowed per connection.
        Attempting to
        queue more bytes would result in an error and in the
        connection being
        closed (too slow). If *tcp_write_buf* is not enabled, it has
        no effect.

        I hope Daniel or someone who knows reads this..

        BR,
        Andrew

        On 01/02/2013 10:38 AM, Amit Elbaz wrote:
        > Hi,
        >
        > While sending a big TCP SIP message (15K+), I get "tcp_read:
        buffer
        > overrun, dropping" message.
        > this happens after a few fragments have been sent, and then
        i get this
        > message and the connection resets.
        > is it possible to set the max-buffer size through
        configuration? if so,
        > where?
        >
        > Thanks, Amit.
        >
        >
        > _______________________________________________
        > sr-dev mailing list
        > sr-dev@lists.sip-router.org
<mailto:sr-dev@lists.sip-router.org>
        > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
        >


        _______________________________________________
        sr-dev mailing list
        sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
        http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev




    _______________________________________________
    sr-dev mailing list
    sr-dev@lists.sip-router.org  <mailto:sr-dev@lists.sip-router.org>
    http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev



_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev