You are here: Home > Analyse > Internet Measurements > RIPE Atlas > Documentation > Known Bugs and Limitations

Known Bugs and Limitations

We are continually developing RIPE Atlas and, based largely on feedback we receive from our users, fixing bugs that come to our attention along the way. Here you can find a log of the bugs we fixed, going back to the start of 2012, broken down by category (whether it pertains to data, the probes or the controlling infrasturcture) and in reverse chronological order. We continue to update this log as new bugs are found and fixed.

We also list the current limitations on the system, whether it has to do with the available data, the probes or the controlling infrastucture. We have plans to remove some of these limitations in the future, and so this list will also change on a continual basis.

Known Bugs



From firmware 4480 on, the UDP variant of traceroute for IPv4 uses the following source ports: for IPv4 (for both the paris and non-paris variations) the value is 20480 plus a small value that indexes the measurement in a table in the probe; this value may change when the probe reboots.


Before firmware 4680, traceroute could experience interference from other measurements. In general, periodic traceroutes did not interfere with other periodic traceroutes, but could experience interference from one-off traceroutes. Typically, this interference will show up in the 'edst' field. This problem was fixed in 4680.


From firmware 4610, the DNS measurement option 'use_probe_resolver' combines all responses from resolvers into one result. Before, the probe would generate multiple results of which only one was actually stored.

From firmware 4610, probes can include IPv6 hop-by-hop and destination option headers in traceroute measurements. Unfortunately, for version 3 probes and anchors, the Linux kernel computes the wrong checksum for the combination of destination options with either ICMP or TCP. The net result is that the final destination will not respond, however the intermediate routers typically will respond.


Firmware versions 4570 and 4580 failed to include the 'ttl' and 'src_addr' fields in ping results. This has been fixed in firmware 4600.


For IPv6, the outgoing port number for UDP traceroutes was selected by the Linux kernel for each outgoing packet. This unfortunately completely broke the paris variation. This has been fixed in firmware 4550.


New probe firmware version 4500 fixed a bug where the DNS TCP measurements may have reported "error".


New probe firmware version 4480 fixed several bugs. The first was a fix for traceroute in order to deal with rfc4884 objects (mpls) that have a wrong size. The second fixed a bug in HTTP GET in which some characters were not properly escaped in generating the result JSON. The third fixed bugs in the libevent stub resolver to better handle DNS errors and timeouts, which affected mostly HTTP GET.


New probe firmware version 4470 fixed two bugs. The first was that DNS results were sometimes mixed up when a probe ran two simultaneous DNS measurements. The second one involved traceroute measurements that sometimes reported a timestamp of 0.



No current issues.


New probe firmware 4770 fixed a bug where DNS TCP queries always failed.


Fixed in 4680, if a probe's IPv4 address is assigned via DHCP and the DHCP reply also contains information about the DNS resolver, then the probe will no longer use that DNS resolver instead of any statically configured DNS resolver. Statically configured DNS resolvers are used exclusively when present. In addition 4680 also support receiving DNS resolvers from IPv6 Router Advertisements.


Fixed in 4610, the DNS "use probe's local resolvers" refreshed the list of resolvers if it has been changed by DHCP. Before the measurement would not pick up changes but keep using the first list it found.


New probe firmware version 4570 picks up a new list of resolvers if it has been updated by DHCP. This affects all measurements that involve DNS lookups (except for DNS "use probe's local resolvers").


New probe firmware version 4480 fixed several bugs. It limited the amount of measurement data sent as one unit, preventing probes that had not connected to a controller for some time from overloading the controller. Probe uptime was also included in the DNS SOS messages sent by probes before they try to connect, allowing us to make a distinction between various reasons for disconnects, such as a probe reboot vs. network problems.


Support for IPv6 literals for the registrations servers is now available, allowing an IPv6-only probe to connect to a registration server even if it doesn't have a DNS resolver. This was included in the new probe firmware 4470.



The user interface never shows any IPv6 gateway; the entry is always displayed as "Undetermined/Unknown."



Data visualisation

Currently, RIPE Atlas only supports visualisations for ping measurements using 20 or fewer probes, and traceroute only for IPv6 traceroutes and built-in measurements. We plan to make visualisations available for all user-defined measurements in the future.


To avoid overloading targets, users are allowed to perform a maximum of ten simultaneous periodic measurements and ten one-off measurements per target at any given time. In addition no more than 500 probes may be used per measurement.


Built-in measurements

Probe versions 1 and 2 have different limitations on the number of measurements they are able to perform at any given time (you can see which probe version you have by clicking on your probe under the "My Probes" tab when logged in to RIPE Atlas). Probe version 1 can perform 700 ping measurements and probe version 2 1200; probe version 1 can perform 400 traceroutes and probe version 2 1200. We plan to make a more comprehensive list of these figures available in the future.

Measurement frequency

RIPE Atlas limits the frequency of the various user-defined measurements that probe hosts can conduct as follows:

  • Ping every 60 seconds (default is 240 seconds)
  • Traceroute every 60 seconds (default is 900 seconds)
  • SSL every 60 seconds (default is 900 seconds)
  • DNS every 60 seconds (default is 240 seconds)

In addition, for one-off measurements, the probe executes at most 10 measurements in parallel. Beyond that, measurements are executed as soon as a previous one-off measurement finishes. Currently, results are delayed until the entire queue is drained.

Probe accuracy

Measurement reply times depend on local network conditions and the inherent delay of the probe. Latency times for ping measurements for both probe versions 1 and 2 are typically higher than what you may see on a modern laptop. For example, a ping to takes approximately 1.5 milliseconds versus approximately 0.05 milliseconds on a modern laptop.

Probe data storage

Probes that become disconnected for whatever reason will continue to perform measurements. Version 1 and 2 probes are only able to store the the most recent six hours of data. Version 3 probes and anchors can collect results for many months. Once reconnected, this data is transmitted to the RIPE Atlas central infrastructure.

UDM credits and limits

RIPE Atlas probe hosts earn credits for the amount of time that their probe(s) remain connected. They can then redeem these credits in order to conduct their own user-defined measurements.

The daily credit consumption limit is set to 1,000,000 credits per day currently.

You can learn more about the credit system at the credits documentation page.


In order to keep the system stable during temporary network glitches and short term downtimes on the infrastructure components, the probes "stick" to a particular controller for 1 hour; i.e. they keep on trying to connect to the same server during this period. During this time the probes keep on executing measurements and buffering results, but they cannot report results or accept new measurement requests.