I was missing a generic layer 4 ping in my toolbox. Initially searching for a mere TCP ping, I have found Nping which completely satisfies my needs and gives so much more. ;)
What’s a layer 4 ping, and why? –> A normal ping (= ICMP echo-request) reveals whether the destination IP address, that is: the mere server/VM, is up and running. That’s great for a layer 3 networker since routing to and from the destination is already working. However, it does NOT reveal whether or not a service at layer 4 (TCP or UDP) is up and running as well. That’s what a layer 4 ping is about: sending TCP SYNs to the port in question, waiting for a “SYN ACK” (port is listening) or “RST”/no reply (port is not available). Common use cases: Waiting for a service to start again after an upgrade, or waiting for new firewall policies (to allow or deny) a certain port.
While I used some special tools for upper-layer protocol pings (ref: Advanced Ping: httping, dnsping, smtpping), I was still missing a generic one as I wanted to test several other TCP ports in a ping style. For a Layer 4 Traceroute, I blogged several years ago.
Nping
“Nping is an open source tool for network packet generation, response analysis and response time measurement”, https://nmap.org/nping/. You can easily get it on any Debian/Ubuntu-based Linux system by installing Nmap, to which Nping belongs to:
sudo apt install nmap
Its usage for TCP/UDP is straightforward. Simply use the --tcp option along with the port in question -p <port>, in my test case, the SSH port 22:
weberjoh@nb15-lx:~$ sudo nping --tcp -p 22 lx3.weberlab.de Starting Nping 0.7.01 ( https://nmap.org/nping ) at 2021-04-22 12:21 CEST SENT (0.0791s) TCP 192.168.3.85:1181 > 85.215.94.29:22 S ttl=64 id=19852 iplen=40 seq=4080408859 win=1480 RCVD (0.2650s) TCP 85.215.94.29:22 > 192.168.3.85:1181 SA ttl=54 id=0 iplen=44 seq=847994447 win=29200 <mss 1460> SENT (1.0793s) TCP 192.168.3.85:1181 > 85.215.94.29:22 S ttl=64 id=19852 iplen=40 seq=4080408859 win=1480 RCVD (1.2650s) TCP 85.215.94.29:22 > 192.168.3.85:1181 SA ttl=54 id=0 iplen=44 seq=863592152 win=29200 <mss 1460> SENT (2.0811s) TCP 192.168.3.85:1181 > 85.215.94.29:22 S ttl=64 id=19852 iplen=40 seq=4080408859 win=1480 RCVD (2.2650s) TCP 85.215.94.29:22 > 192.168.3.85:1181 SA ttl=54 id=0 iplen=44 seq=879302070 win=29200 <mss 1460> SENT (3.0831s) TCP 192.168.3.85:1181 > 85.215.94.29:22 S ttl=64 id=19852 iplen=40 seq=4080408859 win=1480 RCVD (3.2650s) TCP 85.215.94.29:22 > 192.168.3.85:1181 SA ttl=54 id=0 iplen=44 seq=895059280 win=29200 <mss 1460> SENT (4.0851s) TCP 192.168.3.85:1181 > 85.215.94.29:22 S ttl=64 id=19852 iplen=40 seq=4080408859 win=1480 RCVD (4.2650s) TCP 85.215.94.29:22 > 192.168.3.85:1181 SA ttl=54 id=0 iplen=44 seq=910622060 win=29200 <mss 1460> Max rtt: 185.982ms | Min rtt: 179.872ms | Avg rtt: 183.451ms Raw packets sent: 5 (200B) | Rcvd: 5 (230B) | Lost: 0 (0.00%) Nping done: 1 IP address pinged in 4.29 seconds
Viewing the packets with Wireshark looks a bit odd since it displays many [TCP Retransmission] and other TCP failures. Never mind, this is correct behaviour from the layer 4 ping tools point of view. After receiving the [SYN, ACK] from the server, Nping sends a [RST] to free the session tables on the server and intermediary NAT/firewalls.
Mission accomplished: Testing whether or not the destination port is listening.
Some notes/caveats:
- Using Nping for pinging an HTTP/HTTPS server isn’t the best way, since it only sends TCP SYNs but no HTTP GET or the like. Use httping instead.
- This is just the tip of the iceberg of Nping. You can do so much more, e.g., different kind of ICMP based pings (that is: not only echo-request but any ICMP type) as well as some ARP/RARP stuff. Nice!
- I’m having trouble using Nping with IPv6. Pings are SENT but not RCVD. Tested it on different systems, but did not succeed. Might be related to the Nping To-Do list that states “Improve IPv6 support. Currently it doesn’t work well.” ;)
- As seen in the Wireshark screenshot, Nping uses the same source port for each ping. To my mind, it should use a different random source port for each ping to have unique “tcp streams” among the pings. At least optionally.
- Windows users can leverage “tcping.exe” for layer 4 pings.
P.S.: I am still missing an sshping tool that does an SSH login or at least a handshake once per second. Haven’t found one yet.
Photo by Steven Skerritt on Unsplash.