Trippy 0.12.0

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 new information 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 measuring forward loss and backward 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 an information bar at the bottom of the screen, replacing the previous Config 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, either privileged or unprivileged
• 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 whether ASN 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, or both)
• The maximum ttl 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 using IPv4/ICMP, is running in privileged mode, the locale is English (en), ASN information is displayed, hop detail mode is disabled, hostnames are displayed, the hop privacy maximum ttl 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 pressing s (default key binding).

The theme colors of the information bar can be customized using the info-bar-bg-color and info-bar-text-color theme items. Refer to the Theme 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 the Last 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 existing samples-chart-color configuration option. Additionally, the theme color for lost probes can now be customized using the new samples-chart-lost-color configuration option. For more details, see the Theme Reference.

See #1247 for further details.

Source and Target Address Display Improvements

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

The Target 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 the provided hostname are shown.
• If the user supplies an IP address, a reverse DNS hostname lookup is attempted. If successful, both the IP address and the first 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 the first resolved hostname are shown; otherwise, only the IP address is displayed.

For example, when the user supplies an IP address as the tracing target, the Target 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 maximum ttl via the tui-privacy-max-ttl configuration option.

Previously, the privacy feature could only be toggled on or off within the TUI using the toggle-privacy command and only if tui-privacy-max-ttl was configured before Trippy was started.

In this release, the toggle-privacy command has been deprecated and replaced by two new TUI commands, expand-privacy (bound to the p key by default) and contract-privacy (bound to the o key by default).

The expand-privacy command increases the tui-privacy-max-ttl value up to the maximum number of hops in the current trace and the contract-privacy command decreases the tui-privacy-max-ttl value to the minimum value, which disables privacy mode.

See #1347 for more details.

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

Values of 1 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 for tui-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 to 0 (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 the quit-preserve-screen TUI command (bound to the shift+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 to en-AU, which is not currently defined in Trippy, it will fall back to the en 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 as IPv4 and ASN, 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 the tui-locale value in the tui 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...

Trippy 0.11.0

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 the expected and actual 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 UDP Checksum 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/ICMP TimeExceeded (or other) error which contains the Original Datagram (OD) IPv4/UDP packet that was sent above with Checksum 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'        | │ │ │                                
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ │ │ │                                

If Checksum B' in the UDP packet nested in the ICMP error does not match Checksum 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 for changes 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 the issue for more details.

Public API

Trippy has been designed primarily as a standalone tool, 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:

Crate	Description
trippy	Common entrypoint crate
trippy-core	The core Trippy tracing functionality
trippy-packet	Packet wire formats and packet parsing functionality
trippy-dns	Perform forward and reverse lazy DNS resolution
trippy-privilege	Discover platform privileges
trippy-tui	The Trippy terminal user interface

To use the Trippy public API you should add the common entrypoint trippy crate to your Cargo.toml file ...

Trippy 0.10.0

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 new Columns 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 the tui-custom-columns entry to the tui section of the Trippy configuration file:

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

Note that the value of tui-custom-columns can be seen in the corresponding field of the Tui 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 the Column 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 the Host column. The width of the Host 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 to jitter 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 Trippy 0.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 the json 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 the Column Reference.

Dublin Tracing Strategy for IPv6/UDP

The addition of support for the dublin tracing strategy for IPv6/UDP marks the completion of a multi-release journey to provide support for both Dublin and paris 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 (but not both) then Trippy will vary the unfixed port per round rather than per hop. This has the effect that all probes within a round will likely follow the same network path but probes between 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 this issue 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 the ECMP tracking issue for details.

IPinfo GeoIp Provider

Trippy currently supports the ability to lookup and display GeoIp information from MMDB files, but prior to 0.10.0 only the MaxMind "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 from IPinfo.

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 the tui 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 as example.com Trippy tries to resolve it to an IPv4 or an IPv6 address and fails if no such IP exists for the configured addr-family mode, which must be either IPv4 or IPv6.

Starting from version 0.10.0, Trippy can be configured to support ipv4-then-ipv6 and ipv6-then-ipv4 modes for addr-family. In the new ipv4-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 new ipv6-then-ipv4 mode). The addr-family mode may also be set to be ipv4 or ipv6 for IPv4 only and IPv6 only respectively.

To set the addr-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 the addr-family value in the strategy section of the configuration file:

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

Note that Trippy supports both the addr-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 to ipv4-then-ipv6.

Extended Colors in TUI

Trippy allows the theme to be customized and supports the named ANSI colors:

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

The 0.10.0 release adds support for CSS named colors (e.g. SkyBlue). Note that these are only supported on some platforms and terminals and may not render correctly elsewhere.

See the Theme 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 behaviour within Trippy.

This is achieved by creating a TUN 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...

Trippy 0.9.0

Highlights

Trippy 0.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 with ECMP (Equal-Cost Multi-Path Routing) when tracing with UDP and TCP protocols. Some of these capabilities, such as the paris and dublin tracing strategies, are designed to restrict 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 help visualize tracing data in the presence of multiple flows. See the 0.8.0 release 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 the toggle-flows command (bound to the f 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 the tui-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 the theme reference for details.

Flow Reports

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

The new flows 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.14
flow 2: 192.168.1.1, 10.193.232.245, 218.102.40.22, 10.195.41.17, 172.217.27.14
flow 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 a GraphViz DOT 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 in DOT format:

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

If you have a tool such as dot (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

Trippy 0.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 in section 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 for additional classes will be added to future versions of Trippy, see the ICMP Extensions tracking issue.

Parsing of ICMP extensions can be enabled by setting the --icmp-extensions (-e) command line flag or by adding the icmp-extensions entry in the strategy 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 the tui-icmp-extension-mode entry in the tui section of the configuration file:

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

This can be set to off (do not show ICMP extension data), mpls (shows a list of MPLS label(s) per hop), full (shows all details of all extensions, such as ttl, exp and bos for MPLS) or all (the same as full but also shows class, subtype and bytes for unknown extension objects).

The following screenshot shows ICMP extensions in normal mode with tui-icmp-extension-mode set to be mpls:

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 the json and stream report modes.

Sample output for a single hop from the json 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 remaining paris and dublin 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 is not true for the return path).

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

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

Refer to the tracking 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 the privileges section of the documentation.

This release of Trippy adds the ability to run without 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 the unprivileged entry in the trippy 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...

Trippy 0.8.0

Highlights

The 0.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 visualize ECMP (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 pressing d (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 and dublin tracing strategies, and this release adds support for the paris 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 new paris 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 the tracking issue for further details.

GeoIp Information & Interactive Map

Trippy now supports the ability to look up and display GeoIP information from a user-provided MaxMind GeoLite2 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 provided GeoLite2-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 pressing m (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 -z true -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 corresponding PTR 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 with s (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 the configuration 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 with chrome://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 a musl binary which was disabled in 0.7.0 due to a bug in a critical library used by Trippy.

See distributions 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 from mmdb files (#503)
• Added settings dialog and simplified Tui header display (#521)
• Added interactive GeoIp map display (#505)
• Added support for the paris ECMP traceroute strategy for IPv4/udp (#542)
• Added silent 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 for report-cycles from -c to -C (#491)
• Ensure administrator privileges on Windows (#451)
  ...

Trippy 0.7.0

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 and rpm package releases, as well as several important bug fixes.

My thanks to all the contributors!

Added

• Added support for Windows (icmp, udp & tcp for IPv4 &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 the tcp may ignore some incoming icmp responses (#407)
• Tracer panics with large --initial-sequence and delayed TCP probe response (#435)
• Trippy Docker fails to start (#277)

See CHANGELOG.md for details.

Full Changelog: 0.6.0...0.7.0

Trippy 0.6.0

Highlights

See CHANGELOG.md for details.

Added

• Added support for tracing using IPv6 for tcp (#191)
• Added -R (--multipath-strategy) flag to allow setting the Equal Cost Multi-path Routing strategy and added support for the dublin traceroute strategies for IPv4/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

Trippy 0.5.0

See CHANGELOG.md for details.

Trippy 0.4.0

See CHANGELOG.md for details.

Trippy 0.3.1

See CHANGELOG.md for details.