Sign in to follow this  
Followers 0
cut

3 way ping mystery

22 posts in this topic

I have 3 PCs, Windows, Linux 1 and Linux 2.

Windows can ping both Linux 1 and Linux 2

Liunx 1 can ping both Windows and Linux 2

Linux 2 can ping Windows but cannot ping Linux 1

It would sound like a firewall issue but Linux 1 has the firewall disabled.

Where/what else can I look at?

Share this post


Link to post
Share on other sites

How are your devices physically connected together?

Switches/Routers/Access points etc?

Share this post


Link to post
Share on other sites

Hmm, I've never really used linux but the problem is

Linux 2 cannot ping Linux 1.

Have you disabled the firewall on both? Are you pinging by IP address rather than hostname?

Share this post


Link to post
Share on other sites

Really need to know how these devices are connected - same switch/router lan ports? Are any of them wireless? Is there a nat between any of them?

Also great question is the name or IP - ping by IP for testing, or you might just have a name resolution issue. Once you know you can ping by IP you can move to name resolution problems.

On the box your trying to ping from -- try to ping the IP, then look at the arp table. Do you show the correct MAC for the IP your trying to ping. If not - you need to find out why, never going to be able to ping if you don't know the mac. This can be an issue sometimes via wireless.

On linux you can view the arp table arp -n

example

budman@ubuntu:~$ arp -n
Address				  HWtype  HWaddress		   Flags Mask			Iface
192.168.1.40			 ether   2c:76:8a:ad:f6:56   C					 eth0
192.168.1.253			ether   00:50:56:00:00:02   C					 eth0
budman@ubuntu:~$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_req=1 ttl=128 time=1.47 ms
64 bytes from 192.168.1.100: icmp_req=2 ttl=128 time=0.557 ms
64 bytes from 192.168.1.100: icmp_req=3 ttl=128 time=0.607 ms
64 bytes from 192.168.1.100: icmp_req=4 ttl=128 time=0.499 ms
64 bytes from 192.168.1.100: icmp_req=5 ttl=128 time=0.820 ms
64 bytes from 192.168.1.100: icmp_req=6 ttl=128 time=0.690 ms
^C
--- 192.168.1.100 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5004ms
rtt min/avg/max/mdev = 0.499/0.775/1.478/0.330 ms
budman@ubuntu:~$ arp -n
Address				  HWtype  HWaddress		   Flags Mask			Iface
192.168.1.40			 ether   2c:76:8a:ad:f6:56   C					 eth0
192.168.1.253			ether   00:50:56:00:00:02   C					 eth0
192.168.1.100			ether   18:03:73:b1:0d:d3   C					 eth0

bad no mac example;

budman@ubuntu:~$ ping 192.168.1.32
PING 192.168.1.32 (192.168.1.32) 56(84) bytes of data.
^C
--- 192.168.1.32 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

budman@ubuntu:~$ arp -n
Address				  HWtype  HWaddress		   Flags Mask		    Iface
192.168.1.32					 (incomplete)							  eth0
192.168.1.253		    ether   00:50:56:00:00:02   C					 eth0
192.168.1.100		    ether   18:03:73:b1:0d:d3   C					 eth0

Share this post


Link to post
Share on other sites

are they all on the same subnet, that can cause it sometimes.

Share this post


Link to post
Share on other sites

Yeah, I would check the subnet masks, make sure they're all the same. If Linux2 thinks Linux1 is in a different subnet than itself then it will send the pings to its default gateway rather than direct to Linux1.

Share this post


Link to post
Share on other sites

How are your devices physically connected together?

Switches/Routers/Access points etc?

Currently, they are all connected to the same switch.

Hmm, I've never really used linux but the problem is

Linux 2 cannot ping Linux 1.

Have you disabled the firewall on both? Are you pinging by IP address rather than hostname?

Yup, firewall is disabled on both. Im pinging by IPs....

Really need to know how these devices are connected - same switch/router lan ports? Are any of them wireless? Is there a nat between any of them?

Also great question is the name or IP - ping by IP for testing, or you might just have a name resolution issue. Once you know you can ping by IP you can move to name resolution problems.

On the box your trying to ping from -- try to ping the IP, then look at the arp table. Do you show the correct MAC for the IP your trying to ping. If not - you need to find out why, never going to be able to ping if you don't know the mac. This can be an issue sometimes via wireless.

On linux you can view the arp table arp -n

example

budman@ubuntu:~$ arp -n
Address				  HWtype  HWaddress		   Flags Mask			Iface
192.168.1.40			 ether   2c:76:8a:ad:f6:56   C					 eth0
192.168.1.253			ether   00:50:56:00:00:02   C					 eth0
budman@ubuntu:~$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_req=1 ttl=128 time=1.47 ms
64 bytes from 192.168.1.100: icmp_req=2 ttl=128 time=0.557 ms
64 bytes from 192.168.1.100: icmp_req=3 ttl=128 time=0.607 ms
64 bytes from 192.168.1.100: icmp_req=4 ttl=128 time=0.499 ms
64 bytes from 192.168.1.100: icmp_req=5 ttl=128 time=0.820 ms
64 bytes from 192.168.1.100: icmp_req=6 ttl=128 time=0.690 ms
^C
--- 192.168.1.100 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5004ms
rtt min/avg/max/mdev = 0.499/0.775/1.478/0.330 ms
budman@ubuntu:~$ arp -n
Address				  HWtype  HWaddress		   Flags Mask			Iface
192.168.1.40			 ether   2c:76:8a:ad:f6:56   C					 eth0
192.168.1.253			ether   00:50:56:00:00:02   C					 eth0
192.168.1.100			ether   18:03:73:b1:0d:d3   C					 eth0

bad no mac example;

budman@ubuntu:~$ ping 192.168.1.32
PING 192.168.1.32 (192.168.1.32) 56(84) bytes of data.
^C
--- 192.168.1.32 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

budman@ubuntu:~$ arp -n
Address				  HWtype  HWaddress		   Flags Mask			Iface
192.168.1.32					 (incomplete)							  eth0
192.168.1.253			ether   00:50:56:00:00:02   C					 eth0
192.168.1.100			ether   18:03:73:b1:0d:d3   C					 eth0

These devices are all connect to the same switch. On this there is also a router and some other Windows PCs, which can ping each other.

I (and I think anyone else should) ping by IP.

Yes I can confirm that the mac in the arp table is correct.

are they all on the same subnet, that can cause it sometimes.

Yeah, I would check the subnet masks, make sure they're all the same. If Linux2 thinks Linux1 is in a different subnet than itself then it will send the pings to its default gateway rather than direct to Linux1.

Yup, also confirming they are all on the same subnet....

Share this post


Link to post
Share on other sites

So that makes no sense then, none. Unless you have mask wrong with some really lucky/unlucky ip choices to where they fall in the mask. Points to firewall on the host to be honest.

I would sniff on the one you can not ping - does he see the pings? If so then clearly he is not answering for a reason, or does he answer just really slow and your getting timeouts?

Or something really weird on the switch, try changing ports around. Is it a smart switch, or just a dumb switch - could you be blocking stuff on it?

Share this post


Link to post
Share on other sites

Maybe show us the dump of ifconfig, arp, and route on both linux boxes?

Share this post


Link to post
Share on other sites

So that makes no sense then, none. Unless you have mask wrong with some really lucky/unlucky ip choices to where they fall in the mask. Points to firewall on the host to be honest.

I would sniff on the one you can not ping - does he see the pings? If so then clearly he is not answering for a reason, or does he answer just really slow and your getting timeouts?

Or something really weird on the switch, try changing ports around. Is it a smart switch, or just a dumb switch - could you be blocking stuff on it?

post-456877-0-08728700-1347882715_thumb.

Ive included a screenshot that shows on Linux 2 that the mask is default and correct. Ive also reran the command to shutdown the firewall.

Ill sniff in about 2 hours and get with the results as I cant right now.

Maybe show us the dump of ifconfig, arp, and route on both linux boxes?

By dumps, I imagine the same thing as in the screenshot, correct?

Share this post


Link to post
Share on other sites

I used tcpdump on the box I could not reach........Surprising results.

It seems that it DOES recieve the ping and it actually replies but I do not see it on the command line. This was ran on Linux 2 (box that does NOT reply)

13:58:22.992748 IP 192.168.100.115.ssh > linux2box..28107: Flags [P.], ack 2511154091, win 6068, length 196

13:58:22.993473 IP linux2box..28107 > 192.168.100.115.ssh: Flags [.], ack 196, win 4112, length 0

13:58:22.995735 IP 192.168.100.115.45340 > 192.168.100.100.domain: 2+ PTR? 115.100.168.192.in-addr.arpa. (46)

13:58:22.998776 IP 192.168.100.100.domain > 192.168.100.115.45340: 2 NXDomain* 0/1/0 (153)

13:58:23.003244 IP 192.168.100.100.domain > 192.168.100.115.46194: 3* 1/0/0 (95)

13:58:23.005639 IP 192.168.100.115.36789 > 192.168.100.100.domain: 4+ PTR? 100.100.168.192.in-addr.arpa. (46)

13:58:23.008618 IP 192.168.100.100.domain > 192.168.100.115.36789: 4 NXDomain* 0/1/0 (153)

13:58:23.902042 IP 192.168.100.199 > 192.168.100.115: ICMP echo request, id 5773, seq 1, length 64

13:58:23.902459 IP 192.168.100.115 > 192.168.100.199: ICMP echo reply, id 5773, seq 1, length 64

13:58:23.904009 IP 192.168.100.115.fido > 192.168.100.100.domain: 5+ PTR? 199.100.168.192.in-addr.arpa. (46)

13:58:23.907282 IP 192.168.100.100.domain > 192.168.100.115.fido: 5 NXDomain* 0/1/0 (153)

13:58:23.997979 IP 192.168.100.115.38366 > 192.168.100.100.domain: 6+[|domain]

13:58:24.001001 IP 192.168.100.100.domain > 192.168.100.115.38366: 6 NXDomain[|domain]

13:58:24.003131 IP 192.168.100.115.52267 > 192.168.100.100.domain: 7+[|domain]

13:58:24.006145 IP 192.168.100.100.domain > 192.168.100.115.52267: 7 NXDomain[|domain]

13:58:24.901941 IP 192.168.100.199 > 192.168.100.115: ICMP echo request, id 5773, seq 2, length 64

13:58:24.902274 IP 192.168.100.115 > 192.168.100.199: ICMP echo reply, id 5773, seq 2, length 64

13:58:24.950779 IP edited..59290 > 239.255.255.250.1900: UDP, length 133

13:58:24.955935 IP 192.168.100.100.domain > 192.168.100.115.47203: 8* 1/0/0 (95)

13:58:24.957545 IP 192.168.100.115.32870 > 192.168.100.100.domain: 9+ PTR? 250.255.255.239.in-addr.arpa. (46)

13:58:24.960529 IP 192.168.100.100.domain > 192.168.100.115.32870: 9 NXDomain 0/1/0 (103)

13:58:25.901936 IP 192.168.100.199 > 192.168.100.115: ICMP echo request, id 5773, seq 3, length 64

13:58:25.902267 IP 192.168.100.115 > 192.168.100.199: ICMP echo reply, id 5773, seq 3, length 64

13:58:26.901958 IP 192.168.100.199 > 192.168.100.115: ICMP echo request, id 5773, seq 4, length 64

13:58:26.902287 IP 192.168.100.115 > 192.168.100.199: ICMP echo reply, id 5773, seq 4, length 64

13:58:27.712914 ARP, Request who-has 192.168.100.115 ((oui Unknown)) tell linux2box., length 46

13:58:27.713037 ARP, Reply 192.168.100.115 is-at macadd (oui Unknown), length 28

13:58:27.970501 IP edited..59290 > 239.255.255.250.1900: UDP, length 133

13:58:28.152491 IP 192.168.100.115.52475 > 192.168.100.199.1194: UDP, length 69

13:58:28.523900 IP linux2box..28107 > 192.168.100.115.ssh: Flags [P.], ack 196, win 4112, length 52

Share this post


Link to post
Share on other sites

so it is sending reply to your ping -- do a sniff on the box that sending, its not seeing replies?

Share this post


Link to post
Share on other sites

so it is sending reply to your ping -- do a sniff on the box that sending, its not seeing replies?

OK, we are getting somewhere: The machine is not seeing the replies from Linux 1.

root@mylocalmachine:~# tcpdump -i eth2 > results

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes

13 packets captured

78 packets received by filter

35 packets dropped by kernel

root@mylocalmachine:~# cat results

16:20:16.308831 IP mylocalmachine.local.ssh > localsite.net.27235: Flags [P.], seq 2762984911:2762985107, ack 2735301118, win 2387, length 196

16:20:16.308882 IP mylocalmachine.local.ssh > localsite.net.27235: Flags [P.], seq 196:248, ack 1, win 2387, length 52

16:20:16.309384 IP localsite.net.27235 > mylocalmachine.local.ssh: Flags [.], ack 196, win 4380, length 0

16:20:16.309672 IP mylocalmachine.local.27450 > 192.168.100.100.domain: 41740+ PTR? 199.100.168.192.in-addr.arpa. (46)

16:20:16.309791 IP localsite.net.27235 > mylocalmachine.local.ssh: Flags [P.], seq 1:85, ack 248, win 4367, length 84

16:20:16.309883 IP localsite.net.27235 > mylocalmachine.local.ssh: Flags [P.], seq 85:137, ack 248, win 4367, length 52

16:20:16.312555 IP 192.168.100.100.domain > mylocalmachine.local.27450: 41740 NXDomain* 0/1/0 (153)

16:20:16.313252 IP mylocalmachine.local.7622 > 192.168.100.100.domain: 56557+ PTR? 100.100.168.192.in-addr.arpa. (46)

16:20:16.316045 IP 192.168.100.100.domain > mylocalmachine.local.7622: 56557 NXDomain* 0/1/0 (153)

16:20:16.360744 IP mylocalmachine.local.ssh > localsite.net.27235: Flags [.], ack 137, win 2387, length 0

16:20:16.377800 IP mylocalmachine.local.ssh > localsite.net.27235: Flags [P.], seq 248:284, ack 137, win 2387, length 36

16:20:16.416444 IP6 fe80::217:3fff:fe99:e4ab.mdns > ff02::fb.mdns: 0 PTR (QM)? 100.100.168.192.in-addr.arpa. (46)

16:20:16.416502 IP mylocalmachine.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 100.100.168.192.in-addr.arpa. (46)

Also some are getting dropped by the kernel (which could be those)

Share this post


Link to post
Share on other sites

set your capture to only be icmp, that should rule out the drops being what your looking for in your capture.

So this make it even more interesting -- what would keep the replies from getting back, since it looks like your capture on the box you were pinging that it was putting replies back on the wire.

What kind of switch is this? Is it possible its doing any filtering? I don't see any icmp in that capture at all?

I would be doing captures on both boxes at the same time, only for icmp and then create your traffic. What are you seeing?

So for example here is from my ubuntu box pinging another box. At the same time you should be doing the capture on the box your pinging.

post-14624-0-94956000-1347895294_thumb.j

I would also verify your listening on the correct interface - eth2 seems odd to me in your post.

Share this post


Link to post
Share on other sites

set your capture to only be icmp, that should rule out the drops being what your looking for in your capture.

Couldnt remember the way to filter, sorry.

What kind of switch is this? Is it possible its doing any filtering? I don't see any icmp in that capture at all?

Dumb simple switch. Nothing about it special.

I would also verify your listening on the correct interface - eth2 seems odd to me in your post.

The PC has 2 network cards. The first one (eth1) is ****ed up so Im on eth2. Ive also confirmed it with a ifconfig.

Ill try this in a second....

Share this post


Link to post
Share on other sites

Here you go:

post-456877-0-36610500-1347955934_thumb.

Ive checked and rechecked again any and all possible firewall issues (software and hardware) and as you saw in posts before, its disabled.

Share this post


Link to post
Share on other sites

What are you showing me there.. You got it showing pings and answers.. And then your capturing on the other side only showing it send.

What about the capture on the other side while that ping was going? My example was to just show the command for ping only, etc..

And can I see the settings of the ips? And the macs, and these are what flavor of linux? Can see output of iptables -L

example

root@ubuntu:/home/budman# iptables -L
Chain INPUT (policy ACCEPT)
target	 prot opt source			   destination
sshguard   all  --  anywhere			 anywhere

Chain FORWARD (policy ACCEPT)
target	 prot opt source			   destination

Chain OUTPUT (policy ACCEPT)
target	 prot opt source			   destination

Chain sshguard (1 references)
target	 prot opt source			   destination

root@ubuntu:/home/budman# ifconfig
eth0	  Link encap:Ethernet  HWaddr 00:0c:29:dd:02:ba
		  inet addr:192.168.1.7  Bcast:192.168.1.255  Mask:255.255.255.0
		  inet6 addr: fe80::20c:29ff:fedd:2ba/64 Scope:Link
		  inet6 addr: 2001:470:7c:27::777/64 Scope:Global
		  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
		  RX packets:215356 errors:0 dropped:10 overruns:0 frame:0
		  TX packets:147978 errors:0 dropped:0 overruns:0 carrier:0
		  collisions:0 txqueuelen:1000
		  RX bytes:125120650 (125.1 MB)  TX bytes:110565504 (110.5 MB)

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:6 errors:0 dropped:0 overruns:0 frame:0
		  TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
		  collisions:0 txqueuelen:0
		  RX bytes:300 (300.0 B)  TX bytes:300 (300.0 B)

Have you tried resetting your switch? What is the model number?

Share this post


Link to post
Share on other sites

sorry to wade in here

i would remove the duff network card just to rule out that lol

Share this post


Link to post
Share on other sites

is that 3 way ping like a 3some???

Share this post


Link to post
Share on other sites

What are you showing me there.. You got it showing pings and answers.. And then your capturing on the other side only showing it send.

What Im showing that it works on one side and on the other side it doesnt work....

And can I see the settings of the ips? And the macs, and these are what flavor of linux? Can see output of iptables -L

example

root@ubuntu:/home/budman# iptables -L
Chain INPUT (policy ACCEPT)
target	 prot opt source			   destination
sshguard   all  --  anywhere			 anywhere

Chain FORWARD (policy ACCEPT)
target	 prot opt source			   destination

Chain OUTPUT (policy ACCEPT)
target	 prot opt source			   destination

Chain sshguard (1 references)
target	 prot opt source			   destination

Im on another thing now so Ill have that in a few days. Latest version of Ubuntu.

Have you tried resetting your switch? What is the model number?

Yes. The model is a Beckhoff ES2008

Share this post


Link to post
Share on other sites

Your eth2 interface looks like it's a 10Mb interface. Are the others 100Mb and are you mixing duplex settings, maybe half duplex on the 10Mb and full duplex on the 100Mb?

Share this post


Link to post
Share on other sites

"What Im showing that it works on one side and on the other side it doesnt work...."

But your showing it the wrong way!

Need the capture from the box your pinging - want to see getting the pings and sending them back, but your box is not getting them back? Or is it - capture on it as well.

Open 3 windows, one showing you sending pings capture on the sender, then in another window show capture on the box your pinging. And lets see full macs and full pings. Like this

and provide more info in the capture, example

tcpdump -i eth0 -n -s 0 -vvv -e icmp

post-14624-0-54852000-1348057156_thumb.p

post-14624-0-77420100-1348057165_thumb.p

And the output of ifconfig on both boxes.. showing all intefaces, and then output of ethtool on the interfaces your using

root@ubuntu:/home/budman# ethtool eth0
Settings for eth0:
	    Supported ports: [ TP ]
	    Supported link modes:   1000baseT/Full
							    10000baseT/Full
	    Supported pause frame use: No
	    Supports auto-negotiation: No
	    Advertised link modes:  Not reported
	    Advertised pause frame use: No
	    Advertised auto-negotiation: No
	    Speed: 10000Mb/s
	    Duplex: Full
	    Port: Twisted Pair
	    PHYAD: 0
	    Transceiver: internal
	    Auto-negotiation: off
	    MDI-X: Unknown
	    Supports Wake-on: uag
	    Wake-on: d
	    Link detected: yes

I am really curious if your actually pinging the correct macs -- which I want to see the output of ifconfig showing the interfaces, and ethtool will show duplex level, etc.. As mentioned as something to look at. ifconfig will also show if errors on your nic, etc.

root@ubuntu:/home/budman# ifconfig
eth0	  Link encap:Ethernet  HWaddr 00:0c:29:dd:02:ba
		  inet addr:192.168.1.7  Bcast:192.168.1.255  Mask:255.255.255.0
		  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
		  RX packets:215356 errors:0 dropped:10 overruns:0 frame:0
		  TX packets:147978 errors:0 dropped:0 overruns:0 carrier:0
		  collisions:0 txqueuelen:1000
		  RX bytes:125120650 (125.1 MB)  TX bytes:110565504 (110.5 MB)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.