Packet-level diagnostics can add context to a scanner result, but they do not replace careful enumeration, service validation, or authorization. This guide outlines a controlled way to compare observations without turning discovery into indiscriminate probing.
$ scanner --target lab-host --ports 80,443 [scan ] tcp/80 open [scan ] tcp/443 filtered $ packet-check --tcp --port 443 lab-host [reply ] flags=RA rtt=14.1 ms compare result depends on path and policy scope: documented test environment
Page 07 / field guide
Scanner labels summarize observed behavior. Packet testing helps explain the response path, but every interpretation depends on timing, filtering, routing, host configuration, and the exact probe used.
Use this page when a scanner result needs a narrowly scoped follow-up. Begin with the least intrusive check and preserve the original evidence so later comparisons remain meaningful.
Interpretation model
Do not treat a single packet response as proof of service identity. Build an explanation from several observations and note what remains uncertain.
Look at the exchange that produced the state: a completed handshake, a reset, silence, or an intermediate filtering response. The same service can appear different from another network position.
Once a port appears reachable, use an appropriate, authorized application-level check. A transport response alone does not establish which software is listening.
Repeatable method
Use a written test record. It makes an apparent contradiction easier to investigate and reduces the temptation to add uncontrolled probes.
Differences may come from stateful firewalls, rate limits, load balancers, NAT, asymmetric routing, packet loss, retries, or a service changing state. Archived examples are concepts, not guarantees for every current platform.
For protocol fundamentals, continue with the TCP/IP notes. For broader packet concepts, see the tool overview.
FAQ
Keep the scope narrow and the interpretation honest.
No. It means the probe did not receive the response needed to classify the port as open or closed. A filter, route, timeout, or other condition may be responsible.
Transport flags can show reachability behavior, but service identification normally requires an appropriate application-level exchange and supporting evidence.
They may use different probe types, retry rules, timing, source locations, or interpretations. Compare their exact methods before comparing their labels.
Usually not. Start with a smaller, slower, better-documented test. Increased volume can trigger controls or affect the system you are trying to understand.
Keep the authorization boundary, target description, date, source segment, commands, tool versions, packet observations, and any relevant environmental changes. Exclude credentials and private captures.
Send a concise note about the page, environment, and non-sensitive observation. Tping treats technical records as evidence to review, not instructions to test unknown systems.