Problem pinging a device from a ubuntu 10.10 server

Hi Experts,
Here's the problem,
I got Nagios3.2.1 installed on ubuntu server 10.10
I have 2 devices that over time,  seems to be down (I use ping test at 10 minutes frequency)
if I do a manual ping from the server to the devices the packet are sent but never received.
if I use my pc for example and ping that very same device, the device reply to my pc.
both pc and servers are on same networks.

is there somewhere in ubuntu that when multiple packet are invalid from a device that it prevents communication with the device?

after an electrical maintenance the camera and the server were shut down and restarted,
the 2 devices that were doing the problem was working properly for about 1 month.
and now I have the very same problem.

if there is a manual way to un ban the device.
if any one can give me at least leads.

thanks,
RogerMoquinAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

shukalo83Commented:
Please,

Try to ping, then do the following commands and post an ouput of each of them here.

ip addr show

ip route show

ping x.x.x.x

arp -an
0
RogerMoquinAuthor Commented:
here's what happening on nagios3 server

localadmin@monitorsvr:~$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:50:56:12:4d:c6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.25.54/24 brd 192.168.25.255 scope global eth0
    inet6 fe80::250:56ff:fe12:4dc6/64 scope link
       valid_lft forever preferred_lft forever
localadmin@monitorsvr:~$ ip route show
192.168.25.0/24 dev eth0  proto kernel  scope link  src 192.168.25.54
default via 192.168.25.1 dev eth0  metric 100

localadmin@monitorsvr:~$ ping 192.168.0.34
PING 192.168.0.34 (192.168.0.34) 56(84) bytes of data.

^C
--- 192.168.0.34 ping statistics ---
448 packets transmitted, 0 received, 100% packet loss, time 447714ms


localadmin@monitorsvr:~$ arp -an
? (192.168.25.68) at 00:00:bc:c4:a4:35 [ether] on eth0
? (192.168.25.102) at 00:09:6b:83:44:88 [ether] on eth0
? (192.168.25.63) at 00:00:bc:64:a4:a9 [ether] on eth0
? (192.168.25.13) at 00:50:56:19:06:aa [ether] on eth0
? (192.168.25.250) at 00:80:45:4b:97:0c [ether] on eth0
? (192.168.25.19) at 00:50:56:2d:0b:69 [ether] on eth0
? (192.168.25.62) at 00:00:bc:c5:21:d7 [ether] on eth0
? (192.168.25.67) at 00:00:bc:c5:3f:ff [ether] on eth0
? (192.168.25.7) at 00:00:bc:66:84:b2 [ether] on eth0
? (192.168.25.69) at 00:00:bc:64:55:87 [ether] on eth0
? (192.168.25.1) at 00:17:c5:2a:88:60 [ether] on eth0
? (192.168.25.79) at 00:23:ae:c7:95:f0 [ether] on eth0
? (192.168.25.5) at 00:00:bc:c4:3e:56 [ether] on eth0
? (192.168.25.52) at 00:50:56:2d:88:94 [ether] on eth0
? (192.168.25.100) at 00:22:15:35:45:a7 [ether] on eth0
? (192.168.25.6) at 00:00:bc:c4:27:f3 [ether] on eth0
? (192.168.25.61) at 00:00:bc:c5:1d:df [ether] on eth0
? (192.168.25.65) at 00:00:bc:64:8c:0f [ether] on eth0
? (192.168.25.80) at 00:25:64:37:fc:fb [ether] on eth0
? (192.168.25.64) at 00:00:bc:63:d4:16 [ether] on eth0
? (192.168.25.9) at 00:00:bc:1c:7d:31 [ether] on eth0
? (192.168.25.76) at 00:21:9b:c0:8c:22 [ether] on eth0
? (192.168.25.4) at 00:00:bc:c4:91:29 [ether] on eth0
? (192.168.25.77) at 00:21:9b:c1:a1:e5 [ether] on eth0
? (192.168.25.15) at 00:50:56:12:e5:20 [ether] on eth0
? (192.168.25.12) at 00:50:56:01:ca:38 [ether] on eth0
? (192.168.25.3) at 00:00:bc:1d:30:5a [ether] on eth0
? (192.168.25.66) at 00:00:bc:c5:42:3c [ether] on eth0
0
shukalo83Commented:
If your gateway is correctly set (192.168.25.1) and if your devices have their own default gateway set correctly everything seems fine.

Before we resort to sniffing traffic, I don't believe the problem is in linux but you never can tell...

So, please disable iptables on ubuntu machine with this
sudo iptables -F
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT

post a tracepath output (or traceroute)
tracepath 192.168.0.34
if you don't have it installed you can pull it down from repos with
sudo apt-get install tracepath traceroute

Also, because it's camera, I'have seen sometimes that these kind of devices do not use default gw configuration but rely on proxy-arp instead. This service is far from reliable so double check it.
If there is a chance, check that there is default gateway configured on remote devices.

If all this is good we will resort to tcpdump and sniffing to see where the packet has gone.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
RogerMoquinAuthor Commented:
here's what tracepath does on another cam that works
root@monitorsvr:/home/localadmin# tracepath 192.168.0.31
 1:  monitorsvr.mci.inc                                    0.238ms pmtu 1500
 1:  192.168.0.31                                          2.804ms reached
 1:  192.168.0.31

but here what it does on the on I have a problem with
root@monitorsvr:/home/localadmin# tracepath 192.168.0.34
 1:  monitorsvr.mci.inc                                    0.275ms pmtu 1500
 1:  no reply
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply

0
RogerMoquinAuthor Commented:
You were right about the default gateway wrongly setted on the device.
it fixes the problem.

big thanks
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Networking

From novice to tech pro — start learning today.