Has anyone ever seen this? It looks like a load thing, because at weekends there are significantly less errors.

Has anyone ever seen this? It looks like a load thing, because at weekends there are significantly less errors.

Hi, we have a load balancer which is handling a lot of SIP traffic all day. There's always 20-40 Mbit SIP traffic going through. From time to time we see in our logs messages like these: Sep 16 09:46:28 ecker /usr/sbin/kamailio[25505]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7f2d9d6b3ce0,1321,0,46.237.225.126:5060 <http://46.237.225.126:5060>,16): Operation not permitted(1) Sep 16 09:46:38 ecker /usr/sbin/kamailio[25194]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7efc982b8fc8,420,0,82.113.121.183:35794 <http://82.113.121.183:35794>,16): Operation not permitted(1) Sep 16 09:46:40 ecker /usr/sbin/kamailio[25505]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7f2d9d6b3ce0,1338,0,5.158.137.9:55067 <http://5.158.137.9:55067>,16): Operation not permitted(1) Sep 16 09:46:44 ecker /usr/sbin/kamailio[25183]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7efc982d9f48,450,0,178.165.131.197:37515 <http://178.165.131.197:37515>,16): Operation not permitted(1) Sep 16 09:46:49 ecker /usr/sbin/kamailio[25643]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7f93fb624530,496,0,172.56.7.69:25643 <http://172.56.7.69:25643>,16): Operation not permitted(1) Sep 16 09:46:55 ecker /usr/sbin/kamailio[25335]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7f41632cda98,598,0,80.215.234.139:3396 <http://80.215.234.139:3396>,16): Operation not permitted(1) Sep 16 09:46:56 ecker /usr/sbin/kamailio[25345]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7f41632f4840,459,0,94.197.120.191:8225 <http://94.197.120.191:8225>,16): Operation not permitted(1) I know that these messages can be produced by iptables blocking the outbound traffic. But our outbound chain looks basically like this: root@ecker:~# iptables-save | grep OUTPUT :OUTPUT DROP [0:0] -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -j ACCEPT -A OUTPUT -m state --state INVALID -j DROP -A OUTPUT -o lo -m state --state NEW -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -m state --state NEW -j ACCEPT We don't have the nf_ct_sip module loaded, syslog doesn't say anything, and even clearing all iptables rules doesn't eliminate those errors. Has anyone ever seen this? It looks like a load thing, because at weekends there are significantly less errors.

Thanks, Sebastian _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hi, just to resolve this thread, we found the reason for the problem. It occurs, when we try sending out packets to a customer, which look identical to netfilter, at roughly the same time. Those could be for example forked calls to two extensions registered on the same device (a FRITZ Box for example). Then netfilter tries to insert the same packet into its conntrack table twice, causing a collision, leading to a rejection of one of the packets. We played around with different kernels, without success. The errors kept on coming as long as the nf_conntrack module was loaded, even if there was no iptables rule using it. The only solution right now seems to be a stateless firewall and unloading the module. Best Regards, Sebastian _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users