Re: [atlas] New coverage and statistics page

Great work! I have waited for a fully client side implementation for a long time. Now it works as quickly as one expects. Great work creates more work ;-): It is nice to see the percentage of global ASes and prefixes. It would be even nice to see percentages per (RIR service) region. Our goa

Re: [atlas] V5 probes

On 06-10-2022 09:44, Robert Kisteleki wrote: Today we have about 440 v1 and 690 v2 connected. These have proven to be way more stable than we anticipated; as you can see many have been running for over 10 years now! Wy more stable! Some are approaching twelve years *uptime*. At the t

Re: [atlas] Probe on sailboat with Starlink

On 28-06-2022 19:46, Stephen Strowes wrote: ... I have no idea how starlink decides what ground station to bounce your service down onto, it might be interesting to see how it works the further you get from home. https://starlink.sx/ is a nice *simulation* that provides some graphical insi

Re: [atlas] Satellite based "last mile" and Atlas probes

I recommend some empirical care when interpreting the 1st and 2nd hop built-in measurements. These measurements heavily depend on the particular implementation of the ‘local loop’ IP layer. So please take them as just one data point. The good news is that RIPE Atlas allows researchers to do on-

Re: [atlas] Feature request for Validated Timestamps

On 15 Apr 2021, at 12:16, Philip Homburg wrote: … How to store all public keys of all servers for ever. …. Suggestion: embed them somehow with the data sets generated by those servers. e.g. make them queryable just like normal measurement data. Daniel

Re: [atlas] Probe location obfuscation

More than a year ago I have started some statistical work to flag probes with likely incorrect geolocation. Unfortunately higher priority work has taken precedence since. I would make time to share and explain what I have done so far if someone were to convince me that they had serious intentio

Re: [atlas] dead v1 probe

On 3 Jun 2020, at 2:19, Randy Bush wrote: i have a few dead v1s. but they are a kkm away, where we would have to send remote hands in :( randy V1s were introduced more than 10 years ago. Many are still going, after more than twice their expected life time. Be happy, replace them (event

Re: [atlas] SSL Certificates for ripe anchors

On 3 Sep 2019, at 15:10, Carsten Schiefner wrote: [https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022] Thanks, Sylvain and Bjørn! And of course ‘our own’ Jan Žorž explains this quite well too: https://www.internetsociety.org/blog/2

Re: [atlas] SSL Certificates for ripe anchors

On 3 Sep 2019, at 11:38, Robert Kisteleki wrote: On 2019-09-03 11:17, Shane Kerr wrote: … Sorry for asking this question so late in this thread, but what exactly are the certificates used for? The anchors provide very basic services intended to help users who want to use the anchors

Re: [atlas] Probes fluctuation

On 29/04/2019 11:59, Robert Kisteleki wrote: > ... It's also possible that the system didn't allocate the probes to you -- > either because they were too busy at certain times, or we couldn't talk > to them, or there are not enough probes in general to satisfy your > request. It's hard to tell w

Re: [atlas] Definition of Commercial Use

Mic, What you describe is one of the *intended* uses of Atlas. So we are happy 😃 that you find Atlas useful for it. Daniel I am not a lawyer and I do not play one on 📺 either. --- Sent from a handheld device. > On 4. Oct 2018, at 13:12, Robert Kisteleki wrote: > > >> On 2018-09-19 17:

Re: [atlas] how to mark probe as dormant

On 16/04/2018 17:26, Randy Bush wrote: > hi chris, > >>> i have a probe, 2283, which has unplugged from its old home and is in >>> suspended animation in a suitcase until it reaches its new home in a >>> month or two. >> >> There's nothing you have to do when a probe is down; it is automatically

Re: [atlas] New on RIPE Labs: Announcing Daily RIPE Atlas Data Archives

>From just another user: For me it is strange. It always works with an FTP client. But in Firefox it does not work for me from outside the NCC. Maybe a load balancer or firewall issue? Until that is resolved I suggest to use an FTP client. Daniel On 23.06.17 12:11 , Mirjam Kuehne wrote: > works f

Re: [atlas] RIPE Atlas V1 Probe Issue

On 17.05.17 13:04 , Michael Hayler wrote: > ... So I powercycled the probe after I was home again and since then it is > online without any issues for 11 hours now. That is identical to my observations with probes #7 and #8. After a power cycle they do re-connect after a while. So I am hopeful t

Re: [atlas] Reconnecting probe 3508 - troubleshooting

On 23.08.16 10:52 , Philip Homburg wrote: > On 2016/08/22 22:14 , Michael-John Turner wrote: >> The reason why the probe was offline originally was that it stopped >> accepting DHCPOFFERs for some reason, with the result that it would >> continually send DHCPDISCOVERs every few seconds but never

Re: [atlas] Is the Atlas probe hackable?

I am positive tinba cannot run on the probes. So either that IDS is brain damaged or some joker made a UDM that acts like tinba or both. What Marc said: the 'CnC' appears to be at the root name servers. Queue conspiracy theory . Daniel On 5.07.16 14:15 , Hank Nussbacher wrote: > I received a

Re: [atlas] probe congestion?

One-offs are not intended to be used like this. The emphasis with them is to schedule as quickly as possible *no matter what*. This is for quick look-see work. Not for repeated measurements on the same set of probes. If you want to schedule that much from an indentical set of probes, do not use on

Re: [atlas] Open ports?

On 15.04.16 10:57 , Andreas Boesen wrote: > > as far as I understand the probe just needs to be able to establish > _outgoing_ connections. ... That is correct. No *incoming* ports need to be opened! Daniel signature.asc Description: OpenPGP digital signature

Re: [atlas] probe tagged as "Hardware problem suspected"

Excellent to see that members of the RIPE Atlas community support each other! Daniel On 24.01.16 23:48 , sarah.wasserm...@student.ulg.ac.be wrote: > Hi Christian, > > I followed the steps your described in your "tutorials" and my probe now > seems to work again. Thanks a lot! > > Sarah

Re: [atlas] What is 'iwantbcp38compliancetesting' user tag?

On 10.01.16 6:17 , Emile Aben wrote: > Hi, > > As for the origin of the tag: I set this on my probe as an experiment to > see if one could do a poll among probe hosts. Apparently the hosts of 21 > other probes already found the tag without it every being advertised. > > Now that it is more wide

Re: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops

On 8.12.15 17:15 , Philip Homburg wrote: > ... > To give an example, the ssh client I use is linked with getdns. Getdns > will try to fetch RRSIG records, etc. from the local resolver. If that > fails, getdns will become a full recursive resolver. > > When ssh starts, the cache of getdns will be

Re: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops

On 8.12.15 16:56 , Philip Homburg wrote: > On 2015/12/08 16:45 , Daniel Karrenberg wrote: >> Real resolvers >> - use caching, >> - retry queries, >> - can use all authoritative servers for a zone, >> - perform recursion, and (again) >>

Re: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops

On 8.12.15 16:45 , Nico CARTRON wrote: > > Fully agreed, but I still don’t see why they are downplaying the event > like this. I would call it "putting into perspective". The DNS kept working. > > Tools such as DNSMON are useful, and of course need to be taken with a > grain of salt and not b

Re: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops

On 8.12.15 16:16 , Nico CARTRON wrote: > On 8 December 2015 at 16:07:02, Stephane Bortzmeyer (bortzme...@nic.fr > ) wrote: >> http://root-servers.org/news/events-of-20151130.txt > > Thanks Stéphane for your reactivity, as usual :) > > “Such test traffic may not be ind

[atlas] Fwd: Re: Measurements delete and ping issue

I did not copy the list on this message and then realised that it is a generic answer that deserves to be seen and archived here. Daniel Forwarded Message Subject: Re: [atlas] Measurements delete and ping issue To: Andrea Consadori References: From: Daniel Karrenberg

Re: [atlas] Spoofing measurenments

On 23.11.15 13:11 , Nick Hilliard wrote: > On 23/11/2015 12:03, Daniel Karrenberg wrote: >> Why exactly do we need to know the exact amount of this problem? > > it would be useful to know the sources of the problem. > > Nick > Those would be the ones not repor

Re: [atlas] Spoofing measurenments

On 17.11.15 17:50 , Pavel Odintsov wrote: > Hello, Community! > > I'm writing from RIPE71 / Anti spoofing BoF. So I want to ask for some > difficult ethical question. > > Could we detect probe hosts who do not deploy outgoing filtering and > accept spoofed traffic? > > We need to know amount o

Re: [atlas] RIPE Atlas anchor self assembly

No, see the other discussion. On 10.11.15 17:31 , Daniel Baeza (Red y Sistemas TVT) wrote: > So... if we give you access to a CentOS VM, you can make it Anchor? :) > > El 10/11/2015 a las 17:01, Philip Homburg escribió: >> On 2015/11/10 16:56 , Colin Johnston wrote: >>> Can we have link to image

Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)

; Awesome! Could you share where we could bought it? I will share this > information with local community. > > On Tue, Nov 10, 2015 at 12:36 PM, Daniel Karrenberg > wrote: >> At this time are 485 connected probes and two connected anchors in >> Russia. As far as I know Soek

Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)

have so much experience with > they and I'm not a technology hater) they are not offer dedicated > service and not isolated perfectly from each other processes. > > > > On Tue, Nov 10, 2015 at 11:56 AM, Gert Doering wrote: >> Hi, >> >> On Tue, Nov 10, 2015 a

Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)

I understand the temptation of "easy deployment". The con-s also have been outlined ad nauseam. So let me repeat this only once: We should all assess this thoroughly before diving into it. What quality of data we expect from VMs? What is the real cost of *supporting* VMs? The main costs are not in

Re: [atlas] Private Probes: What's the Point

etime one wouldn’t learn > these rules if one hadn’t violet them in first place. > > Regards, > Wenqin > > > >> On 22 Oct 2015, at 17:17, Daniel Karrenberg >> wrote: >> >> Wengin, >> >> Thank you for your good question. >> >>

Re: [atlas] Private Probes: What's the Point

Im my, biased, opinion Atlas is has significantly less ethical issues. Atlas is not running on the user's system or browser and we do much less than could be done with javascript. So Atlas measurement traffic looks very much less like it is coming from the user and the user is not exposed to conte

Re: [atlas] Private Probes: What's the Point

Wengin, Thank you for your good question. This is exactly why we allow HTTP measurements only to well defined targets. So far we assume that DNS queries are not harmful. Since we cannot know what is "risky" in all places there is little else we can do. Would you have more peace of mind if you cou

Re: [atlas] 3rd generation probe doesn't appear as online

Actually both the power and the USB memory issues can be related. I have "repaired" non-working flash by changing the power supply. Daniel

Re: [atlas] Question about "location setting" of RIPE Atlas

Anurag, thanks for the good question. Please set the location as the physical location of the probe itself. We need a common definition for this. If we all over-think and fudge this, the data will become meaningless. Also Inigo's suggestions are good ones. Daniel On 22.08.15 23:42 , Anurag Bhat

Re: [atlas] DNS over IPv6

On 6.08.15 18:24 , Brzozowski, John wrote: > Apologies if this is documented some where. https://atlas.ripe.net/docs/udm/ > Does the RIPE atlas probes> explicitly measure/test DNS over IPv6? When specifying a measurement you can set the address family (IPv4 or IPv6). > Also do DNS measurement

Re: [atlas] Probe question - Issue

Ah, nobody tells me anything anymore around here ;-). So does this mean you can no longer just change the USB stick anymore like you used to? Daniel On 23.06.15 12:24 , Philip Homburg wrote: > On 2015/06/23 8:38 , Daniel Karrenberg wrote: >> I can tell you that the USB Flash only store

Re: [atlas] Probe question - Issue

Hi Laurent, while I am not in charge of customer support I can tell you that the USB Flash only stores results, the OS is on the internal flash and that the most common problem is insufficient or unstable USB power to the unit. I hope this helps until the pros arrive at the office. Danie