Nmap vs Wireshark: Find a Service or Explain Its Traffic?
Use one local HTTP service to see when an Nmap port check answers the question and when a Wireshark packet capture is needed.
Suppose a small HTTP server should be accepting connections on port 18081. You can ask two different questions: does a probe reach a TCP listener at that address and port? Or what packets were exchanged during a particular attempt? Nmap is useful for the first question; Wireshark is useful for the second. Neither result alone proves that the page contains the expected content.
The comparison here uses one service you own, one target address (127.0.0.1), and one TCP port. It does not rank the tools by their wider feature sets.
Give Nmap a precise question
Start a disposable local service in one terminal:
mkdir -p /tmp/network-tool-demo
printf 'network-tool-demo\n' > /tmp/network-tool-demo/index.html
python3 -m http.server 18081 --bind 127.0.0.1 --directory /tmp/network-tool-demoFrom a second terminal, scan only that loopback port:
nmap -sT -Pn -p 18081 127.0.0.1The expected state while the server is listening is open. After you stop the server and repeat the command, a reachable loopback port with no listener is normally reported closed. The Nmap port-scanning guide is careful about scope: states describe how the scanner sees a port, and a different vantage point can see a different state. -sT requests a TCP connect scan; -Pn avoids making this small test depend on a separate host-discovery result.
That answer is deliberately narrow. open does not prove that the server is HTTP, that it serves the right file, or that another machine can connect through a firewall. To verify the application response, make an HTTP request:
curl -fsS http://127.0.0.1:18081/Capture the attempt when the packets matter
Start Wireshark on the loopback capture interface before repeating the Nmap scan or curl request. The interface name and capture permissions vary by operating system. Wireshark’s loopback capture guidance explains why a request to 127.0.0.1 will not appear on an ordinary Ethernet or Wi-Fi capture interface.
After the capture, use the display filter tcp.port == 18081. A connect scan should reveal a TCP connection attempt and, for an open port, connection establishment; a curl request adds application traffic. Select a packet to inspect the addresses, ports, flags and timing. Wireshark distinguishes capture filters from display filters: a display filter can hide or show packets that were captured, but cannot recover packets from an interface you did not capture.
Do not expect an identical packet count on every system. The scanner, operating system, capture point and background traffic affect what appears. If the capture is empty, first verify the interface and capture permissions, then the display filter.
| Reader’s question | Better first tool | What to record |
|---|---|---|
| Does this address and TCP port accept a connection from here? | Nmap with an explicit target and port | Target, scan type, vantage point, observed state |
| What happened during this particular connection attempt? | Wireshark on the relevant interface | Packet sequence, addresses, ports, timing |
| Did the application return the expected page? | An HTTP client such as curl |
Status and response body |
For guided follow-up, LabEx lists a local service-version exercise in Nmap and a Wireshark display-filter exercise. Their published titles identify separate practice tasks; the local experiment above gives you a shared question to bring to each one.
References
- Nmap’s port-scanning overview defines the observed port states and their dependence on viewpoint.
- Nmap’s TCP connect scan documentation explains the
-sTprobe used here. - Wireshark’s loopback capture guide and display-filter guide explain the capture point and the distinction between captured and displayed packets.