> If you ever see packet loss in a trace at one step but the steps after it aren't showing it, you can ignore that packet loss, it's likely a CPU limitation on a busy router.
Trippy now includes [0] forward loss (Floss) and backward loss (Bloss) _heuristics_ to help surface such behaviour.
The idea was inspired by our previous discussion [1] on the topic on HN some time ago!
These columns are experimental and so not shown by default but can be enabled [2].
a blog about traceroute in 2026. imagine that. hard to believe it could possibly be of any interest at all, especially written by someone that only just discovered it. but i'm oh so glad i stopped in, to learn about trippy! it looks amazing.
I’ve recently been building a similar tool [1] which defines a specification for CLIs, though the goals are slightly different to the tool you mention I think. I just added support for fish as it happens.
Something I’ve been working on recently is a command line tool [1] to bring clap declarative command line parsing to shell scripts. Unfinished WIP but largely functional.
Great concept. I was on mobile and agree the custom keyboard is far from ideal. As others have said I also found it to be overly US-centric. Keen to see how this develops, feels like a winning idea!
You can, with several caveats, detect which hop(s) on the path perform NAT by using some trickery [1]:
> 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.
OP, you may find this [1] “trick” useful. It allows you to dynamically determine the correct byte order for the various IPv4 headers for the platform and thus avoid the need to statically decide on the byte ordering for each platform you intend to target.
You may also find this [2] table useful, it shows which platforms allow the combination of IPPROTO_ICMP + IP_HDRINCL so it may be used without elevated privileges.
In general, my experience of raw sockets is that they are not very “raw” at all, the OS can and does still perform a variety of modifications and additions to what you send and receive, in highly platform specific and often poorly documented ways. In particular, TCP and raw sockets should generally be avoided.
It’s not guaranteed to be accurate, but tracing using the UDP/dublin strategy with a fixed dest port and varying src port per round can help to identify and visualize valid ECMP flows. I recently wrote some guidance [1] on using Trippy in this way.
Once I used iperf3 with 100 different udp streams/srcports to troubleshoot an issue, a small % of connections had >90% packet loss and this caused the connection pool of this service to fill up until it had only failed connections waiting to time out or going extremely slowly. ISP told me it was a broken linecard in a router, so packets were being dropped/corrupted on the backplane between the linecards.
Traceroute and mtr didn't use enough ports to show the issue clearly.
I used this to identify some intermittent loss in one direction from I think Kyrgyzstan to the UK, There was a claim that sometime flows were fine and sometimes they weren't. Problem was an ECMP in Pakistan or Iran which was using udp port numbers to balance the flow. Could consistently get 25% loss with certain numbers and not with others.
I recently had to look at the implementation of the Sparkline [1] widget in Ratatui which uses a similar Unicode technique but scales nicely for sparklines with larger vertical size.
Trippy now includes [0] forward loss (Floss) and backward loss (Bloss) _heuristics_ to help surface such behaviour.
The idea was inspired by our previous discussion [1] on the topic on HN some time ago!
These columns are experimental and so not shown by default but can be enabled [2].
[0] https://github.com/fujiapple852/trippy/blob/master/RELEASES....
[1] https://news.ycombinator.com/item?id=38591827
[2] https://trippy.rs/reference/column