- ripe-atlas - mailman.ripe.net

Filtering measurements
by Sanaa GHANDI 23 Apr '21

23 Apr '21

Hello, I hope you are all doing well. I have a few questions concerning the measurements selection, and I am interested only on the anchoring mesh measurements. In fact, for optimisation issues, I would like to be able to select only measurements of interest: For example, I want to get the results coming from sources: X and Y, and targeting the anchor 6771. Now I can get the measures targeting the anchor 6771 using this code from Altas Cousteau ################################################################## from ripe.atlas.cousteau import MeasurementRequest filters = {'tags': ['anchoring','mesh',6771] } measurements = MeasurementRequest(**filters) #################################################################### But I have no idea of how to make a filter on the sources as well, since all we can access through the measurements are the number of anchors requested and not their ids. Do you know a way to get access to the sources of a measurement via Atlas Cousteau or another Ripe Tool ? Thank you -- Sanaa

4 4

Custom box and bag
by Slite 22 Apr '21

22 Apr '21

Hello, Have a nice day. Does your company needs any Custom packaging box/bags for your products? We are Chinese supplier who can produce customized packaging/bag with custom logo. Dear,we have cartons,cardboard box,plastic box,metal tin box,paper bag,plastic bag,non-woven bag ... to pack your products. Then tell me which one you want,I will give you best price with good service. Any of your reply will be appreciated. Looking forward to your reply. Best regards, Slite Contact Email: slite(a)slcpackage.com What's app: 0086 15314679598SLC-PACKAGE CO. LTDwww.slcpackage.com www.slcpackages.comContact Person: Slite Cao Address:1406, No 11,Dongyue Huayuan,Nancheng,Xinluo,Longyan,Fujian,China If you no longer wish to receive mail from us, you can <http://tracking.littleindustrial.info/tracking/unsubscribe?d=hV-G-DkT38mtq2…> Unsubscribe

1 0

Request for credits for research
by Mohan, Nitinder 20 Apr '21

20 Apr '21

Dear RIPE community, I hope you are all safe and sound. I am a Postdoctoral fellow at the Technical University of Munich, Germany. We are currently working on an ongoing research project which aims to analyze the availability and reachability of cloud data centers globally. The first work of our work will appear in ACM HotNets 2020 titled "Pruning Edge Research with Latency Shears" (http://conferences.sigcomm.org/hotnets/2020/program.html). We are currently preparing the camera-ready version of the paper and will share it with the community by hosting it (and the associated dataset) publicly soon. We are currently planing to submit the second leg of our work to a conference with submission deadline a month. In order to complete all set of measurements for required analysis, we are scheduling very large-scale measurements over the platform which has burned through almost all our credits and left us in need. I have always found the RIPE Atlas community to be helpful and generous towards research and I am hoping that you could support our research by donating us some of your spare credits. Your help will be highly appreciated. My RIPE account is nitinder.mohan(a)helsinki.fi Thanks and Regards Nitinder Mohan Postdoctoral Fellow Technical University of Munich, Germany <http://www.cs.helsinki.fi/u/nmohan/>https://www.nitindermohan.com/

15 18

Feature request for Validated Timestamps
by Will 15 Apr '21

15 Apr '21

I was starting to work on a mapping measurement project where I wanted to delegate measurements to remote machines. There are a number of schemes that have been used where a not fully trusted node can come away from a measurement with a record that can be used to verify that it actually made the measurement. Many of these make use of a time stamp signed by the "server" as a way to prevent replaying old measurements. Things that have been done with this feature also include tlsnotary[1], which works with web servers where the "server random" bytes of the tls handshake includes the server timestamp (the default for openssl). The implementation of ssl currently used by probes does not appear to include the timestamp in the server hello. Another approach would be to add a "roughtime" service on probes Interested to hear if there would be willingness to have probe software support something in this direction. [1] https://tlsnotary.org/ --Will

5 9

Spurious "would violate your maximum daily spending limit"
by Stephane Bortzmeyer 07 Apr '21

07 Apr '21

I receive a: {"error":{"detail":"There was a problem with your request","status":400,"title":"Bad Request","code":102,"errors":[{"source":{"pointer":""},"detail":"Executing this measurement request would violate your maximum daily spending limit of 1000000.0 credits. Please stop some of your currently running measurements and try again."} from the API. The request is: {'is_oneoff': True, 'definitions': [{'description': 'DNS resolution of use-application-dns.net./A from AS #3215', 'af': 4, 'type': 'dns', 'query_argument': 'use-application-dns.net.', 'query_class': 'IN', 'query_type': 'A', 'set_rd_bit': True, 'protocol': 'UDP', 'use_probe_resolver': True}], 'probes': [{'requested': 100, 'type': 'asn', 'value': '3215', 'tags': {'include': ['system-ipv4-works', 'system-resolves-a-correctly', 'system-resolves Which is very small. I run this sort of requests frequently. My daily expenditure is small (13,680 credits). Why is it rejected?

3 5

What to do with broken v1 probe?
by Lorenzo Colitti 30 Mar '21

30 Mar '21

Fellow atlas users, After more than 10 years (!) of 99% uptime (see below), my probe v1 appears to have given up the ghost. When connected to power, the lights still come on, but after a few seconds link bounces, and it never sends any packets. Any idea what to do? Should I just apply for a new probe? Are new probes being given out these days? Cheers, Lorenzo ---------- Forwarded message --------- From: RIPE Atlas <no-reply(a)ripe.net> Date: Tue, Nov 24, 2020 at 9:59 PM Subject: Congratulations! Your RIPE Atlas probe 333 is 10 years old! To: Lorenzo Colitti <lorenzo(a)colitti.com> Dear Lorenzo Colitti, It's your probe's birthday today !! To celebrate that fact, we are giving you 9869024 credits to use for scheduling your own measurements. In the last 10 years your probe was connected for 99% of the time. Happy measuring and thank you on behalf of everyone at the RIPE NCC and the other RIPE Atlas users. The RIPE Atlas Team

7 6

Re: [atlas] Probe location obfuscation
by Ponikierski, Grzegorz 26 Mar '21

26 Mar '21

I would add to it additional problem that some hosts obfuscate probe location even more. For example you can find probes which in reality are located in US but are marked as CN or probes which are in reality in Wisconsin but are marked in California. Of course these are extreme cases. I guess most hosts just put a pin with probe location just somewhere around where it's locate as long it's in the same city. I don't remember, as a host of 3 probes, to get any precise recommendations how to mark probe location. Personally I just put a pin in city district where probe is locate. Regards, Grzegorz From: "Mccherry, Paul (Student)" <p.mccherry(a)lancaster.ac.uk> Date: Thursday 2021-03-25 at 11:20 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Probe location obfuscation Can anyone confirm the geo-location obfuscation of probes as being up to 1km as per https://atlas.ripe.net/about/faq/#are-the-locations-of-probes-made-public<https://urldefense.com/v3/__https:/atlas.ripe.net/about/faq/*are-the-locati…> I am a Phd student carrying out research on the RIPE atlas platform and an early result seems to indicate 1 probe has an obfuscation of 10km distance but this may be an anomaly or perhaps something not taken into account as yet.

10 13

Unused Probes (was: What to do with broken v1 probe?)
by Sylvain Baya 25 Mar '21

25 Mar '21

{change the subject [0]} Dear all, Hope you are doing well! Le lun. 22 mars 2021 10:35, Estelmann, Christian <c.estelmann(a)gmx.net> a écrit : > Is there a possibility to return no longer used probes? Hi Christian, Thanks for your email brother. ...imho, it's a very useful idea! Within one [1] of our NOG's activities we have included the recovery of unused probes ; but maybe we should have tried it the other side...by asking probe's hosters to send it to an other volunteer or to us, if they become unable to keep it online... __ [1]: FR <https://www.cmnog.cm/dokuwiki/IdeasAndProjects:Projects:AtlasCM> I have one which was homed at a now closed location. Someone else could > give it a new home. > ...i suggest that you write to your ccNOG's mailinglist to find the nearest volunteer who could want to host your protected probe ;-) ...hope this could help. Blessed thursday! __ [0]: <https://lists.ripe.net/pipermail/ripe-atlas/2021-March/004638.html> Shalom --sb. > Greeting, > Christian > > Am 21. März 2021 17:14:57 MEZ schrieb Chriztoffer Hansen <ch(a)ntrv.dk>: > >On Sun, 21 Mar 2021 at 08:18, Lorenzo Colitti via ripe-atlas wrote: > >> After more than 10 years (!) of 99% uptime (see below), my probe v1 > >appears to have given up the ghost. [...] > >Cheers, > >Chriztoffer > > -- -- Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]|<www.cmnog.cm/dokuwiki> Subscribe to Mailing List: <lists.cmnog.cm/mailman/listinfo/cmnog/> __ #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!» ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬ «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)

1 0

Probe location obfuscation
by Mccherry, Paul (Student) 25 Mar '21

25 Mar '21

Can anyone confirm the geo-location obfuscation of probes as being up to 1km as per https://atlas.ripe.net/about/faq/#are-the-locations-of-probes-made-public I am a Phd student carrying out research on the RIPE atlas platform and an early result seems to indicate 1 probe has an obfuscation of 10km distance but this may be an anomaly or perhaps something not taken into account as yet.

1 0

Probe #1000165 showed as down in tab#status
by Jacques Lavignotte 02 Mar '21

02 Mar '21

Dear RIPE NCC crew, Some diag below : # systemctl status atlas mars 02 11:12:43 melusine.eu.org ATLAS[32011]: Do a controller INIT mars 02 11:12:43 melusine.eu.org ATLAS[32011]: Controller init -p 443 atlas(a)ctr-fsn01.atlas.ripe.net INIT mars 02 11:12:43 melusine.eu.org ATLAS[32011]: 255 controller INIT exit with error Probe seems down since scheduled machine reboot this night. Help for fixing welcome, Merci, Jacques -- GnuPg : 156520BBC8F5B1E3 Because privacy matters. « Quand est-ce qu'on mange ? » AD (c) (tm)

5 6

Join the RIPE NCC Open House: Internet in Turkey: 24 February 2021, 11:00 UTC
by Vesna Manojlovic 26 Feb '21

26 Feb '21

Dar all, You're invited for an open discussion with the RIPE NCC about the Internet in Turkey! We are hosting a RIPE NCC Open House for our members and other Internet stakeholders in Turkey on Wednesday, 24 February at 11:00 - 12:30 UTC and invite you to join the discussion. The RIPE NCC Open House is a ninety minute remote session where RIPE NCC staff, community members and industry experts can meet up and share insights, feedback and support. https://www.ripe.net/participate/meetings/open-house This session is focusing on the Turkish Internet community. We will be discussing various topics including: * The state of the Internet in Turkey and across our service region * How RIPE NCC tools and measurements can help operators (RIPE Atlas, RIPEstat, RIPEIPmap, etc.) * Improvements that the RIPE NCC can make to help operators in Turkey * IPv6 deployment * Local community development and the support available from the RIPE NCC Want to join in? Register for the RIPE NCC Open House https://meeting-registration.ripe.net/meeting-pub/registration?0&meetingId=… Looking forward to seeing you online! Regards, Vesna Manojlovic Community Builder RIPE NCC

2 3

New on RIPE Labs: RIPE Atlas Big Data is Back
by Alun Davies 23 Feb '21

23 Feb '21

Dear colleagues, At the beginning of the year, RIPE Atlas users started encountering delays in data retrieval and an overall drop in the responsiveness of the system. With service having gone back to normal earlier this month, we take a look at what caused the problem and what we're doing prevent it from happening again: https://labs.ripe.net/Members/paul_de_weerd/ripe-atlas-big-data-is-back Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

Re: [atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses
by Robert Kisteleki 18 Feb '21

18 Feb '21

Dear All, A little bit of poking since there were no reactions to this question on the MAT mailing list. Before embarking on evaluating what it takes for RIPE Atlas to contribute to this, I'd like to ask for some input from the community; is this something we should spend energy on? More specifically, would it be worthwhile for us to spend time on evaluating the cost of / implementing such measurements in RIPE Atlas? Regards, Robert Kisteleki On 2021-01-26 08:28, Seth David Schoen wrote: > Hi mat-wg, > > I'm Seth, formerly a staff technologist at EFF and one of the > co-developers of Let's Encrypt and Certbot. > > Recently, I've been working with John Gilmore on the IPv4 Unicast > Extensions Project, which aims to make some of the IPv4 address blocks > that were reserved in the 1980s and 1990s (and that continue to be unused, > or nearly so) available for addressing and routing on the Internet. > > This project involves many different kinds of work, including writing > software patches to make various OSes and devices willing to generate > and accept packets to reserved addresses, writing Internet-Drafts to > describe addressing policy changes with IETF, testing devices to see how > they actually treat such packets, talking to various constituencies > about these proposals, and working with the Internet measurement > community to understand how the Internet as a whole treats packets to or > from currently-reserved address ranges, and how that treatment evolves > over time. > > Two prominent examples that are already supported by Linux hosts are the > netblocks 0/8 ("this network") and 240/4 ("experimental"/"future use"). > According to Internet standards created in the 1980s and still in > effect, these address ranges cannot be allocated and should not be > assigned to hosts or used on the public Internet. However, several key > implementations started allowing 240/4 addresses about 11 years ago > during an earlier IETF attempt to open up that netblock, including > Linux, Android, macOS, iOS, and Solaris. In 2019, Linux kernel version > 5.3 allowed ordinary unicast use of 0/8. Today, there are rumors that > various organizations are currently using such reserved addresses as > unofficial RFC 1918-like private address space, without formal policy > coordination with anyone. (There is even some public documentation from > Google suggesting making private use of 240/4.) > > I participated in the Atlas probe deployathon in November and > successfully got a probe up and running. I have also been talking to > a few RIPE people about our interests and managed to confirm that > (regardless of their underlying OS or network treatment) the Atlas > software probes will reject probing any reserved address space, while > the backend infrastructure will refuse to ask probes to connect to it. > > So, I'm here to introduce our project and ask the community's view about > removing these restrictions so that such addresses can actually be > probed and measured. We understand and hope that the majority of such > tests would currently result in errors. Even the errors themselves > could be interesting: for example, we would like to know how often > routing to reserved address ranges fails on a probe host, versus on the > probe host's first-hop router, versus inside of ISP infrastructure. We > would also like to see how this changes over time as a result of OS > software changes that roll out into the field. We would also like to > see whether we can detect unofficial use of particular reserved address > ranges as private address space. Our medium-term goal is to advertise > global routes to portions of these reserved address spaces, and use the > probes to assess how well those routes propagate through the Internet, > and find where blockages occur. Clearly, we can't do this until both > the probe firmware, and the central dispatcher, allow tests to these > addresses. Our long-term goal is to have these addresses treated as > ordinary unicast addresses by all nodes, including Atlas probes, so the > Atlas changes to remove the restrictions would be useful permanent > changes. > >

12 16

RIPE Atlas Measurements packets sent number not always 16
by Debora Marettek 17 Feb '21

17 Feb '21

Dear RIPE NCC, for my ping measurements, I incremented the number of sent packets to 16. Now I noticed that in the measurement with the ID 28779821, the probes didn't always send 16 packets, sometimes, albeit rarely, only 7 or 3. Below you see an extract of the packets_sent data of Probe 52673. Now I wanted to ask what could possibly be the reason for that phenomena. Kind regards, Debora Probe: 52673 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 5, 1, 9, 16, 16, 16, 14, 16, 16, 16, 16, 8, 13, 6, 7, 6, 6, 16, 16, 12, 16, 16, 16, 16, 16, 10, 11, 10, 7, 6, 16, 4, 16, 16, 16, 16, 4, 7, 15, 6, 9, 12, 11, 7, 8, 11, 6, 5, 13, 13, 13, 5, 10, 16, 16, 7, 7, 9, 7, 7, 7, 9, 16, 16, 11, 4, 7, 16, 7, 2, 8, 16, 4, 6, 8, 16, 7, 8, 6, 5, 8, 8, 9, 8, 7, 4, 3, 10, 1, 2, 11, 6, 16, 8, 12, 6, 11, 10, 11, 8, 12, 12, 12, 11, 8, 16, 6, 5, 5, 9, 10, 6, 10, 7, 9, 10, 9, 11, 8, 8, 11, 7, 12, 7, 11, 9, 13, 2, 10, 12, 10, 7, 9, 16, 13, 5, 4, 7, 8, 6, 5, 7, 6, 7, 9, 9, 9, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 4, 9, 4, 6, 8, 6, 11, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, <https://atlas.ripe.net/measurements/28931367/>

1 0

Re: [atlas] Updating probe ssh pub keys via API PUT/PATCH requests
by Chriztoffer Hansen 15 Feb '21

15 Feb '21

Hi RIPE Atlas, Was reading through the documentation yesterday... Is there a specific reason why it is NOT possible to update probe (ssh) pub keys via authenticated API PUT/PATCH requests? https://beta-docs.atlas.ripe.net/apis/metadata-reference/ -- Best regards, Chriztoffer Hansen

3 3

Measurement Result Broken
by r.sommese＠utwente.nl 10 Feb '21

10 Feb '21

Hi everyone, I am getting trouble getting results for ping measurements. Looking at the web portal and JSON results, they are both empty. Measurement ID: 29049476 I also checked from the account of a colleague, same story. There is something broken in the pipeline? Best, Raffaele Sommese

5 5

Is there a way to de-register a long dead probe?
by Kyriacos Sakkas 09 Feb '21

09 Feb '21

Hi All, Can't seem to find a way to just mark a long dead probe as such. Thanks, Kyriacos

3 6

atlas probe down : ID 35603
by MAYER Hans 08 Feb '21

08 Feb '21

Dear All, Our Atlas probe with ID 35603 is down since about 6 days. It’s a V3 probe. Model: TL-MR3020(UN) Ver: 1.9 ; S/N: 2176197008302. When I realised it this atlas probe was not ping-able. ( due to a power outage ) I followed the instructions https://labs.ripe.net/Members/philip_homburg/troubleshooting-ripe-atlas-pro… with solution 1. Unfortunately it didn’t work. During the time without USB stick the probe was on the network reachable, getting the IP from DHCP. But later on, it wasn’t ping-able. So I tried solution 2. I took a different USB stick as described. After a while the probe is now ping-able. ( 2001:628:21f0:911:c225:e9ff:fea8:6530 , 147.125.100.34 , DNS name: ripencc.iiasa.ac.at<http://ripencc.iiasa.ac.at> ) But when I go to https://atlas.ripe.net/probes/35603/ I see it is offline. The web page says „no flash drive“ and „trying to connect“. What else can I do ? It seems, that the TP-Link device itself isn’t broken. Shall I try with a different USB stick. (a third one) I took a 64MB USB stick. Was this maybe too big ? I saw the original stick had only 1 MB. The documentation says it should have at least 4GB. Any ideas ? Any feedback is welcome. Kind regards Hans -- Ing. Dipl.-Ing. Hans Mayer Systems Analyst Network Unix Security Team (NUST) Information and Communication Technologies (ICT) International Institute for Applied Systems Analysis (IIASA) Schlossplatz 1 A-2361 Laxenburg, Austria Phone: +43 2236 807 Ext 215 Mobile: +43 676 83 807 215 Web: http://www.iiasa.ac.at E-Mail: hans.mayer(a)iiasa.at<mailto:hans.mayer@iiasa.at> Note: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it.

2 6

querying the config
by Randy Bush 04 Feb '21

04 Feb '21

howdy so i wanted info about a probe's config, specifically what dns resolver(s) it is using. i could not figure out how to do this. assuming it was a lack of clueons, i asked a friend with far deeper atlas fu. they said such queries are not available. really? [ yes we have bright ideas on how to discover this indirectly by mining past data ] but really? randy

5 6

Measuring reachability query
by Hank Nussbacher 27 Jan '21

27 Jan '21

2 1

atlas streaming data broken?
by Teun Vink 20 Jan '21

20 Jan '21

Hi, RIPE Atlas API streams seem to have broken down today at ~12.05h CET. Is this a known problem? Best regards, -- Teun Vink BIT | teun(a)bit.nl | +31 318 648 688 KvK: 09090351 | GPG: 0xFC8B25D6 | RIPE: TEUN-RIPE

4 8

"Ripe Atlas > Measurements, Maps and Tools > Tools" web portal not working?
by chris lee 12 Jan '21

12 Jan '21

Hi, Not sure am I missing something , as all the tools links under https://atlas.ripe.net/measurements-and-tools/tools/ don't seem to be working. It just stays on the same landing page when clicked. Thx, Chris Lee

2 1

Automating software probe creation?
by Steve Gibbard 04 Jan '21

04 Jan '21

I’m working on creating some Raspberry Pi-based software probes, to put in some networks that currently lack Atlas probes. I’d like to have a standard image that can come up and work wherever an individual probe lands, instead of needing to configure each one separately. As far as I can tell from the documentation, it looks like the probes are identified by the encryption keys in /var/atlas-probe/etc/probe-key* . If creating new probes from an image, is it sufficient to make each probe generate its own encryption keys, or are there other files that need to change? For registering the probes, I see a web form that requires being logged into a RIPE account, and don’t see any equivalent in the API documentation. Is there a way to register new software probes via the API? Thanks, Steve

7 9

Anyone else getting high requests for hitlist-rr6.hitlist.sdstrowes.co.uk
by Anurag Bhatia 28 Dec '20

28 Dec '20

Hello everyone, There seems to be high regular request on my for hitlist-rr6.hitlist.sdstrowes.co.uk. Anyone else getting the same? Since the DNS fails and it gives SERVFAIL, wondering why it's going on from over a day now. Thanks. -- Anurag Bhatia anuragbhatia.com

4 5

new website, but outdated information
by Thomas Schäfer 15 Dec '20

15 Dec '20

Hi, https://atlas.ripe.net/resources/announcements/ (Technical Updates) the last version mentioned there is: 4965 Now we are at 5020. same here: https://atlas.ripe.net/resources/source-code/ (except the link to github, that's up to date) https://atlas.ripe.net/resources/code/ Contributed Code on GitHub (https://atlas.ripe.net/github ) link is dead. Regards, Thomas

2 1

Probes suffering DNS interception?
by Ray Bellis 15 Dec '20

15 Dec '20

Is there any RIPE policy about whether nodes that are subject to DNS interception should be excluded from results (or maybe even dropped altogether) ? While these probes are perhaps still useful for ping and traceroute tests, they are effectively useless for DNS related tests other than as a proxy measure for how prevalent that practise actually is. For the visualisation I've just been building based on the Root System's "hostname.bind" data returned by Atlas it was pretty difficult to figure out how to exclude those probes on the client side. If there was a heuristic that could be applied on the probe itself or within the RIPE data collector that tagged the probe as having "bad DNS" that would help a lot. cheers, Ray Bellis Director of DNS Operations, ISC.

10 11

Re: [atlas] Probe operator notifications
by ripe＠brite.cz 14 Dec '20

14 Dec '20

For this purpose I use an online ping check service. Your probe need to have IPv6 or public IPv4 and ICMP be not blocked by a firewall to be able to respond pings from outside. To be exact, I use http://wedos.online that is run by one of the largest server-hosting company in the Czech Republic. It is free of charge. You can choose how often (1 minute or more) it will ping the probe and how many pings can be lost, then it sends both DOWN and UP notifications (email, Slack, Rocket chat) Cheers Jiri ______________________________________________________________ > Od: "Ponikierski, Grzegorz" <gponikie(a)akamai.com> > Komu: "Edward Lewis" <edlewisjr(a)cox.net>, "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> > Datum: 11.12.2020 12:16 > Předmět: Re: [atlas] Probe operator notifications > >+1 for 'your probe came back on-line' > >Regards, >Grzegorz > >From: Edward Lewis <edlewisjr(a)cox.net> >Date: Thursday 2020-12-10 at 22:32 >To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> >Cc: Ed Lewis <edlewisjr(a)cox.net> >Subject: [atlas] Probe operator notifications > >(Seeing the thread about DNS intercepted probes reminded me to send this:) > >For 5 or so years running I have a probe operating in my garage (behind my home’s NAT and using the ISP’s NXDOMAIN rewriting, non-DNSSEC handling recursive server) a run-of-the-mill home cable set up. > >When I got my November report, it said I’d been down the last half of November. That was news to me. I then down'd/up’d it and it reconnected and seems to be on-line again. > >I do get the “your probe went off-line” notices. I would like “your probe came back on-line” notices as well. If we had those, I may have noticed it stayed down after the last message I saw. > >Ed > > > > > >

5 4

Credit request
by Konstantin Averkin 04 Dec '20

04 Dec '20

Good afternoon, My name is Konstantin Averkin, and I am a Bachelor student of University of Twente. Currently, I am working on my thesis on resilience of DNS servers. In order to successfully perform the research, I need to do ping and trace route measurements against a series of DNS servers located all around the world. With this email I am writing to ask you to provide 20 million credits to perform measurements with the RIPE Atlas platform. Would that be possible? My account is linked to the same name and address as in this email. Thank you in advance. Kind regards, Konstantin Averkin

8 10

List of (scientific) publications using RIPE Atlas
by Moritz Muller 26 Nov '20

26 Nov '20

Hi everyone, A follow up to last week’s Atlas Open House: One of the speakers mentioned that the Wikipedia page of RIPE Atlas [1] lists a number of publications that made use of RIPE Atlas. This list is incomplete and I was wondering if there’s a page somewhere, maybe provided by RIPE NCC, where researchers can submit and list work that used Atlas in some way. This could give beginning researchers and students some inspiration. Maybe this page could also provide links to the measurements themselves for transparency. - Moritz [1] https://en.wikipedia.org/wiki/RIPE_Atlas

3 3

RIPE Atlas outage this evening
by Robert Kisteleki 25 Nov '20

25 Nov '20

Dear colleagues, Due to an internal misconfiguration, RIPE Atlas was unavailable between approximately 1:00-9:00 (UTC+1) this morning. This affected the UI, APIs, some internal tasks, and the scheduling of new measurements. Ongoing measurements were not affected. Our team is analysing the root cause and will take steps to prevent this issue from re-occurring. Regards, Robert Kisteleki RIPE NCC

1 0

Today: RIPE Atlas Software Probes Deployathon!
by Vesna Manojlovic 25 Nov '20

25 Nov '20

Dear colleagues, We're looking forward to celebrating 10 years of RIPE Atlas by deploying software probes - and there's still time for *you* to join us! We have 120+ registered participants from more than 20 countries, that will get help from RIPE NCC staff, with mentors from the community that speak your language. There are also several ideas for hackathon projects, by more advanced RIPE Atlas community experts. We will be online all day today with sessions scheduled at regular intervals. You can join in for the presentations that interest you, or spend some time in one of the online platforms only open today: * SpatialChat for social interactions & hacking * Two Zoom rooms, for presentations, Q&As and live demo's * Slack for chat and technical / code sharing -------------------------- Zoom Presentations Schedule -------------------------- Living Room (English): 08:00 UTC, 11:00 UTC, 15:00 UTC Sun Room (Russian): 09:00 UTC Sun Room (Spanish): 14:00 UTC The Closing Session will take place in the Living Room: 16:00 UTC The full schedule and access codes are on RIPE Labs: https://labs.ripe.net/Members/becha/lets-deploy-together-ripe-atlas-softwar… Kind regards, Vesna Manojlovic Community Builder RIPE NCC

1 0

Do we have an easy list of RIPE Atlas Webinars?
by Barry Greene 23 Nov '20

23 Nov '20

Are there any more current Ripe Atlas webinars hosted? The 2015 on posted on the site is a bit dated.

1 0

Problem today? Measurements do not finish
by Stephane Bortzmeyer 18 Nov '20

18 Nov '20

See for instance #28206873. 100 probes, all with "No recent report available".

3 5

New on RIPE Labs: Join Us for a RIPE NCC Open House on 10 Years of RIPE Atlas
by Alun Davies 17 Nov '20

17 Nov '20

Dear colleagues, Tomorrow we’ll he holding a RIPE NCC Open House event to celebrate 10 years of RIPE Atlas. Join us for a mix of presentations, diverse use cases from external speakers, and open discussion between the people who are helping expand RIPE Atlas right now. In this new article on RIPE Labs, we tell you what we’ve got lined up and invite you to register: https://labs.ripe.net/Members/alun_davies/join-us-for-a-ripe-ncc-open-house… Kind regards, Alun Davies RIPE NCC

1 0

10 years of RIPE Atlas - some stories
by Robert Kisteleki 16 Nov '20

16 Nov '20

Dear colleagues, RIPE Atlas has officially turned 10! As a way of marking the occasion, we'll be sharing a series of stories over the next couple of weeks looking at its development from the early days onwards. Read the latest instalment every day on RIPE Labs: https://labs.ripe.net/Members/kistel/10-years-of-ripe-atlas-tales-from-the-… Kind regards, Robert Kisteleki RIPE NCC

1 0

Status Check API Documentation
by Julian Panke 13 Nov '20

13 Nov '20

Hello, I can not find any documentation about the status-check API anymore. The documentation disappeared when the new Atlas UI went live, I think. So I am wondering. Is the status-check API deprecated? And if not, where do I find the documentation? Mit freundlichen Grüßen/ Sincere regards Julian Panke

2 1

New on RIPE Labs: Rolling Out the RIPE Atlas Redesign
by Alun Davies 12 Nov '20

12 Nov '20

Dear colleagues, You might have noticed that RIPE Atlas is looking different. To explain what's changed and why, this article on RIPE Labs gives an update on our latest efforts to roll out a new design for all our services: https://labs.ripe.net/Members/michela_galante/rolling-out-the-ripe-atlas-re… Kind regards, Alun Davies RIPE NCC

1 0

Planned changes to "measurement archive"
by Robert Kisteleki 12 Nov '20

12 Nov '20

Dear RIPE Atlas users, You may be aware that we publish "measurement metadata dumps" on "FTP" (https://ftp.ripe.net/ripe/atlas/measurements/) every week. These are meant to make the complete measurement metadata downloadable for those who are interested. Even though there is still a point in publishing our metadata in a downloadable format, the current method is not sustainable: as it is defined it'll grow forever - which is not realistic. Currently *every* dump contains *all* the measurements we *ever* had in the system. We plan to change that to "everything that's running now + everything that was running in the last two weeks". This has about 200k items currently. If we published this every day instead of once a week, we will still only produce 10% of the output we do today - by virtue of eliminating 90% of redundancy and repeated work. The syntax and semantics of the content will not change. We will keep the existing dumps as they are mostly because there's no reason to remove them. What this means for users is: * if you care about "current / recent" measurements, you can just use the last dump from yesterday * if you really need all (or a large part of) history, you can fetch one dump per 2 weeks or so and combine them * you can still use the API for random, finite searches We plan to implement the above change just after RIPE 81 (i.e. early November). Please be aware of this change if you rely on these dumps. Regards, Robert

1 1

RIPE Atlas UI change
by Robert Kisteleki 11 Nov '20

11 Nov '20

Dear All, We will work on releasing the new, significantly changed UI for RIPE Atlas next week Tuesday (10 November) in the early morning hours. The UI may be unavailable for a short time, and during this work your browser may show inconsistent or strange looking pages - where you may have to reload the page(s) (a few times). Please bear with us while this facelift happens. Regards, Robert Kisteleki RIPE NCC

2 3

Meta-information dumps for built-in measurements?
by Vasileios Giotsas 09 Nov '20

09 Nov '20

Is there any repository like https://ftp.ripe.net/ripe/atlas/measurements/ that contains meta-information about built-in RIPE Atlas measurements (the above repository contains meta-information only for public measurements)? I couldn't find anything similar in the new FTP repository at https://data-store.ripe.net/datasets/atlas-daily-dumps/ I guess using the API is an alternative but it would be more convenient to have such dumps Thanks, Vasileios

15 24

RIPE Atlas 10 years anniversary events
by Lia Hestina 05 Nov '20

05 Nov '20

Dear all, RIPE Atlas turns 10 years old this month! We're excited to share two events to mark this occasion, and we invite you to join us for them: * RIPE Atlas Open House session (18 November): This is a 90 minute long virtual session in which we will celebrate 10 years of RIPE Atlas by sharing use cases, updates and having an open discussion about everything Atlas. https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-10… * Virtual RIPE Atlas Software Probe Deployathon (25 November): Deploying software probes is even more fun if we get together for it! We're aiming to get software probes deployed with mentors and participants logging in from around the world. https://labs.ripe.net/Members/becha/lets-deploy-together-ripe-atlas-softwar… Both these events are free and open to all, but please make sure to register as soon as possible. We’d be delighted if you could spread the word and invite your local communities too! Kind regards, RIPE Atlas team

1 0

DoH / DoT test in Atlas Probes
by Imre Tuskes 02 Nov '20

02 Nov '20

Hello, Is there any plan to measure DNS over HTTPs (or TLS). We are interested in the performance of this kind of service. Regards, Imre

2 1

Re: [atlas] measurements not starting
by Viktor Naumov 29 Oct '20

29 Oct '20

Sorry, my bad. I didn't rub my eyes enough. Indeed the reason is different. What I can see from the logs is that the scheduler couldn't find any probe in AS4771 that would be capable of doing v6 measurement. wbr /vty On 10/29/20 8:35 AM, Povl Ole Haarlev Olsen wrote: > On Thu, 29 Oct 2020, Viktor Naumov wrote: >> The times shown on the page are in UTC. So your measurement should >> start in about 1h 15 minutes from the current moment. > > 2020-10-28 was yesterday. > >> On 10/29/20 7:12 AM, Yang Yu wrote: >>> SCHEDULED from >>> 2020-10-28T08:41:35Z >>> to >>> 2020-11-11T00:35:07Z >>> every 900s >

2 3

measurements not starting
by Yang Yu 29 Oct '20

29 Oct '20

Hi, I created 2 measurements with start time now, but neither started after 1 day https://atlas.ripe.net/measurements/27881135/ https://atlas.ripe.net/measurements/27881134/ > SCHEDULED from 2020-10-28T08:41:35Z to 2020-11-11T00:35:07Z every 900s >none of requested probes got scheduled SCHEDULED None yet Number of probes actually scheduled for this measurement What am I missing here? Thanks. Yang

3 2

RIPE Atlas Deployathon - 25 November 2020
by Lia Hestina 27 Oct '20

27 Oct '20

Dear colleagues, As part of the 10th anniversary of RIPE Atlas, we're organising a virtual RIPE Atlas software probe deployathon. Join us on 25 November 2020 to help us celebrate 10 years of RIPE Atlas by adding 10x10 software probes over 10 hours! You can get much more information about the event in this RIPE Labs article: https://labs.ripe.net/Members/becha/lets-deploy-together-ripe-atlas-softwar… Feel free to share it with your local communities and hopefully we’ll see you all on 25 November! Kind regards, Lia Hestina RIPE NCC _________

1 0

Result processing glitch
by Robert Kisteleki 12 Oct '20

12 Oct '20

Dear RIPE Atlas users, Today one of our controllers (a component that handles probes and deals with their submitted results) was updated to run a new version of result processing code. Unfortunately this code had a bug that caused results to be mixed up. As a result, some of the results that were delivered by this controller were of the wrong type / syntax, which may result in errors in processing this data. We reverted this change as soon as we detected the error. This issue likely affected results delivered by about 2% of our probes, between 13:30 and 15:15 (CEST). We apologise for the inconvenience. Regards, Robert Kisteleki RIPE NCC

1 0

Latest software version for v3 probe
by Ashu 06 Oct '20

06 Oct '20

Hi My v3 probe 25250 has software version firmware version 4900(1100). However, i have seen other v3 probe on version 5020(1100). Why my probe is not updated to the latest version automatically. Is there a way i can update my probe to latest firmware version. Regards, Ashu

1 0

Re: [atlas] ripe-atlas Digest, Vol 109, Issue 11
by Florian Rohde 24 Sep '20

24 Sep '20

10 million points have just been added to the Research Concern. I wish you success. Cheers, Florian Florian Rohde Neue Landbuch GmbH & Co. KG Telefon: +49 4231 9552-79 Fax: E-Mail: Florian.Rohde(a)nlb.de --------------------------------------------------------------------------------- Neue Landbuch Gesellschaft m.b.H Gesellschaft für moderne Datenverarbeitung & Co. KG Heinrich-Schröder-Weg 1 27283 Verden Telefon: +49 4231 9552-0 Fax: +49 4231 9552-66 E-Mail: info(a)nlb.de Internet: www.nlb.de Kommanditgesellschaft mit Sitz in Verden Registergericht Walsrode, HRA 121111 Pers. haftender Gesellschafter: Neue Landbuch GmbH, Verden Geschäftsführer: Bernhard Kramer Aufsichtsratsvorsitzender: RA StB Ralf Stephany -----Ursprüngliche Nachricht----- Von: ripe-atlas [mailto:ripe-atlas-bounces@ripe.net] Im Auftrag von ripe-atlas-request(a)ripe.net Gesendet: Donnerstag, 24. September 2020 12:00 An: ripe-atlas(a)ripe.net Betreff: ripe-atlas Digest, Vol 109, Issue 11 Send ripe-atlas mailing list submissions to ripe-atlas(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.ripe.net/mailman/listinfo/ripe-atlas or, via email, send a message with subject or body 'help' to ripe-atlas-request(a)ripe.net You can reach the person managing the list at ripe-atlas-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ripe-atlas digest..." Today's Topics: 1. Re: Request for credits for research (Ponikierski, Grzegorz) ---------------------------------------------------------------------- Message: 1 Date: Thu, 24 Sep 2020 09:46:45 +0000 From: "Ponikierski, Grzegorz" <gponikie(a)akamai.com> To: "Mohan, Nitinder" <nitinder.mohan(a)helsinki.fi>, "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: Re: [atlas] Request for credits for research Message-ID: <EEB33D82-5DC6-481B-89B0-C11B6FB52EC6(a)akamai.com> Content-Type: text/plain; charset="utf-8" 50M from me. Waiting for paper ;) Regards, Grzegorz From: "Mohan, Nitinder" <nitinder.mohan(a)helsinki.fi> Date: Thursday 2020-09-24 at 00:02 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Request for credits for research Dear RIPE community, I hope you are all safe and sound. I am a Postdoctoral fellow at the Technical University of Munich, Germany. We are currently working on an ongoing research project which aims to analyze the availability and reachability of cloud data centers globally. The first work of our work will appear in ACM HotNets 2020 titled "Pruning Edge Research with Latency Shears" (http://conferences.sigcomm.org/hotnets/2020/program.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__conferences.sigcomm.org…>). We are currently preparing the camera-ready version of the paper and will share it with the community by hosting it (and the associated dataset) publicly soon. We are currently planing to submit the second leg of our work to a conference with submission deadline a month. In order to complete all set of measurements for required analysis, we are scheduling very large-scale measurements over the platform which has burned through almost all our credits and left us in need. I have always found the RIPE Atlas community to be helpful and generous towards research and I am hoping that you could support our research by donating us some of your spare credits. Your help will be highly appreciated. My RIPE account is nitinder.mohan(a)helsinki.fi Thanks and Regards Nitinder Mohan Postdoctoral Fellow Technical University of Munich, Germany https://www.nitindermohan.com/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.nitindermohan.com_…>

1 0

Re: [atlas] Request for credits for research
by Ponikierski, Grzegorz 24 Sep '20

24 Sep '20

50M from me. Waiting for paper ;) Regards, Grzegorz From: "Mohan, Nitinder" <nitinder.mohan(a)helsinki.fi> Date: Thursday 2020-09-24 at 00:02 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Request for credits for research Dear RIPE community, I hope you are all safe and sound. I am a Postdoctoral fellow at the Technical University of Munich, Germany. We are currently working on an ongoing research project which aims to analyze the availability and reachability of cloud data centers globally. The first work of our work will appear in ACM HotNets 2020 titled "Pruning Edge Research with Latency Shears" (http://conferences.sigcomm.org/hotnets/2020/program.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__conferences.sigcomm.org…>). We are currently preparing the camera-ready version of the paper and will share it with the community by hosting it (and the associated dataset) publicly soon. We are currently planing to submit the second leg of our work to a conference with submission deadline a month. In order to complete all set of measurements for required analysis, we are scheduling very large-scale measurements over the platform which has burned through almost all our credits and left us in need. I have always found the RIPE Atlas community to be helpful and generous towards research and I am hoping that you could support our research by donating us some of your spare credits. Your help will be highly appreciated. My RIPE account is nitinder.mohan(a)helsinki.fi Thanks and Regards Nitinder Mohan Postdoctoral Fellow Technical University of Munich, Germany https://www.nitindermohan.com/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.nitindermohan.com_…>

1 0

Invalid results in TraceMON tool
by Andreas Siskos 09 Sep '20

09 Sep '20

Hello everyone, I am an undergraduate student at University of Crete and as a part of my bachelor thesis, I am trying to integrate TraceMON in a website. I used the example code that it was provided by the web page of TraceMON in RIPE Atlas website ( https://atlas.ripe.net/docs/tools-tracemon/#embed), but I noticed something unexpected. The graph of the TraceMON was not taking the same path as the raw data of traceroutes. There were the right destinations/IPs, but in shuffled order. Let's consider the example of measurement ID 26813196. As you can see, in the raw data of the traceroute ( https://atlas.ripe.net/api/v2/measurements/26813196/results/), it reaches the target IP (103.83.160.1) at 16th hop from probe 55564. When I checked the graph in TraceMON on the RIPE Atlas website ( https://atlas.ripe.net/measurements/26813196/#!tracemon) (see attached: general.png), the traceroute from probe 55564 was represented in the picture graph.png. As you can see in the data file data.png, the destination IP was reached at 3rd hop instead of 16th, that was in the raw data of the traceroute. The same behavior can be observed for the probes 19648 and 32788. Am I missing something? Thank you in advance, Andreas Siskos

1 0