Nmap online course

Nmap Packet Trace: Viewing and Interpreting Sent and Received Packets

Learn how to use Nmap --packet-trace to inspect sent and received packets, interpret TCP and ICMP responses, troubleshoot filtering, and correlate trace data with scan results.

Nmap packet tracing shows packet activity generated and observed by Nmap during a scan. The --packet-trace option prints low-level details about probes, replies, endpoints, protocols, and timing so you can compare what Nmap sent with what it received.

Use packet tracing only on systems and networks you are authorized to test. Keep troubleshooting scans narrow, choose low-impact options where possible, and avoid unnecessary high-volume scans. Packet tracing exposes scan traffic; it does not bypass firewalls, access-control lists, routing restrictions, or other network controls.

What Nmap Packet Tracing Is Used For

A normal Nmap report summarizes conclusions such as whether a host is up or whether a port is open, closed, or filtered. Packet tracing adds evidence behind those conclusions. It can help you learn how host discovery works, understand TCP and ICMP behavior, and investigate results that differ from expectations.

Tracing is especially useful when results may be affected by filtering, routing, firewalls, target-host behavior, packet loss, or name resolution. For example, a host may appear down because discovery replies are filtered, or a port may appear filtered because a firewall silently drops probes.

Packet trace is not a replacement for the final scan report. Treat it as diagnostic evidence and correlate it with the reported host status, port state, latency, scan type, and any reason information.

Enabling --packet-trace

Place --packet-trace among the Nmap options before the target. The command can include host discovery, a port-scan method, a port list, timing controls, verbosity, DNS settings, or reason reporting.

nmap [options] --packet-trace target

Start with one authorized host so that the output is manageable:

nmap -sn --packet-trace 192.168.5.102

The -sn option performs host discovery without a port scan. Depending on privileges, platform, target location, and Nmap defaults, the discovery process may use more than one probe type.

To trace a small TCP SYN scan and display the reason for each reported state:

sudo nmap -sS -p 80,443 --packet-trace --reason 192.168.5.102

Useful options with packet tracing

Option — Purpose — Useful combination

--packet-trace — Prints packet-level send and receive information — Use with any suitable scan for troubleshooting.

-sn — Performs host discovery without a port scan — Use to study whether one authorized host responds.

-sS — Performs a TCP SYN scan — Use with a small explicit port list to study SYN responses.

-p — Selects ports — Limit the trace to ports such as 80,443.

--reason — Displays why Nmap assigned a host or port state — Use to connect trace evidence to the final conclusion.

-n — Disables DNS resolution — Use when reverse DNS activity adds noise or delay.

-v and -vv — Increase progress and result detail — Use when you need context in addition to packet records.

-T3 — Uses a moderate timing profile — Useful while diagnosing ambiguous results without starting aggressively.

Understanding Packet-Trace Output

Packet records commonly begin with a direction marker. SENT means Nmap transmitted a packet or probe. RCVD means Nmap received and recognized a packet.

Trace timestamps are elapsed time since the scan began. They are useful for comparing the delay between a probe and its response, identifying retransmissions, and spotting pauses caused by DNS or network behavior.

Protocol labels can include TCP, UDP, ICMP, and IP. Nmap may also print NSOCK diagnostic lines. NSOCK is Nmap's networking framework; these messages describe internal socket and network-I/O events, including DNS activity. They are not target-port results.

The final human-readable report is separate from individual packet records. A packet may contribute to a conclusion, but Nmap considers the scan method, retransmissions, filtering behavior, and other evidence before assigning a state.

Packet-trace line components

Component — Meaning — How to use it

SENT / RCVD — Direction of the packet from Nmap's perspective — Match an outgoing probe with an incoming response.

Elapsed timestamp — Time since the scan started — Measure response delay, retries, and DNS pauses.

Protocol — Network or transport protocol such as TCP, UDP, ICMP, or IP — Identify which kind of exchange occurred.

Source and destination IP addresses — Packet endpoints — Confirm that traffic involves the intended scanner and target.

Source and destination ports — TCP or UDP service endpoints — Check that a probe and reply concern the expected port.

TCP flags — Control bits such as SYN, ACK, and RST — Interpret connection attempts and resets.

TTL — IP hop limit — Compare packet direction and possible path differences, without treating it as definitive OS identification.

IP ID and packet length — IPv4 identification and total packet-size information — Use as supporting packet attributes.

TCP sequence, acknowledgement, window, and MSS values — TCP state and capability fields — Correlate segments and understand connection parameters.

Reading Endpoints and Directions

For every record, identify the source and destination IP addresses first. In a typical scan, a SENT line travels from the scanning host to the target, while a matching RCVD line travels from the target back to the scanner.

TCP and UDP records also contain source and destination ports. A TCP probe to target port 443 should have the target port as its destination. The reply normally reverses the endpoints. Nmap may use an ephemeral source port, meaning a temporary high-numbered port selected by the operating system. That source port can help associate a reply with the original probe.

Do not assume that every packet involving the scanner is a target response. DNS traffic may go between the scanner and a DNS server, and local-network discovery may use different addresses or protocols. Confirm the endpoints before drawing conclusions.

Interpreting TCP Trace Details

TCP is a transport protocol that uses ports and control flags. A SYN flag starts a connection attempt or serves as a scan probe. ACK acknowledges received sequence space. RST resets a connection or rejects an unexpected connection attempt. A record can contain combinations such as SYN/ACK.

For a common TCP SYN probe, the usual patterns are:

  • SYN followed by SYN/ACK: The service is responding as though it is willing to establish a connection. In a SYN scan, this commonly supports an open port conclusion; Nmap generally follows with a reset rather than completing the connection.
  • SYN followed by RST: The host responded but rejected the connection attempt. This commonly supports a closed port conclusion.
  • SYN with no matching response: The packet may have been filtered, lost, routed incorrectly, or ignored by the target. Depending on the scan type and other evidence, Nmap may report filtered or may not be able to resolve the state confidently.

Trace output may show a TCP sequence number, acknowledgement number, advertised window, and MSS. The sequence number tracks byte positions in a TCP stream. The acknowledgement number indicates the next sequence value expected from the peer. The window advertises how much data the receiver can accept, and MSS, or Maximum Segment Size, is a TCP option commonly visible in SYN packets.

Read TCP exchanges as conversations rather than isolated packets. Correlate flags and endpoints with Nmap's final port state and, when useful, the explanation supplied by --reason.

Interpreting ICMP Trace Details

ICMP, the Internet Control Message Protocol, carries diagnostic and control messages. Nmap may use an ICMP Echo Request as a host-discovery probe and may receive an ICMP Echo Reply from a reachable host. An ICMP Timestamp Request and its related reply are another possible discovery exchange.

ICMP records identify a type and code. The type identifies the broad message category, while the code provides more detail within that category. For example, an unreachable message can have different codes describing why delivery failed.

No ICMP reply does not prove that a host is down. Firewalls and host controls frequently filter ICMP while allowing other traffic. Evaluate ICMP evidence alongside TCP, UDP, local-network discovery, routing, and the final Nmap result.

IP-Layer Fields

The TTL, or Time To Live, limits how many router hops an IP packet may cross. Each router normally decreases the value. A reply can therefore have a different TTL from the outgoing probe because the packets travel in opposite directions or begin with different initial values.

Some traces show the IPv4 IP ID, the identification field used in fragmentation-related processing, and the packet length. These fields describe packet construction and can help distinguish records during analysis.

TTL can provide useful path context, but it is not a definitive operating-system identification method by itself. Avoid inferring an operating system from one TTL value.

Host Discovery Trace Example

Run this only against an authorized private-network host:

nmap -sn --packet-trace 192.168.5.102

While reading the output, look for SENT discovery probes and then search for RCVD records with the expected target address. Depending on the environment, Nmap may send ICMP probes, TCP discovery probes, ARP or neighbor discovery traffic, or other applicable probes. The exact mix varies with privileges, operating system, network location, target type, defaults, and Nmap version.

An observed response from the target or an appropriate local-network response supports Nmap's final statement that the host is up. Match the response to an earlier probe by checking addresses, protocol, ports, and relevant fields. Do not expect every environment to produce the same packet sequence.

DNS and NSOCK Activity

Nmap may perform a reverse DNS lookup, which asks DNS to map an IP address to a hostname. These lookups can appear as UDP traffic involving a DNS server and as NSOCK messages describing socket connections, reads, or writes.

Separate DNS and NSOCK records from target-probe records. NSOCK lines describe internal network-I/O events and do not mean that a target port is open. An unreachable DNS server or a slow lookup can add delay and make the trace harder to read.

Use -n to disable DNS resolution when you want an IP-focused diagnostic run:

nmap -sn -n --packet-trace 192.168.5.102

The trade-off is that Nmap will show IP addresses instead of resolved host names. Comparing runs with and without -n can reveal whether name resolution contributes to delays or output noise.

Correlating Packets With Nmap Conclusions

Always compare the trace with the final report. Check the host status, measured latency, scan type, port state, and any --reason explanation.

Observed exchange — Typical significance — Important caveat

TCP SYN followed by SYN/ACK — Common evidence for an open port in a SYN scan — Interpretation depends on the scan method and complete exchange.

TCP SYN followed by RST — Common evidence for a closed port — A different scan type may describe the same response differently.

ICMP Echo Request followed by Echo Reply — Supports a reachable host conclusion — Lack of this exchange does not prove the host is down.

Probe with no matching response — May support filtered or unresolved results — Filtering, loss, routing, and target behavior can look alike.

Repeated probes or retries — May indicate loss, filtering, or timing behavior — Retries are affected by scan type and timeout settings.

DNS or NSOCK messages — Show name-resolution or internal socket activity — They are not target-port state evidence.

An RST in response to a TCP probe often contributes to a closed-port determination. A missing response may lead to filtered or unresolved output depending on the scan type, retry behavior, and other packets. Network position and firewall rules can substantially change what Nmap sees.

Using Packet Trace for Troubleshooting

Host reported down unexpectedly

  • Confirm that discovery probes have SENT entries.
  • Look for RCVD ICMP, TCP, ARP, neighbor, or other appropriate responses.
  • Verify the target address, route, interface, subnet, and network segment.
  • Consider that host-discovery traffic may be filtered.

Narrow the test to one authorized target. If appropriate for the engagement, compare discovery with a scan that skips discovery, understanding that this changes the test and should be used only with permission. Validate from the network location where the host is expected to be reachable.

Port appears filtered or has no expected response

  • Verify that the intended TCP or UDP probe was sent to the expected destination port.
  • Look for a matching reply, an ICMP unreachable message, or retransmissions.
  • Investigate firewalls, ACLs, asymmetric routing, packet loss, and incorrect target addresses.

Use --reason with a small explicit port list. Start with moderate timing, and corroborate with firewall logs or an authorized packet capture when available.

Many NSOCK lines make the trace difficult to read

Identify whether the lines involve DNS server connections and distinguish them from SENT and RCVD target-probe records. Add -n for an IP-only run, reduce the target scope, and inspect the final report separately.

Different probes appear than expected

Review the scan type, discovery defaults, privileges, platform, target location, and enabled options. Nmap may use ICMP, TCP, ARP or neighbor discovery, and DNS-related traffic in different circumstances. Specify the intended scan mode explicitly and document environmental differences instead of assuming all traces are identical.

Timestamps show delays or repeated traffic

Compare the elapsed time between each SENT probe and any RCVD response. Look for retransmissions and delayed DNS activity. Reduce scope, use -n when DNS is irrelevant, and use conservative timing while determining whether the delay is network-related or target-related.

Timing and Retries

Timing templates, timeouts, and retry behavior affect both when probes appear and how many records are visible. Aggressive timing can make an ambiguous situation harder to diagnose by increasing concurrency or changing retransmission behavior.

Begin with a narrow target scope and moderate timing:

sudo nmap -sS -p 443 --packet-trace --reason -T3 192.168.5.102

Elapsed timestamps help identify slow responses, pauses between phases, and DNS-related delays. A repeated probe may indicate loss or filtering, but it may also reflect Nmap's normal retry logic. Interpret repetition together with the scan type and final state.

Packet Trace Compared With Other Diagnostic Output

-v and -vv provide more progress and result detail. They help explain what Nmap is doing at a higher level, but they do not replace packet-level records.

--reason explains the basis Nmap used for host and port states. Combining it with --packet-trace is useful because the trace shows the exchange while the reason output summarizes how that exchange affected the conclusion.

External tools such as tcpdump and Wireshark are complementary. An external capture can verify what reached a selected network interface, while Nmap packet tracing presents Nmap's view of its sent and recognized received activity.

sudo tcpdump -ni <interface> host 192.168.5.102

Use external captures only on systems and networks you administer or are authorized to monitor.

Practical Analysis Workflow

  1. Confirm authorization and limit the target to one host or a small approved set.
  2. Choose the smallest suitable scan, such as -sn for discovery or -sS -p 80,443 for a constrained TCP test.
  3. Add --packet-trace and, when useful, --reason.
  4. Read each SENT record: confirm the protocol, target address, destination port, and intended probe.
  5. Search for the corresponding RCVD record, checking reversed endpoints and response fields.
  6. Note timestamps, retransmissions, DNS activity, and unexpected destinations.
  7. Compare the evidence with Nmap's final host and port conclusions.
  8. If uncertainty remains, verify routing, firewall logs, DNS behavior, or an authorized interface capture.

Related Nmap Topics