Koozali.org: home of the SME Server
Obsolete Releases => SME VoIP (Asterisk, SAIL etc) => Topic started by: groutley on August 12, 2011, 03:10:29 AM
-
Hi S.
2 days ago I started getting emails every 5 minutes from SAIL..
titled... "Cron <root@l2nuxsvr> perl /opt/sark/scripts/perlarp.pl"
The email contains..
sendto in send_ip_packet: sendto(5, packet, 28, 0, 0.0.0.1, 16) => Invalid argument
sendto in send_ip_packet: sendto(4, packet, 40, 0, 0.0.0.1, 16) => Invalid argument
sendto in send_ip_packet: sendto(5, packet, 28, 0, 0.0.0.2, 16) => Invalid argument
sendto in send_ip_packet: sendto(4, packet, 40, 0, 0.0.0.2, 16) => Invalid argument
sendto in send_ip_packet: sendto(5, packet, 28, 0, 0.0.0.3, 16) => Invalid argument
sendto in send_ip_packet: sendto(4, packet, 40, 0, 0.0.0.3, 16) => Invalid argument
.
.
sendto in send_ip_packet: sendto(4, packet, 40, 0, 0.0.0.255, 16) => Invalid argument
sendto in send_ip_packet: sendto(5, packet, 28, 0, 0.0.0.255, 16) => Invalid argument
sendto in send_ip_packet: sendto(4, packet, 40, 0, 0.0.0.255, 16) => Invalid argumentFor now I have commented out line 2 in /etc/cron.d/sark to stop the flooding of emails..
but perhaps there is a better action to address the issue ?
These emails seemed to start after I made a configuration change to a call group, but perhaps that is co-incidental.
I cannot see any error in the change I made.
I was running SAIL 3.1.0.116 and have since upgraded to .127
I have stopped SAIL, committed and restarted, as well as rebooted the server.
but nothing stopped these emails (apart from stopping the script from running).
G
-
Hi,
The solution is to edit your cron template.
I tried creating an account on the new SAIL forum to notify Jeff, but never received approval from the forum administrator.
Best,
-
Hi Franco,
thanks for the reply...
The solution is to edit your cron template.
can you be a bit more specific on which template and what to edit in it ?
G
-
Sorry Groutley,
I wasn't specific because I removed sail completely.
This is only one of the few bugs I found.
Basically you need to edit the sail template inside /etc/cron.d/
Just put a # in front of the line that leads to the script.
Best,
-
Thanks Franko,
sounds like exactly what I have done already.. as stated in my original post...
"For now I have commented out line 2 in /etc/cron.d/sark to stop the flooding of emails.."
But I am hoping that perhaps the source of the problem might be able to be isolated as opposed to merely masking the reporting of it.
G
-
It's broken, and trying to scan invalid ranges.
And you are isolating the problem by commenting out from cron, so it does not run anymore.
Sorry I've read your first post too fast and went straight to the answer.
Best,
-
hi G
Odd that perlarp is giving an error. It doesn't do much; just runs an nmap and then pings what nmap finds. Can you uncomment the print statements in it, run it from the console and send the output to us here at admin@aelintra.com
Kind Regards
S
-
Hi Jeff,
I had not got around to doing as requested with travel, work etc..
But I just upgraded my SME server to v8b7 level via YUM, and I upgraded SAIL to 3.1.0-140
one of which obviously removed the 'commented crond' task..
So I am again flooded with an email every 5 minutes due to this..
I sent the console output of manually running the /opt/sark/scripts/perlarp.pl script as requested.
I will comment out the script again to save my sanity, but look forward to anything you might offer to solve the problem.
Note: I am not running IPV6.. just straight IPV4
-
HI Gordon
Copy and paste this somewhere on your box.
#!/usr/bin/perl
use lib '/opt/sark/perl/modules';
use strict;
use sark::SarkSubs;
my $subnet = SarkSubs::ret_subnet();
print "subnet $subnet \n";
Run it with
perl {name.you.gave.it}
post the output
Kind Regards
S
-
[root@l2nuxsvr ~]# perl sarktool
subnet 0.0.0.0
[root@l2nuxsvr ~]#
-
what does ifconfig give?
-
[root@l2nuxsvr ~]# ifconfig
br0 Link encap:Ethernet HWaddr 00:14:85:2E:82:A8
inet addr:192.168.37.252 Bcast:192.168.37.255 Mask:255.255.255.0
inet6 addr: fe80::214:85ff:fe2e:82a8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1488175 errors:0 dropped:0 overruns:0 frame:0
TX packets:1653890 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:220091412 (209.8 MiB) TX bytes:1550617269 (1.4 GiB)
eth0 Link encap:Ethernet HWaddr 00:14:85:2E:82:A8
inet6 addr: fe80::214:85ff:fe2e:82a8/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:1488451 errors:0 dropped:2 overruns:0 frame:0
TX packets:1653929 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:221618055 (211.3 MiB) TX bytes:1550630995 (1.4 GiB)
Interrupt:177
eth1 Link encap:Ethernet HWaddr 00:80:5F:F5:8A:1B
inet addr:4.88.0.56 Bcast:255.255.255.255 Mask:255.255.240.0
inet6 addr: fe80::280:5fff:fef5:8a1b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1838965 errors:36 dropped:0 overruns:0 frame:36
TX packets:1366249 errors:24 dropped:0 overruns:0 carrier:24
collisions:1655 txqueuelen:1000
RX bytes:1547852427 (1.4 GiB) TX bytes:225003865 (214.5 MiB)
Interrupt:225 Base address:0xa400
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:53674 errors:0 dropped:0 overruns:0 frame:0
TX packets:53674 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6605163 (6.2 MiB) TX bytes:6605163 (6.2 MiB)
tap0 Link encap:Ethernet HWaddr C6:E0:D8:D5:7D:A6
inet6 addr: fe80::c4e0:d8ff:fed5:7da6/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:30100 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:5885640 (5.6 MiB)
[root@l2nuxsvr ~]#
-
Hi
That clears that up then; it uses nmap to look for locally connected devices on eth0. Just leave it switched off. I'll put a note in the roadmap to put a switch into Globals to turn it off/on. It may be a release or two before it gets in.
Kind Regards
S
-
Hi,
Thanks.. although I don''t understand totally..
so my 'br0' apparently spoofs 'eth0' and I assume from what you say, that is the cause of the nmap failure.
But what is br0 ? I think br0 appeared when I enabled VPN to my server ?
What function / ability is lost for SAIL with this script disabled ?
G
-
HI
so my 'br0' apparently spoofs 'eth0'
I do not know what your br0 does (it usually means some kind of bridge). The issue is that you have no subnet connected to eth0 (or perhaps vice versa). Usually (not always), SME boxes have eth0 connected to the local subnet and that's where SARK looks for phones to adopt and to resolve(if they aren't registered). If fails on your unit because there is no ip address associated with eth0.
You lose nothing by disabling the script because, presumably, there is nothing there anyway.
Kind Regards
S
-
I'll put a note in the roadmap to put a switch into Globals to turn it off/on. It may be a release or two before it gets in.
I just upgraded to 3.1.1--22 and had this problem start up again.
I looked in Globals for a switch but can't spot one for this.. did it ever make it as an option ?
So I've commented out the line 2 in /etc/cron.d/sark to stop the flooding of emails again.
Glen
-
Where is the sarktool ?
Line 2 of /etc/cron.d/sark calls /opt/sark/scripts/perlarp.pl every 5 minutes.
/opt/sark/scripts/perlarp.pl calls nmap binary which is not there in the default SME8 install.
Hence the following should settle matters:
yum install nmap
This will install nmap v2:4.11-2 as on date.
The following nmap rpms are installed when installing from the SME 8 SAIL ISOs (v3.1.1-22 and v4.0.0-15):
nmap-4.11-1.1.i386.rpm
nmap-5.51.6-1.el5.rfx.i386.rpm
Note: Currently the second line in the /etc/cron.d/sark file executing the script perlarp.pl is commented out as it works only when both nmap is installed and the LAN is on eth0. This issue is being investigated by the SARK devs. However, individual installs of SME8 where the LAN is on eth0 can remove the comment enabling it's use.
Purpose: Do not force eth0 as LAN because there is no guarantee that it won't be disruptive to other code. Nmap runs to find orphan IPs (IP phones) on the sub-net that aren't known to SAIL. It isn't crucial to normal operations.