This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Echo (ping) reply not generated, but can see Echo (ping) request is received on interface

0

I have an odd situation

10.50.50.25 --- |Svr02| --- 10.50.50.26

10.50.50.16 --- |Srv01| --- 10.50.50.15

When I ping 10.50.50.25 and 10.50.50.26 from Srv01 I can see the echo requests and echo replies are received and the pings report as successful.

When I ping 10.50.50.16 and 10.50.50.15 from Srv02 only 10.50.50.16 sends the echo replies.

When doing a wireshark trace I can see the failing ping request from Srv02 goes like this

  • echo request sent out of 10.50.50.26
  • interface echo request recieved on 10.50.50.15
  • Then however, I see no attempt on Srv01 to send an echo reply on any interface

Why could this be?

asked 09 Nov '15, 10:47

wshark_man_123's gravatar image

wshark_man_123
6224
accept rate: 0%

edited 09 Nov '15, 12:29


One Answer:

1

You haven't stated whether the icmp echo requests from Srv01 are sent from 10.50.50.15 or 10.50.50.16. I would suspect some firewall to block icmp on the 10.50.50.15 interface of srv01. What happens if you shut down 10.50.50.16 and try to ping 10.50.50.15 from Srv02?

answered 09 Nov '15, 12:47

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

I can see Windows Firewall drops inbound for the failed pings which is why no echo reply is being generated.

(09 Nov '15, 23:36) wshark_man_123

Hint: If a supplied answer resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions. For extra points you can up vote the answer (thumb up).

(10 Nov '15, 00:24) Kurt Knochner ♦

So my assumption was correct and according to the principles of the site you should mark my answer as correct/helpful.

If the behaviour seems weird to you: libpcap (Wireshark) is hooked as close as possible to the hardware so it gets any incoming packet before the Windows firewall. So you can see incoming packets dropped by the firewall in the capture but they don't reach higher levels of the protocol stack because the firewall drops them. For sent packets, however, the same arrangement means that if an application sends a packet but the firewall drops it, the packet does not reach libpcap and so you won't see it in the capture. This would hardly happen in case of icmp but it does happen for application protocols.

(10 Nov '15, 00:33) sindy