they totally do lie, for a number of reasons. A most common one is that multimeter presents much higher resistance than many loads, so an almost-empty battery might present "8.7V" to multimeter but that immediately drops down to 1-3V if any real load is present. This won't happen with smoke alarm, but can happen with a radio or a toy. This is a common gotcha for many people who are just learning to use the tool.

The less common reason include: shaking the battery (such as when you are removing it from the device) might increase its voltage for a few minutes; bringing outdoor device into warn room might also make battery appear more full.

So yes, multimeters have their own limitations, and if the device under test cooperates (exposes test points for example), they work much better. You need some skill to know when to trust it and when to ignore its reading. Kinda like for traceroute :) so maybe the analogy is not that bad after all.

Yes, I understand that any physical measurement tool in the universe has an error range whether it's a multimeter or an air pressure gauge. I have 3 air pressure gauges and yes -- all of them are are "lying" to me because they're all "wrong" by various percentages for various environmental reasons. Even the $150 Longacre elite air pressure gauge is lying to me about my car's actual tire pressure by the perspective you're using. The mistruth you're pointing out is from the perspective of the measurement tool (e.g. the multimeter has higher internal resistance.)

However, the "lie" perspective I was using was from the human-configured _target_ device itself -- for adversarial-or-performance-optimization reasons. The humans that configured the network nodes can deliberately make it not respond to ICMP packets which renders the traceroute statistics less than helpful (or "not real" as the author puts it). That's the angle the author was trying to explain in a confusing way. That's a different situation from the analogies that gp (kazinator) was using.

Your perspective is also correct but the physical limitations of measurement tools wasn't my point. The humans with "agency" in how to make their routers or servers respond to ICMP packets is a different kind of "lie" than batteries that haven't been shaken.

>Kinda like for traceroute :) so maybe the analogy is not that bad after all.

I use digital multimeters every day and reading "3v" from a 9-vote battery doesn't feel like a "lie" but a sort of "truth" based on the load factors you point out. However, pinging a system and getting timeouts feels more like a mistruth because the target system is often actually there but somebody didn't want to make it reply to those particular packets.

Or for a more extreme example: Apple chargers prominently say "20V" on them.. and yet if you get one and hook up a multimeter to it, you will only measure 6 volts (see "Charger Startup Process" in [0] to see why, spoiler: it needs special enable pulse as a safety measure). Will you call this "a lie"? Can we say "multimeters aren't real" because Apple power supplies require special pulse? Can we say "humans have deliberately made it not work with multimeters"?

Instruments, be it traceroute or multimeters, have limitations; and users should know about them. Even if technology advances make tools less useful in some situations, there is no reason to disparage them.

[0] http://www.righto.com/2013/06/teardown-and-exploration-of-ma...

Devices that don't have such a thing are like hosts that may or may not give you an ICMP message. You're on your own, reverse engineering and guessing.

The author says that the latter approach isn't "real".

If an object is man-made, investigating it empirically using the scientific method, using whatever tricks are available, including the repurposing of its features, is off the table and the results are not real.

OK, a few idiots think that if traceroute shows node 6 and node 8, node 7 must be down. So what?

A few idiots probably also think that if they put an ohmmeter on a resistor that is soldered into a circuit, they can read off that resistor's resistance.

Or that if a 10V battery reads 8.5V, it's still 85% full!

No, that isn't what the author is saying about "real". He's not saying that using some common sense problem-solving is "not real" as you're claiming.

Instead, he's saying official industry support for traceroute is what's "not real". Example quote: "For a good summary I highly recommend this presentation. But as good as that deck is, I always felt it left out a crucial piece of information: Traceroute, as far as the industry is concerned, does not exist."

To your credit, I don't think it's your fault for misinterpreting it since the author went for a "cute" title instead of just plainly stating limitations of traceroute in a non-dramatic way.

This following outlines the writing style the author used that inadvertently caused readers to hyperfocus on the word "real" instead of just agreeing or disagreeing on the actual points about "limitations of traceroute":

- step 1: define "not real" in a very specific idiosyncratic way so it conveniently creates a nice shock-value blog "title". E.g. "With the powers vested to me as author of this blog, I'm going to use "Not Real" to mean ... no modern-RFC, and no ironclad legally-binding SLA for ICMP/UDP/TTL responses from all network hosts, and no hidden performance hacks or dropping of packets, etc." (Basically, he's saying that there's no perfect cooperation/coordination between all actors in the network so that means "traceroute isn't real" in his constrained definition.) And bonus points for creating a special definition "not real" that is so nuanced that no casual reader could hold it in their head.

- step 2: write in a condescending way ("everyone was wrong") so that traceroute appears completely useless and any user is clueless for even trying it as a diagnostic tool

The author's writing style undermined the effect he wanted since the end result is a reader like you thinking he meant "reverse engineering as a problem-solving technique isn't real".

It's obvious that the author means "not real" in the same way that i = a[i++] returning a particular value on one C compiler is "not real". There are no engineering requirements anywhere which give you specifics that you can rely on.

Yes, traceroute is "not real" in a similar way.

What it means is that you probably don't want to be writing an application in which you run traceroute and have the code making important decisions based on what is scraped from the output.

Traceroute gives real information though: yes, that host #5 you see in the list really did drop the TTL-dead packet and sent you the ICMP notice. Yes, the repeated listing of hosts 9, 10, 9, 10, 9, 10 .. almost certainly mean they have a routing loop between them.

My argumentation is that people have to investigate and predict the behavior of systems that are not specified by any engineering requirements. For instance, we have meteorologists who predict the weather, imperfectly. The weather doesn't come with a metrics API and reference manual so meteorology isn't real. And look, it's often hardly better than a wild guess more than about 4 days out.

Maybe traceroute is like a weather radar. It tells you there are some droplets in the air out to the northeast, about 15 miles away. Maybe it's rain, maybe not; or is it a swarm of locusts? Those radars are useful nonetheless and pretty real.

Traceroute is a byproduct of a complex process that may match the forward path of real application traffic you send to some address. It may not if you have some local (transparent) proxy for certain protocols, or QoS in the middle (that may mis-classify your application traffic, unlike regular ICMP pings), or intrusion detection system, DoS protection system, or low level load balancer on the other end. The author invites to check another explanation multiple times, and it gives at least one example when replies from a certain hop are canonically sent by a different network hop. Some ISPs use IP addresses from private ranges, and they surface in traceroutes. Some ISPs lease others' infrastructure, and you see those IP addresses and DNS names inside their networks. Some ISPs deliberately mess with low TTL packets to cloak details like those from clients and competitors, and keep their physical network layout secret.

You need to know all of that, from ARP to BGP, to understand traceroute output. You also need to remember that one post in network engineering community a month ago that told that ISP M was bought by Corp N to guess that they are probably switching traffic from leased line between IX A and IX B to Corp N's own lines between City X and City Y, which might explain what you see. However, traceroute manual doesn't give you a list of 30 thick books to read in advance, nor does it contain the latest gossip about the state of ISP O's hardware in City Z. Therefore, unprepared user is not aware of all the possible complexities.

This reminds me of “helpful” websites that state that hosts with IP addresses of well known CDNs are located in California. Then people from all other the world run ping or traceroute, and deduce that they have a 10 ms RTT to California. Wow, such a great CDN!