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

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

[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:

[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

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,

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

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: [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

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

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

[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

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.

[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

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

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 "probes"

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

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

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

[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 <

[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

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

[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] 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:

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

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,

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

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

[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: [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.

[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

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

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

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.

[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

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 >

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

[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

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

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

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

[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

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

[atlas] [rfc-edi...@rfc-editor.org: RFC 8193 on Information Model for Large-Scale Measurement Platforms (LMAPs)]

This recent RFC on the data model for Internet measurements platform is of course of interest for RIPE Atlas. Note that their model separates controller and collector, which are one in Atlas. --- Begin Message --- A new Request for Comments is now available in online RFC libraries.

[atlas] [ripe-atlas-tools] Anyone had success with renderer aggregate_ping?

I cannot make the renderer aggregate_ping work: https://github.com/RIPE-NCC/ripe-atlas-tools/issues/186

[atlas] TLS tests with login.live.com

TLS tests from the Atlas probes work for me, for every server... *but* login.live.com, for which I always get timeouts (it works with other TLS clients). Measurement #8775150 if someone has an idea...

Re: [atlas] DNS and recursion

On Mon, May 22, 2017 at 02:15:54PM +0200, Chris Amin wrote a message of 89 lines which said: > This behaviour is still > documented in the manual: > https://atlas.ripe.net/docs/api/v2/manual/measurements/types/type_specific_attributes.html OK, I see, there was a problem in my

[atlas] DNS and recursion

API v1 had a field recursion_desired when performing DNS measurements. If I remember correctly (but I cannot find the reference right now), it worked only when querying a specific name server, and not when using the probe's own resolver, to avoid cache snooping. API v2 has instead a set_rd_bit.

Re: [atlas] DNS over TCP problems?

On Tue, Mar 21, 2017 at 05:10:02PM +0100, Stephane Bortzmeyer <bortzme...@nic.fr> wrote a message of 204 lines which said: > [I did not test it myself.] According to DNSmon, there is indeed a problem since 14 March: https://atlas.ripe.net/dnsmon/group/fr.?dnsmon.session.color_range

Re: [atlas] Cannot understand the daily limit

On Tue, Mar 21, 2017 at 03:11:46PM +0100, Stephane Bortzmeyer <bortzme...@nic.fr> wrote a message of 15 lines which said: > But I'm still puzzled about exactly what happened. I checked my > previous measurements (such as #7932387) and they were clearly > marked "This is a

[atlas] DNS over TCP problems?

[I did not test it myself.] --- Begin Message --- It appears that RIPE ATLAS is having issues with the ability to do TCP-based DNS queries as part of their probes. Anyone else able to confirm this issue? Here's an image of RIPE ATLAS saying that all of L-Root is unreachable on TCP. -Jacob Zack

Re: [atlas] Cannot understand the daily limit

On Tue, Mar 21, 2017 at 12:30:05PM +0100, Viktor Naumov wrote a message of 20 lines which said: > The system thinks that you are creating a recurrent measurements > which costs above 1M. You're putting the one-off flag inside > definitions but it must be outside. Like

Re: [atlas] Cannot understand the daily limit

On Tue, Mar 21, 2017 at 12:30:05PM +0100, Viktor Naumov wrote a message of 20 lines which said: > The system thinks that you are creating a recurrent measurements > which costs above 1M. You're putting the one-off flag inside > definitions but it must be outside. Like

[atlas] Trivia of the day: Atlas probes and alternative DNS roots

A quick test with a thousand probes seem to indicate that less than a dozen of all the probes use an alternative DNS root (or, more stricly, use a DNS resolver which is configured for an alternative root). The only alternative root used seems to be OpenNIC. Measurements #7865679 #7865870

[atlas] Atlas API down?

RIPEAtlas.RequestSubmissionError: Status 405, reason "{"error":{"status":405,"code":104,"detail":"Method \"POST\" not allowed.","title":"Method Not Allowed"}}" Just when I wanted to investigate pool.ntp.org failure :-(

Re: [atlas] ripe.atlas.net issues

On Wed, Oct 05, 2016 at 01:54:59PM +0200, Max Mühlbronner wrote a message of 8 lines which said: > "Oops - this page experienced an error while loading." My atlas / My probe > does not work, the checks are failing. (Since ~12 minutes) RIPE Atlas Web site works for me (but

Re: [atlas] "Invalid target" error for RFC 1918 space

On Sun, Sep 18, 2016 at 10:19:52AM -0500, Yang Yu wrote a message of 9 lines which said: > I got "Invalid target" error when I tried to create a measurement to > see how far some RFC 1918 prefixes got propagated (carrier not > properly filtering customer announcement).

[atlas] Alternative to jq: gron

It seems many people here use jq to browse JSON files. I've been referred recently to gron which is quite different: less features but probably simpler to use for beginners. Unlike jq, gron does not have a filtering language: it just formats the JSON in a way

[atlas] Implementing structured error reports ("Problem Details for HTTP APIs")?

Hello, IETF approved the future RFC draft-ietf-appsawg-http-problem "Problem Details for HTTP APIs" which standardize structured error reports (in JSON) to add machine-readable information to HTTP error codes. Would it be a good idea to convert current Atlas reports

Re: [atlas] integrity checks for the Atlas software?

On Tue, Jan 12, 2016 at 06:54:09AM -0500, Tanner Ryan wrote a message of 52 lines which said: > I think that is completely possible. No, for the reasons explained by Micha and Dario. For a detailed survey (using the PC as an example), see this excellent review

Re: [atlas] more than 10 concurrent measurements to the same target

On Wed, Dec 09, 2015 at 07:38:52PM +0100, Klaus Darilion wrote a message of 12 lines which said: > When scheduling checks I often get the error: "We do not allow more than > 10 concurrent measurements to the same target." > > Imo this is not correct. I believe

Re: [atlas] Support for arbitrary DNS queries

On Wed, Dec 09, 2015 at 08:51:21PM +0200, Micha Bailey wrote a message of 48 lines which said: > > A partial workaround is to use ANY as a query_type. > > > > Not necessarily: > https://tools.ietf.org/html/draft-jabley-dnsop-refuse-any-00#section-8 and >

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

http://root-servers.org/news/events-of-20151130.txt

Re: [atlas] [Request] System tags for DNS resolution

On Sun, Nov 15, 2015 at 09:32:09AM +0200, Chris Amin wrote a message of 64 lines which said: > I think what is happening here is that all of those probes except > for 17854 have at least *one* resolver which does respond to > queries. OK, I get it. I modified resolve-name

Re: [atlas] Spoofing measurenment

On Tue, Nov 17, 2015 at 07:01:24PM +0100, Peter Koch wrote a message of 10 lines which said: > while this may sound tempting, I think it would be more helpful in > the long run to maintain atlas probes as a tool to map the Internet > rather than as "spy in the house". Hmmm,

Re: [atlas] [Request] System tags for DNS resolution

On Thu, Nov 12, 2015 at 10:41:03AM +0100, Chris Amin wrote a message of 75 lines which said: > > For instance, probes 16659, 17072, 17620, 17854 use a resolver > > which yields a REFUSED for any request and probe 19948, 20065 one > > with systematic SERVFAIL. ... > The above

[atlas] [Request] System tags for DNS resolution

[Is there a better way to record enhancement requests for Atlas? Atlas has no public issue tracker, if I'm correct?] It would be cool to have system (automatic) tags for DNS resolution because some probes are using broken DNS resolvers. For instance, system-dns-works (modeled on IPv6's system

[atlas] Any way to select the probes from upstream AS (not origin AS)?

Is there an easy way to select probes, not on the origin AS, but on an AS upstream? Example: probe 23865, IP prefix announced by AS 56339 which currently has only one provider, AS 16080. Currently, Atlas tells me there are no probes in AS 16080...

Re: [atlas] VM probes

On Mon, Nov 09, 2015 at 12:49:19PM +, Colin Johnston wrote a message of 30 lines which said: > one vote for vmware virtualisation Strong -1 against any proprietary technology. Free software or nothing. (But, like most people here, I'm not interested in VM probes and

Re: [atlas] Any way to select the probes from upstream AS (not origin AS)?

On Wed, Nov 11, 2015 at 04:43:49PM +0100, Robert Kisteleki wrote a message of 14 lines which said: > No, we don't have direct support for this. I guess one could > download latest traceroute results for a (random) built-in > measurement, map IPs to ASNs and use that -- but I

Re: [atlas] Read on RIPE Labs about the newest features & the community efforts

On Thu, Nov 05, 2015 at 10:36:11AM +0100, Vesna Manojlovic wrote a message of 9 lines which said: > https://labs.ripe.net/Members/kistel/ripe-atlas-update-http-measurements-cli-tools-domainmon-and-more Apparently, there is no link to the documentation of the API v2. Where is

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

On Thu, Oct 22, 2015 at 05:42:37PM +0200, Wenqin SHAO wrote a message of 33 lines which said: > I recall (I tried and failed to find the reference for the moment > being) that in France, some type of metadata might be as well > sensitive, say a URL, My talk

  1   2   >