trippy

> 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]. [0] https://github.com/fujiapple852/trippy/blob/master/RELEASES.... [1] https://news.ycombinator.com/item?id=38591827 [2] https://trippy.rs/reference/column

Another interesting tool in this space is trippy, which ‘combines the functionality of traceroute and ping’ https://github.com/fujiapple852/trippy

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. [1] https://github.com/fujiapple852/trippy/releases/tag/0.11.0

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. [1] https://github.com/fujiapple852/trippy/blob/master/crates/tr... [2] https://github.com/fujiapple852/trippy/issues

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. [1] https://github.com/fujiapple852/trippy?tab=readme-ov-file#ud...

Exploring adding the (novel?) concept of forward and backward packet loss heuristics to Trippy [1] as discussed here [2]. [1] https://github.com/fujiapple852/trippy/issues/860 [2] https://news.ycombinator.com/item?id=38591945

This Tailscale blog [1] from 2020 has been posted on HN many times before I’m sure but is worth highlighting again as it does a great job outlining the technical complexities that CGNAT (and NAT in general) introduce. I have my head in this space at the moment as I’m trying to implement NAT detection (as pioneered by Dublin traceroute [2]) into Trippy [3]. [1] https://tailscale.com/blog/how-nat-traversal-works [2] https://dublin-traceroute.net/ [3] https://github.com/fujiapple852/trippy/issues/1104

What is the state of the art for running NetBSD (and other *BSD) in CI such as GitHub actions? Edit: to add a bit more detail, I maintain a cross platform tool [1] on GitHub and require a way to build and test it in CI for several platform not natively supported by GitHub. Currently I use cargo-cross [2] to build it from a Linux OS but this doesn’t work for running the tests. One option I’m aware of is running a qemu VM on Linux, which is the approach taken by postgres [3]. Another option is using an external CI provider such as Cirrus who claim to have native support [4] for various *BSD. [1] https://github.com/fujiapple852/trippy [2] https://github.com/cross-rs/cross [3] https://github.com/anarazel/pg-vm-images [4] https://cirrus-ci.org/guide/FreeBSD/

For the RTT and loss% measurements Trippy just does the obvious thing (i.e. RTT = recv time - send time and loss% = lost / total_sent). There is a plan [0] to add custom columns to Trippy and then to add various jitter measurements [1]. Thanks for pointing out the above RFCs, I'll take a look at those and see if they make sense to add to Trippy. [0] https://github.com/fujiapple852/trippy/issues/757 [1] https://github.com/fujiapple852/trippy/issues/39

Thanks for that, I'll give this some thought and write a proposal in this [0] placeholder issue. [0] https://github.com/fujiapple852/trippy/issues/860

I agree regarding documentation. There was a request [0] for something similar, though not specifically covering this important point. Regarding sending a ping flood, Trippy allow you to reduce the minimum and maximum round time (and grace period) to send packets almost as fast as you like. For example, to send at 50ms intervals (with a 10ms grace period): > trip example.com -i 50ms -T 50ms -g 10ms [0] https://github.com/fujiapple852/trippy/issues/853

You are right that showing packet loss for intermediate hops is a frequent source of confusion. Rather than leave it out, I added a status column which shows different statuses for intermediate hops (blue if the hop responds to less than 100% of probes and brown if it responds to 0%) vs the target hop (which show amber and red respectively). Where this breaks down is when dealing with ECMP for UDP & TCP tracing, as a given hop (ttl) may represent the target for a given round of tracing but not for the next. The mistake, imho, is to associate _any_ data with a hop (ttl) rather than the hop in the context of a tracing flow. That is why Trippy had a number of features aimed at helping with ECMP, such as Paris and Dublin tracing, and the ability to filter tracing by unique flow id. I've covered these quite a bit in the 0.8.0 [0] and 0.9.0 [

Yes, in my experience GeoIp is _highly_ unreliable, alas Trippy can do no more than report the location from the provided mmdb file. I'm aware of some interesting techniques which use timing measurements from multiple locations to try and triangulate a more accurate location. In fact somebody raised a request for supporting JA4L [0] to me just this morning. [0] https://github.com/fujiapple852/trippy/issues/856

Author here, thanks for posting this (i’d meant to do a show HN post at some point). Trippy is a modern, cross platform, feature rich alternative to MTR with a fancy TUI. And yes, it’s written in Rust. https://github.com/fujiapple852/trippy