[SR-Users] Kamailio recvfrom out of bounds

[Daniel-Constantin Mierla]

Hello,

maxbuffer doesn't influence processing of udp traffic, because each SIP
message over UDP is handled at once, not internal buffering of many udp
packets.

You look at the statistics for network interface to see if there are
dropped received packets (ifconfig should show that).

What is the value for children parameter in kamailio.cfg?

CentOS has lots of hidden and strange limits, the next suggestion I
could do it to try on a Debian server

Cheers,
Daniel

On 28/09/15 19:07, José Seabra wrote:
> Hello Daniel,
>
> Indeed xlog doesn't print in syslog the sip message received and
> wireshak got it, that means that packet was received in network
> interface but kamailio didn't received the packet(as xlog didn't print
> that packet).
>
> Anyway i have configured the following parameters in sysctl
>
> net.ipv4.udp_rmem_min = 131072
> net.ipv4.udp_wmem_min = 131072
> net.core.netdev_max_backlog=1000
> net.core.rmem_max=67108864
> net.ipv4.udp_mem = 192576 256768 385152
>
> and also set maxbuffer=134190336 in my kamailio configuration.
>
> With these configurations I got an improvement but still below of what
> we need and even the CPU is between 65% and 70%  sleeping.
>
> Do you have any suggestion? the traffic average that interface
> receives now is 200mbs.
>
> The server network interface is 10GB.
>
> Any suggestion is welcome.
>
> Best Regards
> José Seabra
>
>
>
> 2015-09-27 17:08 GMT+01:00 Daniel-Constantin Mierla <miconda at gmail.com
> <mailto:miconda at gmail.com>>:
>
>     Hello,
>
>     first, be sure you run latest version of branch 4.3, there was a
>     fix for dialog since 4.3.2.
>
>     If a process in shown to run recvfrom() that means it waits for
>     kernel to pass a new upd packet to it -- recvfrom() is a function
>     from standard lib c.
>
>     Wireshark (like other sniffing tools) is capturing the network
>     traffic before the kernel passes it to application layer. If
>     wireshark see it, doesn't mean the application has received it
>     from kernel, it can still be dropped by firewall or other kernel
>     modules.
>
>     You can add a xlog() at the beginning of request_route to see what
>     requests are received by kamailio.
>
>     Cheers,
>     Daniel
>
>
>     On 27/09/15 15:52, José Seabra wrote:
>>     Hello Danel,
>>     Thank you for your response,
>>
>>     Well i don't have SELinux enabled and IPTables isn't running.
>>
>>     About kamailio configuration, Pike module isn't also enabled, the
>>     only thing that i have enabled to limit the number of concurrent
>>     calls  is the dialog module, counting the number of active
>>     dialogs and reject next new invites only  after it has reached
>>     the 10.000 simultaneous calls.
>>
>>     The strange behavior is that kamailio only stop processing some
>>     sip messages like Byes and 200 Ok after more or less 40 seconds
>>     after siptester start sending calls.
>>
>>     And i can see several cases in wireshark that kamailio receives
>>     BYES/200OK from interface B(Carriers interface) but it isn't
>>     forward to Interface A(customer interface), if i make for example
>>     20cps i don't have this issue, all packets are handled correctly
>>     and there isn't 408 requests timeouts.
>>
>>
>>     Best Regards
>>     José Seabra
>>
>>      
>>
>>     2015-09-27 13:52 GMT+01:00 Daniel-Constantin Mierla
>>     <miconda at gmail.com <mailto:miconda at gmail.com>>:
>>
>>         The tmp variable is not intialized by default, so it can be
>>         anything therefore the out of bounds value. It used only when
>>         printing some errors, so it didn't get a proper value as no
>>         such error was printed for you case.
>>
>>         The backtrace shows the process in in recvfrom(), so it waits
>>         for traffic from network. That is the case when the
>>         processing of former sip message was finished and now
>>         Kamailio waits to receive another one.
>>
>>         If you run centos, be sure you don't have limits in selinux
>>         rules - better disable it completely and test again. Also, be
>>         sure you don't have limits in the firewall, especially
>>         contrack module and sip firewall modules in the kernel.
>>
>>         In kamailio.cfg, if you have pike module, be sure you don't
>>         drop good packet with this module.
>>
>>         Cheers,
>>         Daniel
>>
>>
>>         On 25/09/15 19:53, José Seabra wrote:
>>>         Adding more information to my last email, when kamailio
>>>         starts receiving calls, after more or less 40 seconds it
>>>         stops processing some sip messages.
>>>
>>>         I'm using the kamailio version 4.3.2
>>>
>>>         Best Regards
>>>

>     		
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150928/0d2ce220/attachment.html>