- ripe-atlas - mailman.ripe.net

Possible software probe "farming" on AS47583
by Ben Cartwright-Cox 02 May '24

02 May '24

Hi everybody, While doing some measurement work earlier this weekend I discovered that there are a large amount of probes on AS47583 that look like they are being set up to farm credits. With a suspiciously high amount of purely software probes on the same IP prefix and sequential IPv6 addresses. $ curl -s 'https://stat-ui.stat.ripe.net/data/atlas-probes/data.json?resource=47583' | jq .data.probes[] -c | grep Connected | jq '.address_v4 + " " + .address_v6' | sort "153.92.14.66 2a02:4780:6:c0de::e" "153.92.14.67 2a02:4780:6:c0de::f" "153.92.14.68 2a02:4780:6:c0de::11" "153.92.14.69 2a02:4780:6:c0de::12" "153.92.14.70 2a02:4780:6:c0de::13" "153.92.14.71 2a02:4780:6:c0de::14" "153.92.14.72 2a02:4780:6:c0de::15" "153.92.14.73 2a02:4780:6:c0de::16" "153.92.14.74 2a02:4780:6:c0de::17" "153.92.14.75 2a02:4780:6:c0de::18" "153.92.14.76 2a02:4780:6:c0de::19" "153.92.14.77 2a02:4780:6:c0de::1b" "156.67.223.15 2a02:4780:3:1::2a" "156.67.223.16 2a02:4780:3:1::2b" "156.67.223.29 2a02:4780:3:1::35" "156.67.223.30 2a02:4780:3:1::36" "156.67.223.31 2a02:4780:3:1::37" "156.67.223.36 2a02:4780:3:1::38" "156.67.223.37 2a02:4780:3:1::39" "156.67.223.38 2a02:4780:3:1::3a" "156.67.223.39 2a02:4780:3:1::3b" "156.67.223.40 2a02:4780:3:1::3c" "156.67.223.41 2a02:4780:3:1::3d" "156.67.223.42 2a02:4780:3:1::49" "156.67.75.19 2a02:4780:b:c0de::16" "156.67.75.20 2a02:4780:b:c0de::17" "156.67.75.21 2a02:4780:b:c0de::18" "156.67.75.22 2a02:4780:b:c0de::19" "156.67.75.23 2a02:4780:b:c0de::1a" "156.67.75.24 2a02:4780:b:c0de::1b" "156.67.75.25 2a02:4780:b:c0de::1c" "156.67.75.26 2a02:4780:b:c0de::1d" "156.67.75.27 2a02:4780:b:c0de::1e" "156.67.75.28 2a02:4780:b:c0de::1f" "156.67.75.29 2a02:4780:b:c0de::20" "156.67.75.30 2a02:4780:b:c0de::21" "156.67.75.31 2a02:4780:b:c0de::22" "156.67.75.32 2a02:4780:b:c0de::23" "156.67.75.33 2a02:4780:b:c0de::24" "185.201.11.3 2a02:4780:1::3" "185.224.136.17 2a02:4780:8::12" "185.224.136.18 2a02:4780:8::13" "185.224.136.19 2a02:4780:8::16" "185.224.136.22 2a02:4780:8::1a" "194.5.158.13 2a02:4780:8:b::11" "194.5.158.15 2a02:4780:8:b::12" "194.5.158.16 2a02:4780:8:b::13" "194.5.158.18 2a02:4780:8:b::15" "194.5.158.223 2a02:4780:8:b::f" "194.5.158.226 2a02:4780:8:b::10" "194.5.158.228 2a02:4780:8:b::16" "194.5.158.238 2a02:4780:8:b::14" "212.1.215.106 2a02:4780:1:12::3" "212.1.215.107 2a02:4780:1:12::4" "212.1.215.108 2a02:4780:1:12::5" "212.1.215.109 2a02:4780:1:12::6" "212.1.215.110 2a02:4780:1:12::7" "212.1.215.111 2a02:4780:1:12::8" "212.1.215.112 2a02:4780:1:12::9" "212.1.215.113 2a02:4780:1:12::a" "212.1.215.114 2a02:4780:1:12::b" "212.1.215.115 2a02:4780:1:12::c" "212.1.215.116 2a02:4780:1:12::d" "217.21.86.65 2a02:4780:11:c0de::d" "217.21.86.66 2a02:4780:11:c0de::e" "217.21.86.67 2a02:4780:11:c0de::f" "217.21.86.68 2a02:4780:11:c0de::10" "217.21.86.69 2a02:4780:11:c0de::11" "217.21.86.70 2a02:4780:11:c0de::12" "217.21.86.71 2a02:4780:11:c0de::13" "217.21.86.72 2a02:4780:11:c0de::14" "217.21.86.73 2a02:4780:11:c0de::15" "217.21.86.74 2a02:4780:11:c0de::16" "217.21.86.75 2a02:4780:11:c0de::17" "217.21.86.76 2a02:4780:11:c0de::18" "217.21.86.77 2a02:4780:11:c0de::19" "217.21.86.78 2a02:4780:11:c0de::1a" "217.21.86.79 2a02:4780:11:c0de::1b" "2.57.90.18 2a02:4780:a:c0de::3" "2.57.90.38 2a02:4780:a:c0de::2" "2.57.90.41 2a02:4780:a:c0de::4" "2.57.90.42 2a02:4780:a:c0de::5" "2.57.90.43 2a02:4780:a:c0de::6" "2.57.90.44 2a02:4780:a:c0de::7" "2.57.90.45 2a02:4780:a:c0de::8" "2.57.90.46 2a02:4780:a:c0de::9" "2.57.90.47 2a02:4780:a:c0de::a" "2.57.90.48 2a02:4780:a:c0de::b" "2.57.90.49 2a02:4780:a:c0de::c" "2.57.90.50 2a02:4780:a:c0de::d" "45.128.160.100 2a02:4780:9:c0de::2be" "45.128.160.101 2a02:4780:9:c0de::1ae" "45.128.160.102 2a02:4780:9:c0de::3f" "45.128.160.104 2a02:4780:9:c0de::10a" "45.128.160.108 2a02:4780:9:c0de::3c2" "45.128.160.111 2a02:4780:9:c0de::11f" "45.128.160.112 2a02:4780:9:c0de::38f" "45.128.160.116 2a02:4780:9:c0de::12" "45.128.160.119 2a02:4780:9:c0de::c6" "45.128.160.121 2a02:4780:9:c0de::116" "45.128.160.124 2a02:4780:9:c0de::94" "45.143.83.65 2a02:4780:13:c0de::b" "45.143.83.66 2a02:4780:13:c0de::c" "45.143.83.67 2a02:4780:13:c0de::d" "45.143.83.68 2a02:4780:13:c0de::e" "45.143.83.69 2a02:4780:13:c0de::f" "45.143.83.70 2a02:4780:13:c0de::10" "45.143.83.71 2a02:4780:13:c0de::11" "45.143.83.72 2a02:4780:13:c0de::12" "45.143.83.73 2a02:4780:13:c0de::13" "45.143.83.74 2a02:4780:13:c0de::14" "45.143.83.75 2a02:4780:13:c0de::15" "45.143.83.76 2a02:4780:13:c0de::16" "45.143.83.77 2a02:4780:13:c0de::17" "45.143.83.78 2a02:4780:13:c0de::18" "45.143.83.79 2a02:4780:13:c0de::19" "89.116.146.65 2a02:4780:27:c0de::b" "89.116.146.66 2a02:4780:27:c0de::c" "89.116.146.67 2a02:4780:27:c0de::d" "89.116.146.68 2a02:4780:27:c0de::e" "89.116.146.69 2a02:4780:27:c0de::f" "89.116.146.70 2a02:4780:27:c0de::10" "89.116.146.71 2a02:4780:27:c0de::11" "89.116.146.72 2a02:4780:27:c0de::12" "89.116.146.73 2a02:4780:27:c0de::13" "89.116.146.74 2a02:4780:27:c0de::14" "89.116.146.75 2a02:4780:27:c0de::15" "89.116.146.76 2a02:4780:27:c0de::16" "89.116.146.77 2a02:4780:27:c0de::17" "89.116.146.78 2a02:4780:27:c0de::18" "89.116.146.79 2a02:4780:27:c0de::19" Now while I myself don't particularly care about credit farming on RIPE Atlas (After all RIPE Atlas credit is kind of like Monopoly money), I do care about things becoming biased towards these software probes. For example, when I had selected for a selection of probes in Brazil I ended up with several of these software probes giving me the exact same results. this is not very useful and this has the potential to bias academic measurements, had I not looked at the probe list results this would not have been immediately obvious. Is there an immediate way to report these probes other than this mailing list? I don't know of one and so I'm here :) Cheers Ben

12 17

ICMP error codes in measurement results
by Marco Moock 25 Apr '24

25 Apr '24

Hello! https://atlas.ripe.net/measurements/70248021#probes That should display route to dest rejected (ICMPv6 Type 1 Code 6), but only shows Last hop's response(s): `6, 6, 6`. Is it intended to implement that? -- kind regards Marco Send unsolicited bulk mail to 1713939075muell(a)cartoonies.org

3 2

Another research credit request
by Peter Thomassen 24 Apr '24

24 Apr '24

Dear friends of ATLAS, We're conducting a research project [1] involving ATLAS measurements with multiple PQC signing implementations (Falcon, XMSS, Dilithium, Sphincs+) to see how many clients choke, in various scenarios, depending on the response packet properties that come with such responses. The idea is to help inform how good or bad the situation is, and which aspects need further research. We'd like to do a very comprehensive measurement, and expect our measurements to use around 25M credits total. (We currently have 3M.) If anyone is willing to donate the missing amount to this project, that would be very much appreciated! My RIPE account is peter(a)desec.io. Thank you very much for considering and your generosity! Best, Peter [1]: https://nlnet.nl/project/PQ-DNSSEC-Testbench/ -- https://desec.io/

7 6

Banner stacked in latest results of measurement
by Marco Moock 24 Apr '24

24 Apr '24

Hello! When hovering on the ticks/crosses in the success column on the latest results page of a measurement, a banner is being displayed. This banner isn't going away when moving the mouse and a new banner will be place on the old one when hovering another cross/tick and make both unreadable. This happens in Pale Moon and Chromium. Can other confirm this? https://atlas.ripe.net/measurements/70021438/#probes See screenshot. -- kind Marco Send unsolicited bulk mail to 1713940405muell(a)cartoonies.org

1 0

Operational work on RIPE Atlas
by Robert Kisteleki 23 Apr '24

23 Apr '24

Dear all, A heads-up: we are just about to start scheduled maintenance work on RIPE Atlas. During the maintenance we expect scheduling of new measurements will be delayed and searching for measurements will not yield up-to-date information. Regards, Robert

1 0

Request RIPE Atlas Credit for Research
by Rolland 18 Apr '24

18 Apr '24

Hi all, I am sorry to spam this email. My name is Fengyan Han, a master's student at Tsinghua University, China. Recently, my research on RPKI requires conducting a large-scale measurement via RIPE Atlas. I have some credits but still need 50M more credits to carry out my study. unfortunately, time constraints prevent me from earning them myself. Therefore, I am reaching out here to ask for assistance. Is there anyone generous enough to offer me some RIPE Atlas credits (like, 1 million?) My account at RIPE NCC is hfy23(a)mails.tsinghua.edu.cn <>. Many thanks in advance! Regards, Fengyan Han

4 3

New default settings for Atlas measurement form
by Stephen Suess 17 Apr '24

17 Apr '24

Hello Atlas users, After an analysis of usage patterns in measurement creation, we have rolled out a couple of changes to the defaults in the measurement form (https://atlas.ripe.net/measurements/form/): - Under timing, the default is now one-off (instead of periodic as before) - Default probe selection is now 50 random, worldwide probes (instead of 10 as before) We hope you find these useful. Please let us know if you encounter any issues. Thanks! Stephen RIPE Atlas UI

4 7

Reverse traceroute
by Hank Nussbacher 16 Apr '24

16 Apr '24

https://pulse.internetsociety.org/blog/reverse-traceroutes-help-troubleshoo… "Measure at least one reverse path from 39,544 Autonomous System (AS) destinations, which host 92.6% of Internet users. As a comparison, RIPE Atlas vantage points can measure from 4,344 AS destinations, representing 67.1% of the Internet user base." Has anyone tried this and indeed found better visibility via their system? Thanks, Hank

3 2

Wohoo: Your RIPE Atlas Probe (ID: 12724) has reconnected
by Gert Doering 09 Apr '24

09 Apr '24

Hi, wohoo, "I'm back" notifications!! Thanks very much to whoever silently implemented this :-) (this was a provider outage, and the probe was indeed offline and came back, so when I got up I found the "it's back, all is well" note already in my mail). If you're bored and want to optimize this: add an "In-Reply-To:" to the original "it's gone"-mail, so there is threading (in case you only see the original mail when it's already back)... cheers, gert ----- Forwarded message from RIPE Atlas <no-reply(a)ripe.net> ----- Date: Tue, 09 Apr 2024 05:00:00 -0000 From: RIPE Atlas <no-reply(a)ripe.net> To: gert(a)space.net Subject: Your RIPE Atlas Probe (ID: 12724) has reconnected Dear RIPE Atlas probe host, We're just letting you know that your probe (#12724 ) has re-established its link to our network and we are again receiving data from it. For your own records, it appears that the reconnection took place at . If you have any questions, please contact us at atlas(a)ripe.net. Thank you for supporting RIPE Atlas. Best regards, RIPE Atlas Team ********** You can change your notification settings on your probe page (go to "My Atlas" and then "Probes" when logged into the RIPE Atlas website). ----- End forwarded message ----- -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 0

Understanding participating probes and probe requests
by Malte Tashiro 08 Apr '24

08 Apr '24

Hi, I'm currently looking at measurement metadata and am a bit confused about the different ways of getting the number of probes participating in a measurement and the number of probes requested by the user. I'd like to know how to... 1. get the number of probes _currently_ participating in a measurement (for ongoing measurements) 2. the number of probes that participated when the measurement finished (for stopped measurements) 3. the number of probes a user requested over the lifetime of a measurement The default response to /measurements returns a participant_count and a probes_requested value. However, there are also the optional fields current_probes and participation_requests and these do not add up. For example, this [0][1] measurement (not mine) has a participant_count of 0 (showing as "Actually Participating: None") in the web interface, but one probe listed in current_probes, which shows up in the "Latest Results" list and is still performing measurements (at least while writing this). So it seems like the current_probes list is more accurate to get the number of probes _currently_ (or when the measurement finished) participating in a measurement? Similarly, there are 35 probes_requested, which equals the sum of "requested" probes from the participation_requests, however, some request are actually "remove" actions, which should not be included in this count? Any hints on how to interpret these fields? I think the requested probes and participation requests are more a problem for long-running measurements, but the participant count is sometimes weird for one-offs as well. Thanks, Malte [0] https://atlas.ripe.net/measurements/67903255 [1] https://atlas.ripe.net/api/v2/measurements/67903255?optional_fields=current…

2 1