Hi Jeff,
Have you checked /proc/sys/net/netfilter/nf_conntrack_expect_max? On
our (Debian) boxes the default is 256 which is way too low, we set it
to 65536. Also, we set it at the end of /etc/rc.local because setting
it in /etc/sysctl.conf doesn't seem to work.
Regards,
Henk Hesselink
On 2/21/13 1:11 PM, Saúl Ibarra Corretgé wrote:
Hi Jeff,
On Feb 8, 2013, at 10:08 PM, Jeff Pyle wrote:
Hi Muhammed,
On Fri, Feb 8, 2013 at 3:19 PM, Muhammad Shahzad <[email protected]> wrote:
In my previous experience, i see this error due to one of following reasons.
1. The media ports you have specified in media proxy configuration overlaps
some other service port range, e.g. in case you are running media proxy and
asterisk on same machine and RTP port range of asterisk overlaps media proxy
port range.
Asterisk is running on the same machine.
/etc/asterisk/rtp.conf contains:
rtpstart=16384
rtpend=20480
/etc/mediaproxy/config.ini contains:
port_range = 20482:32768
Having said that, one relay machine does see more Asterisk activity than the
other. Still it's activity is in the calls-per-minute range, not
calls-per-second.
2. Check dmesg, do you see this message or any relevant message from network
stack or ethernet driver there?
No. The last relevant line is:
[ 44.905812] ctnetlink v0.93: registering with nfnetlink.
Most "irrelevant" lines are promiscuous mode reports from my tshark testing.
Otherwise,
[40380457.905028] Machine check events logged
The machine's uptime is just over 500 days.
3. Check syslog and see if you get following message or something similar from
nf_conntrack.
nf_conntrack: table full, dropping packet
Nothing of the sort.
4. Check ulimit and selinux, but seems from your previous posts on this issue
that they are fine.
ulimit is handled by the application itself I believe. selinux has never been
configured.
5. Do you have any SNAT or Multicast related rule in iptables?
No. There is no *nat table defined at all, only *mangle (to remark DSCP EF)
and *filter (basic INPUT security). No mention of multicast anywhere. There
is IPv6 but it's not used for this application.
Saúl,
I'd be happy to add a logging line, but I'm not familiar enough with Python to
know what to add where. Guidance is welcome!
John provided me with some logs which I've inspected. The problem is still not
100% clear to me but I have a couple of suspicions.
I spent some time trying to understand what is going on, since it's really
uncommon to get EPERM for a datagram socket.
Please find attached a patch which logs and ignores the error. What I'm
interested in seeing is if it would actually work if the error is just ignored.
You seem to be running an older MediaProxy release, so the attached patch may
not apply cleanly. It should be easy to manually apply though.
Now, as for the error reason, the only plausible explanation in case no
firewall is being used is a problem with traffic pacing. Basically there seems
to be a chance of getting EPERM when sending data over a UDP socket in case the
sender is too quick and kernel buffers are full. We do have a (undocumented)
setting for this: userspace_transmit_every in the [relay] section. The default
value is 1, which means every packet would be relayed in user-space until the
conntrack rule has been established. Please also test setting that value to 4,
which means that only one out of every 4 packets will be sent to the
destination. Since bidirectional media is not yet established (otherwise there
would be a conntrack rule) this shouldn't be harmful.
Recap: please apply the supplied patch and run these tests:
- Just run the current config, watch for the log lines and see if audio flows
regardless
- Set userspace_transmit_every = 4 in the [relay] section of the configuration
file
Please let me know how testing goes.
Regards,
--
Saúl Ibarra Corretgé
AG Projects
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
