We’ve talked about several testing utilities in the past such as ping, traceroute, iperf, and others. And every so often a new one pops into my radar, and I keep repeating “How come I didn’t know about this already?” In this case, the utility in question is nping.
There are so many ping variations out there: ping, fping, hping3, psping, hrping. I am sure I will discover a couple more in the following years. I was surprised I didn’t know about nping because it’s a very well maintained and updated utility, while some of the ones listed above are unmaintained and haven’t aged well over the years.
Nping can do so much more than simple ICMP pinging. It can manipulate pretty much any parameter and field of TCP, UDP, ICMP packets, and it can be used for network stack stress testing, ARP poisoning, Denial of Service attacks, route tracing, etc.
Nping is part of the nmap package and it’s installed by default if you install nmap on your Linux system with:
apt-get install nmap
Nmap and nping are supported on Linux, Windows, Mac OS X, so if you learn to use it on one platform your knowledge is transferable to the rest. That’s not the case for other utilities, such as hping, fping, and psping.
On Windows specifically you’d need to install the npcap driver for nping to work properly. If you run the nmap or the nping installer (or you have Wireshark installed), the drivers will be installed automatically.
The simplest thing you can do with nping is to test if a port of any kind (TCP, UDP, ICMP) is open.
There are several ICMP utilities, and most of them do the basics of sending an echo request packet, waiting for an echo reply and messing the latency. Nping includes that functionality as shown below (you might need to run this with elevated privileges).
netbeez.net$ sudo nping --icmp -c 2 google.com Starting Nping 0.7.40 ( https://nmap.org/nping ) at 2020-08-31 22:21 PDT SENT (0.0794s) ICMP [172.31.0.69 > 188.8.131.52 Echo request (type=8/code=0) id=63051 seq=1] IP [ttl=64 id=16703 iplen=28 ] RCVD (0.2469s) ICMP [184.108.40.206 > 172.31.0.69 Echo reply (type=0/code=0) id=63051 seq=1] IP [ttl=55 id=62721 iplen=28 ] SENT (1.0800s) ICMP [172.31.0.69 > 220.127.116.11 Echo request (type=8/code=0) id=63051 seq=2] IP [ttl=64 id=16703 iplen=28 ] RCVD (1.2969s) ICMP [18.104.22.168 > 172.31.0.69 Echo reply (type=0/code=0) id=63051 seq=2] IP [ttl=55 id=39803 iplen=28 ] Max rtt: 216.656ms | Min rtt: 167.355ms | Avg rtt: 192.005ms Raw packets sent: 2 (56B) | Rcvd: 2 (92B) | Lost: 0 (0.00%) Nping done: 1 IP address pinged in 1.44 seconds
-c option just tells nping to send 2 packets instead of the default 5.
The beauty of nping is that it allows you to manipulate parameters such as the ICMP sequence number field, the originate timestamp, and many others.
TCP Connect Mode
Testing a TCP port is very simple with the
--tcp-connect option. With this option you can change some basic parameters of a TCP connection such as source and destination port.
netbeez.net$ nping --tcp-connect -c 2 -p 80 google.com Starting Nping 0.7.40 ( https://nmap.org/nping ) at 2020-08-31 22:15 PDT SENT (0.0045s) Starting TCP Handshake > google.com:80 (22.214.171.124:80) RCVD (0.0167s) Handshake with google.com:80 (126.96.36.199:80) completed SENT (1.0074s) Starting TCP Handshake > google.com:80 (188.8.131.52:80) RCVD (1.0192s) Handshake with google.com:80 (184.108.40.206:80) completed Max rtt: 12.612ms | Min rtt: 11.676ms | Avg rtt: 12.144ms TCP connection attempts: 2 | Successful connections: 2 | Failed: 0 (0.00%) Nping done: 1 IP address pinged in 1.02 seconds
The TCP mode is very similar to the TC connect, but it allows you to manipulate several other parameters such as the packet flags and the system’s TCP windows size. Below you can see how you can send a TCP packet with the SYN flag set.
netbeez.net$ sudo nping --tcp -c 2 --flags S -p 80 google.com Starting Nping 0.7.40 ( https://nmap.org/nping ) at 2020-08-31 22:39 PDT SENT (0.0926s) TCP 172.31.0.69:22537 > 220.127.116.11:80 S ttl=64 id=37825 iplen=40 seq=3213691949 win=1480 RCVD (0.2601s) TCP 18.104.22.168:80 > 172.31.0.69:22537 SA ttl=55 id=0 iplen=44 seq=3343970569 win=65535 <mss 1460> SENT (1.0932s) TCP 172.31.0.69:22537 > 22.214.171.124:80 S ttl=64 id=37825 iplen=40 seq=3213691949 win=1480 RCVD (1.3101s) TCP 126.96.36.199:80 > 172.31.0.69:22537 SA ttl=55 id=0 iplen=44 seq=3359595746 win=65535 <mss 1460> Max rtt: 216.664ms | Min rtt: 167.290ms | Avg rtt: 191.977ms Raw packets sent: 2 (80B) | Rcvd: 2 (92B) | Lost: 0 (0.00%) Nping done: 1 IP address pinged in 1.39 seconds
The UDP mode works as follows:
netbeez.net$ sudo nping --udp -c 2 -p 5001 172.31.0.25 Starting Nping 0.7.40 ( https://nmap.org/nping ) at 2020-08-31 22:41 PDT SENT (0.0977s) UDP 172.31.0.69:53 > 172.31.0.25:5001 ttl=64 id=48591 iplen=28 SENT (1.0981s) UDP 172.31.0.69:53 > 172.31.0.25:5001 ttl=64 id=48591 iplen=28 RCVD (1.3151s) UDP 172.31.0.25:5001 > 172.31.0.69:53 ttl=64 id=42729 iplen=1498 Max rtt: 216.701ms | Min rtt: 216.701ms | Avg rtt: 216.701ms Raw packets sent: 2 (56B) | Rcvd: 1 (1.498KB) | Lost: 1 (50.00%) Nping done: 1 IP address pinged in 1.40 seconds
For all of these modes, nping measures latency and prints statistics following every execution.
The most interesting feature of nping is the “echo mode” This is a nifty network troubleshooting functionality that uses a server and a client that communicate with each other on a side TCP channel, while sending testing traffic to each other. To put it in the their own words:
The Echo mode is based on a client/server architecture. Both ends run Nping, one of them in server mode and the other in client mode. The way it works is: the Nping client performs an initial handshake with the server over some standard port (creating a side-channel). Then it notifies the server what packets are about to be sent. The server sets up a liberal BPF filter that captures those packets, and starts listening. When the server receives a packet it encapsulates it (including the link layer frame) into our own protocol packet and sends it back to the nping client. This would be essentially like running tcpdump on the remote machine and having it report back the packets you sent to it with Nping.
There is a protocol specification that describes how this works, and here is an example:
netbeez.net$ sudo nping -c 1 --echo-client "public" scanme.nmap.org Starting Nping 0.7.40 ( https://nmap.org/nping ) at 2020-09-01 06:31 PDT SENT (1.0132s) ICMP [172.31.0.69 > 188.8.131.52 Echo request (type=8/code=0) id=57924 seq=1] IP [ttl=64 id=51692 iplen=28 ] CAPT (1.0774s) ICMP [99.xx.xx.xx > 184.108.40.206 Echo request (type=8/code=0) id=57924 seq=1] IP [ttl=54 id=51692 iplen=28 ] RCVD (1.1608s) ICMP [220.127.116.11 > 172.31.0.69 Echo reply (type=0/code=0) id=57924 seq=1] IP [ttl=55 id=55773 iplen=28 ] Max rtt: 147.395ms | Min rtt: 147.395ms | Avg rtt: 147.395ms Raw packets sent: 1 (28B) | Rcvd: 1 (46B) | Lost: 0 (0.00%)| Echoed: 1 (46B) Nping done: 1 IP address pinged in 2.09 seconds
scanme.nmap.org is a test echo server nmap.org is maintaining for testing purposes.
The “SENT” line tells us what IPs are in the outgoing test traffic from the client to the destination server.
The “CAPT” like tells us what the destination server actually received. The destination server sees a source IP (99.xx.xx.xx) that is different than the actual IP of the client (172.31.0.69) which reveals the presence of a NAT between the client and the server.
The “RCVD” line is the packet the client actually received from the server.
In the past we talked about hping3 as a network testing utility. Hping3 offers a wide range of packet manipulation and testing capabilities. The problem is hping3 is not maintained any more, and works only on Linux. For what I personally usually use hping3, nping is a full replacement and it might be for you as well.