13

I've been having trouble with some network configuration lately which has been tricky to resolve.

It seems this would be much easier to diagnose if I knew which direction the traffic was failing to get through. Since all ping requests receive no responses back I'd like to know if the ping-request packets are getting through and the responses failing, or if it's the requests themselves that are failing.

To be clear, standard utilities like ping and traceroute rely on sending a packet out from one machine and receiving a packet in response back to that same machine. When no response comes back, it's always impossible to tell if the initial request failed to get through, or the response to it was blocked or even if the response to it was simply never sent. It's this specific detail, "which direction is the failure", that I'd like to analyse.

Are there any utilities commonly available for Linux which will let me monitor for incoming ICMP ping requests?

Philip Couling
  • 17,591
  • 5
  • 42
  • 82

4 Answers4

26

tcpdump can do this, and is available pretty much everywhere:

tcpdump -n -i enp0s25 icmp

will dump all incoming and outgoing ICMP packets on enp0s25.

To see only ICMP echo requests:

tcpdump -n -i enp0s25 "icmp[0] == 8"

(-n avoids DNS lookups, which can delay packet reporting and introduce unwanted traffic of their own.)

This allows you to find if it is receiving the packets from the other machine (from which you would e.g. ping it), so the problem is with the return path, or if they directly don't arrive.

Ángel
  • 3,383
  • 1
  • 13
  • 16
Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
3

Apart from @Stephen Kitt's suggestion you can run tcpdump to filter a packet in one direction only:

  # see if the icmp request exits the interface
  tcpdump -nQ out 'icmp'

tshark is another useful tool you can use and it doesn't require you to run as root:

  tshark -nf "icmp && (icmp[icmptype] == icmp-echo)"

aparte packet capture you can parse the output of

netstat -s

which prints a statistics for each network socket, an example would be the following:

  netstat -s | grep -Eo "^[[:space:]]+[[:digit:]]+ ICMP messages sent$"; 1>/dev/null ping -c1 -w1 host; !-1

  28 ICMP messages sent
  30 ICMP messages sent
DanieleGrassini
  • 2,769
  • 5
  • 17
0

2ping might work for you. It's probably available via your distro's package manager.

But if no traffic is getting through, I'm not sure it will be able to tell you anything you don't already know.

To quote the website:

2ping is a bi-directional ping utility. It uses 3-way pings (akin to TCP SYN, SYN/ACK, ACK) and after-the-fact state comparison between a 2ping listener and a 2ping client to determine which direction packet loss occurs.

user@alice:~$ 2ping test.2ping.net
2PING test.2ping.net (209.177.154.210): 64 to 512 bytes of data.
Lost outbound packet to 209.177.154.210: ping_seq=1
64 bytes from 209.177.154.210: ping_seq=2 time=10.557 ms
Lost inbound packet from 209.177.154.210: ping_seq=3
64 bytes from 209.177.154.210: ping_seq=4 time=10.527 ms
^C
--- test.2ping.net 2ping statistics ---
4 pings transmitted, 2 received, 50% ping loss, time 4008ms
1 outbound ping losses (25%), 1 inbound (25%), 0 undetermined (0%)
rtt min/avg/max = 10.527/10.542/10.557 ms
6 raw packets transmitted, 3 received
Matt Nordhoff
  • 445
  • 3
  • 5
-5

Read man traceroute. It will use small TTL values on ICMP Pings to get ICMP responses from each node on the path from Source to Destination (in your case, it's more like Source to Wilderness, but whatever).

The tracepath utility (sudo apt install tracepath;man tracepath) uses the same small TTL trick, but at the TCP/IP level, to a specified port.

waltinator
  • 4,439
  • 1
  • 16
  • 21
  • 1
    Investigate routing on each node you have acess to with, e.g. `ip route`. – waltinator Feb 12 '21 at 16:04
  • Both those utilities (read the `man` pages) send a packet towards the destination with a TTL (Time To Live) value of 1. The 1st node along the network path decrements. the TTL, sees that TTL is 0, and sends an error packet back to the Source. This was designed to prevent routing loops. Then, the Source sends a packet towards the destination with a TTL value of 2 ... – waltinator Feb 12 '21 at 16:13
  • 2
    Yes this really isn't answering the question that was asked. I am already in the hard position of investigating routing on every node I have access to. I'm looking for some specific information which is *which direction* (inbound or outbound) does the problem occur. – Philip Couling Feb 12 '21 at 16:25
  • `traceroute` assumes that any failures are symmetric. It can't tell you which direction an asymmetric failure is in. – Mark Feb 12 '21 at 23:24
  • The TCP/IP protocol requires acknowledgement of each – waltinator Feb 13 '21 at 02:51
  • The TCP/IP protocol requires acknowledgement of each packet sent. Your insistence on "one way" testing seems weird. If a packet is to be sent from node A to node D, and is routed along a A <=> B <=> C <=> D network, A will send the packet to B; B will send an ACK back to A. B will use its local routing tables to send the packet to C. C returns an ACK to B, and uses its local routing tables to send packet to D. D sends an ACK to C. The return packet does the same in reverse (but could have different intermediate nodes, e.g. D <=> R <=> S <=> A if any routing tables have changed) – waltinator Feb 13 '21 at 03:10
  • The reverse route never uses the same entries as the outbound route especially if the reverse route is the exact mirror. The route A B C from 10.10.0.1 to 10.20.0.1 uses entries on A and B only (not C) in in reverse C B A uses entries on C and B's table (not A). Further outbound packets use entries keyed by 10.20.x.x but in reverse the entries are for 10.10.x.x. That's before we get into the complexities of firewall rules. Asymmetric problems are very common. – Philip Couling Feb 13 '21 at 09:02
  • 1
    Putting this more simply, to send you a letter, someone needs to know where you live. But to deliver back, you need to know where they live. Anyone can drop a letter in a post box, that doesn't mean the post service knows where they live to deliver the reply. – Philip Couling Feb 13 '21 at 09:11
  • 4
    @waltinator, Remember not all IP traffic is TCP. And while TCP and most (but not all) other network protocols communication in two directions, it's still useful to know which direction fails, be it due to routing mess-ups, overzealous filtering, hardware issues or whatever. – ilkkachu Feb 13 '21 at 16:10
  • Have you read the RFCs? `https://www.ietf.org/standards/rfcs/` start with 0020, 0768, 0791, 0792, 0793. The RFCs are the documents at the base of TCP/IP, UDP/IP and IP networking. – waltinator Feb 13 '21 at 21:21
  • 1
    @waltinator *I'm really trying to redraft this comment politely...*. Yes I have read all of those RFCs many times over as well as RFC 1149 and 2549. You have wholly misunderstood TCP. ACK packets are not generated by routing nodes. They are generated by the end recipient only. So in your example the initial packet is generated by A and then sent A => B => C => D. D then acknowledges it with an ACK packet sent D => C => B => A. In this example neither B nor C **ever** generate an ACK packet. They only *route* packets. – Philip Couling Feb 14 '21 at 01:31
  • Are you familiar with the OSI 7 level model? E.g. https://fossbytes.com/osi-model-7-layers-osi-model-explained/ – waltinator Feb 20 '21 at 04:22