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].
could you say a little bit more about the design and/or purpose of NAT detection in this context? i'm unfamiliar but see what the service generally does in lay terms. curious more about the technical necessity.
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.
Something I intend to add to Trippy, but have not got around to it yet; is to codify the "If a packet takes the path A -> B -> C and pings to B have 50% loss but pings to C have 0% loss, then the path is perfectly fine" idea and use that to produce more meaningful headline status information to the user. How would you codify this?
It's probably tricky but if there's loss at D, maybe only then materialize the display of the loss backwards until there is no loss: C? B? A? It gets tricky though where maybe there is a small loss at D, but say that C and B have chronic loss because of throttling in the slow path responses.
If D has 1% loss and B and C have 50%, is it fair to say A=0, B=1%, C=1%, D=1%?
MTR display of loss is indeed confusing, but when weird things are going on it can be helpful just stare at it a while to see what's going on. Trippy looks fantastic, and I need to play with it, but there are cases where I just want to stare at the path loss for a while.
There's no way to influence the TTL on TTL timed-out responses, is there? That'd be pretty cool if there were some way to get the return path of the intermediaries to reply.
I would love for there to be a useful indicator to the user to say if loss or latency is an issue.
Being able to indicate cascading loss (e.g. path A->B->C->D) shows loss at B, C, and D, is worth bubbling up to the user to say there might be real issues. Also any indication of loss at D is also an issue. Trying to reconcile these scenarios with the UI matters, but I don't think there's an easy way. What I think is more important than UI that is sorely needed is documentation / users guide explaining how to read and understand these indicators. I know documentation is usually overlooked by users first trying out a program, but having it documented and explained can be used as a reference to point to a user that is misunderstanding the tool. I found that MTR didn't have this much needed documentation / reference that people would easily misunderstand the tool and it was a herculean effort to correct them.
I would also like to point out that a 0% loss indicator at the destination isn't reliable either if the packets are spaced out with enough slack. One of my goto when testing packet loss of a link I've brought up is to smash a destination host with a ping flood, e.g. ping -c 100 -f 1.1.1.1. By inundating the link it helps provide a clear indicator if there is loss somewhere on the path (usually the first mile or the last). Cloudflare speedtest now has a packet loss tester that floods 1000 packets, although I'm not sure if it does it over an unreliable transport or not.
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):
> how did you accomplish all the package managers?
In most cases I didn't do anything! I've discovered that there are many kind souls out there who are willing to give up their free time to package and maintain 3rd party applications for a variety of systems they wish to support. It's tedious and, I suspect, usually thankless work. I am very grateful to all of those who have helped with this for Trippy.
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 [1] release notes if you want to know more.
The TUI is built with the awesome Ratatui [0] library (formerly tui-rs [1]). UX is certainly not my area of expertise and I would not have been able to create Trippy without this library.
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.
Free geoip database is very so-so, at least for residential addresses. For example, my ISP is of Romanian ownership (Digi), and although I'm Spanish, located in Spain, and using a Spanish contract (not roaming at all) for years (not a recently arrived ISP), I'm still very frequently shown Romanian versions of ecommerce sites I visit from my phone or home connection.
But I wonder: shouldn't at least intermediate router/exchanges locations be better pinpointed through their who is information? Isn't that database updated?
I wonder how reliable is JA4L once you start adding hops in the middle of the trace, I guess it takes in account the timing of the intermediate points.
A little time ago (1 month? 2? I'm so bad with dates) somebody showed their IP location service that was built using a similar technique, but measuring from multiple different locations, and I think they had a free version of the database. I'll try to find it later.
I think I might've mixed a bunch of different stuff in my comment, but the provider I was talking about was IPInfo. They do distributed JA4L-like location guessing and have a free IP-to-country DB:
That looks great, seems like they've raised the bar for GeoIp accuracy, kudos to them.
It looks like they provide mmdb files (for a fee) which should be compatible with Trippy. I'd love to be able to test it out, the sample [0] they provide is rather limited but I guess enough to test compatibility.
What a coincidence! I am the DevRel of IPinfo, and I was just about to reach out to you. My teammate (Shoutout to Max) has already mentioned your project on our team Slack, and I was thinking about a polite way to pitch our free IPinfo Country ASN dataset to your project. I will open a Github Issue right now.
You might also be interested in "geofeed" attributes in the WHOIS databases, in some database they can be found in a "remarks" field).
This record usually leads to an RFC 8805 formatted document that shows a mapping between IP address ranges and their (approximate) location. In RFC 9092, efforts were made to make this a more structural field.
Wondering if you took a look at or took some inspiration from the packet structures for TWAMP/TWAMP-LITE/SDLM RFCs for round trip times/packet loss measurements or if you sort of winged it and came up with your own. I've been meaning to learn rust by implementing those protocols.
> Very little coverage of this bill passing in the UK mainstream media that I have seen.
because there's no opposition to it. everyone wants these rules. the opposition wants them strengthened for example. since there's no discord, there's really no news.
Delaying the 2030 ICE ban was inevitable. Moving it to 2035 puts it in line with the EU.
(But it'll probably get delayed again. You can't just price the poor off the roads nationwide and expect the economy not to nosedive. As well as charging options for people without large detached homes with private driveways/garages, we need affordable used EVs, and we need to be sure thet battery packs in those older vehicles won't be utterly worthless)
The poor don't buy new cars, which this ban affects. They buy second hand cars, which would only slowly be removed from the market as new ones were not entering. Indeed, old ICE cars would automatically stick around longer if electric cars were too expensive. This was not a big bang approach.
The question is whether there will ever be an affordable used market for EVs (comparable with the used ICE vehicle market), due to the high price of new vehicles combined with battery degradation.
Will EVs have the multi-decade lifespan of a well-maintained ICE vehicle, or will they be on the scrapheap much sooner due to battery longevity issues, or repair-hostile practices as cars move ever further into 'tech product' status, unrepairable without proprietary tools/information/parts.
Meanwhile, the world seems to be getting ever more hostile to personal light EVs (e-scooters/bikes/skateboards)
For one thing mainstream media is exempt from the bill.
It has been there, just not directly. Always ask yourself; what is the deeper unstated reasons why a story is being covered widely by mainstream media?
Lot of truth in that though to be fair the 'page three' tradition (the inclusion of an image of a half-naked female on page 3 of a tabloid newspaper) finally ended in 2019. https://en.wikipedia.org/wiki/Page_3
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