- ripe-atlas - mailman.ripe.net

FreeBSD/MacOS probe
by Jared Mauch 15 Sep '25

15 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

5 17

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

Non-Profit Arts Organization Seeking Credit Donations
by ADCIBC Tech Support 03 Sep '25

03 Sep '25

Hello All, My name is Ari Broad and I am the IT Director for a non-profit arts organization called The American Dance Competition, Inc. (www.adcibc.com). We have expanded our organization internationally and I need to do performance checks on the website in various countries abroad to ensure the site is working for international users as we recently found out our site is blocked in Mainland China, so I am doing my due diligence with other countries where we are touring. I have created a python script that will do this checking process for us (versus doing it manually through online tools which is time-consuming) that utilizes RIPE-Atlas, but it will not work because I have 0 credits on my account. I see that you have to contribute to the probes in order to get credits, I would love to contribute for science, but I do not have a desktop I could host this on. I reached out to RIPE-Atlas help and they suggested I reach out to this mailing list to ask for credit donations. *Here is a list of the tests I am attempting to run:*In these countries: JP,ES,DE,SE,DK,CH,GB,IT,CA,FR,NL,PL Run measurements on 3 ASNs per country. That's *36 site performance measurements. * I am not sure what the credit currency exchange is like, but if we could get enough credits to run these tests that'd be great. *But truly any amount of credits will help!* *If you have any amount of credits you would like to donate to us for our international site performance checks please send them to the recipient: adcibc.tech(a)gmail.com <adcibc.tech(a)gmail.com> * Thank you in advance for any donations we may receive. Best, *Ari Broad, M.S.* *(she/her)* IT Director ADC|IBC www.adcibc.com

4 3

Re: Notification on removal of system-ipv4-works && system-ipv6-works tags while connected
by Antony Gollan 03 Sep '25

03 Sep '25

Hello all, We use Brevo to send these emails primarily because it ensures deliverability and allows people to easily unsubscribe. This is important because big email providers have recently increased their penalties for potential spam, so we track bounces and unsubscribes to make sure the RIPE NCC stays within acceptable limits. It is not possible for us to turn off the tracking pixel in Brevo on our end, but we use it only to view the status of delivery, opens and unsubscribes. We are aware this tracking is not 100% accurate, but it gives us a general view of whether emails are reaching their recipients, which helps us to stay below the spam threshold. If you’d rather get a plaintext version of these emails from Brevo, some email clients provide an option to switch to the plaintext view. This will also block the tracking pixel. Regards, Antony Gollan Communications Team Manager RIPE NCC

2 1

Massive uptick in number of flows to/from probe
by Jenisch Ewald 03 Sep '25

03 Sep '25

Hi, Maybe coincidence with the update of the UI rolled out today, but we've seen a massive uptick in the number of flows going out from our probe up to a range of 120k flows/sec starting around 15:00 local time (CEST) Anybody else experiencing the same thing? Any ideas as to what's going on here? Thanks in advance for any clue, -ewald eingeschränkt/restricted

5 6