1. Overview
In this tutorial, we’ll be looking at several commands that allow us to ping other hosts with TCP-based packets.
2. Why TCP Packet Based Ping?
ping is a network command tool that’s widely used to test the network reachability and quality between two hosts.
It works by sending an ICMP echo request to a network host and waiting for a reply. Then, ping displays several statistics such as the round trip time (RTT) of the packet, as well as the percentage of packets being dropped.
Interestingly, the word “ping” is also commonly used as a verb to represent the action of checking the reachability of the target network hosts without necessarily using the ping command for doing so.
2.1. Downside of ICMP Ping
It’s common for network hosts to implement a firewall rule to filter ICMP packets. In other words, network hosts might have a firewall rule to drop all ICMP packets while allowing TCP and UDP packets to pass through.
Additionally, network hosts can implement different traffic-shaping policies on ICMP and TCP packets. For instance, we can sometimes see a huge difference in RTT for ICMP and TCP packets on the same network hosts and it’s likely due to different traffic-shaping policies being applied.
As a result, the results from ICMP ping might not reflect the behavior of the TCP and UDP packets on the same network hosts. Therefore, if the intention is to test the reachability and quality of TCP or UDP-based packets, it’s better to perform the testing using tools that are based on TCP/UDP packets.
Fortunately, there are several command line tools out there that offer the same functionality using TCP or UDP packets.
3. tcptraceroute
tcptraceroute is a network utility in Linux that charts the path taken by a packet to reach the destination.
It works by sending a TCP packet to the host and waiting for the response. Although it’s more sophisticated than a simple ping program, tcptraceroute can display timing diagnostic information that tells us the quality of the network.
3.1. Installation
To obtain tcptraceroute in Debian-based Linux, we can install it using apt-get install:
$ sudo apt-get install -y tcptraceroute3.2. Pinging a Destination
Let’s ping google.com using the tcptraceroute command:
$ tcptraceroute google.com
Selected device eth0, address 172.17.0.2, port 46501 for outgoing packets
Tracing the path to google.com (142.250.199.46) on TCP port 80 (http), 30 hops max
1 172.17.0.1 0.058 ms 0.175 ms 0.082 ms
2 142.250.199.46 [open] 15.316 ms 6.684 ms 9.598 msThe first two lines of output show some diagnostic information about the source and destination hosts. From the second line, we can see that, by default, tcptraceroute probes the destination’s TCP port 80 since it’s the common HTTP port.
Then, it prints the packet hop information in five columns. The first column is simply the index of the hop and will be incremented as there are more hops. Then, the second column shows the address for each of the hops. The last three columns are the packet’s round trip time. The reason there are three columns is that tcptraceroute sends three separate TCP packets to probe the network hosts by default. This allows us to better understand the consistency of the performance.
3.3. Probing Other Port
To target a different port, we simply supply the port we want to ping as the second argument to tcptraceroute.
For example, let’s ping port 443 of google.com:
$ tcptraceroute google.com 443
Selected device eth0, address 172.17.0.2, port 53931 for outgoing packets
Tracing the path to google.com (142.250.199.14) on TCP port 443 (https), 30 hops max
1 172.17.0.1 0.081 ms 0.054 ms 0.060 ms
2 142.250.199.14 [open] 8.623 ms 8.789 ms 7.003 ms3.4. Changing the Number of Probes
We can change the number of probes we want to do using the -q option:
$ tcptraceroute -q 5 google.com
Selected device eth0, address 172.17.0.2, port 58589 for outgoing packets
Tracing the path to google.com (142.250.199.46) on TCP port 80 (http), 30 hops max
1 172.17.0.1 0.087 ms 0.024 ms 0.076 ms 0.054 ms 0.055 ms
2 142.250.199.46 [open] 7.761 ms 7.624 ms 8.253 ms 6.275 ms 7.525 msIn this example, we’ve sent five different probes to google.com and therefore there are five different columns showing the round trip time for each probe. From the result, we can see that the quality is rather consistent between the source and destination hosts. This is because the difference in the round trip time of each probe doesn’t differ much.
4. lft
lft is similar to tcptraceroute in that it tracks and times the packet’s route toward the destination. The main difference that sets lft apart from tcptraceroute is that it supports several more commands that return rich information regarding the route taken.
4.1. Installation
To install the lft command, we use the install command of the package manager in our Linux.
For instance, we run apt-get install on Debian-based Linux:
$ sudo apt-get install -y lft4.2. Pinging a Destination
To ping a destination, it’s sufficient to run lft followed by the hostname:
$ lft google.com
Tracing ..T
TTL LFT trace to 142.250.199.46:80/tcp
1 172.17.0.1 0.1ms
2 [target open] 142.250.199.46:80 7.4msThe command displays the result in a columnar format. The first column is simply the index of the hop. Then, it’s followed by the address of the hop. Finally, the third column shows the round trip time of the packet at that hop.
To send the probe to another port, we need to append the port number to the hostname, separated by a colon:
$ lft google.com:443
Tracing ..T
TTL LFT trace to 216.58.196.46:443/tcp
1 172.17.0.1 0.2ms
2 [target open] 216.58.196.46:443 8.2ms4.3. Sending Multiple Probes
In contrast to tcptraceroute, lft only sends one TCP packet for probing, by default. It’s evident from the result of the previous execution since it only returns one timing information per hop.
We can have lft send multiple probing packets per hop using the -m flag:
$ lft -m 5 google.com
lft -T -m 5 216.58.196.46:443
LFT trace started at 09-Oct-22 09:27:33 GMT
Tracing .........T
TTL LFT trace to 216.58.196.46:443/tcp
1 172.17.0.1 0.1/0.1/0.1/0.1/0.1ms
2 [target open] 216.58.196.46:443 7.1/7.9/7.6ms
LFT trace finished at 09-Oct-22 09:27:34 GMT (1.15s elapsed)With the option -m 5, we now see five different timing information and each corresponds to the round trip time taken by each packet.
4.4. Timing the Ping
The lft command supports the -T option that times the execution of the ping. Together with the -V verbosity option, we can obtain richer details about the execution time.
Let’s time our ping to google.com using -T and -V options:
$ lft -T -V google.com
Layer Four Traceroute (LFT) version 3.8
Receiving on eth0, type 1 (EN10MB), transmitting on eth0 as 922ba453f054 (172.17.0.2):53
Receive link type is EN10MB (1), skipping 14 bytes
Transmit Initial Sequence Number (ISN) will be 797601297
LFT trace started at 09-Oct-22 09:37:17 GMT
TTL LFT trace to 142.250.199.46:80/tcp
1 172.17.0.1 0.0ms
2 [target open] 142.250.199.46:80 8.7ms
LFT trace finished at 09-Oct-22 09:37:18 GMT (1.06s elapsed)
Time spent tracing: 0.06s, resolving: 1.01sFrom the output, we can see that the total time it spent executing is 1.06 seconds. Out of that total execution time, lft spent a mere 0.06 seconds tracing the packets. What’s interesting to note is that it spent 1.01 seconds in “resolving”. The “resolving” here is referring to the reverse DNS lookup it performs on each hop’s address.
4.5. Disabling Reverse DNS Lookup
From the previous example, we see how lft is spending so much time resolving the hostname of the address.
If we aren’t interested in the registered domain name of each address, we can disable the resolution using the -n option:
$ lft -T -V -n google.com
Layer Four Traceroute (LFT) version 3.8
Receiving on eth0, type 1 (EN10MB), transmitting on eth0 as 172.17.0.2:53
Receive link type is EN10MB (1), skipping 14 bytes
Transmit Initial Sequence Number (ISN) will be 1114150539
LFT trace started at 09-Oct-22 09:42:10 GMT
TTL LFT trace to 216.58.196.14:80/tcp
1 172.17.0.1 0.0ms
2 [target open] 216.58.196.14:80 7.6ms
LFT trace finished at 09-Oct-22 09:42:10 GMT (0.05s elapsed)
Time spent tracing: 0.05sThe command returns much faster now as lft no longer attempts to resolve the domain name of each hop’s address.
5. Conclusion
In this article, we learned that ICMP-based ping might not be the best tool for learning the behavior of TCP and UDP-based traffic.
Then, we looked at tcptraceroute as a non-ICMP-based ping that probes target hosts using TCP packets. Finally, we’ve discussed the working of lft along with its different option flags to enrich the diagnostic output from the program.