January 2023 - ripe-atlas - mailman.ripe.net

Verdien 3.0.3
by Ernst J. Oud 07 Sep '23

07 Sep '23

Hi, @Chris Amin: Yes, commit c999953, version 3.0.3 completely solves this. My gratitude is larger than the losses Mr. Musk is making now that Twitter is going down the drain :-) Thanks! Regards, Ernst J. Oud

5 4

Requesting Credits for Research
by Alex Gamero-Garrido 29 Jul '23

29 Jul '23

Hi folks, My name is Alexander Gamero-Garrido and I'm a 5th year PhD student at CAIDA, UC San Diego. We're soon launching a large traceroute campaign for research and could use your generous donation of credits. We'll need about 150 million credits, but any partial amount that gets us closer to that goal is welcome and greatly appreciated. My account is agamerog at eng.ucsd.edu Thank you, Alex -- *Alex Gamero-Garrido* *PhD Student, Computer Science* Web: cseweb.ucsd.edu/~agamerog Center for Applied Internet Data Analysis (CAIDA) San Diego Supercomputer Center UC San Diego Pronouns: He/Him/His <https://inboxwhenready.org/?utm_campaign=signature&utm_medium=email&utm_sou…> I'm using Inbox When Ready <https://inboxwhenready.org/?utm_campaign=signature&utm_medium=email&utm_sou…> to protect my focus.

13 15

Probe DHCPv6 support
by Aleksi Pirttimaa 19 May '23

19 May '23

Hi! I recently received my v4 probe and I'm very happy with it. But unfortunately it doesn't support DHCPv6. I present a practical reason for implementing a DHCPv6 client on the probe. You see, my ISP doesn't send router advertisements with the prefix for stateless autoconfiguration set, and instead DHCPv6 must be used. I believe their decision could have something to do with the fact that the regulating body here requires ISP's to prevent IP address spoofing in consumer plans. And to meet that requirement my ISP may be using a feature similar to Cisco's IP source guard, where switch ports and/or mac addresses are passively associated to leased ip's or prefixes, breaking SLAAC. Unfortunately they hate letting consumers talk with their engineers so it's difficult to speculate this further. For now, I've put a stateful firewall appliance in front of the probe which provides SLAAC, it works just fine. Do you think a DHCPv6 client should be implemented?

8 13

Missing ping and traceroute dumps for 2023-01-23
by Maxime Mouchet 15 Feb '23

15 Feb '23

Hi, I noticed that there is no ping and traceroute dumps for 2023-01-23: https://data-store.ripe.net/datasets/atlas-daily-dumps/2023-01-23/ The other days are fine though. Is there any chance to get these dumps? Or are they just lost? Thanks! Maxime

2 3

Rate limiting on the APIs
by Robert Kisteleki 06 Feb '23

06 Feb '23

Dear all, We have seen in the past that even with the best intentions, every now and then some users are using excessive amounts of requests to the RIPE Atlas APIs, in some cases resulting in degraded performance to all users. An example for the curious: some AWS account asking the probe API for live queries once a day at 8am like clockwork; over a million queries for probe statuses (note: we don't have a million probes - every query is repeated hundreds or thousands of times) [1] We will apply rate limiting to protect from (some of) these. In particular: * The API in general will impose a limit of no more than 300 queries/second (if done over multiple connections) * The measurement API in particular will impose a limit of 150 queries/second (if done over multiple connections) * When reaching the limit, an HTTP response code of 429 (Too Many Requests; https://www.rfc-editor.org/rfc/rfc6585#section-4) will be given. According to our logs these limits will in general not be visible to users. Users going over these limits will see the 429 response code; client libraries should be able to handle this. We will observe the effect of these measures to determine if we need to tighten further - or perhaps relax them. We plan to apply these changes sometime next week; I'll let you know once they are in place. Regards, Robert [1] a much better way of doing this is to use the probe archive (https://ftp.ripe.net/ripe/atlas/probes/archive/) this is one-time fetch of 2MB or so and probe statuses are pretty stable in general

1 1

Encouraging people to upgrade software probe versions
by Seth David Schoen 01 Feb '23

01 Feb '23

Hi, I recently posted two threads ultimately related to the same question, where it turned out that a feature I wanted to use was present in the current software probe release, but not in the old version that I had installed. It was indeed relatively easy to upgrade (as a reply on this list predicted, the upgrade didn't break anything or require any reconfiguration). But I'd still say "relatively easy", because, on the other hand, the upgrade wasn't managed through my OS package manager like the rest of the software on my VPS server. It appears to me that a lot of software probes (like mine was until recently!) are still running whichever software probe version was current when they were first deployed. After all, I don't believe there's automatic software upgrade functionality in the methods that most people are using to deploy these. Is that true from the point of view of the rest of the Atlas community? Is there anything that might usefully be done to encourage people to upgrade periodically? (For example, either sending some kind of e-mail reminder, or distributing probe software via OS package managers, or even including a mechanism in the probe client itself by which it could upgrade itself -- even if as an opt-in feature?)

10 28

Notification of brief downtime for anchor - ie-dub-as1213
by Mick O'Donovan 31 Jan '23

31 Jan '23

Hi all, I just wanted to give you a brief proactive notification that we, HEAnet, shall be taking our RIPE Atlas anchor called ie-dub-as1213 offline for a brief period as per the below to perform a network maintenance on the edge device it connects to. Date - 8th February 2023 Time - UTC 08:00 - 09:00 Regards, Mick -- Mick O’Donovan Senior Network Engineer HEAnet CLG Ireland's National Education and Research Network 1st Floor | 5 George's Dock | IFSC | Dublin D01 X8N7 | Ireland +353 1 6609040 | mick.odonovan(a)heanet.ie | www.heanet.ie Registered in Ireland, No. 275301 | CRA No. 20036270

1 0

Notification of brief downtime for anchor - ie-dub-as1213
by Mick O'Donovan 31 Jan '23

31 Jan '23

Hi all, I just wanted to give you a brief proactive notification that we, HEAnet, shall be taking our RIPE Atlas anchor called ie-dub-as1213 offline for a brief period as per the below to perform a network maintenance on the edge device it connects to. Date - 8th February 2023 Time - UTC 08:00 - 09:00 Regards, Mick -- Mick O’Donovan Senior Network Engineer HEAnet CLG Ireland's National Education and Research Network 1st Floor | 5 George's Dock | IFSC | Dublin D01 X8N7 | Ireland +353 1 6609040 | mick.odonovan(a)heanet.ie | www.heanet.ie Registered in Ireland, No. 275301 | CRA No. 20036270

1 0

Atlas anchors as ping targets
by Brian E Carpenter 30 Jan '23

30 Jan '23

Hi, I have a question about using Atlas anchors for a special purpose. Is the following acceptable, or would people have objections to the following idea? TL;DR: Is it OK to use Atlas anchors as random ping targets? Over in IETF-land we are (again) debating how to make IPv6 multi-provider multihoming work properly. There's a scenario description and picture at https://github.com/becarpenter/book6/blob/main/6.%20Management%20and%20Oper… One unsolved problem is that if one provider fails, many client applications may continue to use a source address belonging to that provider, instead of switching to a source address belonging to the other provider. One approach to solving this without any changes except in the host is to magically deprecate failing source addresses until they work again. One approach to that is a pure hack - a program that runs in the background pinging a remote target from various source addresses, to deprecate and undeprecate them as appropriate. There's code at https://github.com/becarpenter/misc/blob/main/deprecator.py. This is experimental software that might disturb network access. Would it be OK to choose the probe target by picking an Atlas anchor at random? (I have running code for that, but will not post it to github if there are objections.) I am quite sure that this code is only of interest to a few IPv6 geeks. It could of course be instrumented for measurement purposes, but multihomed sites of this kind are so rare that I don't think there would be much to measure. Regards Brian Carpenter

3 4

Access to probes and documents
by Mccherry, Paul (Postgraduate Researcher) 30 Jan '23

30 Jan '23

Althiough I am logged in when trying to access various probes I do not seem to have the rights, probes such as 91,353,365,3094.... Additionally I noticed I cannot access any documents on RIPE labs such as 'RIPE IPmap: geolocating routes across the internet' or 'Five proposals for a better RIPE Atlas.' Can anyone resolve these access rights please ? Regards Paul McCherry Phd Researcher Lancaster University

2 2

TLS Certificate probes fail ("handshake failure") against Vercel servers
by Daniel Kahn Gillmor 25 Jan '23

25 Jan '23

Hi RIPE Atlas folks-- I noticed today that using the "SSL" probe (gathering X.509 certificates from a TLS endpoint) appears to fail against servers operated by Vercel. the failure is a uniform "handshake failure" according to the web interface. I think this might be a bug in the probe's implementation of the client side of TLS. Where could i find the specific implementation of that probe type so that i can debug it further? Or, if this is a known issue, where can i read up on it in more detail? I've demonstrated this by probing Vercel's own servers, since they appear to be eating their own dogfood. You can see this with measurement 49131334: https://atlas.ripe.net/measurements/49131334/#probes here is the definition of the query i made: { "definitions": [ { "target": "vercel.com", "af": 4, "port": 443, "hostname": "vercel.com", "description": "SSL measurement to vercel.com", "resolve_on_probe": true, "skip_dns_check": false, "type": "sslcert" } ], "probes": [ { "type": "area", "value": "WW", "requested": 10 } ], "is_oneoff": true, } This is pretty odd, since normal TLS clients appear to be able to connect to them fine. Here's me running a manual handshake debugger against vercel.com's servers: $ gnutls-cli-debug vercel.com GnuTLS debug client 3.7.8 Checking vercel.com:443 whether the server accepts default record size (512 bytes)... yes whether %ALLOW_SMALL_RECORDS is required... no whether we need to disable TLS 1.2... no whether we need to disable TLS 1.1... no whether we need to disable TLS 1.0... no whether %NO_EXTENSIONS is required... no for TLS 1.0 (RFC2246) support... no for TLS 1.0 (RFC2246) support with TLS 1.0 record version... no for TLS 1.1 (RFC4346) support... no fallback from TLS 1.1 to... failed for TLS 1.2 (RFC5246) support... yes for TLS 1.3 (RFC8446) support... yes for known TLS or SSL protocols support... yes TLS1.2 neg fallback from TLS 1.6 to... failed (server requires fallback dance) for HTTPS server name... Vercel for certificate chain order... sorted for safe renegotiation (RFC5746) support... yes for encrypt-then-MAC (RFC7366) support... no for ext master secret (RFC7627) support... no for heartbeat (RFC6520) support... no for version rollback bug in RSA PMS... yes whether the server ignores the RSA PMS version... yes whether small records (512 bytes) are tolerated on handshake... yes whether cipher suites not in SSL 3.0 spec are accepted... yes whether a bogus TLS record version in the client hello is accepted... yes whether the server understands TLS closure alerts... yes whether the server supports session resumption... yes for anonymous authentication support... no for RSA key exchange support... no |<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice for ephemeral Diffie-Hellman support... yes |<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice for RFC7919 Diffie-Hellman support... no for ephemeral EC Diffie-Hellman support... yes for VKO GOST-2012 (draft-smyshlyaev-tls12-gost-suites) support... no for curve SECP256r1 (RFC4492)... yes for curve SECP384r1 (RFC4492)... yes for curve SECP521r1 (RFC4492)... yes for curve X25519 (RFC8422)... yes for AES-GCM cipher (RFC5288) support... yes for AES-CCM cipher (RFC6655) support... no for AES-CCM-8 cipher (RFC6655) support... no for AES-CBC cipher (RFC3268) support... no for CAMELLIA-GCM cipher (RFC6367) support... no for CAMELLIA-CBC cipher (RFC5932) support... no for 3DES-CBC cipher (RFC2246) support... no for ARCFOUR 128 cipher (RFC2246) support... no for CHACHA20-POLY1305 cipher (RFC7905) support... yes for GOST28147-CNT cipher (draft-smyshlyaev-tls12-gost-suites) support... no for MD5 MAC support... no for SHA1 MAC support... no for SHA256 MAC support... no for GOST28147-IMIT MAC (draft-smyshlyaev-tls12-gost-suites) support... no for max record size (RFC6066) support... no for OCSP status response (RFC6066) support... yes $ Thanks for any pointers, --dkg

2 2

Duplicate packet detection in traceroute results
by Ana Custura 20 Jan '23

20 Jan '23

Hi everyone, Just a question on how Atlas detects duplicate ('dup') packets in a traceroute. Is the 'dup' field added to a result when two received packets are exactly the same, regardless of whether they were received for a different initial TTL? Or are any packets that were unexpectedly received for a specific TTL marked as duplicates (e.g. if you receive 6 replies from 2 different IP addresses to the 3 initial packets sent with TTL 1, will 3 of these replies be marked as duplicates)? Thanks for your help! Regards, Ana

2 2

Re: [atlas] ripe-atlas Digest, Vol 137, Issue 8
by Geert Jan de Groot 19 Jan '23

19 Jan '23

On 09/01/2023 11:32, ripe-atlas-request(a)ripe.net wrote: > The hardware probes are fully managed by RIPE NCC, and their only purpose is to execute measurements. I agree here, whether to update is up to RIPE NCC. > On software probes, RIPE NCC is not in control of the unit. The software probe may run other services and updating is up to its local sysadmin. Consider operating system updates, which are updated by RIPE NCC on the hardware probes, but cannot be updated on software probes. > > To automatically update, the solution here is a simple CRON job which executes yum -q update atlasswprobe periodically (say once per day or so), which was the solution that was part of the RPM up to 5080. Would it help if we add this to the instructions? One question perhaps is if a probe running very obsoleted probe code, is useful or perhaps at some time probes older than version 1234 should not be used for pool measurements? For instance, release 2345 enables measurements on 240/12 while older releases, including release 2344, 240/12 is broken. Then, having probes with software 2344 or lower will give bias on measurements for 240/12. And for that reason I wonder if it makes sense to have a policy to "phase out" probes that are running obsoleted code, however well intended? Geert Jan

2 1

probes on mobile opérateurs
by Cristel Pelsser 13 Jan '23

13 Jan '23

Hello, We are looking for RIPE atlas probes that are connected to mobile operators. Could you drop me an email with the id of the probe if you have such a probe? We found some but would like to enlarge our study. Best regards, Cristel

4 3

Proposal: Remove support for non-public measurements [ONLY-PUBLIC]
by Robert Kisteleki 11 Jan '23

11 Jan '23

Dear RIPE Atlas users, We recently published a RIPE Labs article containing a few proposals: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. We'd like to encourage you to express your comments about this proposal (if you'd like to share them) here. Regards, Robert Kisteleki For the RIPE Atlas team

15 24

V3 Probe: USB Flash Drive Filesystem Corrupted
by ripe.net＠toppas.net 11 Jan '23

11 Jan '23

Hello, i have two v3 probes and i'm experiencing issues: "USB Flash Drive Filesystem Corrupted" I have tried multiple USB Sticks, including brand new ones and also sticks from "good" brands like Lexar and Sandisk. The issue is not permanent, the error appears and disappears from time to time: 2022-12-22 @ 12:14:04 UTC Probe auto-tagged Your probe #xxxxx was automatically tagged as "system: Flash drive filesystem corrupted" 2022-12-22 @ 18:14:42 UTC Probe auto-untagged Your probe #xxxxx was automatically untagged as "system: Flash drive filesystem corrupted" This leads me to the thought, that the flash storage is not the real problem. It's unlikely, since i tried multiple dongles. Could it be possible, that not the flash storage is broken, but the speed of the USB dongles is too low? All dongles I tried were USB 2.0, not 3.0, since the TP-Link TL-MR3020 is not USB 3.0 capable anyway. But maybe USB 3.0 is a better choice? What do you think? BR, Simon

2 6

Proposal: Add support for STARTTLS measurements [STARTTLS]
by Robert Kisteleki 09 Jan '23

09 Jan '23

Dear RIPE Atlas users, We recently published a RIPE Labs article containing a few proposals: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. We'd like to encourage you to express your comments about this proposal (if you'd like to share them) here. Regards, Robert Kisteleki For the RIPE Atlas team

4 3

Re: [atlas] Ability to traceroute to 240/4 - software vs. hardware probes
by Seth David Schoen 09 Jan '23

09 Jan '23

Hi! I noticed that Phillip Homburg merged a RIPE Atlas client patch in November of last year, based on our request, that removes the Atlas probe's inability to test addresses in 0/8 and 240/4. https://github.com/RIPE-NCC/ripe-atlas-probe-measurements/commit/59475f848b… So, I just tried a couple of measurements to 240.1.2.3 to see how Atlas would handle them: https://atlas.ripe.net/measurements/48100582/ https://atlas.ripe.net/measurements/48100585/ (I don't expect these to succeed, as no part of 240/4 is publicly announced in BGP; the interesting information to be garnered from this isn't whether the probes succeed, but how they fail.) For the first measurement, with ping, 6 hardware probes and 4 software probes all gave the same result: "Unreachable" (which is what you would get if you ran this on any ordinary Internet host with command-line ping). For the second measurement, with traceroute, 6 hardware probes all actually attempted the traceroute (getting failures after some small number of network hops), while 3 software probes all reported back "!address not allowed". What could account for the difference in how hardware and software probes handle this task? I would have thought that the change from last November would make software probes willing to attempt these.

2 2

Magellan report on built-in measurement 1
by Ernst J. Oud 09 Jan '23

09 Jan '23

Asked this question before but that post did not make it to the mailing list: Why can’t Magellan report on built-in measurement 1 (first hop)? It always shows “No packets found”. Met vriendelijke groet/Regards, Ernst J. Oud

2 1

Positively meant critique …
by Ernst J. Oud 09 Jan '23

09 Jan '23

LS. Is there a kind of common understanding what this mailing list is about? What its purpose is? I see important discussions such as those on private measurements but no conclusions… I ask questions that lead to response from a RIPE employee but not to answers/solutions… (For instance on why results from first hop measurement to ping.ripe.net cannot be reported on by Magellan.) Can RIPE give some explanation what the use for them is of this mailing list? Are there other entries into RIPE for support questions? Would some kind of forum not be a much better solution to discuss matters with probe “owners” instead of using old fashioned unstructured mailing lists… the way we did things when the internet was in its infancy? Regards, Ernst J. Oud

2 1

New version of the WR802N probe write-up
by Ernst J. Oud 04 Jan '23

04 Jan '23

L.S. Added a paragraph on security. Shame on me not adding that in the first version. Available at http://www.kineta.nl/atlas/wr802n-write-up-v2.pdf Regards, Ernst J. Oud

1 0

Use TP-Link WR802N as an Atlas probe
by Ernst J. Oud 04 Jan '23

04 Jan '23

Hi, I promised to create a write-up on how to turn the low cost, energy efficient, TP-Link travel router WR802N into a fully functional Atlas probe. This write-up is now available at: http://www.kineta.nl/atlas/wr802n-write-up-v1.pdf Might be an idea perhaps to also mention the document somewhere on the RIPE Atlas blog pages? My email address is on the last page of the document for any questions. In case you wonder, kineta.nl is the (very, very old) website of my company before I retired. The .pdf is malware free (at least that is what Microsoft Defender says). If your house burns down following the actions in the document don't blame me. Happy hacking. Regards, Ernst

3 2