- ripe-atlas - mailman.ripe.net

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

Updating software probe version (with .deb package)
by Seth David Schoen 31 Dec '22

31 Dec '22

Hi, I have a software probe which I installed by creating a Debian package from source (as described in INSTALL.rst). The documentation suggests that one should regularly update software probe versions, and I'm interested in upgrading mine -- I was reminded by my earlier question about 240/4, as I may be running a client version from prior to when the patch allowing 240/4 scans was merged. The documentation doesn't specifically mention how to upgrade; can I assume that making a new .deb from current sources, and then installing that with dpkg on a machine where an older .deb is installed, will maintain the credentials and identity of my existing probe? It won't wipe everything out and require me to re-register as a new software probe, right?

2 1

Proposal: Measure well-known CDNs,[CDN-HTTP]
by Robert Kisteleki 30 Dec '22

30 Dec '22

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

8 9

Re: [atlas] DNS issue
by Mezgani Ali 30 Dec '22

30 Dec '22

> Hello, > > > I set my probe and I got a problem with DNS. > > Please what figure out on my probe ? Maybe I have to set other DNS address into my ADSL Router. > > Any query are welcome. Regards, > > > > Mezgani Ali's home > General > <https://atlas.ripe.net/frames/probes/63005/#tab-general>Network > <https://atlas.ripe.net/frames/probes/63005/#tab-network>Built-ins > <https://atlas.ripe.net/frames/probes/63005/#tab-builtins>UDMs > <https://atlas.ripe.net/frames/probes/63005/#tab-udms>Status (beta) > <https://atlas.ripe.net/frames/probes/63005/#tab-status> > General InformationEdit <https://atlas.ripe.net/frames/probes/63005/form-fragment/general/> > Id 63005 > MAC Address D8:58:D7:03:02:C0 > Architecture atlas-mox > Firmware Version None > Router Type > Bandwidth Limit Not set > DNS Entry Simple: > p63005.probes.atlas.ripe.net <http://p63005.probes.atlas.ripe.net/> > Shared Publicly Yes > User Tags <https://atlas.ripe.net/docs/getting-started/probe-tags.html#user-tags> Mobile Datacentre IPv6 Tunnel IPv66to4 ADSL VPN Native IPv4 IPv6-onlyDocker > System Tags <https://atlas.ripe.net/docs/getting-started/probe-tags.html#system-tags> V5 DNS problem suspected > <https://atlas.ripe.net/frames/probes/63005/ripestat/9002/> > Connection & Traffic > > > Connected Time 3 months > > Management SharingEdit <https://atlas.ripe.net/frames/probes/63005/form-fragment/sharing/> > Currently you're not sharing this probe within your LIR. > > The management of this probe is not allowed for any other individuals. > > NotificationsEdit <https://atlas.ripe.net/frames/probes/63005/form-fragment/notifications/> > There aren't any downtime notifications configured for this probe. > There aren't any uptime reports sent for this probe. > Transfer OwnershipEdit <https://atlas.ripe.net/frames/probes/63005/form-fragment/transfer/> > You can transfer ownership of the probe to someone else by submitting this form. Note that this change cannot be undone. > > 3 months > #63005 > Firmware > None > Architecture > atlas-mox > MAC Address > D8:58:D7:03:02:C0 > Update Location <https://atlas.ripe.net/frames/probes/63005/location/> > <3939.jpeg><3940.jpeg><3939.jpeg><3940.jpeg><3939.jpeg><3940.jpeg> > <a51052730657106d6f160440dd590bec.png> > + > <https://atlas.ripe.net/probes/63005/#>- > <https://atlas.ripe.net/probes/63005/#>Leaflet <http://leafletjs.com/> | Tiles © Esri > Kind regards, > > Mezgani Ali > ali.mezgani(a)nativelabs.ma <mailto:ali.mezgani@nativelabs.ma> > https://wiki.debian.org/mezgani <https://wiki.debian.org/mezgani> > > ⢀⣴⠾⠻⢶⣦⠀ Active member of IETF, GNU, Debian, FreeBSD and Kernel. > ⣾⠁⢠⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋⠀ > ⠈⠳⣄⠀ > > > >> On 30/12/2022, at 17:54, Gert Doering <gert(a)space.net <mailto:gert@space.net>> wrote: >> >> Hi, >> >> On Fri, Dec 30, 2022 at 08:42:18AM -0800, Randy Bush wrote: >>> i asked this quietly before, but let me be more direct. >>> >>> how much private data is there actually? what percentage of the stored >>> data is private? >> >> Indeed, this is a good question. If it turns out that there is a lone >> private measurement from me, or "in the sub-percent range", I'm willing >> to let myself be convinced in the name of "make the measurement backend >> more simple = robust"... >> >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> -- >> ripe-atlas mailing list >> ripe-atlas(a)ripe.net <mailto:ripe-atlas@ripe.net> >> https://lists.ripe.net/mailman/listinfo/ripe-atlas >

1 0

Probe 24434 down but pingable
by Dave 30 Dec '22

30 Dec '22

Hi, One of my probes is pingable but the status is disconnected for over a day. Could it be that it has troubles with DNS over IPv6 and that it is not smart enough to fall back to IPv4? https://atlas.ripe.net/probes/24434/#tab-general Thanks, Dave

3 4

Re: [atlas] A number of built-ins stopped?
by Ernst J. Oud 23 Dec '22

23 Dec '22

L.S. All the probes in NL that I had a look at, in a variety of different ASN’s, have no data available via the Atlas web of via the api (JSON, Magellan) for a.o. built-in measurement 1009 (ping to a.root-servers.net) and several others after December 22nd, around 18:00 hrs. UTC. When I have a look at German probes there is data available. This thus appears to be a problem with all and only Dutch probes’ data. A normal ping via a Windows command line works fine, i.e. a.root-servers.net is reachable. Creating a ping measurement via Magellan to a.root-servers.net using Dutch probes generates results, i.e. the probe infrastructure works but data storage does not, for data from probes in NL. Rather serious problem I guess. No mentioning on status.ripe.net though. Had an email conversation with Robert from the Atlas team today. No solution yet. Regards, Ernst J. Oud Met vriendelijke groet, Ernst J. Oud

2 1

Apologies for OOO reply
by Guy Meyer 23 Dec '22

23 Dec '22

Hi all, As some of you might have seen, something went wrong with my out-of-office email settings, and I'm sorry that you received the email multiple times. We're cleaning up the mailing list, and I wish you all happy holidays and a great year ahead. Kind regards, Guy Meyer

1 0

A number of built-ins stopped?
by Ernst J. Oud 23 Dec '22

23 Dec '22

Hi, Both on the atlas webpages as via the api, data for a number of built-ins stop at December 22th, at around 18:00 UTC for all my probes in 4 different ISP’s, all in NL. For instance measurement 1009, ping to a.root-servers.net stopped at that time while measurement 1010, ping to b.root-servers.net continues normally. Also stopped are: #1017 Ping to ctr-nue13.atlas.ripe.net #1012 Ping to d.root-servers.net #1013 Ping to e.root-servers.net #1015 Ping to h.root-servers.net #1005 Ping to i.root-servers.net Any idea what is causing this? Regards, Ernst J. Oud

1 0

Proposal: Generic HTTP measurements [GENERIC-HTTP]
by Robert Kisteleki 22 Dec '22

22 Dec '22

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

3 2

Low cost, low energy consumption probe
by Ernst J. Oud 21 Dec '22

21 Dec '22

Hi, I have probes running on VMware (CentOS), Ubuntu (native) and on Docker for Windows. These small PC’s consume a lot more than the Ripe supplied HW probes. So I looked for a cheap and *very* low energy alternative. TP-Link sells the WR802N mini travel router for around USD 20 (o.a. on Amazon) that runs the latest version of OpenWRT fine and the Atlas probe SW has been ported to it. With some acrobatics I managed to turn it into an excellent alternative. Runs fine, energy consumption 700 mW (!). The device is as small as the Ripe supplied probe. Since the flash memory of this device is too small for some of the required libraries, the acrobatics involved copying them to RAM and putting links to them in flash. This means that with FTP after a power outage a couple of files need to be copied to the device and that one command must be given after that. There is a more expensive version with a USB port so that a USB stick can be used to store those files. Will investigate that option. If someone here wants a detailed write-up let me know and I will invest the time to write it. Regards, Ernst J. Oud

3 4