A newbie to NagiosNA.
Has anyone had this issue before, or can give an idea on when to look?
If you require more info, please ask me.
Working with: Nagios NA 2.3.0
Did the installation of NagiosNA agent on SUSE SLES 12.1 using ./fprobeinstall.sh, then executed on the client server "fprobe -i <interface> <NNA server>:<port>", but a few second later it stops listening.
Error seen in /var/log/messages
2018-02-14T14:14:28.791189-08:00 localhost kernel: [1367103.624148] device eth0 entered promiscuous mode
2018-02-14T14:14:28.811463-08:00 localhost fprobe[23325]: [WARNING]: Filter expression is empty! Are you sure?
2018-02-14T14:14:28.813645-08:00 localhost fprobe[23325]: [INFO]: Starting 1.1...
2018-02-14T14:14:28.813982-08:00 localhost fprobe[23325]: [INFO]: pid: 23325
2018-02-14T14:14:28.814144-08:00 localhost fprobe[23325]: [INFO]: interface: eth0, datalink: EN10MB (1)
2018-02-14T14:14:28.814287-08:00 localhost fprobe[23325]: [INFO]: filter: ""
2018-02-14T14:14:28.814426-08:00 localhost fprobe[23325]: [INFO]: options: p=1 s=5 g=30 d=60 e=300 n=5 a=0.0.0.0 x=0:0 b=10000 m=0 q=100 B=0 r=0 t=0:0 S=256 K=14 k=0 c= u= v=6 l=1
2018-02-14T14:14:28.814577-08:00 localhost fprobe[23325]: [INFO]: collector #1: 10.253.19.242:9951/0.0.0.0/m
2018-02-14T14:14:37.824665-08:00 localhost kernel: [1367112.658977] traps: fprobe[23328] general protection ip:7f6ee3dfd198 sp:7f6ee18a2ee8 error:0 in libpthread-2.19.so[7f6ee3dec000+18000]traps:
2018-02-14T14:14:37.824684-08:00 localhost kernel: [1367112.659908] device eth0 left promiscuous mode
kernel: device eth0 left promiscuous mode
Re: kernel: device eth0 left promiscuous mode
These messages are normal. Typically the card enters promiscuous mode when a traffic sniffer (tcpdump, snort, etc...) is being used. In your case, fprobe is running, sending netflow data to your Nagios Network Analyzer box.
What do you mean when you say: "but a few second later it stops listening"? Do you mean that the fprobe is not running on your SUSE machine?
Can you run the following command on the SUSE box and show the output?
Also, run the following command on your Nagios Network Analyzer server and show the output:
You can check to see if the netflow data is being sent to the NNA box but running the following command on it:
when you substitute <your port> with the actual port number you are listening to.
What do you mean when you say: "but a few second later it stops listening"? Do you mean that the fprobe is not running on your SUSE machine?
Can you run the following command on the SUSE box and show the output?
Code: Select all
ps -ef | grep fprobe
Code: Select all
ps -ef --cols=300 | grep nfcapd
Code: Select all
tcpdump -i eth0 port <your port>
Be sure to check out our Knowledgebase for helpful articles and solutions!
Re: kernel: device eth0 left promiscuous mode
"but a few second later it stops listening"? Do you mean that the fprobe is not running on your SUSE machine?
Yes, it seems that after a few second of executing "fprobe -i <interface> <NNA server>:<port>" the fprobe dies out, but only for eth0.
Can you run the following command on the SUSE box and show the output?
ps -ef | grep fprobe
Also, run the following command on your Nagios Network Analyzer server and show the output:
ps -ef --cols=300 | grep nfcapd
You can check to see if the netflow data is being sent to the NNA box but running the following command on it:
tcpdump -i eth0 port <your port>
A temp solution that was found is to execute the fprobe command but not putting it into promiscuous mode, example:
fprobe -p -i eth0 10.255.145.242:9951
but not sure if this will create a new issue.
Yes, it seems that after a few second of executing "fprobe -i <interface> <NNA server>:<port>" the fprobe dies out, but only for eth0.
Can you run the following command on the SUSE box and show the output?
ps -ef | grep fprobe
Code: Select all
SERVER:~ # date
Wed Feb 21 09:03:13 PST 2018
SERVER:~ # ps -ef | grep fprobe
root 92438 1 0 Feb15 ? 00:04:16 fprobe -i eth1 10.255.145.242:9951
root 92482 1 0 Feb15 ? 00:58:00 fprobe -i eth2 10.255.145.242:9951
root 92549 1 0 Feb15 ? 00:03:24 fprobe -i eth4 10.255.145.242:9951
root 114258 109638 0 09:03 pts/0 00:00:00 grep --color=auto fprobe
SERVER:~ # fprobe -i eth0 10.255.145.242:9951
SERVER:~ # tail -f /var/log/messages
2018-02-21T09:03:29.832382-08:00 SERVER kernel: [1945492.763707] device eth0 entered promiscuous mode
2018-02-21T09:03:29.844512-08:00 SERVER fprobe[114386]: [WARNING]: Filter expression is empty! Are you sure?
2018-02-21T09:03:29.846301-08:00 SERVER fprobe[114386]: [INFO]: Starting 1.1...
2018-02-21T09:03:29.846707-08:00 SERVER fprobe[114386]: [INFO]: pid: 114386
2018-02-21T09:03:29.846921-08:00 SERVER fprobe[114386]: [INFO]: interface: eth0, datalink: EN10MB (1)
2018-02-21T09:03:29.847120-08:00 SERVER fprobe[114386]: [INFO]: filter: ""
2018-02-21T09:03:29.847322-08:00 SERVER fprobe[114386]: [INFO]: options: p=1 s=5 g=30 d=60 e=300 n=5 a=0.0.0.0 x=0:0 b=10000 m=0 q=100 B=0 r=0 t=0:0 S=256 K=14 k=0 c= u= v=6 l=1
2018-02-21T09:03:29.847518-08:00 SERVER fprobe[114386]: [INFO]: collector #1: 10.255.145.242:9951/0.0.0.0/m
2018-02-21T09:03:48.184425-08:00 SERVER kernel: [1945511.117582] traps: fprobe[114389] general protection ip:7fc79740e198 sp:7fc794eb3ee8 error:0 in libpthread-2.19.so[7fc7973fd000+18000]traps:
2018-02-21T09:03:48.184437-08:00 SERVER kernel: [1945511.118264] device eth0 left promiscuous mode
^C
SERVER:~ # date
Wed Feb 21 09:04:51 PST 2018
SERVER:~ # ps -ef | grep fprobe
root 92438 1 0 Feb15 ? 00:04:16 fprobe -i eth1 10.255.145.242:9951
root 92482 1 0 Feb15 ? 00:58:00 fprobe -i eth2 10.255.145.242:9951
root 92549 1 0 Feb15 ? 00:03:24 fprobe -i eth4 10.255.145.242:9951
root 115945 109638 0 09:04 pts/0 00:00:00 grep --color=auto fprobe
SERVER:~ #
ps -ef --cols=300 | grep nfcapd
Code: Select all
[root@TNNAG002 ~]# ps -ef --cols=300 | grep nfcapd
nna 1786 1 0 Feb15 ? 00:00:38 /usr/local/bin/nfcapd -I 5 -l /usr/local/nagiosna/var/SERVER/flows -p 9951 -x /usr/local/nagiosna/bin/reap_files.py %d %f %i -P /usr/local/nagiosna/var/SERVER/9951.pid -D -e -w -z
nna 1788 1786 0 Feb15 ? 00:00:02 /usr/local/bin/nfcapd -I 5 -l /usr/local/nagiosna/var/SERVER/flows -p 9951 -x /usr/local/nagiosna/bin/reap_files.py %d %f %i -P /usr/local/nagiosna/var/SERVER/9951.pid -D -e -w -z
root 3027 19064 0 13:02 pts/0 00:00:00 grep nfcapd
You can check to see if the netflow data is being sent to the NNA box but running the following command on it:
tcpdump -i eth0 port <your port>
Code: Select all
SERVER:~ # tcpdump -i eth0 port 9951
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:13:33.000081 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 936
09:13:33.002026 IP SERVER.24392 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002042 IP SERVER.24392 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002725 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002741 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002757 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002766 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002776 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002787 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002797 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002809 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002819 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002829 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002840 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002850 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002868 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002876 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002884 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 1464
09:13:33.002899 IP SERVER.14599 > 10.255.145.242.apc-9951: UDP, length 1464
^C
19 packets captured
19 packets received by filter
0 packets dropped by kernel
SERVER:~ #
A temp solution that was found is to execute the fprobe command but not putting it into promiscuous mode, example:
fprobe -p -i eth0 10.255.145.242:9951
but not sure if this will create a new issue.
Re: kernel: device eth0 left promiscuous mode
We haven't been able to recreate the issue in house. Not running the fprobe in promiscuous mode on eth0 shouldn't affect anything, but if you want to get to the bottom of the original issue, you could try running strace:
Upload to the forum the output.txt that was generated from running the command above. We will examine the output and try to figure out what the issue is.
Code: Select all
strace -o output.txt fprobe -i eth0 10.255.145.242:9951
Be sure to check out our Knowledgebase for helpful articles and solutions!
Re: kernel: device eth0 left promiscuous mode
Ok did:
Attached is the output.
As you realized "10.255.145.242" is the main IP of Nagios NA. I am just mentioning it so all is clear .
Thanks for all the help.
Code: Select all
strace -o /tmp/output.txt fprobe -i eth0 10.255.145.242:9951
As you realized "10.255.145.242" is the main IP of Nagios NA. I am just mentioning it so all is clear .
Thanks for all the help.
You do not have the required permissions to view the files attached to this post.
Re: kernel: device eth0 left promiscuous mode
Closing topic as resolved. Thank you for visiting the Nagios Support Forum.