Summary

  • In Sagan’s pinned traceroute parser, is_success can be true when the final supplied hop has a non-error RTT but no packet sender equals the destination address. The library supplies destination_ip_responded as a separate test; this distinction is not concealed.
  • last_median_rtt can remain populated when the terminal hop is silent, because a reverse scan finds an earlier responding hop. The number is not automatically a latency measurement to the target.
  • Twenty-one existing upstream tests and five synthetic cases passed locally against the exact selected classes without network calls. They establish these parsing behaviours, not a deployed outage, consumer misuse or application-availability result.

A trace finishes with a reply from a router. Its round-trip time is ten milliseconds. The address is not the destination. A program inspecting Sagan’s result object can nevertheless find is_success set to true.

That is the outcome of a small synthetic check, not an account of a customer incident. It exposes a precise reading problem. The successful condition in this parser is not the same condition as a reply from the destination. A user who wants the latter answer has another property to read.

Sagan is RIPE NCC’s parsing library for RIPE Atlas measurement results. Its stated purpose is useful and modest: handle changing formats and their awkward cases so users can work with Python objects rather than repeat the same JSON interpretation. The source considered here is commit 45d01f754896ad648e5b306c4209153bab774af9, committed on 2026-06-03. This is a source boundary, not an inventory of installed copies or a claim about the package currently downloaded by every user. Project purpose.

Three questions at the final hop

The relevant functions ask three different questions about the final hop in the supplied result list.

set_destination_ip_responded looks for a packet whose origin matches the result’s destination address. set_last_hop_responded looks for a packet with a truthy RTT. set_is_success looks for a truthy RTT on a packet not marked as an error. The last function does not add a destination-address comparison. Traceroute selectors.

Those distinctions matter more than the friendly names. A normal reply from the target can satisfy all three predicates. A non-error reply from another address can satisfy the last-hop and success predicates without satisfying the destination predicate. The code has not moved the destination. It has classified another aspect of the final supplied hop.

Conversely, a packet from the destination address can be marked as an error. In the synthetic case with a ten-millisecond reply and the parser’s p error code, the destination and last-hop response flags were true while is_success was false. The reported final-hop error was “Port unreachable”. The base parser records error state separately from the packet’s address and numerical timing. An address response and a non-error classification can therefore diverge in either direction. Error handling.

It would be unfair to present this as a hidden failure to supply destination evidence. Sagan already exposes the dedicated destination flag. Its type documentation lists that flag alongside the last-hop response flag, the success flag and final-hop errors. Readers have the components for a more exact answer. The risk begins when an application keeps one convenient component and silently lets its name stand for the others. This research has not identified a named application doing that. Published properties.

The ten-millisecond number has several homes

The RTT selector introduces a second distinction. A hop computes its median from retained packet RTTs. The result parser then walks the supplied hop list backwards until it finds a truthy hop median, which becomes last_median_rtt. Finding that number does not require a match with the destination address.

A second synthetic trace contained three hops. An earlier router replied in five milliseconds, the next in ten, and the final hop contained a timeout marker. Sagan returned false for destination response, last-hop response and success. It still returned ten milliseconds as last_median_rtt.

There is nothing contradictory about those four outputs. The number describes the selected responding hop. The flags describe conditions at the final supplied hop. Contradiction arrives only if a report labels the number “target latency” or interprets the mere existence of a latency value as proof that the target responded.

The same ten-millisecond value also appeared in the synthetic ordinary target reply, the non-target router reply and the target error reply. Identical magnitudes did not make the observations equivalent. Nor would taking their median make their endpoint meanings converge. Before combining numbers, a reader needs to know which packets and which condition qualified them for the calculation.

The reverse scan is a rule over the supplied list, not an independent reconstruction of the real forwarding path. These checks used an ordinarily ordered list. They do not establish that arbitrary malformed, reordered or unusual results always identify the physically furthest router. A value should retain the context of its selection rather than borrow certainty from the word “last”.

A fast reading need not keep every object

Sagan offers parse_all_hops=False for users who do not need every parsed hop. Its documentation explains that this option can leave only the final Hop object in the result’s hops list. It is a sensible way to avoid unnecessary object construction.

For the three-hop synthetic trace, minimal parsing retained Hop index three, the silent final hop. The derived last_median_rtt was still ten milliseconds, found while examining the earlier responding hop. The complete original input remained in raw_data. This is not deletion of the measurement source; it is a distinction between the original input, the objects retained for convenience and the derived property.

A consumer that exports only hops and the derived number may consequently omit the parsed object that supplied that number. Anyone wishing to explain the selection later should retain the original input or explicitly record the selected hop context. The choice is practical, not mystical: less object construction should not become an undocumented change in what a recipient can inspect.

A local check, not a survey of users

The existing upstream traceroute tests were run against the exact captured base, compatibility and traceroute source, loaded as local modules. All twenty-one passed. Five invented cases then exercised a non-target final reply, a normal target reply, terminal silence with an earlier RTT, a target error reply and the same silent trace under minimal parsing. All five passed their declared expectations. Network operations were prohibited; none occurred. Existing regression tests.

This is stronger than an impression from a property name and narrower than an operational finding. It checks the selected classes and examples. It does not prove equivalence with every released package, every producer format or controller acceptance rule. It does not measure how often such terminal states occur, whether users mislabel them or whether a particular service failed. The upstream tests also demonstrate that several response distinctions already receive explicit attention. The evidence is not a licence to call the library careless.

Addresses and packets need their own roles

Even a destination-address match is a predicate, not a certificate. The parser compares strings in a result. It does not authenticate the packet sender or test an application transaction.

The generic Atlas result documentation provides another reminder against flattening address roles. It distinguishes top-level from, added by the measurement backend, from probe-derived src. These fields can legitimately differ. In the traceroute parser, the nested packet’s from is used as that packet’s origin. A top-level address, a nested responding address and the destination address answer different questions; familiar spelling does not make them interchangeable. Official address distinctions.

ICMP also speaks about more than destination services. RFC 792 describes Time Exceeded messages associated with expired TTLs and the circumstances in which a gateway may notify the source. A responding forwarding device can tell an operator something valuable without completing a transaction at the target application. Equally, silence need not identify the forwarding path as broken: the response and its treatment are additional parts of the measurement. ICMP specification.

The methodological boundary is older than this library. RFC 2330 distinguishes singleton observations, samples assembled from observations and statistics derived from samples. Its Type-P convention makes the measured traffic type explicit. A hop RTT, a result-level predicate and a service-availability estimate across time are not the same metric merely because one report can display them together. Performance-metrics framework.

Sagan’s existing flags offer a useful starting point. Keep the number with the responding-hop context, keep the terminal predicates beside it, and state what additional endpoint or application test supports a larger claim. The library makes evidence easier to read. It should not be asked to decide more than its selected evidence can answer.

Sources