Measurement network (Sonar)

The outside view of your own infrastructure – voluntary, limited, logged.

NODE64 sees your system from the inside. Some questions cannot be answered from there: is the port really reachable from outside? How long does a packet take? Does the nameserver answer the same way everywhere?

That is what Sonar is for: a measurement network of devices whose operators explicitly opted in.

How it works #

You order a measurement against a target that belongs to you. A probe – another participating device or a NODE64 measurement node – runs it and reports back. You see latency, loss, route or certificate data.

What can be measured:

Targets: yours only #

Before you may measure something, you have to show that it belongs to you. Two ways:

• Via a device: the public address of a connected device counts as proven.
• Via DNS: you publish a TXT record with a token we give you. Whoever can set that record controls the zone.

In addition there is a short, curated list of anchors we maintain – public DNS resolvers and our own measurement nodes, whose operators expect measurement traffic. You can adopt those without proof; they serve as a reference ("is my line bad, or the target?").

Third-party targets are blocked. Sonar is not a scanner, and the port measurement runs exclusively against proven own systems – a single port, a single connection attempt.

Taking part #

Participation is voluntary and switchable per device – it is off by default. If you turn it on, your device occasionally runs measurements for others. Three things you should know:

1. The measurement traffic originates from your connection. Not from a NODE64 data centre. Whoever operates the target address sees your IP.
2. You see every task your device took on – type, target, time, result. You do not see who ordered it; conversely, the requester does not see your address.
3. Your device has hard caps built into the agent itself. They apply even if the NODE64 server asks for something else.

You can switch it off any time in the dashboard – or locally in the configuration with NODE64_SONAR=false.

Limits and protection #

The plan limits nothing at all in the measurement network — not the number of nodes, not concurrent measurements, not probes per measurement. The only thing still tied to the plan is how long results are kept — and that is not a limit but a deletion promise.

A measurement network without controls would still be a distributed attack tool. What governs throughput instead applies the same to every account, regardless of plan:

• No internal targets. Private ranges, loopback, cloud metadata are excluded; after DNS resolution everything is checked again.
• Layered caps per target, per probe, per account and globally. The per-target cap applies across all users – it prevents many harmless individual measurements from adding up to a load.
• Narrow packet profile: small packets, fixed timeouts, limited hop count. No floods, no large payloads, no port ranges.
• Automatic abuse detection: measuring conspicuously many different targets in the same network gets you throttled.
• Complete logging. Every measurement and every rejection is recorded.
• A route for target operators: node64.de/en/sonar explains the traffic and gives the address to opt out.

Checking from outside #

The most common use case sits right on the matching finding: where NODE64 suspects a port is reachable from outside, you find Check from outside now. A measurement node knocks – and a guess becomes a measurement.

Path MTU: the measurement no ping replaces #

Nobody notices a too-small path MTU from a ping. Small packets get through, the connection is up, everything looks healthy. Only when a large packet travels – the TLS handshake carrying the certificate, an upload, a VPN tunnel – does the connection stall.

The Path MTU measurement type sets the DF bit and searches for the largest packet size that survives the whole path. It gives one of three answers:

The third case is why this measurement type exists. It is the cause behind connections that are up and still transfer nothing, and no other tool makes it this easy to see.

Reference values: 1500 Ethernet without extras · 1492 PPPoE (DSL) · around 1420 WireGuard · 1280 IPv6 minimum.

What you measure for others #

When your probe takes part, it runs jobs for other accounts – that is the whole point: you measure with other people's eyes, so you lend your own.

What goes over your connection is tightly bounded:

• Only the measurement types listed above. What is not compiled in does not exist for the probe – a job with an unknown type is rejected, not executed.
• Every job is signed. The probe verifies the server's signature before doing anything. A slipped-in job is discarded.
• The probe checks the blocklist itself. It does not rely on the server having filtered correctly – it rejects internal addresses independently.
• Its own caps on the probe: number of jobs and number of packets per time window. They apply even if the server sends more.
• Switchable off at any time, per device in the dashboard and additionally locally on the agent.

What does not happen: no port scans across ranges, no large payloads, no connections to third-party services beyond the listed measurement types. Port reachable runs exclusively against proven own targets of the requesting account.

The map #

Under Probes there is a world map of the measurement network. One dot per country, drawn from the country the probe reported itself while measuring.

Deliberately no more precise than that. There is no GeoIP database behind it – that would be a third-party dependency, it would be inaccurate, and it would turn a coarse figure into an apparently precise one. These are other people's servers; the country is enough.

Probes without a known country do not disappear; they are counted below the map. A map that silently omits half of them would be worse than none.

Connection arcs appear only when both ends are known – that is, when the target is itself a NODE64 device. For an arbitrary third-party address the server does not know where it stands, and should not know.

What a node delivers #

A node's page lists nine traits, all measured: whether it can do ICMP itself, whether it traces paths, whether it serves both address families, how many measurement types it has actually delivered, its answer rate, its longest gap, whether it agrees with the others, whether its address is stable and whether its location is known.

No grade. Turning nine traits into one number would mean weighting them, and there is no basis for that beyond an opinion. What stands there is a tally – and what cannot be judged is shown as open, not as a shortcoming.

Every trait carries its evidence. "Met" without a number beside it is a claim; "214 of 214 runs with a latency" can be recalculated and refuted.

Until 22 August 2026 there were badges here – a thousand measurements, a year on the network, every hour of the day measured once. They counted what someone had collected. What counts is whether a node does its job.

Where the parts come from #

• Map geometry: Natural Earth, public domain. In coarse resolution (110 m), simplified and rounded – around 65 KB, served by us. Map tiles from a third-party server would be ruled out by the content security policy anyway.
• Inspiration: RIPE Atlas showed that a volunteer measurement network works. NODE64 Sonar is considerably smaller and serves a narrower purpose, but shares the attitude: transparency about what is measured, and visibility for those who lend their connections.
• ICMP, traceroute and PMTU are written from scratch, without a third-party library. The agent deliberately carries no dependencies.

Two programs, not one with a switch #

Since August 2026 NODE64 ships two programs:

Why separate. A security agent that also measures has outbound traffic to targets somebody else chose. Anyone auditing it – and that is the point of an open-source agent – then has to read the source to understand why that is harmless. Separated, each program's purpose can be read off its network traffic.

During a run the security agent holds exactly one connection: to its own server. You can measure that yourself instead of believing us:

deploy/tools/agent-gegenstellen.sh

One machine may carry both. Two units, two directories, two keys – stopping the measurement mesh does not stop the security check.

A probe is not a device #

Until then you had to create a security device before you could get a probe. Anyone who only wanted a measurement point – a Raspberry Pi at another provider, a small machine in another country – had to give it a security agent it did not want.

A probe is now created on its own. It describes a measurement point: location, provider, address families, reputation and anchor status. Whether a security agent also runs on the same machine is a separate decision.

Consent lies in the act. Setting up a probe is the consent; a second checkbox next to it would be a question put to someone who just answered it.

Existing probes keep everything. Identity, anchor status and reputation move along. A reputation builds up over months and is the actual value of a probe.