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 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 > 220.127.116.11:22 S ttl=64 id=19852 iplen=40 seq=4080408859 win=1480
RCVD (0.2650s) TCP 18.104.22.168: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 > 22.214.171.124:22 S ttl=64 id=19852 iplen=40 seq=4080408859 win=1480
RCVD (1.2650s) TCP 126.96.36.199: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 > 188.8.131.52:22 S ttl=64 id=19852 iplen=40 seq=4080408859 win=1480
RCVD (2.2650s) TCP 184.108.40.206: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 > 220.127.116.11:22 S ttl=64 id=19852 iplen=40 seq=4080408859 win=1480
RCVD (3.2650s) TCP 18.104.22.168: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 > 22.214.171.124:22 S ttl=64 id=19852 iplen=40 seq=4080408859 win=1480
RCVD (4.2650s) TCP 126.96.36.199: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.
- 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.
4 thoughts on “Nping aka Layer 4 Ping”
Maybe https://github.com/vaporup/ssh-tools/blob/master/ssh-ping is what you are looking for ;-)
Haha, exactly. Thanks for that. ;)
Sounds like building a simple nagios-like monitoring. Where do you plan to integrate this nping?
So far, for layer4 connectivity tests I use netcat, e.g.
nc --zero --verbose lx3.weberlab.de 22(gnu netcat here). Layer4 is also the appropriate way to test whether TCP connectivity is allowed (re firewall). icmp might be dropped by some network ops per default.
I’ll have a look an nping, maybe it has some neat features I could also use. Thanks for mentioning it.
Application-layer monitoring is complete different thing to me.
Issueing ssh connections at the rate of 1/s might be evaluated as malicious by some IDS and you get blocked.
Please check this project out too: