December 2024 - 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

Re: Changes to RIPE Atlas API keys
by Ponikierski, Grzegorz 26 Feb '25

26 Feb '25

Hi! > * We'll deprecate and remove the ability to use the URL form in about a > year (around October 2024). > * We plan to send further reminders about this change over time, as well > as reaching out to heavy users of the to-be-removed format. It’s October 2024. Is this plan still valid? I admit that I have a bunch of tools which use URL form which I would have to update to use "Authorization" header. Regards, Grzegorz From: Robert Kisteleki <robert(a)ripe.net> Organisation: RIPE NCC Date: Tuesday, 19 September 2023 at 12:11 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Changes to RIPE Atlas API keys Dear RIPE Atlas users, We'd like to update you on some upcoming changes regarding API keys in RIPE Atlas. TL;DR nothing changes regarding how you can use your API keys in the short term - as long as you're actually using them. However, we'll change how unused or forgotten keys are handled as well as remove the less secure in-URL use of them. At the moment RIPE Atlas users can query their existing API keys via the UI and API, including the possibility to retrieve old keys. In order to improve the security of how we handle these, we'll introduce the following changes in October 2023: * The listing (retrieval) of keys will only reveal parts of the keys (enough to identify them) in the API as well as in the UI. * We'll add the ability to "regenerate" an API key, which will replace the secret UUID of the key while keeping exactly the same permissions. * Unused API keys will automatically be frozen after 1 year of not being used. Active keys (i.e. the ones that have been used at least once) will not be frozen. You still have the ability to save your keys until these changes are done and, as written above, you will be able to regenerate them later. We'll notify this list when the changes are about to be done. In addition, in order to further increase the security of our system, in the long run we'll make changes about how these API keys are communicated to the API: * At the moment the API accepts these either in HTTP headers ("Authorization" header) or in the URL (?key=xyz), although the Authorization header version has been documented as the preferred version for some time. * We'll deprecate and remove the ability to use the URL form in about a year (around October 2024). * We plan to send further reminders about this change over time, as well as reaching out to heavy users of the to-be-removed format. Regards, Robert Kisteleki RIPE Atlas team -- ripe-atlas mailing list ripe-atlas(a)ripe.net<mailto:ripe-atlas@ripe.net> https://urldefense.com/v3/__https://lists.ripe.net/mailman/listinfo/ripe-at…<https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atl…>

2 5

Why measurements using api are apt to fail while those using web interface can usually succeed?
by 孙乐童 02 Feb '25

02 Feb '25

Dear all, I have been attempting to use Atlas to launch traceroute measurements recently. Initially, I used ripe.atlas.cousteau to run the measurements in batches, keeping the total number under 10,000 to avoid exceeding the measurement limit. However, only 10% of the measurements returned successful results, while the other 90% showed the status "scheduling denied." Next, I tried launching only 12 measurements in batch, where each measurement contained one traceroute from a specific probe to a designated IPv4 destination. Out of these, 4 succeeded and the other 8 showed the status "specified". Following that, I launched the 12 measurements one by one with 2-second intervals, resulting in a success rate of 6 out of 12. However, when I increased the interval to 3 seconds, the success rate dropped to 4 out of 12. Interestingly, when I created the same measurements for the designated probes and destinations through the web interface, all of them were successful. Below is the Python code I used to launch the measurements: fromripe.atlas.cousteauimport ( Traceroute, AtlasSource, AtlasRequest, AtlasCreateRequest, AtlasResultsRequest, AtlasLatestRequest, ProbeRequest ) traceroute=Traceroute(af=4, target=dstip, description="traceroute subpref ip {} from {}{}".format(dstip, probe_type, probe_value), protocol='ICMP') if probe_type =='asn': probe_value =int(probe_value) source = AtlasSource(type=probe_type, value=probe_value, requested=1, tags={"include": ["system-ipv4-capable"]}) _key = ATLAS_API_KEY_2 for _ inrange(2): atlas_request = AtlasCreateRequest( start_time=datetime.utcnow() + timedelta(random.randint(0, 1)), key=_key, measurements=[traceroute], sources=[source], is_oneoff=True ) (is_success, response) = atlas_request.create() if is_success: print('create_task', dstip, is_success, response) msm_id = response['measurements'][0] return Could you kindly let me know if there might be an issue with my approach or provide any advice on how to improve this process? I would greatly appreciate any guidance. Thank you very much! Best regards, Sun Letong

4 7

Schroedinger's AAAA?
by Peter Eckel 28 Jan '25

28 Jan '25

I have a strane effect with probe 10293. Under "System Tags" I have both "Resolves AAAA Correctly" and "Resolves AAAA Incorrectly" listed. Apparently only one of the tags can be correct - or am I missing something? Best regards and seasonal wishes, Peter.

5 4

Probe on ctr-dub-hw01 disconnected
by Ernst J. Oud 25 Dec '24

25 Dec '24

Hi, My probe 55795 disconnected from ctr-dub-hw01. Could it be that this controller has an issue? My other probes on other controllers are fine. Regards, Ernst J. Oud

2 4

Conflicting tags for resolver
by RIPE 22 Dec '24

22 Dec '24

Hi, I just noticed my probe (1008458) shows a strange status: System Resolves A or AAAA Records Incorrectly But looking at the tags I see both the resolves correctly and the resolves incorrectly tags are set for both A and AAAA. That looks like a strange combination of tags. Any idea what’s causing this ? Cheers, Paul

1 0

cannot forward src on fbsd
by Sulev-Madis Silber 21 Dec '24

21 Dec '24

i have fbsd box with pf that routes my traffic i get this endlessly: cannot forward src fe80:24::4e6d:580f:fc89:81ae, dst 2001:7d0:8437:13bf:da58:d7ff:fe 03:1274, nxt 58, rcvif vlan3, outif vlan91 cannot forward src fe80:24::4e6d:580f:fc89:81ae, dst 2001:7d0:8437:13bf:da58:d7ff:fe 03:1274, nxt 58, rcvif vlan3, outif vlan91 cannot forward src fe80:24::4e6d:580f:fc89:81ae, dst 2001:7d0:8437:13bf:da58:d7ff:fe 03:1274, nxt 58, rcvif vlan3, outif vlan91 sometimes androids do this a few times, but probes do it all the time. multiple hw ver probes. for a decade i get few obscure results when i look that up but don't know what this is or why i tried to sniff and iirc i found weird icmp ttl exceeded packets i think kernel is correct on that cannot forward part. i'm unsure what measurements my probes actually run the src is apparently some linklocal, dst is my probe v6, recv if is vlan3, this is my v4/v6 wan to isp, out is vlan91, this is dedivated v5 probe vlan in local network did i misconfigure something or isp or ripe or else or? does it affect measurements? i'm not sure what this issue is. i think you can't forward that traffic indeed, from ll ip to global ip? google doesn't help to even shed some light on this weird behaviour, let alone any fix doesn't bother me, just curious i'm not surprised, as this device sends and receives traffic i don't have any control of. and is specifically ip measuring device so, unsure... about all this!

1 0

Requested and participating probes
by Huseyn Gambarov 13 Dec '24

13 Dec '24

Hello. I am currently working on a project that heavily relies on Ripe Atlas Ping measurements. During the development, I noticed that sometimes when, let’s say, I request 3 probes, only 2 are participating in the measurement. In the Ripe Archive, I found that there was a similar discussion here - https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/thread/D6QZS4WC5… I have two questions, that I could not find answers to, and I would be very grateful if you could help me with them. First, in the mentioned discussion it is said that there are multiple reasons why fewer probes are participating and there is ongoing work to allow users to obtain information about specific conditions that occurred during the measurement creation. Can you tell, if there is a way to get that information via API? Second, do you know if there is a reasonable timeout to wait before a new attempt to reschedule the probe that failed to participate in the first measurement? Thank you for your help. With regards, Huseyn Gambarov.

2 1

Understanding how to use the `paris` parameter
by Bhaskar, Abhishek Vasisht 13 Dec '24

13 Dec '24

Hello y'all! I'm a PhD student from Georgia Tech and had a question about the "paris" field when performing traceroute measurements. The RIPE documents states that ```Paris - A number greater than 0 will indicate the number of variations to be used for a Paris traceroute. Setting the value to 0 makes the measurement use the standard traceroute``` But regardless of what Paris value I give to the traceroute measurement, I only get one path with a single paris_id. I would expect that if I gave a paris value of 10, I should see 10 potential variations of the path between A and B, correct? Please correct me if I'm wrong. Here is an example measurement https://atlas.ripe.net/measurements/84562046 Thanks! -- Abhishek Vasisht Bhaskar Student, PhD in Computer Science Georgia Institute of Technology https://abhishekvasishtb.github.io/

1 0

MTU tracepath in RIPE atlas
by Marco Moock 12 Dec '24

12 Dec '24

Hello! Maybe some people here know the Linux tracepath application. It tests the PMTU to a destination. Could such a feature be implemented in RIPE Atlas? -- kind regards Marco Send unsolicited bulk mail to 1734020167muell(a)stinkedores.dorfdsl.de

1 0