Highlights

The 0.13.0 release of Trippy includes several enhancements related to Type of Service (ToS) and adds newDscp andEcn columns.

It also includes improvements to the TUI such as allowing a custom timezone to be set and adding the ability to read the configuration file from the XDG app config directory. Thejson report has been enriched with start and end timestamps.

This release includes a number of bug fixes. For Windows users in particular, this release includes several important stability improvements.

The release also introduces a newsystem address family option, which will become the new default in the next major release.

Finally, Trippy now has a dedicated website and a logo!

Type of Service (DSCP/ECN) Improvements

Trippy allows setting the Type of Service (ToS) for IPv4 via the--tos (-Q) command-line argument (or via the configuration file). TheToS value is the second byte of theIPv4 header and encodes the Differentiated Services Code Point (DSCP) and Explicit Congestion Notification (ECN) fields.

Setting theToS on outgoing probe packets can influence the Quality of Service (QoS) used by the network devices along the path.

Probe responses received from the hops along the path include theToS values in the Original Datagram (theIPv4/IPv6 header of the probe packet nested inside theICMP error). Examining theToS value from the Original Datagram can provide useful insight into theQoS treatment of the probe packets by network devices along the path.

This release of Trippy adds two new columns to display theDSCP &ECN values, which are derived from theToS value from the Original Datagram for each hop. The new columns are:

• Dscp (K): The Differentiated Services Code Point (DSCP) of the Original Datagram for a hop
• Ecn (M): The Explicit Congestion Notification (ECN) of the Original Datagram for a hop

TheDscp andEcn columns are decoded from theToS field of the Original Datagram. If noToS value is present, then the columns will showna. Note that these columns show the most recentToS value received from the hop and may therefore change between rounds.

Well-knownDSCP values are displayed as follows:

• Default Forwarding (DF) aka Best Effort aka Class Selector 0 (CS0)
• Assured Forwarding (AFn)
• Class Selector (CSn)
• High Priority Expedited Forwarding (EF)
• Voice Admit (VA)
• Lower Effort (LE)

UnknownDSCP values are displayed as a hexadecimal value.

TheECN value is displayed as follows:

• Not ECN-Capable Transport (NotECT)
• ECN Capable Transport(1) (ECT1)
• ECN Capable Transport(0) (ECT0)
• Congestion Experienced (CE)

These columns are hidden by default but can be enabled as needed. For more details, see theColumn Reference.

The following example sets theToS to be224, which is aDSCP value ofCS7 (0x38) and anECN value ofNotECT (0x0), and enables the new columns:

trip example.com --tos 224 --tui-custom-columns holsravbwdtKM

The following screenshot shows the example trace:

TheToS field of the Original Datagram has also been added to thejson output format as a decimal value.

See#1539 for details.

This release also adds support for setting theIPv6 Traffic Class (which encodes theDSCP &ECN values in the same way asIPv4) via the same--tos (-Q) command-line argument (or via the configuration file). Note that setting theIPv6 Traffic Class is not currently supported on Windows. See#202 for details.

Finally, a bug which caused the--tos (-Q) command-line argument to be ignored forIPv4/UDP tracing has been fixed in this release. See#1540 for details.

Custom TUI Timezone

Trippy shows the wall-clock time in the header of the TUI. Currently, this is set to show the local timezone of the system running Trippy. This can be problematic for users who are running Trippy in a container or on a remote system that uses a different timezone.

This release adds the ability to set a custom timezone for the TUI using the--tui-timezone command-line argument (or via the configuration file). The timezone can be set to any valid IANA timezone identifier, such asUTC,America/New_York, orEurope/London.

The following example sets the timezone toUTC:

trip example.com --tui-timezone UTC

This can be made permanent by setting thetui-timezone value in thetui section of the configuration file:

[tui]tui-timezone ="UTC"

See#1513 for details.

XDG App Config Directory

Trippy will now attempt to locate atrippy.toml or.trippy.toml config file in the XDG app config directory (i.e.$XDG_CONFIG_HOME/trippy or~/.config/trippy) in addition to existing locations.

This allows users to store their Trippy configuration files in a dedicated directory for Trippy, separate from other applications.

The full list of locations Trippy will check for atrippy.toml or.trippy.toml config file is as follows:

• the current directory
• the user home directory
• the XDG config directory (Unix only):$XDG_CONFIG_HOME or~/.config
• the XDG app config directory (Unix only):$XDG_CONFIG_HOME/trippy or~/.config/trippy
• the Windows data directory (Windows only):%APPDATA%

See#1528 for details.

System Address Family

Trippy supports tracing for bothIPv4 andIPv6 address families. If the tracing target is supplied as a hostname, Trippy will attempt to resolve the hostname to a singleIPv4 orIPv6 address. If the hostname resolves to both, Trippy will use the address family (--addr-family) configuration to determine which address family to use.

The possible values for--addr-family are:

• ipv4 - Lookup IPv4 only
• ipv6 - Lookup IPv6 only
• ipv6-then-ipv4 - Lookup IPv6 with a fallback to IPv4
• ipv4-then-ipv6 - Lookup IPv4 with a fallback to IPv6 [default]

The current default value for--addr-family isipv4-then-ipv6, which means that if the hostname resolves to bothIPv4 andIPv6 addresses, Trippy will prefer theIPv4 address family.

Some users find the default behavior undesirable, as it can lead to unexpected results when the hostname resolves to a different address family than the one used by other applications on the system.

This release adds a new value for--addr-family calledsystem. This value defers the choice of address family to the first address returned by OS resolver. This means that if the hostname resolves to bothIPv4 andIPv6 addresses, the OS resolver will determine which address family to use based on the OS configuration.

Note that if the--addr-family value is set tosystem and the--dns-resolve-method is set to any valueother thansystem (i.e.resolv,cloudflare orgoogle), then the address family lookup will effectively default toipv6-then-ipv4.

Important: The default value for--addr-family will change to becomesystem in the next major release of Trippy (0.14.0). This will be a breaking change for users who rely on the current default value ofipv4-then-ipv6.

See#1469 for details.

Remove Address Family "downgrade" for Dublin Strategy

Currently, the address familiesipv4-then-ipv6 andipv6-then-ipv4 are silentlydowngraded toipv4 when thedublin ECMP strategy is used. This behaviour was previously necessary, as Trippy did not support thedublin ECMP strategy forIPv6. However, Trippy has supported thedublin ECMP strategy forIPv6 since version 0.10.0. As a result, this release removes the address familydowngrade for thedublin ECMP strategy.

See#1476 for details.

Windows Stability Improvements

This release includes several stability improvements for Windows. It fixes several known or potential issues that could cause crashes or memory corruption. It is recommended that all Windows users upgrade to this release.

See the following issues for details:

• Memory corruption on Windows (#1527)
• Socket being closed twice on Windows (#1443)
• Potential crash on Windows for adapters without unicast addresses (#1547)
• Potential use-after-free when discovering source address on Windows (#1558)

Start and End Timestamps in JSON report

The Trippyjson report mode has been enhanced to show the start and end timestamps for the trace. These timestamps are shown in UTC using RFC 3339 format.

The following example runs a trace toexample.com for a single round and outputs the results injson format:

trip example.com -m json -C 1

Theinfo section of the output now includes thestart_timestamp andend_timestamp fields:

{"info": {"target": {"ip":"23.192.228.80","hostname":"example.com"    },"start_timestamp":"2025-05-04T09:50:10.383221Z","end_timestamp":"2025-05-04T09:50:11.392039Z"  }}

See#1510 for details.

Reduce Tracing Verbosity

Thetrippy-core crate logging is overly verbose. This rel...

Contributors

Highlights

This maintenance release of Trippy fixes a bug introduced in 0.12.0 which causes a tracer panic if--first-ttl is set to be greater than one. The release also addresses a longstanding bug which causes--dns-resolve-method resolv to ignore any value provided for--addr-family and therefore always use the default value ofipv4. Finally the help text for--addr-family has been corrected.

See the main0.12.0 release note.

Changelog

Fixed

• Tracer panic when--first-ttl is greater than 1 (#1460)
• IP--addr-family not respected for--dns-resolve-method resolv (#1461)
• Incorrect cli help text for--addr-family (#1456)

New Contributors

• @jsoref made their first contribution in#1459

SeeCHANGELOG.md for details.

Full Changelog:0.12.1...0.12.2

Contributors

Highlights

This maintenance release of Trippy fixes a bug which prevented translations from working in Docker and also divests all internal use ofyaml dependencies which were problematic to maintain on some platforms (thanks to@nc7s).

See the main0.12.0 release note.

Changelog

Fixed

• Locale data not copied into docker image (#1431)

Changed

• Replace use ofyaml withtoml dependency (#1416)

New Contributors

• @nc7s made their first contribution in#1424

SeeCHANGELOG.md for details.

Full Changelog:0.12.0...0.12.1

Contributors

Highlights

The latest release of Trippy brings both cosmetic and functional improvements to the TUI, new columns, new distribution packages, and a number of bug fixes.

The TUI has been updated to include a newinformation bar at the bottom of the screen which allows for the header to be shortened and simplified. The sample history chart has been enhanced to highlight missing probes and the presentation of source and target addresses has also been simplified.

As well as these cosmetic changes, the TUI has gained support for internationalization (i18n) and the ability to adjust the hop privacy setting dynamically.

This release introduces three new columns, which provide novel heuristics for measuringforward loss andbackward loss, that are designed to assist users in interpreting the status of the trace.

Finally, this update includes new distribution packages for Debian and Ubuntu and addresses a number of bugs.

TUI Information Bar

The TUI now includes aninformation bar at the bottom of the screen, replacing the previousConfig line in the header. This change shortens the header by one line, optimizing space usage while keeping the overall vertical space of the TUI unchanged.

The main TUI screen now appears as shown below (120x40 terminal size):

The left-hand side of the information bar displays a selection of static configuration items (in order):

• The address family and tracing protocol, e.g.,IPv4/ICMP
• The privilege level, eitherprivileged orunprivileged
• The locale, e.g., English (en), French (fr), etc.

The right-hand side of the information bar displays a selection of adjustable configuration items (in order):

• A toggle controlling whetherASN information is displayed (□ ASN for disabled,■ ASN for enabled)
• A toggle controlling whether hop detail mode is enabled (□ detail for disabled,■ detail for enabled)
• A toggle controlling whether hostnames, IP addresses, or both are displayed (host,ip, orboth)
• The maximumttl value for hop privacy, shown as- (privacy disabled) or a number (0, 1, 2, etc.)
• The maximum number of hosts displayed per hop, shown as- (automatic) or a number (1, 2, etc.)

In the above screenshot, the information bar indicates the trace is usingIPv4/ICMP, is running inprivileged mode, the locale is English (en),ASN information is displayed, hop detail mode is disabled, hostnames are displayed, the hop privacy maximumttl is 2, and the maximum number of hosts per hop is set to automatic.

Note: The information bar displays only a small number of important settings. All other settings can be viewed in
the settings dialog, which can be opened by pressings (default key binding).

The theme colors of the information bar can be customized using theinfo-bar-bg-color andinfo-bar-text-color theme items. Refer to theTheme Reference for more details.

Thanks to@c-git for their valuable feedback in refining the design of the information bar.

See#1349 for details.

Sample History Missing Probes

Trippy displays a history of samples for each hop as a chart at the bottom of the TUI display. Each vertical line in the chart corresponds to one sample, representing the value of theLast column.

Previously, if a probe was lost, the sample for that round would be shown as a blank vertical line. Starting with this release, Trippy now highlights lost probes using a full vertical line in red (default theme color), making them easier to identify.

The theme color for regular samples can be configured using the existingsamples-chart-color configuration option. Additionally, the theme color for lost probes can now be customized using the newsamples-chart-lost-color configuration option. For more details, see theTheme Reference.

See#1247 for further details.

Source and Target Address Display Improvements

This release simplifies the display of the source and target addresses in theTarget line in the header of the TUI.

TheTarget line has been updated such that, for both the source and destination addresses, the hostname is only shown if it differs from the IP address.

For the destination address:

• If the user supplies a target hostname, it is resolved to an IP address, and both the IP address and theprovided hostname are shown.
• If the user supplies an IP address, a reverse DNS hostname lookup is attempted. If successful, both the IP address and thefirst resolved hostname are shown; otherwise, only the IP address is displayed.

For the source address:

• A reverse DNS hostname lookup is attempted. If successful, both the IP address and thefirst resolved hostname are shown; otherwise, only the IP address is displayed.

For example, when the user supplies an IP address as the tracing target, theTarget line in the header is now shown as follows:

Target: 192.168.1.21 -> 93.184.215.14 (example.com)

See#1363 for details.

Adjustable Hop Privacy Mode Settings

Trippy includes a privacy feature designed to hide sensitive information, such as IP addresses and GeoIP data, for all hops up to a configurable maximumttl via thetui-privacy-max-ttl configuration option.

Previously, the privacy feature could only be toggled on or off within the TUI using thetoggle-privacy command and only iftui-privacy-max-ttl was configuredbefore Trippy was started.

In this release, thetoggle-privacy command has been deprecated and replaced by two new TUI commands,expand-privacy (bound to thep key by default) andcontract-privacy (bound to theo key by default).

Theexpand-privacy command increases thetui-privacy-max-ttl value up to the maximum number of hops in the current trace and thecontract-privacy command decreases thetui-privacy-max-ttl value to the minimum value, which disables privacy mode.

See#1347 for more details.

This release also repurposes the meaning oftui-privacy-max-ttl when set to0. Previously, a value of0 indicated that no hops should be hidden. Starting from this release, a value of0 will indicate that the source of the trace, as shown in theTarget line of the header, should be hidden.

Values of1 or greater retain their existing behavior but will now also hide the source of the trace in addition to the specified number of hops.

As a result of this change, the default value fortui-privacy-max-ttl has been updated:

• If not explicitly set (via a command-line argument or the configuration file), nothing will be hidden by default.
• If explicitly set to0 (the previous default), the source of the trace will be hidden.

See#1365 for details.

Preserve Screen on Exit

Trippy previously supported the--tui-preserve-screen command-line flag, which could be used to prevent the terminal screen from being cleared when Trippy exits. This feature is useful for users who wish to review trace results after exiting the application. However, the flag had to be set before starting Trippy and could not be toggled during a trace.

This release introduces thequit-preserve-screen TUI command (bound to theshift+q key by default). This command allows users to quit Trippy without clearing the terminal screen, regardless of whether the--tui-preserve-screen flag is set.

See#1382 for details.

TUI Internationalization (i18n)

The Trippy TUI has been translated into multiple languages. This includes all text displayed in the TUI across all screens and dialogs, as well as GeoIP location data shown on the world map.

The TUI will automatically detect the system locale and use the corresponding translations if available. The locale can be overridden using the--tui-locale configuration option.

Locales can be specified for a language or a combination of language and region. For example a general locale can be created for English (en) and specific regional locales can be created, such as United Kingdom English (en-UK) and United States English (en-US).

If the user's chosen full locale (language-region) is not available, Trippy will fall back to using the locale for the language only, if it exists. For example if the user sets the locale toen-AU, which is not currently defined in Trippy, it will fall back to theen locale, which is defined.

If the user's chosen locale does not exist at all, Trippy will fall back to English (en).

Locales are generally added for the language only unless there is a specific need for region-based translations.

Some caveats to be aware of:

• The configuration file, command-line options, and most error messages are not translated.
• Many common abbreviated technical terms, such asIPv4 andASN, are not translated.

The following example sets the TUI locale to be Chinese (zh):

trip example.com --tui-locale zh

This can be made permanent by setting thetui-locale value in thetui section of the configuration file:

[tui]tui-locale ="zh"

The following screenshot shows the TUI with the locale set to Chinese (zh):

<img width="60%" src="https://raw.githubusercontent.com/fujiapple852/trippy/master/assets/0.12.0/he...

Contributors

Highlights

This release of Trippy adds NAT detection for IPv4/UDP/Dublin tracing, a new public API, reverse DNS lookup cache time-to-live, transient error handling for IPv4, a new ROFF manual page generator, several new columns, improved error messages and a revamped help dialog with settings tab hotkeys.

There are two breaking changes, a new initial sequence number is used which impacts the default behavior of UDP tracing and two configuration fields have been renamed and moved.

Finally, there are a handful of bug fixes and two new distribution packages, Chocolatey for Windows and an official PPA for Ubuntu and Debian based distributions.

NAT Detection for IPv4/UDP/Dublin

When tracing with the Dublin tracing strategy for IPv4/UDP, Trippy can now detect the presence of NAT (Network Address Translation) devices on the path.

RFC 3022 section 4.3 requires that "NAT to be completely transparent to the host" however in practice some fully compliant NAT devices leave behind a telltale sign that Trippy can use.

Trippy will indicate if a NAT device has been detected by adding[NAT] at the end of the hostname. There is also a new (hidden by default) column,Nat, which can be enabled to show the NAT status per hop.

NAT devices are detected by observing a difference in theexpected andactual checksum of the UDP packet that is returned as the part of the Original Datagram in the ICMP Time Exceeded message. If they differ then it indicates that a NAT device has modified the packet. This happens because the NAT device must recalculate the UDP checksum after modifying the packet (i.e. translating the source port) and so the checksum in the UDP packet that is nested in the ICMP error may not, depending on the device, match the original checksum.

To help illustrate the technique, consider sending the following IPv4/UDP packet (note the UDPChecksum B here):

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │             |Version|  IHL  |Type of Service|          Total Length         | │             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │             |         Identification        |Flags|     Fragment Offset     | │             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │             |  Time to Live |    Protocol   |            Checksum A         | │ IPv4 Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │             |                         Source Address                        | │             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │             |                      Destination Address                      | │             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │                                                                                             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │             |          Source Port          |        Destination Port       | │             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │ UDP Header  |             Length            |            Checksum B         | │             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │

Trippy expect to receive an IPv4/ICMPTimeExceeded (or other) error which contains the Original Datagram (OD) IPv4/UDP packet that was sent above withChecksum B' in the Original Datagram (OD) IPv4/UDP packet:

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │                                     |Version|  IHL  |Type of Service|          Total Length         | │                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │                                     |         Identification        |Flags|     Fragment Offset     | │                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │                                     |  Time to Live |    Protocol   |            Checksum C         | │ IPv4 Header                         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │                                     |                         Source Address                        | │                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │                                     |                      Destination Address                      | │                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │                                                                                                                                             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │                                     |      Type     |      Code     |            Checksum D         | │                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │ IPv4 Payload (ICMP TE Header)       |                             Unused                            | │                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │                                                                                                       │                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │ │                                   |Version|  IHL  |Type of Service|          Total Length         | │ │                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │ │                                   |         Identification        |Flags|     Fragment Offset     | │ │                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │ │                                   |  Time to Live |    Protocol   |            Checksum A'        | │ │ ICMP TE Payload (OD IPv4 Header)  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │ │                                   |                         Source Address                        | │ │                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │ │                                   |                      Destination Address                      | │ │                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │ │                                                                                                     │ │                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │ │ │                                 |          Source Port          |        Destination Port       | │ │ │                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │ │ │ OD IPv4 Payload (UDP header)    |             Length            |            Checksum B'        | │ │ │                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │ │ │

IfChecksum B' in the UDP packet nested in the ICMP error does not matchChecksum B in the UDP packet that was sent then Trippy can infer that a NAT device is present.

This technique allows for the detection of NAT at the first hop. To detect multiple NAT devices along the path, Trippy must also check forchanges in the observed checksum between consecutive hops, as changes to the UDP checksum will "carry forward" to subsequent hops. This requires taking care to account for hops that do not respond. This is only possible when using the Dublin tracing strategy, as it does not modify the UDP header per probe; therefore, the checksums are expected to remain constant, allowing changes in the checksum between hops to be detected.

Note that this method cannot detect all types of NAT devices and so should be used in conjunction with other methods where possible.

See theissue for more details.

Public API

Trippy has been designed primarily as a standalonetool, however it is built on top of a number of useful libraries, such as the core tracer, DNS resolver and more. These libraries have always existed but were tightly integrated into the tool and were not designed for use by third party crates.

This release introduces the Trippy public API which can be used to build custom tools on top of the Trippy libraries.

The full set of libraries exposed is:

To use the Trippy public API you should add the common entrypointtrippy crate to yourCargo.toml file ...

Contributors

Highlights

The first release of 2024 is packed with new features, such as customizable columns, jitter calculations, Dublin tracing strategy for IPv6/UDP, support for IPinfo GeoIp files, enhanced DNS resolution with IPv6/IPv4 fallback and CSS named colors for the TUI as well as a number of bug fixes. Since the last release there has also been a significant improvement in automated testing, notably the introduction of TUN based simulation testing for IPv4.

Customize Columns

Customize Columns in TUI

It is now possible to customize which columns are shown in the TUI and to adjust the order in which they are displayed. This customization can be made from within the TUI or via configuration.

To customize the columns from the TUI you must open the settings dialog (s key) and navigating to the newColumns tab (left and right arrow keys). From this tab you can select the desired column (up and down arrow keys) and toggle the column visibility on and off (c key) or move it left (, key) or right (. key) in the list of columns.

You can supply the full list of columns, in the desired order, using the new--tui-custom-columns command line argument. The following example specifies the standard list of columns in the default order:

trip example.com --tui-custom-columns holsravbwdt

Alternatively, to make the changes permanent you may add thetui-custom-columns entry to thetui section of the Trippy configuration file:

[tui]tui-custom-columns ="holsravbwdt"

Note that the value oftui-custom-columns can be seen in the corresponding field of theTui tab of the settings dialog and will reflect any changes made to the column order and visibility via the Tui. This can be useful as you may copy this value and use it in the configuration file directly.

New Columns

This release also introduced several new columns, all of which are hidden by default. These are:

• Last source port: The source port for last probe for the hop
• Last destination port: The destination port for last probe for the hop
• Last sequence number: The sequence number for the last probe for the hop
• Jitter columns: see the "Calculate and Display Jitter" section below

See theColumn Reference for a full list of all available columns.

Column Layout Improvement

The column layout algorithm used in the hop table has been improved to allow the maximum possible space for theHost column. The width of theHost column is now calculated dynamically based on the terminal width and the set of columns currently configured.

Calculate and Display Jitter

Trippy can now calculate and display a variety of measurements related tojitter for each hop. Jitter is a measurement of the difference in round trip time between consecutive probes. Specifically, the following new calculated values are available in Trippy0.10.0:

• Jitter: The round-trip-time (RTT) difference between consecutive rounds for the hop
• Average Jitter: The average jitter of all probes for the hop
• Maximum Jitter: The maximum jitter of all probes for the hop
• Inter-arrival Jitter: The smoothed jitter value of all probes for the hop

These values are always calculated and are included in thejson report. These may also be displayed as columns in the TUI, however they are not shown by default. To enabled these columns in the TUI, please see theColumn Reference.

Dublin Tracing Strategy for IPv6/UDP

The addition of support for thedublin tracing strategy for IPv6/UDP marks the completion of a multi-release journey to provide support for both Dublin andparis tracing strategies for both IPv4/UDP and IPv6/UDP.

As a reminder, unlike classic traceroute and MTR, these alternative tracing strategies do not encode the probe sequence number in either the src or dest port of the UDP packet, but instead use other protocol and address family specific techniques. Specifically, the Dublin tracing strategy for IPv6/UDP varies the length of the UDP payload for this purpose.

By doing so, these strategies are able to keep the src and dest ports fixed which makes it much more likely (though not guaranteed) that each round of tracing will follow the same path through the network (note that this is not true for the return path).

The following command runs an IPv6/UDP trace using the Dublin tracing strategy with fixed src and dest ports:

trip example.com --udp -6 -R dublin -S 5000 -P 3500

Note that, for both Paris and Dublin tracing strategies, if you fix either the src or dest ports (butnot both) then Trippy will vary the unfixed portper round rather thanper hop. This has the effect that all probeswithin a round will likely follow the same network path but probesbetween round will follow different paths. This can be useful in conjunction with flows (f key) to visualize the various paths packet flow through the network. See thisissue for more details.

With UDP support for the Paris and Dublin tracing strategies now complete, what remains is adding support for these for the TCP protocol. Refer to theECMP tracking issue for details.

IPinfo GeoIp Provider

Trippy currently supports the ability to lookup and display GeoIp information from MMDB files, but prior to0.10.0 only theMaxMind "GeoLite2 City" (and lite) MMDB files were supported. This release introduces support for the "IP to Country + ASN Database" and "IP to Geolocation Extended Database" MMDB files fromIPinfo.

The "IP to Country + ASN Database" MMDB file provided by IPinfo can be used as follows:

trip example.com --geoip-mmdb-file /path/to/country_asn.mmdb --tui-geoip-mode short

These settings can be made permanent by setting the following values in thetui section of the configuration file:

[tui]geoip-mmdb-file ="/path/to/country_asn.mmdb"tui-geoip-mode ="short"

Enhanced DNS Resolution with IPv4/IPv6 Fallback

When provided with a DNS name such asexample.com Trippy tries to resolve it to an IPv4 or an IPv6 address and fails if no such IP exists for the configuredaddr-family mode, which must be either IPv4 or IPv6.

Starting from version0.10.0, Trippy can be configured to supportipv4-then-ipv6 andipv6-then-ipv4 modes foraddr-family. In the newipv4-then-ipv6 mode Trippy will first attempt to resolve the given hostname to an IPv4 address and, if no such address exists, it will attempt to resolve to an IPv6 address and only fail if neither are available (and the opposite for the newipv6-then-ipv4 mode). Theaddr-family mode may also be set to beipv4 oripv6 for IPv4 only and IPv6 only respectively.

To set theaddr-family to be IPv6 with fallback to IPv4 you can set the--addr-family command line parameter:

trip example.com --addr-family ipv6-then-ipv4

To make the change permanent you can set theaddr-family value in thestrategy section of the configuration file:

[strategy]addr-family ="ipv6-then-ipv4"

Note that Trippy supports both theaddr-family entry in the configuration file and also the--ipv4 (-4) and--ipv6 (-6) command line flags, all of which are optional. The command line flags (which are mutually exclusive) take precedence over the config file entry and if neither are provided there it defaults toipv4-then-ipv6.

Extended Colors in TUI

Trippy allows the theme to be customized and supports the namedANSI colors:

Black, Red, Green, Yellow, Blue, Magenta, Cyan, Gray, DarkGray, LightRed, LightGreen, LightYellow, LightBlue, LightMagenta, LightCyan, White

The0.10.0 release adds support for CSSnamed colors (e.g. SkyBlue). Note that these are only supported on some platforms and terminals and may not render correctly elsewhere.

See theTheme Reference

Simulation Testing

Manually testing all Trippy features in all modes and on all supported platforms is an increasingly time consuming and error prone activity. Since the last release a significant effort has been made to increase the testing coverage, including unit and integration testing.

In particular, the introduction of simulation testing allows for full end-to-end testing of all modes and features on Linux, macOS and Windows without the need to mock or stub any behaviourwithin Trippy.

This is achieved by creating aTUN device to simulate the behavior of network nodes, responding to various pre-configured scenarios like packet loss and out-of-order arrivals.

Whilst not a change that directly benefits end users, this new testing approach should reduce the effort needed to test each release of Trippy and help improve the overall reliability of t...

Contributors

Highlights

Trippy0.9.0 introduces many new features, including tracing flows and ICMP extensions, the expansion of support for the Paris tracing strategy to encompass IPv6/UDP, an unprivileged execution mode for macOS, a hop privacy mode and many more. Additionally, this release includes several important bug fixes along with a range of new distribution packages.

Tracing Flows

Flow Id

A tracing flow represents the sequence of hosts traversed from the source to the target. Trippy is now able to identify individual flows within a trace and assign each a unique flow id. Trippy calculate a flow id for each round of tracing, based on the sequence of hosts which responded during that round, taking care to account for rounds in which only a subset of hosts responded. Tracing statistics, such as packet loss % and average RTT are recorded on a per-flow basis as well as being aggregated across all flow.

Tracing flows adds to the existing capabilities provided by Trippy to assist withECMP (Equal-Cost Multi-Path Routing) when tracing with UDP and TCP protocols. Some of these capabilities, such as theparis anddublin tracing strategies, are designed torestrict tracing to a single flow, whilst others, such as the hop detail navigation mode (introduce in the last release) and tracing flows, are designed to helpvisualize tracing data in the presence of multiple flows. See the0.8.0release note for other such capabilities.

Tracing Flows in the TUI

The TUI has been enhanced with a new mode to help visualise flows. This can be toggled on and off with thetoggle-flows command (bound to thef key by default).

When toggled on, this mode display flow information as a chart in a new panel above the hops table. Flows can be selected by using the left and right arrow keys (default key bindings). Flows are sorted by the number of rounds in which a given flow id was observed, with the most frequent flow ids shown on the left. When entering this mode flow id 1 is selected automatically. The selected flow acts as a filter for the other parts of the TUI, including the hops table, chart and maps views which only show data relevant to that specific flow.

When toggled off, Trippy behaves as it did in previous versions where aggregated statistics (across all flows) are shown. Note that per-flow data is always recorded, the toggle only influences how the data is displayed.

The number of flows visible in the TUI is limited and can be controlled by thetui-max-flows configuration items which can be set via the command line or via the configuration file. By default up to 64 flows are shown.

The flows panel, as with all other parts of the TUI, can also be themed, see thetheme reference for details.

Flow Reports

As well as visualising flows in the TUI, Trippy0.9.0 introduces two new reports which make use of the tracing flow data.

The newflows report mode records and print all flows observed during tracing.

The following command will run a TCP trace for 10 round and report all of the flows observed:

trip example.com --tcp -m flows -C 10

Sample output (truncated) showing three unique flows:

flow 1: 192.168.1.1, 10.193.232.245, 218.102.40.38, 10.195.41.9, 172.217.27.14flow 2: 192.168.1.1, 10.193.232.245, 218.102.40.22, 10.195.41.17, 172.217.27.14flow 3: 192.168.1.1, 10.193.232.245, 218.102.40.38, 10.195.41.1, 172.217.27.14

Another new report,dot, outputs aGraphVizDOT format chart of all hosts observed during tracing.

The following command will run a TCP trace for 10 round and output a graph of flows inDOT format:

trip example.com --tcp -m dot -C 10

If you have a tool such asdot (Graphviz) installed you can use this to rendered the output in various formats, such as PNG:

trip example.com --tcp -m dot -C 10| dot -Tpng> path.png

Sample output:

ICMP Extensions

Parsing Extensions

Trippy0.9.0 adds the ability to parse and display ICMP Multi-Part Messages (aka extensions). It supports both compliant and non-compliant ICMP extensions as defined insection 5 of rfc4884.

Trippy is able to parse and render any generic Extension Object but is also able to parse some well known Object Classes, notably the MPLS class.

Support foradditional classes will be added to future versions of Trippy, see the ICMP Extensionstracking issue.

Parsing of ICMP extensions can be enabled by setting the--icmp-extensions (-e) command line flag or by adding theicmp-extensions entry in thestrategy section of the configuration file:

[strategy]icmp-extensions =true

ICMP Extensions in the TUI

The TUI has been enhanced to display ICMP extensions in both the normal and hop detail navigation modes.

In normal mode, ICMP extensions are not shown by default but can be enabled by setting the--tui-icmp-extension-mode command line flag or by adding thetui-icmp-extension-mode entry in thetui section of the configuration file:

[tui]tui-icmp-extension-mode ="full"

This can be set tooff (do not show ICMP extension data),mpls (shows a list of MPLS label(s) per hop),full (shows all details of all extensions, such asttl,exp andbos for MPLS) orall (the same asfull but also showsclass,subtype andbytes for unknown extension objects).

The following screenshot shows ICMP extensions in normal mode withtui-icmp-extension-mode set to bempls:

In hop detail mode, the full details of all ICMP extension objects are always shown if parsing of ICMP extensions is enabled.

The following screenshot shows ICMP extensions in hop detail mode:

ICMP Extensions in Reports

ICMP extension information is also included the thejson andstream report modes.

Sample output for a single hop from thejson report:

{"ttl":14,"hosts": [    {"ip":"129.250.3.125","hostname":"ae-4.r25.sttlwa01.us.bb.gin.ntt.net"    }  ],"extensions": [    {"mpls": {"members": [          {"label":91106,"exp":0,"bos":1,"ttl":1          }        ]      }    }  ],"loss_pct":"0.00","sent":1,"last":"178.16","recv":1,"avg":"178.16","best":"178.16","worst":"178.16","stddev":"0.00"}

Paris Tracing Strategy for IPv6/UDP

The work to support the remainingparis anddublin tracing modes continues in this release with the addition of support for the Paris tracing strategy for IPv6/UDP.

As a reminder, unlike classic traceroute and MTR, these alternative tracing strategies do not encode the probe sequence number in either the src or dest port of the UDP or TCP packet, but instead use other protocol and address family specific techniques. Specifically, the Paris tracing strategy for IPv6/UDP utilizes the UDP checksum for this purposes and manipulates the UDP payload to ensure packets remind valid.

By doing so, these strategies are able to keep the src and dest ports fixed which makes it much more likely (though not guaranteed) that each round of tracing will follow the same path through the network (note that this isnot true for the return path).

The following command runs a IPv6/UDP trace using theparis tracing strategy with fixed src and dest ports:

trip example.com --udp -6 -R paris -S 5000 -P 3500

Refer to thetracking issue for details of the work remaining to support all ECMP strategies for both UDP and TCP for IPv4 and IPv6.

Unprivileged Mode

Trippy normally requires elevated privileges due to the use of raw sockets. Enabling the required privileges for a given platform can be achieved in several ways as in described theprivileges section of the documentation.

This release of Trippy adds the ability to runwithout elevated privileged on a subset of platforms, but with some limitations which are described below.

The unprivileged mode can be enabled by adding the--unprivileged (-u) command line flag or by adding theunprivileged entry in thetrippy section of the configuration file:

[trippy]unprivileged =true

The following command runs a trace in unprivileged mode:

trip example.com -u

Unprivileged mode is currently only supported on macOS. Linux support is possible and may be added in the future. Unprivileged mode is not supported on NetBSD, OpenBSD, FreeBSD or Windows as these platforms do not support the `IPPRO...

Contributors

Highlights

The0.8.0 release of Trippy brings several new features, UX enhancements, and quality of life improvements, as well as various small fixes and other minor improvements.

Hop Detail Navigation

Trippy offers various mechanisms to visualizeECMP (Equal-Cost Multi-Path Routing) when tracing with UDP and TCP protocols. Features include displaying all hosts for a given hop in a scrollable table, limiting the number of hosts shown per hop (showing the % of traffic for each host), and greying out hops that are not part of a specific tracing round.

Despite these helpful features, visualizing a complete trace can be challenging when there are numerous hosts for some hops, which is common in environments where ECMP is heavily utilized.

This release enhances ECMP visualization support by introducing a hop detail navigation mode, which can be toggled on and off by pressingd (default key binding). This mode displays multiline information for the selected hop only, including IP, hostname, AS, and GeoIP details about a single host for the hop. Users can navigate forward and backward between hosts in a given hop by pressing, and. (default key bindings), respectively.

In addition to visualizing ECMP, Trippy also supports alternative tracing strategies to assist with ECMP routing, which are described below.

Paris Tracing Strategy

Trippy already supports both classic anddublin tracing strategies, and this release adds support for theparis tracing strategy for the UDP protocol.

Unlike classic traceroute and MTR, these alternative tracing strategies do not encode the probe sequence number in either the src or dest port of the UDP or TCP packet, but instead use other protocol and address family specific techniques.

This means that every probe in a trace can share common values for the src & dest hosts and ports which, when combined with the protocol, is typically what is used to making traffic route decisions in ECMP routing. This means that these alternative tracing strategies significantly increase the likelihood that the same path is followed for each probe in a trace (but not the return path!) in the presence of ECMP routing.

The following command runs a UDP trace using the newparis tracing strategy with fixed src and dest ports (the src and dest hosts and the protocol are always fixed) and will therefore likely follow a common path for each probe in the trace:

trip www.example.com --udp -R paris -S 5000 -P 3500

Future Trippy versions will build upon these strategies and further improve the ability to control and visualize ECMP routing, refer to thetracking issue for further details.

GeoIp Information & Interactive Map

Trippy now supports the ability to look up and display GeoIP information from a user-provided MaxMindGeoLite2 City database. This information is displayed per host in the hop table (for both normal and new detail navigation modes) and can be shown in various formats. For example, short form like "San Jose, CA, US" or long form like "San Jose, California, United States, North America," or latitude, longitude, and accuracy radius like "37.3512, -121.8846 (~20km)".

The following command enables GeoIP lookup from the providedGeoLite2-City.mmdb file and will show long form locations in the hop table:

trip example.com --geoip-mmdb-file GeoLite2-City.mmdb --tui-geoip-mode long

Additionally, Trippy features a new interactive map screen that can be toggled on and off by pressingm (default key binding). This screen displays a world map and plots the location of all hosts for all hops in the current trace, as well as highlighting the location of the selected hop.

Autonomous System Display Enhancements

Trippy has long offered the ability to look up and display AS information. This release makes this feature more flexible by allowing different AS details to be shown in the hops table, including AS number, AS name, prefix CIDR, and registry details.

The following command enables AS lookup and will display the prefix CIDR for each host in the TUI:

trip example.com -ztrue -r resolv --tui-as-mode prefix

This release also fixes a limitation in earlier versions of Trippy that prevented the lookup of AS information for IP addresses without a correspondingPTR DNS record.

UI Cleanup & Configuration Dialog

The number of configurable parameters in Trippy has grown significantly, surpassing the number that can be comfortably displayed in the TUI header section. Previous Trippy versions displayed an arbitrarily chosen subset of these parameters, many of which have limited value for users and consume valuable screen space.

This release introduces a new interactive settings dialog that can be toggled on and off withs (default key binding) to display all configured parameters. The TUI header has also been cleaned up to show only the most relevant information, specifically the protocol and address family, the AS info toggle, the hop details toggle, and the max-hosts setting.

Configuration File

The previous Trippy release introduced the ability to customize the TUI color theme and key bindings, both of which could be specified by command-line arguments. While functional, this method is inconvenient when configuring a large number of colors or keys.

This release adds support for a Trippy configuration file, allowing for persistent storage of color themes, key bindings, and all other configuration items supported by Trippy.

For a sample configuration file showing all possible configurable items that are available, see theconfiguration reference for details.

Shell Completions

This release enables the generation of shell completions for various shells, including bash, zsh, PowerShell, and fish, using the new--generate command-line flag.

The following command will generate and store shell completions for the fish shell:

trip --generate fish>~/.config/fish/completions/trip.fish

Improved Error Reporting & Debug Logging

This release adds a number of command-line flags to enable debug logging, enhancing the ability to diagnose failures. For example, the following command can be used to run tracing with no output, except for debug output in a format suitable to be displayed withchrome://tracing or similar tools:

trip www.example.com -m silent -v --log-format chrome

Socket errors have also been augmented with contextual information, such as the socket address for a bind failure, to help with the diagnosis of issues.

New Distribution Packages

Trippy is now also available as a Nix package (@figsoda), a FreeBSD port (@ehaupt) and a Windows Scoop package. This release also reenables support for amusl binary which was disabled in0.7.0 due to a bug in a critical library used by Trippy.

Seedistributions for the full list of available packages.

My thanks, as ever, to all Trippy contributors!

New Contributors

• @utkarshgupta137 made their first contribution in#537

Change Log

Added

• Added--tui-as-mode flag to control how AS information is rendered (#483)
• Added support for configuration files and added a-c (--config-file) flag (#412)
• Added--generate flag for generating shell completions (#86)
• Added support for showing and navigating host detail (#70)
• Added--geoip-mmdb-file and--tui-geoip-mode flags for looking up and displaying GeoIp information frommmdb files (#503)
• Added settings dialog and simplified Tui header display (#521)
• Added interactive GeoIp map display (#505)
• Added support for theparis ECMP traceroute strategy forIPv4/udp (#542)
• Addedsilent reporting mode to run tracing without producing any output (#555)
• Added-v (--verbose),--log-format,--log-filter &--log-span-events flags to support generating debug trace logging output (#552)

Changed

• Show AS information for IP addresses without PTR record (#479)
• Re-enabled musl release builds (#456)
• [BREAKING CHANGE] Renamed short config flag forreport-cycles from-c to-C (#491)
• Ensure administrator privileges on Windows (#451)
  ...

Contributors

Highlights

The major highlight of the 0.7.0 release of Trippy is the addition of full support for Windows, for all tracing modes and protocols! 🎉. This has been many months in the making and is thanks to the hard work and perseverance of@zarkdav.

This release also sees the introduction of custom Tui themes and key bindings,deb andrpm package releases, as well as several important bug fixes.

My thanks to all the contributors!

Added

• Added support for Windows (icmp,udp &tcp forIPv4 &IPv6) (#98) [@zarkdav]
• Added support for custom Tui key bindings (#448)
• Added support for custom Tui color themes (#411)
• Added RPM packaging (#95) [@OmarAtefThabet]
• Added DEB packaging (#94) [@Marwanmhks]

Fixed

• Variable Equal Cost Multi-path Routing (ECMP) causing truncated trace (#269)
• Tracing using thetcp may ignore some incomingicmp responses (#407)
• Tracer panics with large--initial-sequence and delayed TCP probe response (#435)
• Trippy Docker fails to start (#277)

SeeCHANGELOG.md for details.

Full Changelog:0.6.0...0.7.0

Contributors

Highlights

SeeCHANGELOG.md for details.

Added

• Added support for tracing usingIPv6 fortcp (#191)
• Added-R (--multipath-strategy) flag to allow setting theEqual Cost Multi-path Routing strategy and added support for thedublin traceroute strategies forIPv4/udp (#158)
• Added zoom-able chart showing round trip times for all hops in a trace (#209)
• Added--udp and--tcp flags as shortcuts to-p udp and-p tcp respectively (#205)

Changed

• Gray out hops which did not update in the current round (#216)

Full Changelog:0.5.0...0.6.0