Nagios Support Forum

jdalrymple wrote:I suspect that your fprobe installation just straight up failed.

Code: Select all

ls -l /usr/local/sbin

If there isn't a file in there called fprobe that is executable you need to re-run the installation and show us the output if it fails again.

[user@linux ~]$ ls -l /usr/local/sbin/
total 92
-rwxr-xr-x. 1 root root 93417 Oct 29 12:58 fprobe

tgriep wrote:xerez, did you get the fprobe software to run on the Linux host?
Try running the following on that system as root and see if it runs and starts sending data the the NA server.

Code: Select all

fprobe xxx.xxx.xxx.xxx:2055

Replace xxx.xxx.xxx.xxx with the IP address of the NA server.

[root@linux user]# fprobe 192.168.10.99:2055
[root@linux user]#

tgriep wrote:Try and restart the flow service on the windows system to see if it starts to send data to the NA server. Maybe it stopped sending when the NA server was off.

tgriep wrote:On the NA server, can you run the following and post back the output?

Code: Select all

service iptables status
ip addr

[root@localhost ~]# service iptables status
Table: filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:2055
2    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:2001
3    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:2001
4    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:2000
5    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:443
6    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

[root@localhost ~]#

tgriep wrote:Run the tcpdump command below for about 10 minutes on the NA server to see if it captures any data from the Linux System. Post the output here.

Code: Select all

tcpdump -i eth0 port 2055

[root@localhost ~]# tcpdump -i eth0 port 2055
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

^C
0 packets captured
2 packets received by filter
0 packets dropped by kernel
[root@localhost ~]#

jdalrymple wrote:`grep fprobe /var/log/messages`

Re: the Windows problem, try restarting 1 thing at a time. Next time try the Windows service without restarting NNA. NNA is typically very stable and doesn't require restarting.

[root@linux user]# grep fprobe /var/log/messages
Nov  3 14:03:28 linux fprobe[10228]: [CRIT]: Uknown data link type 239. Use -K option.
[root@linux user]#

fprobe -K18 192.168.10.99:2055

-K <bytes>
Link layer header size. By default fprobe take this information from libpcap, but sometimes obtained size unsuitable for our purpose. It occurs, for example, on trunk interfaces in
VLAN enviroment, where link layer header contain additional VLAN header

tgriep wrote:Try running the fprobe command on the remote linux system like below and see if the NA server starts to receive data.

Code: Select all

fprobe -K18 192.168.10.99:2055

This is the explanation of the -K option.

-K <bytes>
Link layer header size. By default fprobe take this information from libpcap, but sometimes obtained size unsuitable for our purpose. It occurs, for example, on trunk interfaces in
VLAN enviroment, where link layer header contain additional VLAN header

What version of Netflow did you setup on the Windows system? Try setting it to Version 5 to see if that helps.