September 2025 - ripe-atlas - mailman.ripe.net

v2 probe repair?
by Phillip Remaker 24 Nov '25

24 Nov '25

Hello! I have an 11+ year old v2 probe Seems to be in a reboot loop. Starts up, all LEDs go blank, and it repeats. Any diagnostics I can do? Any repairs? https://atlas.ripe.net/probes/4111/#tab-network

4 7

Atlas UI updates 2025-09-26
by Stephen Suess 26 Sep '25

26 Sep '25

Hello Atlas friends, We have just released an update to the UI that includes (among other items): - NEW: Measurement form: auto-top-up settings - NEW: Measurement details manage tab: auto-top-up settings and manual top-up (when possible) - CHANGES: Khipu (beta): Horizontal layout mode, much improved RTT mode with anomaly notes, country filter dropdown, country view lookup/scoring, IP labels in IP view For the full list of what has changed, please see the release notes here: https://atlas.ripe.net/docs/releases/website_index/2025-09-26 Please let us know what you think! Kind regards, Stephen Atlas UI

1 0

FreeBSD/MacOS probe
by Jared Mauch 22 Sep '25

22 Sep '25

I’m looking for people to test out my attempted FreeBSD/MacOS changes to shift a few calls to POSIX compliant and other tweaks to make it build on other operating systems. You can try to build from this git repo: https://github.com/jaredmauch/ripe-atlas-software-probe I would request comments go here: https://github.com/RIPE-NCC/ripe-atlas-software-probe/pull/135 Or possibly in this issue which originated from someone else, but the recent note from Randy had me look at the codebase. https://github.com/RIPE-NCC/ripe-atlas-software-probe/issues/123 Hopefully this is useful and might be able to be merged back in, but I know this may cause some troubles due to the busy box parent as well. - Jared

7 29

Debian trixie support for s/w probes?
by Andrew Elwell 16 Sep '25

16 Sep '25

Hi folks, Is there a plan to support debian stable 'soon' for the software probes? I know I could build from the git repo, but I'm lazy and would rather apt-get install it, but https://ftp.ripe.net/ripe/atlas/software-probe/debian/dists/ only has bullseye & bookworm. Hat tip to all involved tho, #1009903 seems to be chugging along happily (well, except that the hypervisor's due for an update & reboot shortly) Andrew

3 2

Atlas UI, Khipu and docs updates
by Stephen Suess 15 Sep '25

15 Sep '25

Hi All, Since the last update on 2 September, we have updated the Atlas UI 3 times (including today). Among the highlights: - Khipu visualisation -- Country view -- DNS multi target view -- Smart popup placement -- Improved path filter -- Docs: https://atlas.ripe.net/docs/tools-and-code/khipu - DomainMON improved error messaging - LatencyMON url param fixes - Legal accordion new sections - Clarify member benefits in the Use Cases menu You can see all the recent changes here: https://atlas.ripe.net/docs/releases/website_index/ And as always we welcome any and all feedback and suggestions. Kind regards, Stephen RIPE Atlas UI

1 0

Notification on removal of system-ipv4-works && system-ipv6-works tags while connected
by Lukas Tribus 15 Sep '25

15 Sep '25

Hello, currently notifications are configurable for the event when a probe is disconnected; however when a probes remains connected but stops working (loosing or no having either system-ipv4-works and system-ipv6-works tags), we are blind. I have written a monitor script to query the API for this, to get this notification but I'm wondering if it would be possible to implement this at RIPE. The system-<AF>-works tags are already there. Software bugs and I guess HW issues can trigger hung probes that remain connected. It's hard to find out, unless one is specifically looking for it or specifically expecting the result of a single probe in a measurement. Lukas

15 29

tracemon false join
by Randy Bush 13 Sep '25

13 Sep '25

looking at TraceMON (for 128292864), it appears as if the traces for a bunch of sources converge at a common node before failing. but they do not. they fail at different points as one can see if one looks at the result details or at khipu. what am i misunderstanding here? this is very misleading to a novice. i see one madly clicking at the apparent point of failure desperately wanting its ip address. of course, i would never make that mistake :) randy

1 0

traffic graph
by Hans Mayer 05 Sep '25

05 Sep '25

Dear All, Based on the conversation about traffic here some days ago I took a look into my statistics. I looked at the dashboard from RIPE Atlas and I looked at netflow from the router for my probe. Both from the last 24 hours. This is the dashboard and this comes from netflow it is summarised for IPv4 in and out and IPv6 in and out. Not to be confused netflow shows bits and the dashboard bytes. There is another difference, netflow has 10 minutes intervals and it seem the dashboard has 3 minutes. But independent of that, the graphs should have some similarities. I am not worried about that because the traffic is below any perception. But is there any explanation ? It becomes funny when I switch to "Last Week" All the traffic is below the 0 KB line. Maybe it should be 10 KB and the "1" is not visible for some reason. Kind regards Hans

2 1

Suggestion to change "next" field in the result of a probes REST API query
by Shane Kerr 05 Sep '25

05 Sep '25

Hello, The REST API query to get probes is documented here: https://atlas.ripe.net/docs/apis/rest-api-reference/probes If you do a lookup which would return too many results, it sets the "next" field in the return, like this: -------------------------------------------------------------------- { "count": 55125, "next": "https://atlas.ripe.net/api/v2/probes/?page=2", "previous": null, ... -------------------------------------------------------------------- The idea is the REST API client will then make a call to the "next" URL and get the next batch of data; this is basic paging. There is no kind of transaction or anything, so the status of the probes can change between each call. This is fine since the status of the probes changes independently and you cannot count on their status really. One problem is that using "page" for this means it is possible to get the same probe twice. For example, if you are looking for "Connected" probes, and returning the probes in order of probe ID, and a probe that you have already returned becomes "Connected", then the answers will all shift up by one, and you will see the last probe twice. This can be avoided by instead of using "page" for the "next" field using whatever the sorting is for the returned values in the query. I think by default this is probe ID, so the "next" field could be: -------------------------------------------------------------------- { "count": 55125, "next": "https://atlas.ripe.net/api/v2/probes/?id__gt=101", "previous": null, ... -------------------------------------------------------------------- I suspect this would be faster on the back-end too. I ended up doing this logic on the client side and it works fine, although that is for a specific sorting order. It would be more complicated to do this for all orderings on the server side. Cheers, -- Shane

2 1

Possibility to specify a POST payload?
by Lars Eggert 04 Sep '25

04 Sep '25

Hi, (Please let me know if there is a better way to make feature requests.) It would be great if it was possible to specify a payload for an HTTP POST when putting together an experiment. Thanks, Lars

5 8