Technical Details

What data do the probes collect?

Probes perform built-in measurements, including:

• Its own network configuration information
• Current uptime, total uptime and uptime history
• RTT (round trip time) measurements (on IPv4) to the first and second hops (think about the first two lines in your outgoing traceroutes)
• Ping measurements to a number of predetermined destinations
• Traceroute measurements to a number of predetermined destinations
• DNS queries to root DNS servers (others to come)
• TLS (SSL) queries to a number of predetermined destinations
• More measurement types may be added in the future

In addition, probes also execute "user defined measurements" asked for by other RIPE Atlas users, which are of the same type (ping, traceroute, DNS, etc.)

You can look at the results of all of the above on your probe's detailed information page. When you're logged in to the RIPE Atlas website, you can find your probe under the "My Probes" tab on the probes page (opens new window).

Hosts also have access to the RIPE Atlas network to conduct their own user-defined measurements based on those above. An example might be setting up traceroute measurements in order to determine how networks in a specific country or region access your own network.

Similarly, other RIPE Atlas hosts will have access to your probe in order to conduct their own user-defined measurements. You can always check what user-defined measurements your probe participated in on your probe's detailed information page.

Find out more about user-defined measurements.

How are the probes powered?

You'll need to supply some electricity to the hardware probe through its USB cable. Any USB port capable of supplying 500mA should be fine; it could be a free USB port on your home router, or you can use a USB power adapter. Note that devices that go into sleep mode (monitors with built-in USB hubs, laptops, etc.) are not good enough as they usually stop supplying power over USB when they go into sleep mode.

Is it possible to power the probes using Power over Ethernet (PoE)?

The probes don't support PoE out of the box, since this would make them much more expensive to manufacture, and very few users would benefit from it. However, since this question comes up occasionally, we looked at options. We've found a potential one (opens new window). Keep in mind that we haven't tested this, but it looks like a possible device that can take power from a PoE cable and give a 5V output. We'd appreciate feedback from our users about this (or any other) solution.

How does the probe connect to the Internet?

Probe versions 1 and 2 have an RJ-45 Ethernet interface. They don't have WiFi capabilities. Probe version 3 (TP-Link) and v4 (NanoPi) technically have hardware WiFi capabilities; however, we have not provided the necessary software to support this capability because we wanted to keep the host's traffic separate from the probe in order to ensure the host's privacy.

This means that you have to connect your probe to a physical Ethernet port. Once this is done, the probe acquires an IPv4 address and DNS resolver information using DHCP, IPv6 configuration using RA, and then tries to look up the controlling infrastructure using DNS and connects over SSH to it on outgoing TCP port 443 (HTTPS).

To make probes stand out in a list of DHCP clients, they use the string RIPE-Atlas-Probe-\<probe-id\> as their DHCP client identifier. However, if the probe doesn't know its probe identifier, which will typically happen after a firmware upgrade, then it will use its ethernet address as client identifier. This means it is required to create two entries to configure a probe statically in DHCP.

If you want to configure a DHCP server, you can use the following example dhcpd.conf snippet, kindly contributed by Alan Barrett:

ddns-update-style none;
subnet <<my subnet>> netmask <<my netmask>> {
    option subnet-mask <<my netmask>>;
    option routers <<address of default gateway>>;
    option domain-name-servers <<address of open resolver>>;
}
host <<hostname assigned to probe>>-hw {
    hardware ethernet <<MAC address of probe>>;
    fixed-address <<IP address assigned to probe>>;
}
host <<hostname assigned to probe>> {
    option dhcp-client-identifier "RIPE-Atlas-Probe-<probe-id>";
    fixed-address <<IP address assigned to probe>>;
}

How much bandwidth will the probe consume?

That depends on the number of measurements the probe is running at any given time. Experience shows that an IPv4-only probe uses approximately 4 Kb/s, an IPv4+IPv6 probe uses approximately 6 kb/s with some user-defined measurements assigned to it. The more UDMs your probe executes, the higher the bandwidth usage will be.

Hosts can also specify the maximum bandwidth their probe can use on their probe's detailed information page. We take these values into account when scheduling measurements, but we cannot promise that we'll never go beyond these limits, as we cannot always predict how much traffic a particular measurement will cause. You can always check your probe's bandwidth usage on the probe's detailed information page.

Why did you choose a hardware solution instead of software?

With a pure software solution, distribution costs are low and the number of potential hosts is very large. However, there are several significant downsides to a pure software approach:

• Host machines may not run continuously over long periods, which affects our ability to gather round-the-clock measurements
• Measurements can be influenced by sharing systems and network resources with other applications on the host computer
• It is often not possible to install software like this in a corporate or computer centre environment
• It is easier to tamper with the results. This is also why we chose not to release a software version in tandem with the hardware solution

Because of these drawbacks, we opted to develop the RIPE Atlas probe as a stand-alone piece of hardware.

What hardware and software do you use?

Over time we had several differen hardware devices:

• v1/v2: The hardware of the first and second generation probes is a Lantronix XPort (opens new window) Pro module with custom powering and housing built around it.
• v3: The third generation probe is a modified TP-Link wireless router (model TL-MR 3020) with a small USB thumb drive in it; this probe does not support WiFi (see below).
• v4: This is an off-the-shelf NanoPi device, with a custom housing around it.
• v5: This is a modified version of the Turris Mox device, with no Wifi capabilities and a custom housing.

As a general rule all hardware versions of the probe perform the same built-in measurements, though the capacities and capabilities of older models prevent some of the measuremens and/or parameters.

The probe is not a powerful device on its own, but it's small and attractive. The software on the device is developed by the RIPE NCC. The probes are connected to a hierarchical control and data collection service, which is also built by us.

So which services do I need for my probe to work?

The absolute minimum set is DHCP, DNS and outgoing TCP port 443 (HTTPS) in order to allow the probe to connect to the network. However, this in itself is not enough to do measurements, which is the entire focus of RIPE Atlas, so you should also allow ICMP, UDP (DNS + traceroute), TCP for traceroute and HTTP(S).

What do the lights on the side of the probe mean?

The first and second generation probes have blinking LEDs (next to the Ethernet connector) when they are connected.

The third generation probe has a series of LEDs on its top side. When the probe is connected and functioning normally, the first, third and fourth LEDs are lit up. For a more detailed breakdown of what the different LEDs mean, please see the table below.

Status	1 (power)	2	3	4	5 (button)
Running from built-in flash	on	slow blink	off	off	undetermined
Network test failed	on	off	fast blink	off	off
Network test failed	on	off	slow blink	off	off
Device booting	on	off	off	off	fast blink
Connecting	on	off	on	blink	off
Connected	on	off	on	on	undetermined

Version 4 has the usual Ethernet traffic indicator LEDs on the connector itself.

Does my probe support WiFi?

In short: no. RIPE Atlas has not wifi measurements.

Probes version 1 and 2 do not have any WiFi capabilities. Probe version 3 is a modified TP-Link ireless router, whereas v4 is based on a NanoPi. However, in configuring the probes, we decided not to provide software to support WiFi because we wanted to keep the host's traffic separate from the probe in order to ensure the host's privacy.

There's a switch on the side of my probe. What does it do?

Probe version 3 (TP-Link) has a switch on the side that is related to the TP-Link's capabilities as a router; however, this link has no function in relation to the device's role as a RIPE Atlas probe and its position does not affect the probe.

Does the probe work behind a NAT? I just want to plug it in at home and not configure anything.

Yes. The probe works fine behind a NAT box. So in most cases, one can just plug it in and it should just work.

Can you connect my probe to a gigabit-only port?

No. The probes support only 10 Mbit/s and 100 Mbit/s. Most gigabit switches support lower speeds, but some don't.

I have an IPv6-only network. Will the probe work on it?

Yes. All probes can be configured statically with an IPv6 address, default router, DNS resolvers, etc. through the web UI. In addition, version 3 probes can be fully configured through router advertisements (support for RFC 6106 was added in firmware release 4680). There is no support for DHCPv6 (RFC 3315) at the moment. Version 1 and 2 probes can obtain addresses and default routers through router advertisements, but cannot obtain DNS resolvers that way. For those probes, the DNS resolvers will have to be configured statically through the web UI.

Do you support mobile measurements?

"Mobile measurements" can mean two separate topics:

• The ability to run a probe on a mobile device, such as an app (in the Android or Apple stores). This is not supported for several reasons:
  • Doing so would considerably affect the power consumption of the device as it is always-on and always active (i.e. measurements are constantly happening).
  • Permissions available to such apps are unlikely to be sufficient to support expected probe behaviour.
  • The resulting data would be hard to interpret as devices tend to switch between wifi and mobile connecitons, or even 3G/4G/5G, resulting in latency, IP and other changes.
• The ability to measure using mobile networks, in other words to host a probe on a wireless connection:
  • This is already possible: several hosts run probes connected via Starlink or some "fixed wireless" connections.
  • In these cases the probe is a regular client device behind the router; one that requires a wired connection to the (home) router.