When the Ping Command Becomes a ‘Liar’
We’ve all been there: a website loads perfectly, but pinging the server results in nothing but “Request timeout”. I once dealt with this headache while managing a Datacenter cluster for a startup. The system’s firewall had been configured to block all ICMP packets to hide from network scans.
Relying solely on ping or traceroute at this point will only leave you more confused. That’s why I always keep hping3 in my toolkit. It’s not just for connectivity checks; it’s a powerful “packet crafter.” You can simulate various types of traffic to see how the system truly reacts.
hping3: The Swiss Army Knife of Networking
While nmap excels at port scanning and tcpdump is great for packet capturing, hping3 sits right in the middle. It allows you to manually craft TCP, UDP, or ICMP packets with custom flags like SYN, ACK, FIN, or RST.
The most valuable aspect of hping3 is its ability to probe firewalls in extreme detail. You can send a SYN packet to port 80 to check access even when ICMP is banned. For me, hping3 is the fastest way to verify if a new firewall rule is “blocking too much by mistake.”
Installing hping3 in 30 Seconds
Most Linux repositories have this tool available. Simply run the command corresponding to your distribution:
# Debian, Ubuntu, Kali Linux
sudo apt update && sudo apt install hping3 -y
# RHEL, CentOS, Fedora
sudo yum install hping3Note: Since hping3 interacts deeply with the network layer to create raw sockets, you must use sudo privileges.
5 Real-World hping3 Techniques You Need to Know
1. TCP Ping: Piercing Through the ICMP Wall
When traditional ping is blocked, use TCP Ping. Instead of sending ICMP, we send a TCP SYN packet to an open port (like port 80 or 443). If we get a response, the connection is alive.
sudo hping3 -S -p 80 1.1.1.1-S: Sends a packet with the SYN flag.-p 80: Targets port 80.
Look for the flags=SA (SYN-ACK) in the output. It confirms the port is open and ready for connection.
2. Stealth Port Scanning
Although nmap is popular, hping3 offers a different level of granularity. You can test how a firewall handles unusual packets. For example, scanning a port range from 80 to 100 using SYN packets:
sudo hping3 -8 80-100 -S 192.168.1.10If you receive flags=RA (RST-ACK), the port is closed but the firewall allowed the packet through. If there is total silence (timeout), the firewall has silently “dropped” your packet.
3. Measuring Real-World Service Latency
In a Datacenter, ICMP packets are often assigned low priority, leading to inaccurate ping results. I often use hping3 to measure the latency of the actual service port:
sudo hping3 -c 10 -S -p 443 google.comThe rtt result here is the actual time a user waits when initiating an HTTPS connection (Port 443).
4. Traceroute via TCP SYN
Have you ever seen traceroute return nothing but asterisks * * *? That’s because intermediate hops are blocking UDP/ICMP. Try using TCP SYN to “see through” them:
sudo hping3 --traceroute -V -S -p 80 8.8.8.8This method helps you identify exactly which router along the path is causing the bottleneck.
5. Stress Testing (Load Testing)
This is a powerful but sensitive feature. I often use it to test the responsiveness of anti-DDoS systems at work. Warning: Only run this command on systems you own.
sudo hping3 -S -p 80 --flood 192.168.1.10The --flood parameter sends packets as fast as possible without waiting for responses. This command helps verify if SYN Cookies on the firewall automatically activate during an attack.
Understanding the Return Flags
When running hping3, focus on the flags column:
- SA (SYN-ACK): The port is open, come on in.
- RA (RST-ACK): The port is closed, but the host responded.
- A (ACK): Often encountered when probing stateful firewalls.
- No response: The packet was “dropped” (discarded) by the firewall.
A Real-World Story: The Nightmare MTU Bug
I once debugged an issue with an accounting server: Ping worked fine, but web access was incredibly slow and intermittent. After using hping3 to send packets of varying sizes (the -d flag), I discovered an old switch that failed when processing packets larger than 1400 bytes. If I had only used default ping, I might have spent a week replacing perfectly good cables.
Conclusion
hping3 isn’t a tool you’ll use every day. But when complex network issues arise, it provides the “hard evidence” you need when working with infrastructure teams. Try experimenting with it in a lab environment; you’ll understand network protocols more deeply than any textbook could teach you.
