[atlas] Re: Globalping

On Tue, Aug 27, 2024 at 04:52:11PM +0200, Ernst J. Oud wrote a message of 50 lines which said: > With Atlas Magellan in a docker container this is also possible, Note that Magellan does not require Docker. (I don't use it from Docker, for instance.) - To unsubscribe from this mailing list

[atlas] Re: Globalping

On Tue, Aug 27, 2024 at 12:42:18PM +0200, Ernst J. Oud wrote a message of 12 lines which said: > It might be “cursing in the church” as we say in NL, but does anyone > here have experience with the Globalping monitoring tools? https://www.jsdelivr.com/globalping ? No real practical experienc

[atlas] Re: RIPE Atlas Infra IP Rages

On Mon, Aug 19, 2024 at 03:55:03PM +0330, Milad Afshari wrote a message of 82 lines which said: > Could you please provide the exact IP range(s) used by the RIPE Atlas > infrastructure? This information is crucial for our ongoing network > configuration. % dig +short atlas.ripe.net A 193.0.6.

[atlas] Bug reports about Atlas

It seems that writing to at...@ripe.net does not go to the Atlas team, but to a generic RIPE-NCC helpdesk, which knows noting about Atlas and sends back funny, but unrelated answers. What is the preferred way to report bugs about Atlas? -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists

[atlas] Missing user tags

We all know that user tags are imperfect and there is not a lot we can do (except pinging from time to time the hosts, like ICANN does with "Keep your social data up-to-date for your domain", with mixed success). One of the problems is that people tag correctly (I hope so) but do not always tag wh

Re: [atlas] Atlas probes in non-production networks

On Mon, Jul 01, 2024 at 02:30:13PM +, Ponikierski, Grzegorz via ripe-atlas wrote a message of 149 lines which said: > RIPE Atlas probes are not tagged and separated into groups that can > be used appropriately for public and internal/private measurements. This is not enirely true, RIPE At

Re: [atlas] [NTP measurements] Minimum offset if negative

On Fri, Jun 28, 2024 at 12:22:45PM +0200, Povl Ole Haarlev Olsen wrote a message of 26 lines which said: > min( abs( value_1 ) , abs( value_2 ) ) would be the minimum difference, not > the minimum offset. I'm afraid I don't understand. There is no minus sign so no difference computed. IMHO,

Re: [atlas] [NTP measurements] Minimum offset if negative

On Fri, Jun 28, 2024 at 12:14:45PM +0200, Philip Homburg wrote a message of 11 lines which said: > In math. min(-2, -1) = -2 > > Why would that be different for offset? Because this is not Math 101 but NTP. You typically don't care about the sign of the offset, only about its absolute value.

[atlas] [NTP measurements] Minimum offset if negative

Measurement #74488034 says on : "Min Offset: -1 173,799". Since offsets can be positive or negative, I suggest it is not a good idea to take the minimum without first removing the sign. Here, the real minimum offset was -0.000345 (the closest from the s

[atlas] [NTP measurements] Work with some servers but not all

I'm playing with NTP measurements and I observe that RIPE Atlas probes can talk to some public NTP servers but not all. See for instance measurements #74488034 (it works) and #74487872 (it fails). Testing with other NTP clients succeed with these two servers (ntp.nic.fr and ntp.netnod.se). I do no

Re: [atlas] [HTTP measurements] Units of timing?

On Wed, Jun 26, 2024 at 12:45:17PM +0200, Robert Kisteleki wrote a message of 27 lines which said: > According to the documentation > (https://atlas.ripe.net/docs/apis/result-format/#version-5000) those > fields are in milliseconds. Yes, thanks. (But NTP measurements are in seconds, so I'll r

Re: [atlas] [HTTP measurements] What is the use of query_string?

On Wed, Jun 26, 2024 at 12:34:30PM +0200, Robert Kisteleki wrote a message of 37 lines which said: > It is hard to judge a particular HTTP proxy's behaviour, but indeed > adding some variance to the URL via the query string likely helps > here. OK, I'll remember that, thanks. (I did not find

[atlas] [HTTP measurements] Units of timing?

When using "extended_timing" with HTTP measurements, in what units are tt*? I suspect that ttr is in seconds and the other two in milli-seconds but I want to be sure. (The Web interface does not display these values, it seems, but see measurement #74293060 if you want an example.) -- ripe-atlas

Re: [atlas] [HTTP measurements] What is the use of query_string?

On Tue, Jun 25, 2024 at 11:32:50AM +0200, Stephane Bortzmeyer wrote a message of 10 lines which said: > The documentation says that you can add a "query_string" parameter in > a HTTP measurement but the anchor seems to ignore it? A colleague suggests that it can be useful to

[atlas] [HTTP measurements] What is the use of query_string?

The documentation says that you can add a "query_string" parameter in a HTTP measurement but the anchor seems to ignore it? -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Delays?

On Mon, May 13, 2024 at 09:51:14PM +0200, Ernst J. Oud wrote a message of 22 lines which said: > I experience delays on creating measurements. > > Even after 2 minutes, a measurement is not running, eventually it will but it > used to take a couple of seconds. Same here. With blaeu, I use t

Re: [atlas] Confused by the documentation

On Fri, Apr 05, 2024 at 10:13:14AM +0200, Christopher Amin wrote a message of 44 lines which said: > As a workaround, you can look at the response documentation for "GET > /api/v2/measurements" -- all of the type-specific fields that are > marked with .e.g [http] or [dns] are options which can

Re: [atlas] Empty responses for HTTP tests with a non-existing path?

On Fri, Apr 05, 2024 at 01:53:02PM +0200, Robert Kisteleki wrote a message of 36 lines which said: > Thank you for pointing this out, it has been fixed: the anchors > respond with a proper 404 now. Indeed, thanks. -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman

[atlas] Confused by the documentation

I confess I have a lot of problems finding something in the documentation in its current state. For instance, I assume that HTTP requests can have a "method" parameter to switch from GET, HEAD, etc but where is it documented? Not here: https://atlas.ripe.net/docs/apis/rest-api-manual/measurements

[atlas] Empty responses for HTTP tests with a non-existing path?

It seems the anchors, when receiving a HTTP request for a non-existing path, instead of a 404, send a broken response: % curl -v http://fr-par-as2486.anchors.atlas.ripe.net/nonono * Trying 2001:67c:217c:4::2:80... * Connected to fr-par-as2486.anchors.atlas.ripe.net (2001:67c:217c:4::2) port 80

[atlas] Atlas weather report: bad day

As reported by , indeed, measurements timeout today. -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas

[atlas] "Thinking About Internet History"

Among the things to preserve for future studies of Internet infrastructure and connectivity, this interesting article mentions Atlas measurements. https://content.cooperate.com/post/internet_history/ -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atla

Re: [atlas] Atlas fully down..

On Wed, Sep 20, 2023 at 12:02:19PM +0200, Ernst J. Oud wrote a message of 34 lines which said: > Yes, I also don’t understand Robert’s remark. All user defined > measurements, new or existing do not give any results. May be the situation is complicated and not fully understood yet. Good luck

Re: [atlas] Atlas fully down..

On Wed, Sep 20, 2023 at 07:43:20AM +0200, Robert Kisteleki wrote a message of 42 lines which said: > All else (continuing to run existing measurements, creating new ones, > real-time streaming of the results, APIs, UI, ...) are running undisturbed. This is not what I observe. For instance, a

Re: [atlas] Easy way to view DNS results?

On Tue, Jul 25, 2023 at 09:40:34AM +0200, Robert Kisteleki wrote a message of 88 lines which said: > We're not parsing and inserting all the bits from the raw response > into the JSON mostly because it would inflate the size of the > results enormously, while users are generally only intereste

Re: [atlas] Probe 24434 down but pingable

On Fri, Dec 30, 2022 at 10:04:35AM +0100, Dave wrote a message of 43 lines which said: > One of my probes is pingable but the status is disconnected for over > a day. Could it be also that the probe is indeed disconnected but there is some middlebox in front of it that intercepts ICMP echo re

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

On Fri, Dec 16, 2022 at 02:57:40PM -0800, Randy Bush wrote a message of 12 lines which said: > i do not understand the big fuss here. so a teensie fraction of > probes are not public. big deal. Apparently, the problem is that the cost of private measurements is not zero: it makes the Atlas

Re: [atlas] Proposal: Measure well-known CDNs,[CDN-HTTP]

On Tue, Dec 20, 2022 at 05:48:08PM +0100, Lukas Tribus wrote a message of 60 lines which said: > - where have those security concerns been previously discussed? Several times on this list. This is a recurring discussion, for many years. > Are you suggesting that people deploy ATLAS probes in

Re: [atlas] Proposal: Measure well-known CDNs,[CDN-HTTP]

On Wed, Dec 14, 2022 at 03:02:46PM +0100, Robert Kisteleki wrote a message of 15 lines which said: > 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

Re: [atlas] RIPE Atlas down?

On Wed, Jun 22, 2022 at 11:34:09AM +0200, Ernst J. Oud wrote a message of 78 lines which said: > Checked a probe in Germany, same thing but stopped a couple of hours later it > seems. > > Is there some problem? Indeed, measurements never return results

Re: [atlas] How to get DNS return codes and TTLs

On Wed, Jun 08, 2022 at 06:16:30PM -0600, Dallan Adamson wrote a message of 39 lines which said: > I'm doing research that requires me to use DNS recursive resolvers > around the world. At a minimum from these recursive resolvers I need > to know what return code the probe received from the re

[atlas] Discrepancy in documentation?

[Message already sent on 6 june but it never appeared in my mailbox. Is there some email problem at RIPE?] In the documentation , various HTTP methods are used (for instance DELETE to delete a measurement), which is nice, but the examples

[atlas] Problem with DoT measurements?

DoT measurements seem partially broken, only 10 % of the probes do report. (See for instance #39675721.) -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Facebook in Russia and a diagnostic problem

On Mon, Mar 14, 2022 at 01:40:02PM +0100, Emile Aben wrote a message of 21 lines which said: > I find the things the OONI project does very insightful. > > For this particular case: > https://ooni.org/post/2022-russia-blocks-amid-ru-ua-conflict/ Good reference, thanks, it explains everything

Re: [atlas] Facebook in Russia and a diagnostic problem

On Mon, Mar 14, 2022 at 10:26:46PM +1100, Jen Linkova wrote a message of 37 lines which said: > It is. Facebook is officially blocked in Russia [1] > > [1] https://rkn.gov.ru/news/rsoc/news74156.htm I know but I was asking *how* it is implemented and it is far from obvious, from the data. He

[atlas] Facebook in Russia and a diagnostic problem

Around half of the RIPE Atlas probes in Russia cannot complete a TLS session with facebook.com . (All the remaining tests have been done with the same set of probes, 'type': 'msm', 'value': '39387725'.) They have no problem with YouTube

Re: [atlas] DNS probes: spurious SERVFAIL

On Sun, May 30, 2021 at 02:27:18PM +0200, Lukas Tribus wrote a message of 41 lines which said: > while troubleshooting DNS issues on the Google network yesterday [1] > we found that RIPE Atlas probes did not recover after Google fixed the > issue, we kept seeing SERVFAIL answers on the RIPE At

Re: [atlas] Result delivery issues - 2021-05-11

On Tue, May 11, 2021 at 09:37:51AM +0200, Robert Kisteleki wrote a message of 11 lines which said: > The RIPE Atlas result storage backend started experiencing issues today at > around 3am (CEST). The team is working on resolving the issue; we'll provide > an update when more information is av

Re: [atlas] Filtering measurements

On Thu, Apr 22, 2021 at 02:20:20PM +0200, Stephane Bortzmeyer wrote a message of 15 lines which said: > I'm afraid you'll have to download the raw JSON file > <https://ftp.ripe.net/ripe/atlas/measurements/>, parse it yourself and > filter according to the "pr

Re: [atlas] Filtering measurements

On Thu, Apr 22, 2021 at 02:01:04PM +0200, Sanaa GHANDI wrote a message of 30 lines which said: > 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

Re: [atlas] Spurious "would violate your maximum daily spending limit"

On Wed, Apr 07, 2021 at 10:11:03AM +, Ponikierski, Grzegorz wrote a message of 115 lines which said: > Atlas takes into account also rate how quickly you spend your > credits and on base of that it tries to predict if you will hit your > daily limit and tries to stop measurements which are

Re: [atlas] Spurious "would violate your maximum daily spending limit"

On Sun, Apr 04, 2021 at 10:54:39AM +0200, Stephane Bortzmeyer wrote a message of 23 lines which said: > Request","code":102,"errors":[{"source":{"pointer":""},"detail":"Executing > this measurement request would vi

[atlas] Spurious "would violate your maximum daily spending limit"

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 100.0 credits. Please stop some of your

Re: [atlas] Probes suffering DNS interception?

On Thu, Dec 10, 2020 at 05:29:46PM +, Ray Bellis wrote a message of 20 lines which said: > Is there any RIPE policy about whether nodes that are subject to DNS > interception should be excluded from results (or maybe even dropped > altogether) ? I disagree. The point of RIPE Atlas probes

Re: [atlas] Problem today? Measurements do not finish

On Wed, Nov 18, 2020 at 10:02:43AM +0100, Alarig Le Lay wrote a message of 22 lines which said: > It seems that the delays are still there: It seems you an recover the data now (note the option --measurement-ID, to avoid making the measurement again). % blaeu-traceroute --format --protocol=I

[atlas] Problem today? Measurements do not finish

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

[atlas] Extreme slowness today?

23 minutes before Atlas tells me there is no suitable probes with my criteria (country=SD, which does not surprise me). Same slowness for all measurements.

Re: [atlas] status-check redirects to itself?

On Wed, Apr 29, 2020 at 08:05:18PM +0200, Philip Homburg wrote a message of 10 lines which said: > The redirect is to a slightly different URL. OK, thanks, I did not notice the detail. But it worked before (I use it in a monitoring script), and the behavior changed somewhere around 29 april,

[atlas] status-check redirects to itself?

Since today, status-check seems to redirect to itself? % curl -v https://atlas.ripe.net/api/v2/measurements/2060427/status-check\?permitted_total_alerts=3 ... < HTTP/1.1 301 Moved Permanently < Server: nginx/1.16.1 < Date: Wed, 29 Apr 2020 17:57:17 GMT < Content-Type: text/html; charset=utf-8 < C

[atlas] Setting the DNS AD bit

It seems there is currently no way to set the AD bit in DNS queries? (Through the API, we can only control RD, CD and DO bits.) --- Begin Message --- Does anyone know of any iterative resolvers one is likely to run into on some ISP's network, hotel, or WiFi hotspot that will choke on queries with A

Re: [atlas] No Atlas today: bad gateway

On Tue, Mar 31, 2020 at 10:40:28AM +0200, Jasper den Hertog wrote a message of 92 lines which said: > There definitely was a glitch, we saw it as well. And it just happened again.

[atlas] No Atlas today: bad gateway

https://atlas.ripe.net/ 502 Bad Gateway nginx/1.16.1 COVID-19 on the server?

Re: [atlas] Reg query of code

On Mon, Feb 24, 2020 at 03:42:05PM +0530, Adarsh Pandey wrote a message of 144 lines which said: > Can we get the code of ripe atlas server As far as I know, it is not public (only the code of the probes is).

Re: [atlas] Using Atlas for Monitoring of Anycast DNS

On Thu, Jan 16, 2020 at 04:33:47PM +0100, Klaus Darilion wrote a message of 48 lines which said: > - analyze the probe locations (ie. country, continent) Instead of analyzing it afterwards, why not directly asking probes on the place you're interested in? I often use NSID to watch anycast se

Re: [atlas] Maintenance or incident?

On Tue, Jan 07, 2020 at 01:50:28PM +0300, Anand Buddhdev wrote a message of 14 lines which said: > This is an incident... the relevant folks are aware, and looking into it. It works again, thanks.

[atlas] Maintenance or incident?

% curl https://atlas.ripe.net/ curl: (7) Failed to connect to atlas.ripe.net port 443: Connection refused It started around 1015 UTC.

Re: [atlas] A new year's break for the probes

On Fri, Jan 03, 2020 at 12:04:37PM +0100, Robert Kisteleki wrote a message of 22 lines which said: > an overlooked fact where the built-in measurements had a pre-defined > end date of 2020-01-01 [...] We fixed this setting on Thursday, 2 > January What is the new date? Before or after the Y20

Re: [atlas] Measurements "synchronizing"

On Wed, Nov 27, 2019 at 02:40:09PM +0100, Stephane Bortzmeyer wrote a message of 9 lines which said: > > > Sorry, I *do* see such delays. Looking into it now! > > > > It works now, thanks. > > Problem just strikes again. And today again :-(

Re: [atlas] Long measurement delays

On Fri, Nov 29, 2019 at 10:07:33PM -0700, Steve Gibbard wrote a message of 35 lines which said: > I’ve been seeing delayed query responses to one-off measurements > since November 22, with the exception of November 25. Isn't it the "synchronizing" problem? (Measurement status is reported as "

Re: [atlas] Finding the NSID in the measurement results

On Wed, Nov 27, 2019 at 01:09:46PM +, Roger Murray wrote a message of 83 lines which said: > So far so good, but when we download the raw measurement result data > we are not able to locate the NSID information. It's in the DNS blob, you have to parse it. Example of source code: https:/

Re: [atlas] Measurements "synchronizing"

On Fri, Nov 15, 2019 at 06:24:04PM +0100, Stephane Bortzmeyer wrote a message of 7 lines which said: > > Sorry, I *do* see such delays. Looking into it now! > > It works now, thanks. Problem just strikes again.

Re: [atlas] Measurements "synchronizing"

On Fri, Nov 15, 2019 at 04:13:16PM +0100, Chris Amin wrote a message of 30 lines which said: > Sorry, I *do* see such delays. Looking into it now! It works now, thanks.

[atlas] Measurements "synchronizing"

It seems that, today, when querying the API about an existing measurement, I always get: {'id': None, 'name': 'synchronizing'} Which I've never seen. (Measurement #23238335 but it's not the only one.) A recent change? A temporay problem?

Re: [atlas] DNS issue with Atlas or with the ISP?

On Mon, Sep 09, 2019 at 12:25:38PM +0200, Bjørn Mork wrote a message of 42 lines which said: > BTW, I seriously doubt that *all* other DNS and RDNSS clients got this > right. Advertising LL DNS servers seems unnecessary risky outside of > the lab. I agree that it is risky, but I'm not the CT

Re: [atlas] DNS issue with Atlas or with the ISP?

On Mon, Sep 09, 2019 at 01:06:48PM +0200, Philip Homburg wrote a message of 20 lines which said: > The problem is that for a link local address you need a scope. The > Atlas measurement code doesn't know how to add one and the addresses > in /etc/resolv.conf don't have one. I was, too, surpri

Re: [atlas] DNS issue with Atlas or with the ISP?

On Sun, Sep 08, 2019 at 06:53:12PM +0200, Stephane Bortzmeyer wrote a message of 26 lines which said: > I assume that the "connect failed Invalid argument" is the fault of > the ISP, which advertises a wrong DNS resolver? Or is the Atlas probe > unable to query link-loca

[atlas] DNS issue with Atlas or with the ISP?

RIPE Atlas Web site displays a lot of "undefined" for the tests in AS 3125. See for instance or But the DNS resolution from this AS seems to work. Checking the raw results in JSON, I see

Re: [atlas] DNS RTT over TCP: twice as long than UDP?

On Fri, Jul 05, 2019 at 12:33:25PM +, Giovane Moura wrote a message of 26 lines which said: > My hypothesis is that the field *rtt* on DNS queries on Atlas[1], > for TCP, is, in fact, measuring 2 RTTs: the RTT of the TCP > handshake, and the RTT of query/response itself. I assume (I didn'

[atlas] Atlas problems this morning?

#22170557, #22171022 and #22171068 terminate but no results are available. Is there some problem going on?

Re: [atlas] When to consider a measurement finished

On Tue, Jun 18, 2019 at 08:08:23PM +0200, Wouter de Vries wrote a message of 26 lines which said: > What heuristics/method do you recommend to determine whether to consider > a measurement as finished? Probing until N % of the requested probes replied. This is implemented in blaeu

Re: [atlas] raspbian.net/raspbian.org ipv6 peering problems

On Tue, Jun 25, 2019 at 09:58:25AM +0200, Thomas Schäfer wrote a message of 17 lines which said: > Does someone measurements to the server of "raspbian"? Indeed, it's not perfect (the sad state of IPv6 connectivity): % blaeu-reach --requested 100 --by_probe 2001:41c9:1:3ce::1:10 99 probes re

Re: [atlas] any clue rtt unreachable packet loss 100% com234.476.249

On Mon, Jun 24, 2019 at 09:35:32AM +0200, Dave . wrote a message of 872 lines which said: > Your destination is not responding to ICMP (ping/traceroute). This > is not an Atlas issue. And, for the services who wrongly block ICMP echo, there is still hope, Atlas probes can run traceroute with

Re: [atlas] DNS-over-TLS and DNS-over-HTTPS measurement

On Mon, Apr 08, 2019 at 04:36:37PM +0200, Petr Špaček wrote a message of 11 lines which said: > could you share plans for DNS-over-TLS and DNS-over-HTTPS measurements? > > I had impression that DNS-over-TLS is already supported but now I cannot > find it in the UI so I'm probably wrong. DNS-

[atlas] DNS measurements broken today?

It seems all DNS measurements (not just mine, checked on return only an empty array today... % curl -s https://atlas.ripe.net/api/v2/measurements/20566896/results/ []%

Re: [atlas] Data in the Internet Maps

On Tue, Dec 18, 2018 at 01:58:30PM +0800, Davey Song wrote a message of 117 lines which said: > It works for me, I receive messages.

Re: [atlas] Need help: launching a periodical atlas measurement

On Thu, Jul 19, 2018 at 10:47:54AM -0500, Yihao Jia wrote a message of 192 lines which said: > I am a little confused because all example on documents is one-off. I guess > error might happen around "is_oneoff", "interval", "spread". > source code for this test is below and in the attachment.

Re: [atlas] Global Traceroute

On Tue, Jul 17, 2018 at 08:58:15PM +0300, Vladislav V. Prodan wrote a message of 57 lines which said: > Firstly, your utility requires API-keys, which have problems getting > them. Fair enough. On the other hand, this means that the Web site needs credits and anonymous Web clients can eat the

Re: [atlas] Need help in launching a periodical atlas measurement

On Thu, Jul 19, 2018 at 08:30:13AM -0500, Yihao Jia wrote a message of 4181 lines which said: > I am in trouble with launching a periodical Ping measurement. > [image: image.png] It is strange to send screenshots instead of text... > my script is like this, but my measurement always fails.

Re: [atlas] Global Traceroute

On Mon, Jul 16, 2018 at 11:49:44PM +0300, Vladislav V. Prodan wrote a message of 50 lines which said: > 6) I want to work correctly in the console programs curl, lynx and wget. Why? If you're a command-line fan like me, why not using the regular programs using the API? % blaeu-traceroute -r

Re: [atlas] DNS measurement using the Probe's resolvers

On Fri, Jul 06, 2018 at 04:30:11PM -0400, Rami Al-Dalky wrote a message of 27 lines which said: > I have a question about using the probe's list of resolvers when > creating a DNS measurement. It is unclear to me whether the probe > would send the query to all resolvers at the same time or not

Re: [atlas] Error: Only anchors may be targeted.

On Mon, Jun 25, 2018 at 03:10:07PM +0200, Guido Iaquinti wrote a message of 16 lines which said: > I was discussing the above with a few friends and I understand that > there might be some security related concerns but I think with a > proper user policy and technical implementation they could

Re: [atlas] No probes working today?

On Tue, Jun 12, 2018 at 03:54:44PM +0200, Stephane Bortzmeyer wrote a message of 9 lines which said: > > The data storage backend had a few hickups today, meaning results > > were queued and served with a delay around 10:00, 11:30 and > > 13:30-15:00. No results were lost.

Re: [atlas] No probes working today?

On Tue, Jun 12, 2018 at 03:50:25PM +0200, Robert Kisteleki wrote a message of 21 lines which said: > The data storage backend had a few hickups today, meaning results > were queued and served with a delay around 10:00, 11:30 and > 13:30-15:00. No results were lost. I confirm it now works. Tha

[atlas] No probes working today?

DNS measurements don't start today, no probes are selected for a long time. See for instance (long delay) or (no probes)

Re: [atlas] CLI

On Sun, Jun 03, 2018 at 04:53:36PM +0430, Milad Afshari wrote a message of 115 lines which said: > Thanks for your suggestion, I have installed the " blaeu" and It is working > better now. Since many people use the streaming interface without problems, I suspect a local MiTM TLS interceptor d

Re: [atlas] CLI

On Wed, May 30, 2018 at 11:13:11AM +0430, Milad Afshari wrote a message of 97 lines which said: > Exception in thread Thread-1 (most likely raised during interpreter shutdown): > Traceback (most recent call last): > File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner > F

Re: [atlas] CLI

On Wed, May 09, 2018 at 12:35:04PM +0430, Milad Afshari wrote a message of 26 lines which said: > It's more than a month that I have a lot of issues with running > measurements through CLI here from IRAN, the measurements starts > correctly but the results will not be displayed. It may be of

Re: [atlas] dnssec validating system tag?

On Sat, Apr 21, 2018 at 03:57:26AM +0300, Tapio Sokura wrote a message of 9 lines which said: > Has there been thoughts about making the probes do dnssec resolver > statistics gathering? I.e. how many / which probes are configured > with dns resolvers that do / don't do dnssec validation? It

Re: [atlas] TLS error when the certificate is expired?

On Mon, Apr 16, 2018 at 03:02:50PM +0200, Philip Homburg wrote a message of 33 lines which said: > What is typically the case is that the server side has all kinds of > restrictions on the ciphers that it is willing to accept. > > I recently made some changes to support a server where the ssl

[atlas] TLS error when the certificate is expired?

I'm reasonably certain that it has been possible to use 'sslcert' measurements even when the certificate is expired. Today, I try to use 'sslcert' with trigger-happy.eu and it fails: "alert": { "description": 40, "level": 2 }, And no certificate in the JSON output (this is me

Re: [atlas] beta status page vs. ipv6 only network

On Fri, Jan 12, 2018 at 11:02:02AM +0100, Robert Kisteleki wrote a message of 31 lines which said: > I'd think it's relatively difficult to automatically (i.e. system) > tag probes as "intentionally single stack", as we don't really know > if that's a misconfiguration (e.g. DHCP server is down

Re: [atlas] Effect of "Resolve on Probe"-option

On Fri, Dec 01, 2017 at 03:44:22PM +0100, Tim Wattenberg wrote a message of 123 lines which said: > In my measurement I activated the option to use the probes > resolver(s) and left the option to resolve on the probe deactivated. The documentation

Re: [atlas] dig +trace equivalency

On Sat, Nov 25, 2017 at 02:12:06PM +0900, dikshie wrote a message of 11 lines which said: > I use to use +trace option in dig command. > Is there any same function equivalency in Atlas's DNS measurement tool? dig +trace is not very reliable, and does not work with all resolvers. And, no, I do

Re: [atlas] Trying to measure Quad9 latency

On Thu, Nov 23, 2017 at 09:56:02AM +0100, Michael Meier wrote a message of 29 lines which said: > Quad9 seem to do some _extremely_ weird nonsense. > We were measuring ICMP-latency just from different machines on the same > subnet and saw _huge_ differences in the responses: Well, a DNS serve

Re: [atlas] Trying to measure Quad9 latency

On Wed, Nov 22, 2017 at 06:27:42PM +, Eduardo Duarte wrote a message of 289 lines which said: > When I got the results from the measurement they were not what I > expected The measurements to Quad9 had high value of REFUSAL. You did not set the RD (Recursion Desired) bit. Most resolve

[atlas] A Go library to talk to RIPE Atlas

https://blog.keltia.net/2017/11/13/ripe-atlas-is-usable-dot-dot-dot/ [Still a bit rough...]

[atlas] Recent TLS supported by probes?

I cannot get the certificate for (measurement #10174881): "alert" is "{u'description': 40, u'level': 2}". It works with other, more "mainstream", HTTPS sites (see #10174883). I suspect this is because the probes don't handle the recent TLS stuff. Can anyone conf

[atlas] Problem in status checks?

Error 500 when trying to retrieve status checks: % curl -v 'https://atlas.ripe.net/api/v2/measurements/2060427/status-check?permitted_total_alerts=3' ... > GET /api/v2/measurements/2060427/status-check?permitted_total_alerts=3 > HTTP/1.1 > Host: atlas.ripe.net > User-Agent: curl/7.52.1 > Accept:

Re: [atlas] List of Atlas probes subjected to DNS traffic interception (MITM)

On Fri, Sep 29, 2017 at 02:56:12PM +0200, Baptiste Jonglez wrote a message of 56 lines which said: > What I mean by "traffic interception" is that DNS queries from the > probe to a third-party DNS server do not reach the server, but are > intercepted and answered by a middle-box instead. Many

Re: [atlas] Can Atlas probe handle Truncated response ?

On Tue, Sep 05, 2017 at 11:33:23AM +0800, Davey Song wrote a message of 102 lines which said: > I once setup a measurement of DNS UDP to see if the number of > timeout increase due to large response. The answer is yes. But I > wonder if the timeout is no answer after three times of retries or

  1   2   >