From bortzmeyer at nic.fr Wed Mar 1 01:13:04 2017
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 28 Feb 2017 16:13:04 -0800
Subject: [atlas] Testing DNS-over-TLS support?
Message-ID: <20170301001304.GA17847@laperouse.bortzmeyer.org>
DNS-over-TLS (RFC 7858) is important for privacy but, today, few DNS
resolvers support it. It would be interesting to measure if this is
changing, but the probes do not seem to be able to query their
resolver with TLS over port 853. (Also, I seem to remember that old
probes do not have a full TLS implementation.)
It is not just a matter of encrypting the data, it's also an
authentication issue (Google Public DNS was already impersonated
)
So, how about adding a 'use_tls': True after 'use_probe_resolver':
True?
From philip.homburg at ripe.net Wed Mar 1 13:52:04 2017
From: philip.homburg at ripe.net (Philip Homburg)
Date: Wed, 1 Mar 2017 13:52:04 +0100
Subject: [atlas] Testing DNS-over-TLS support?
In-Reply-To: <20170301001304.GA17847@laperouse.bortzmeyer.org>
References: <20170301001304.GA17847@laperouse.bortzmeyer.org>
Message-ID: <8acd984a-7fd8-3077-f0ea-1c03027fc482@ripe.net>
Hi Stephane,
On 2017/03/01 1:13 , Stephane Bortzmeyer wrote:
> DNS-over-TLS (RFC 7858) is important for privacy but, today, few DNS
> resolvers support it. It would be interesting to measure if this is
> changing, but the probes do not seem to be able to query their
> resolver with TLS over port 853. (Also, I seem to remember that old
> probes do not have a full TLS implementation.)
What works today is the sslgetcert measurement and traceroute with tcp.
That should give some idea about how often 853 is blocked.
At the moment, no probes have a full tls implementation (in the
measurement code).
> So, how about adding a 'use_tls': True after 'use_probe_resolver':
> True?
That makes sense, but there are a lot of things to do wrt probe code.
Philip
From hsalgado at vulcano.cl Wed Mar 1 15:18:25 2017
From: hsalgado at vulcano.cl (Hugo Salgado)
Date: Wed, 1 Mar 2017 11:18:25 -0300
Subject: [atlas] Feature request: API call in results page
Message-ID:
Hi RIPE Atlas people.
I wonder if it could be possible to add an option on the "measurements"
webpage of a previous stopped or running measurement, to be able to see
the API call that created it. Just like the "Measurement API Compatible
Specification" section, when you create one. It could be available just
to the user who created it... and even with API keys obscured.
That will be very handy to be able to replay and exact measurement, or
to have the list of probes in a ready-to-use format.
Thanks a lot!
Hugo Salgado
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jordi.palet at consulintel.es Wed Mar 1 19:12:18 2017
From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ)
Date: Wed, 01 Mar 2017 19:12:18 +0100
Subject: [atlas] changing probes of a given measurement
Message-ID: <0BDB59F9-3017-4099-BD72-C9BF42B22112@consulintel.es>
Hi,
Is it possible to change some of the probes of a given measurement?
The issue is that I?ve a set of 10 probes for a specific measurement and it seems that 1 of them is no longer connected.
Last time I?d this situation, I created a new measurement with the same probes except the failed one, but I wonder if it is possible to ?modify? the actual measurement instead of creating a new one?
Regards,
Jordi
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
From robert at ripe.net Wed Mar 1 19:25:00 2017
From: robert at ripe.net (Robert Kisteleki)
Date: Wed, 1 Mar 2017 10:25:00 -0800
Subject: [atlas] changing probes of a given measurement
In-Reply-To: <0BDB59F9-3017-4099-BD72-C9BF42B22112@consulintel.es>
References: <0BDB59F9-3017-4099-BD72-C9BF42B22112@consulintel.es>
Message-ID:
On 2017-03-01 10:12, JORDI PALET MARTINEZ wrote:
> Hi,
>
> Is it possible to change some of the probes of a given measurement?
>
> The issue is that I?ve a set of 10 probes for a specific measurement and it seems that 1 of them is no longer connected.
>
> Last time I?d this situation, I created a new measurement with the same probes except the failed one, but I wonder if it is possible to ?modify? the actual measurement instead of creating a new one?
>
> Regards,
> Jordi
Hi,
This is possible via the API. The magic keyword is "participation request"
-- you can add or remove to/from an ongoing measurement.
Hope this helps,
Robert
From ck+atlasripe at bl4ckb0x.de Thu Mar 2 00:39:08 2017
From: ck+atlasripe at bl4ckb0x.de (Conrad Kostecki)
Date: Wed, 01 Mar 2017 23:39:08 +0000
Subject: [atlas] Your probe is currently disconnected
Message-ID:
Hi!
I've applied for an Atlas probe v3 and got one via postage.
So, I've connected the probe to my network.
I can see in my DNSMasq logs, that the probe gets successfully an IP
address. It can be pinged without any problems.
But that's all. Even after 24 hours it's still reported not connected.
I can see multiple LEDs:
1 (power): on
2: off
3: slow blink
4: fast blink
5 (button): on
I can't find that in the FAQ, the LEDs should light different.
The FAQ also did mention to try first without USB and insert USB later.
Or try to replace the USB. Both cases did not help.
If I connect my ThinkPad instead the probe with the same network
connection (cable and port), it can access the internet just fine
without any problems.. I've no clou, what could be wrong. Any ideas?
Thanks!
Conrad
Viele Gr??e
Conrad Kostecki
From jandrewartha at ccgs.wa.edu.au Thu Mar 2 04:23:50 2017
From: jandrewartha at ccgs.wa.edu.au (James Andrewartha)
Date: Thu, 2 Mar 2017 11:23:50 +0800
Subject: [atlas] Your probe is currently disconnected
In-Reply-To:
References:
Message-ID: <1ea868a5-282c-f9b6-cf42-aac601ae0c9c@ccgs.wa.edu.au>
Hi Conrad,
On 02/03/17 07:39, Conrad Kostecki wrote:
> So, I've connected the probe to my network.
> I can see in my DNSMasq logs, that the probe gets successfully an IP
> address. It can be pinged without any problems.
>
> But that's all. Even after 24 hours it's still reported not connected.
[snip LEDs]
> The FAQ also did mention to try first without USB and insert USB later.
> Or try to replace the USB. Both cases did not help.
How long did you leave it booting without the USB before plugging it in?
In your probe's network tab on the website, do you see anything in the
SOS history?
My probe that I received in January also didn't connect automatically, I
had to follow the re-initialisation procedure for it to connect.
Thanks,
--
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877
From listclient at sokolov.eu.org Thu Mar 2 05:56:02 2017
From: listclient at sokolov.eu.org (Daniel AJ Sokolov)
Date: Thu, 2 Mar 2017 00:56:02 -0400
Subject: [atlas] Your probe is currently disconnected
In-Reply-To:
References:
Message-ID:
On 2017-03-01 at 19:39, Conrad Kostecki wrote:
> So, I've connected the probe to my network.
[...]
> If I connect my ThinkPad instead the probe with the same network
> connection (cable and port), it can access the internet just fine
> without any problems.. I've no clou, what could be wrong. Any ideas?
Unlikely, but possible: The router/modem could restrict network access
by MAC address. That could explain why one device (laptop) can connect,
while another (probe) can not.
Unlikely, but worth checking.
BR
Daniel AJ
From jon.brewer at gmail.com Thu Mar 2 08:10:33 2017
From: jon.brewer at gmail.com (Jonathan Brewer)
Date: Thu, 2 Mar 2017 14:10:33 +0700
Subject: [atlas] Your probe is currently disconnected
In-Reply-To:
References:
Message-ID:
On 2 March 2017 at 11:56, Daniel AJ Sokolov
wrote:
> On 2017-03-01 at 19:39, Conrad Kostecki wrote:
> > So, I've connected the probe to my network.
> [...]
> > If I connect my ThinkPad instead the probe with the same network
> > connection (cable and port), it can access the internet just fine
> > without any problems.. I've no clou, what could be wrong. Any ideas?
>
> Unlikely, but possible: The router/modem could restrict network access
> by MAC address. That could explain why one device (laptop) can connect,
> while another (probe) can not.
>
>
This is a very possible - the USB key hardware fault can cause exactly this
behaviour.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From pc.chiodi at activenetwork.it Thu Mar 2 09:28:50 2017
From: pc.chiodi at activenetwork.it (Pier Carlo Chiodi - Active Network S.p.A.)
Date: Thu, 2 Mar 2017 09:28:50 +0100
Subject: [atlas] SSL issue with atlas.ripe.net
Message-ID:
Hello,
I'm facing an issue while using Atlas API.
Some connections (not all) to https://atlas.ripe.net fail because of
what seems to be an invalid certs chain. It looks like that an
intermediate cert is missing.
SSLLabs too reports something similar:
https://www.ssllabs.com/ssltest/analyze.html?d=atlas.ripe.net&s=193.0.6.158
$ openssl s_client -connect atlas.ripe.net:443 -servername atlas.ripe.net
CONNECTED(00000003)
depth=0 C = NL, ST = Noord-Holland, L = Amsterdam, O = RIPE NCC, CN =
atlas.ripe.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = NL, ST = Noord-Holland, L = Amsterdam, O = RIPE NCC, CN =
atlas.ripe.net
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = NL, ST = Noord-Holland, L = Amsterdam, O = RIPE NCC, CN =
atlas.ripe.net
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=NL/ST=Noord-Holland/L=Amsterdam/O=RIPE NCC/CN=atlas.ripe.net
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High
Assurance Server CA
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/C=NL/ST=Noord-Holland/L=Amsterdam/O=RIPE NCC/CN=atlas.ripe.net
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High
Assurance Server CA
---
...
Verify return code: 21 (unable to verify the first certificate)
--
Pier Carlo Chiodi - Active Network S.p.A.
via della Chimica, 18 - 01100 Viterbo
Tel: +39 0761 17691 08 - Fax: +39 06 23328079
From bjorn at mork.no Thu Mar 2 09:52:40 2017
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Thu, 02 Mar 2017 09:52:40 +0100
Subject: [atlas] SSL issue with atlas.ripe.net
In-Reply-To: (Pier
Carlo Chiodi's message of "Thu, 2 Mar 2017 09:28:50 +0100")
References:
Message-ID: <87poi0qcvb.fsf@miraculix.mork.no>
"Pier Carlo Chiodi - Active Network S.p.A."
writes:
> Some connections (not all) to https://atlas.ripe.net fail because of
> what seems to be an invalid certs chain. It looks like that an
> intermediate cert is missing.
I see the same problem. Extra data point: The requests appear to be
served by one or more Apache instances and one or more nginx instances.
The chain is complete and validation suceccessful for Apache. The chain
is incomplete and validation fails for nginx.
Apache:
bjorn at miraculix:/tmp$ openssl s_client -connect 193.0.6.158:443 -servername atlas.ripe.net
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
verify return:1
depth=0 C = NL, ST = Noord-Holland, L = Amsterdam, O = RIPE NCC, CN = atlas.ripe.net
verify return:1
Server did acknowledge servername extension.
---
Certificate chain
0 s:/C=NL/ST=Noord-Holland/L=Amsterdam/O=RIPE NCC/CN=atlas.ripe.net
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
---
..
---
SSL handshake has read 4752 bytes and written 773 bytes
Verification: OK
---
..
---
HEAD / HTTP/1.0
HTTP/1.1 400 Bad Request
Date: Thu, 02 Mar 2017 08:47:32 GMT
Server: Apache
Strict-Transport-Security: max-age=15768000
Connection: close
Content-Type: text/html; charset=iso-8859-1
closed
nginx:
bjorn at miraculix:/tmp$ openssl s_client -connect 193.0.6.158:443 -servername atlas.ripe.net
CONNECTED(00000003)
depth=0 C = NL, ST = Noord-Holland, L = Amsterdam, O = RIPE NCC, CN = atlas.ripe.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = NL, ST = Noord-Holland, L = Amsterdam, O = RIPE NCC, CN = atlas.ripe.net
verify error:num=21:unable to verify the first certificate
verify return:1
Server did acknowledge servername extension.
---
Certificate chain
0 s:/C=NL/ST=Noord-Holland/L=Amsterdam/O=RIPE NCC/CN=atlas.ripe.net
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
---
..
---
SSL handshake has read 2578 bytes and written 325 bytes
Verification error: unable to verify the first certificate
---
..
---
HEAD / HTTP/1.0
HTTP/1.1 403 Forbidden
Server: nginx/1.10.2
Date: Thu, 02 Mar 2017 08:47:40 GMT
Content-Type: text/html
Content-Length: 169
Connection: close
Strict-Transport-Security: max-age=15768000; includeSubDomains
closed
Bj?rn
From rzwart at ripe.net Thu Mar 2 10:56:31 2017
From: rzwart at ripe.net (Romeo Zwart)
Date: Thu, 2 Mar 2017 10:56:31 +0100
Subject: [atlas] modifications to Atlas front-end servers
Message-ID: <9c9c5615-beb6-15b5-d7aa-90920b98bdc3@ripe.net>
dear Pier, Bj?rn and all,
We are in the process of migrating the atlas front-end machinery from
apache to nginx. Despite our extensive preparations, this change has not
been completely transparent, as you have noticed, and has caused some
problems with the certificate chains.
The problems with the CERTs have now been fixed.
Apologies for this inconvenience to everyone.
Please let us know if you would spot any other anomalies in the
behaviour of the Atlas service.
Kind regards,
Romeo Zwart
From ck+atlasripe at bl4ckb0x.de Thu Mar 2 20:21:59 2017
From: ck+atlasripe at bl4ckb0x.de (Conrad Kostecki)
Date: Thu, 02 Mar 2017 19:21:59 +0000
Subject: [atlas] Your probe is currently disconnected
In-Reply-To:
References:
Message-ID:
Hello Daniel,
Am 02.03.2017 05:56:02, "Daniel AJ Sokolov"
schrieb:
>Unlikely, but possible: The router/modem could restrict network access
>by MAC address. That could explain why one device (laptop) can connect,
>while another (probe) can not.
>
>Unlikely, but worth checking.
>
Nope ;-) This is my home network here, I don't have any restriction by
MAC.
Conrad
From ck+atlasripe at bl4ckb0x.de Thu Mar 2 20:23:12 2017
From: ck+atlasripe at bl4ckb0x.de (Conrad Kostecki)
Date: Thu, 02 Mar 2017 19:23:12 +0000
Subject: [atlas] Your probe is currently disconnected
In-Reply-To: <1ea868a5-282c-f9b6-cf42-aac601ae0c9c@ccgs.wa.edu.au>
References:
<1ea868a5-282c-f9b6-cf42-aac601ae0c9c@ccgs.wa.edu.au>
Message-ID:
Hi James!
Am 02.03.2017 04:23:50, "James Andrewartha"
schrieb:
>How long did you leave it booting without the USB before plugging it
>in?
>In your probe's network tab on the website, do you see anything in the
>SOS history?
The last time, I've waited about 24 hours.
I've plugged it now again without the usb stick, 2 hours ago.
So without an usb stick, it always should list at least a SOS message?
Because, after the 2 hours now, it's still marked as disconnected.
Conrad
Viele Gr??e
Conrad Kostecki
From robert at ripe.net Thu Mar 2 20:45:06 2017
From: robert at ripe.net (Robert Kisteleki)
Date: Thu, 2 Mar 2017 11:45:06 -0800
Subject: [atlas] Your probe is currently disconnected
In-Reply-To:
References:
<1ea868a5-282c-f9b6-cf42-aac601ae0c9c@ccgs.wa.edu.au>
Message-ID:
On 2017-03-02 11:23, Conrad Kostecki wrote:
> Hi James!
>
> Am 02.03.2017 04:23:50, "James Andrewartha"
> schrieb:
>
>> How long did you leave it booting without the USB before plugging it in?
>> In your probe's network tab on the website, do you see anything in the
>> SOS history?
> The last time, I've waited about 24 hours.
> I've plugged it now again without the usb stick, 2 hours ago.
>
> So without an usb stick, it always should list at least a SOS message?
> Because, after the 2 hours now, it's still marked as disconnected.
>
> Conrad
>
> Viele Gr??e
> Conrad Kostecki
Hi,
The probe should send SOS messages at each boot regardless of having a USB
stick or not. However, it cannot connect to the infrastructure without one,
as it does not have the needed firmware. You need to insert one a few
minutes after booting.
In case that doesn't help, our staff may be able to help you further if you
send mail to atlas at ripe.net mentioning your probe's ID.
Regards,
Robert
From danny at trisect.uk Thu Mar 2 20:57:35 2017
From: danny at trisect.uk (Danny Horne)
Date: Thu, 2 Mar 2017 19:57:35 +0000
Subject: [atlas] USB stick?
Message-ID: <60dcad0ab10c40b2824c0ca8bc787902@trisect.uk>
Hi all,
I've seen in another thread mention of a USB stick. I've got an Atlas probe coming and haven't seen mention of a USB stick anywhere else, just the need for an Ethernet connection and USB power adapter.
Have I missed something?
Thanks for looking
Regards
Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From emil at emilstahl.dk Thu Mar 2 21:12:22 2017
From: emil at emilstahl.dk (Emil Stahl Pedersen)
Date: Thu, 02 Mar 2017 20:12:22 +0000
Subject: [atlas] USB stick?
In-Reply-To: <60dcad0ab10c40b2824c0ca8bc787902@trisect.uk>
References: <60dcad0ab10c40b2824c0ca8bc787902@trisect.uk>
Message-ID:
The probe is shipped with a small USB stick inserted.
On Thu, Mar 2, 2017 at 21:04 Danny Horne wrote:
> Hi all,
>
>
>
> I?ve seen in another thread mention of a USB stick. I?ve got an Atlas
> probe coming and haven?t seen mention of a USB stick anywhere else, just
> the need for an Ethernet connection and USB power adapter.
>
>
>
> Have I missed something?
>
>
>
> Thanks for looking
>
>
>
> Regards
>
> Danny
>
--
Med venlig hilsen / Best regards
Emil Stahl Pedersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_1662.PNG
Type: image/png
Size: 6870 bytes
Desc: not available
URL:
From camin at ripe.net Fri Mar 3 11:10:04 2017
From: camin at ripe.net (Chris Amin)
Date: Fri, 3 Mar 2017 11:10:04 +0100
Subject: [atlas] Feature request: API call in results page
In-Reply-To:
References:
Message-ID: <078e1d27-9cfb-4830-6e6f-14b4543746a9@ripe.net>
On 01/03/2017 15:18, Hugo Salgado wrote:
> Hi RIPE Atlas people.
> I wonder if it could be possible to add an option on the "measurements"
> webpage of a previous stopped or running measurement, to be able to see
> the API call that created it. Just like the "Measurement API Compatible
> Specification" section, when you create one. It could be available just
> to the user who created it... and even with API keys obscured.
>
> That will be very handy to be able to replay and exact measurement, or
> to have the list of probes in a ready-to-use format.
Hi Hugo,
Replicating existing measurements is something which has been on our
radar for a while, and we are considering options similar to that which
you propose.
In the meanwhile, you can get a lot of the way towards replicating a
measurement by basing your POST data on the JSON measurement spec from
the API (/api/v2/measurements/{existing_msm_id}/) and using the "msm"
type of probe selection
(https://atlas.ripe.net/docs/api/v2/manual/measurements/types/in_detail.html)
to run the measurement on the same set of probes (if desired).
Thanks for the feedback.
Regards,
Chris Amin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
From bortzmeyer at nic.fr Fri Mar 3 17:22:25 2017
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Fri, 3 Mar 2017 17:22:25 +0100
Subject: [atlas] HTTPS interception in Atlas probes
Message-ID: <20170303162225.wicgycv5fjx5hi2z@nic.fr>
After this excellent talk at NDSS 17
,
I wanted to see if there are some Atlas probes behind such an
interceptor. I cannot run on all Atlas probes (maximum daily spending limit) but I've found at least one:
% python cert.py --requested 500 --area North-Central --issuer www.afnic.fr
497 probes reported
[] : 1 occurrences
[] : 496 occurrences
Test #7854923 done at 2017-03-03T16:20:43Z
The probe is #10035, in Amsterdam
The cert.py program is at
From eduardo.duarte at dns.pt Sun Mar 5 23:20:48 2017
From: eduardo.duarte at dns.pt (Eduardo Duarte)
Date: Sun, 05 Mar 2017 23:20:48 +0100
Subject: [atlas] Probe Fulfilment
Message-ID:
Hi,
I have craeted several measurements and the I always have a lower "Probe Fulfilment" rate. What does this mean?
Thank you,
Eduardo
Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
From danny at trisect.uk Mon Mar 6 11:20:04 2017
From: danny at trisect.uk (Danny Horne)
Date: Mon, 6 Mar 2017 10:20:04 +0000
Subject: [atlas] Probe Fulfilment
In-Reply-To:
References:
Message-ID:
I think it just means that some of the probes in your selected geographical area / ASN are offline
-----Original Message-----
From: ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Eduardo Duarte
Sent: Sunday, 5 March 2017 10:21 pm
To: ripe-atlas at ripe.net
Subject: [atlas] Probe Fulfilment
Hi,
I have craeted several measurements and the I always have a lower "Probe Fulfilment" rate. What does this mean?
Thank you,
Eduardo
Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
From ck+atlasripe at bl4ckb0x.de Mon Mar 6 23:23:04 2017
From: ck+atlasripe at bl4ckb0x.de (Conrad Kostecki)
Date: Mon, 06 Mar 2017 22:23:04 +0000
Subject: [atlas] Your probe is currently disconnected
In-Reply-To:
References:
Message-ID:
Am 02.03.2017 00:39:08, "Conrad Kostecki"
schrieb:
>Any ideas?
I've found the cause. It was a small typo for the assigned DNS server
via DHCP.
After setting the correct one, the probe is now working correctly.
But it's strange, because the wrong DNS is also reachable via ThinkPad,
but is in a different subnet.
It should have worked with the probe.
Anyway, it's working now.
Cheers
Conrad
From remaker at gmail.com Tue Mar 7 00:41:20 2017
From: remaker at gmail.com (Phillip Remaker)
Date: Mon, 6 Mar 2017 15:41:20 -0800
Subject: [atlas] Failing probe, all lights blink
Message-ID:
This is a new one for me.
A V3 probe, when powered on, lights the power light, and then blinks all
other lights for about a second every few seconds. Forever.
I opened a case on it and was referred to the USB stick recovery process.
Sigh. This is not that problem, I know how to deal with the USB stick issue.
Has anyone seen this? Is there a deeper recovery trick we can use? I'm
perfectly happy to attach a console to the TP-Link device. I was planning
on doing it anyway to see what errors I am getting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From vnaumov at ripe.net Tue Mar 7 10:01:27 2017
From: vnaumov at ripe.net (Viktor Naumov)
Date: Tue, 7 Mar 2017 10:01:27 +0100
Subject: [atlas] Failing probe, all lights blink
In-Reply-To:
References:
Message-ID: <153d29fe-a256-29bd-c380-7f4a414b3c5d@ripe.net>
Hi Philip,
The chance that is bricked is very low so there is no need for such
hardcore methods :)
On the
https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean
you can find your LED flashing patterns. If the second led is blinking
slow it looks like it is running from the internal flash which means
that either external flash is corrupted or damaged. Sometimes you're
able to format the flash but do not notice the reduced size. Probe will
not be able to function if the flash drive is smaller than 4GB.
WBR
/vty
On 3/7/17 12:41 AM, Phillip Remaker wrote:
> This is a new one for me.
>
> A V3 probe, when powered on, lights the power light, and then blinks
> all other lights for about a second every few seconds. Forever.
>
> I opened a case on it and was referred to the USB stick recovery
> process. Sigh. This is not that problem, I know how to deal with the
> USB stick issue.
>
> Has anyone seen this? Is there a deeper recovery trick we can use? I'm
> perfectly happy to attach a console to the TP-Link device. I was
> planning on doing it anyway to see what errors I am getting.
>
From remaker at gmail.com Tue Mar 7 10:44:30 2017
From: remaker at gmail.com (Phillip Remaker)
Date: Tue, 7 Mar 2017 01:44:30 -0800
Subject: [atlas] Failing probe, all lights blink
In-Reply-To: <153d29fe-a256-29bd-c380-7f4a414b3c5d@ripe.net>
References:
<153d29fe-a256-29bd-c380-7f4a414b3c5d@ripe.net>
Message-ID: <9CBC96FB-4202-4104-AE8D-83AB6D4B9B26@gmail.com>
I know all of those things. The pattern I am seeing is not documented. Do you need a video?
Power light comes on, then ALL of the other lights blink on simultaneously for a second, off for two seconds, and all on again. The power is the only one solid the whole time. I've never seen it before.
> On Mar 7, 2017, at 1:01 AM, Viktor Naumov wrote:
>
> Hi Philip,
>
> The chance that is bricked is very low so there is no need for such hardcore methods :)
>
> On the https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean you can find your LED flashing patterns. If the second led is blinking slow it looks like it is running from the internal flash which means that either external flash is corrupted or damaged. Sometimes you're able to format the flash but do not notice the reduced size. Probe will not be able to function if the flash drive is smaller than 4GB.
>
> WBR
>
> /vty
>
>
>> On 3/7/17 12:41 AM, Phillip Remaker wrote:
>> This is a new one for me.
>>
>> A V3 probe, when powered on, lights the power light, and then blinks all other lights for about a second every few seconds. Forever.
>>
>> I opened a case on it and was referred to the USB stick recovery process. Sigh. This is not that problem, I know how to deal with the USB stick issue.
>>
>> Has anyone seen this? Is there a deeper recovery trick we can use? I'm perfectly happy to attach a console to the TP-Link device. I was planning on doing it anyway to see what errors I am getting.
>>
>
From philip.homburg at ripe.net Tue Mar 7 10:57:14 2017
From: philip.homburg at ripe.net (Philip Homburg)
Date: Tue, 7 Mar 2017 10:57:14 +0100
Subject: [atlas] Failing probe, all lights blink
In-Reply-To:
References:
Message-ID: <818db113-1810-f68e-7423-ad10d7652108@ripe.net>
Hi Phillip,
On 2017/03/07 0:41 , Phillip Remaker wrote:
> A V3 probe, when powered on, lights the power light, and then blinks all
> other lights for about a second every few seconds. Forever.
If it does this without the USB stick then it is very likely that the
probe is bricked. That can happen if the probe loses power when it is
trying upgrade it's built-in firmware.
Though we haven't release a new firmware for the built-in flash for
quite a while now.
If this is about probe 16110 then the logs are consistent with the probe
trying to upgrade it's built-in flash.
Philip
From remaker at gmail.com Tue Mar 7 11:06:53 2017
From: remaker at gmail.com (Phillip Remaker)
Date: Tue, 7 Mar 2017 02:06:53 -0800
Subject: [atlas] Failing probe, all lights blink
In-Reply-To: <818db113-1810-f68e-7423-ad10d7652108@ripe.net>
References:
<818db113-1810-f68e-7423-ad10d7652108@ripe.net>
Message-ID: <189A6BB6-B62D-4D7F-B7E7-CB3C4F0A4ECA@gmail.com>
Are there any steps I can take to unbrick?
> On Mar 7, 2017, at 1:57 AM, Philip Homburg wrote:
>
> Hi Phillip,
>
>> On 2017/03/07 0:41 , Phillip Remaker wrote:
>> A V3 probe, when powered on, lights the power light, and then blinks all
>> other lights for about a second every few seconds. Forever.
>
> If it does this without the USB stick then it is very likely that the
> probe is bricked. That can happen if the probe loses power when it is
> trying upgrade it's built-in firmware.
>
> Though we haven't release a new firmware for the built-in flash for
> quite a while now.
>
> If this is about probe 16110 then the logs are consistent with the probe
> trying to upgrade it's built-in flash.
>
> Philip
>
From philip.homburg at ripe.net Tue Mar 7 11:11:28 2017
From: philip.homburg at ripe.net (Philip Homburg)
Date: Tue, 7 Mar 2017 11:11:28 +0100
Subject: [atlas] Failing probe, all lights blink
In-Reply-To: <189A6BB6-B62D-4D7F-B7E7-CB3C4F0A4ECA@gmail.com>
References:
<818db113-1810-f68e-7423-ad10d7652108@ripe.net>
<189A6BB6-B62D-4D7F-B7E7-CB3C4F0A4ECA@gmail.com>
Message-ID:
On 2017/03/07 11:06 , Phillip Remaker wrote:
> Are there any steps I can take to unbrick?
Not officially. There are ways to open up the probe and reflash it
without losing key material, but it is very tricky.
Better to send the old one back and ask for a new one.
Philip
From danny at trisect.uk Wed Mar 8 12:06:47 2017
From: danny at trisect.uk (Danny Horne)
Date: Wed, 8 Mar 2017 11:06:47 +0000
Subject: [atlas] Ripe website problems
Message-ID: <683c7aff416a4928aa6d3f2d46d0cda4@trisect.uk>
Hi all,
Anyone getting this when trying to get to access.ripe.net?
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /.
Reason: Error reading from remote server
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From danny at trisect.uk Wed Mar 8 12:15:13 2017
From: danny at trisect.uk (Danny Horne)
Date: Wed, 8 Mar 2017 11:15:13 +0000
Subject: [atlas] Ripe website problems
In-Reply-To: <683c7aff416a4928aa6d3f2d46d0cda4@trisect.uk>
References: <683c7aff416a4928aa6d3f2d46d0cda4@trisect.uk>
Message-ID: <5bdc3371d26a4632ae8fd0fc1c1c35a7@trisect.uk>
Sorry to reply to my own post, but it seems they're now aware of the problem, this notice is on the login page
RIPE NCC Access is having difficulties. Please retry later.
From: ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Danny Horne
Sent: Wednesday, 8 March 2017 11:07 am
To: Atlas ML (ripe-atlas at ripe.net)
Subject: [atlas] Ripe website problems
Hi all,
Anyone getting this when trying to get to access.ripe.net?
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /.
Reason: Error reading from remote server
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From robert at ripe.net Wed Mar 8 16:27:36 2017
From: robert at ripe.net (Robert Kisteleki)
Date: Wed, 8 Mar 2017 16:27:36 +0100
Subject: [atlas] Ripe website problems
In-Reply-To: <5bdc3371d26a4632ae8fd0fc1c1c35a7@trisect.uk>
References: <683c7aff416a4928aa6d3f2d46d0cda4@trisect.uk>
<5bdc3371d26a4632ae8fd0fc1c1c35a7@trisect.uk>
Message-ID:
Hello,
You experienced the effect of intermittent errors that affected multiple
services for a short while today. The issues were resolved few hours ago.
The official announcement is here:
https://www.ripe.net/support/service-announcements/intermittent-outages-affecting-some-services
Regards,
Robert
On 2017-03-08 12:15, Danny Horne wrote:
> Sorry to reply to my own post, but it seems they?re now aware of the
> problem, this notice is on the login page
>
>
>
> RIPE NCC Access is having difficulties. Please retry later.
>
>
>
>
>
>
>
> *From:*ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] *On Behalf Of *Danny
> Horne
> *Sent:* Wednesday, 8 March 2017 11:07 am
> *To:* Atlas ML (ripe-atlas at ripe.net)
> *Subject:* [atlas] Ripe website problems
>
>
>
> Hi all,
>
>
>
> Anyone getting this when trying to get to access.ripe.net?
>
>
>
>
> Proxy Error
>
> The proxy server received an invalid response from an upstream server.
> The proxy server could not handle the request /POST /
> /.
>
> Reason: *Error reading from remote server*
>
>
>
From danny at trisect.uk Thu Mar 9 13:59:58 2017
From: danny at trisect.uk (Danny Horne)
Date: Thu, 9 Mar 2017 12:59:58 +0000
Subject: [atlas] No data in Connection & Traffic graph
Message-ID: <121c403ad665497091097961de18bc88@trisect.uk>
Hi all,
Is anyone not seeing any data on the Connection & Traffic graph in the General tab on their probe's homepage? (My probe ID 31491)
Regards
Danny Horne
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From robert at ripe.net Thu Mar 9 14:08:46 2017
From: robert at ripe.net (Robert Kisteleki)
Date: Thu, 9 Mar 2017 14:08:46 +0100
Subject: [atlas] No data in Connection & Traffic graph
In-Reply-To: <121c403ad665497091097961de18bc88@trisect.uk>
References: <121c403ad665497091097961de18bc88@trisect.uk>
Message-ID: <5bef2157-66b9-a10e-9ad5-affbcd740021@ripe.net>
On 2017-03-09 13:59, Danny Horne wrote:
> Hi all,
>
>
>
> Is anyone not seeing any data on the Connection & Traffic graph in the
> General tab on their probe?s homepage? (My probe ID 31491)
>
>
>
> Regards
>
> Danny Horne
Hi,
I can see graphs there for the past 5-6 days, everything looks ok. I'll help
you further offline.
Regards,
Robert
From mkh at rqc.ru Fri Mar 10 09:47:12 2017
From: mkh at rqc.ru (Marat Khalili)
Date: Fri, 10 Mar 2017 11:47:12 +0300
Subject: [atlas] More even earth distribution of measurement probes
Message-ID: <0cad3773-8b19-ae42-aaa0-488bb39220cc@rqc.ru>
I'd like to check worldwide connectivity to my site. I create a new
measurement via web-interface and add, say, 300 probes, expecting them
to cover most world countries. However, looking at the map
I notice that
most are selected from Europe: there're two dozens in Netherlands (many
with same ASNs), but only two in Australia, one in Japan and nothing in
Brazil. Obviously, most ATLAS probes are from Europe, and selection
algorithm does not take probe density into account.
Wouldn't it be nice to have the following features in web-interface and API:
* even distribution of probes by country or continent based on
population, area, and other user-defined weight numbers;
* avoiding probes with same ASNs
?
I don't know how current algorithm works, but easiest modification would
be two-step process: (1) randomly select country based on specified
weights; (2) randomly select probe within country, avoiding earlier
selected probes or ASNs and failing if none are left available; repeat
from step 1 until necessary number of probes is selected.
P.S. I tried to manually request 1 probe from each country, but stumbled
on unrecognised country codes, countries with no probes etc. before even
trying population-weighted distribution. Without direct access to probes
database nice solution can be difficult to achieve via current API,
although crude one looks possible.
P.P.S. I understand this option will create more load on probes in
less-covered countries, but since it's possible to limit selection to
specific countries anyway this is hardly a strong argument against
adding this feature.
--
With Best Regards,
Marat Khalili
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bortzmeyer at nic.fr Fri Mar 10 11:01:52 2017
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Fri, 10 Mar 2017 11:01:52 +0100
Subject: [atlas] Testing DNS-over-TLS support?
In-Reply-To: <8acd984a-7fd8-3077-f0ea-1c03027fc482@ripe.net>
References: <20170301001304.GA17847@laperouse.bortzmeyer.org>
<8acd984a-7fd8-3077-f0ea-1c03027fc482@ripe.net>
Message-ID: <20170310100152.m6bqpehetoenyxkn@nic.fr>
On Wed, Mar 01, 2017 at 01:52:04PM +0100,
Philip Homburg wrote
a message of 22 lines which said:
> What works today is the sslgetcert measurement
I never noticed that it was possible to indicate the port, thanks.
% python cert.py -v --issuer -r 500 --port 853 80.67.188.188
{'definitions': [{'target': '80.67.188.188', 'af': 4, 'is_oneoff': True, 'type': 'sslcert', 'port': 853, 'description': 'X.509 cert of 80.67.188.188 from the whole world'}], 'probes': [{'requested': 500, 'type': 'area', 'value': 'WW'}]}
Measurement #7862817 to 80.67.188.188 uses 500 probes
497 probes reported
[] : 1 occurrences
[FAILED TO GET A CERT: connect: timeout] : 2 occurrences
[FAILED TO GET A CERT: timeout reading hello] : 69 occurrences
[] : 425 occurrences
Test #7862817 done at 2017-03-10T09:55:55Z
It seems to indicate there is *some* filtering of port 853.
(It is not a network issue since testing with the same probes shows a complete
success:
% atlas-reach --old_measurement 7862817 80.67.188.188
495 probes reported
Test #7862825 done at 2017-03-10T09:57:19Z
Tests: 1484 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), average RTT: 74 ms
From bortzmeyer at nic.fr Fri Mar 10 11:07:38 2017
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Fri, 10 Mar 2017 11:07:38 +0100
Subject: [atlas] More even earth distribution of measurement probes
In-Reply-To: <0cad3773-8b19-ae42-aaa0-488bb39220cc@rqc.ru>
References: <0cad3773-8b19-ae42-aaa0-488bb39220cc@rqc.ru>
Message-ID: <20170310100738.r3sk77ritd3wdhdr@nic.fr>
On Fri, Mar 10, 2017 at 11:47:12AM +0300,
Marat Khalili wrote
a message of 94 lines which said:
> 300 probes, expecting them to cover most world countries.
Most people seem to expect some sort of random selection in the
complete set of probes, but it does not work that way. Some probes are
favored over others (anchors, for instance) and there is a priority
for the less loaded probes.
> Wouldn't it be nice to have the following features in web-interface and API:
> * even distribution of probes by country or continent based on
> population, area, and other user-defined weight numbers; * avoiding
> probes with same ASNs
Currently, you have to do it yourself: retrieve the list of probes,
apply your criteria, and submit a measurement with the explicit IDs.
> Without direct access to probes database
But you have access
ftp://ftp.ripe.net/ripe/atlas/probes/archive/2017/03/
From mkh at rqc.ru Fri Mar 10 11:23:12 2017
From: mkh at rqc.ru (Marat Khalili)
Date: Fri, 10 Mar 2017 13:23:12 +0300
Subject: [atlas] More even earth distribution of measurement probes
In-Reply-To: <20170310100738.r3sk77ritd3wdhdr@nic.fr>
References: <0cad3773-8b19-ae42-aaa0-488bb39220cc@rqc.ru>
<20170310100738.r3sk77ritd3wdhdr@nic.fr>
Message-ID: <5d161b83-9b5c-e776-a080-1471f27e9239@rqc.ru>
On 10/03/17 13:07, Stephane Bortzmeyer wrote:
> But you have access
> ftp://ftp.ripe.net/ripe/atlas/probes/archive/2017/03/
Aw, great! Didn't know about this "interface" :) Thank you!
--
With Best Regards,
Marat Khalili
From BECHA at ripe.net Fri Mar 10 12:56:40 2017
From: BECHA at ripe.net (Vesna Manojlovic)
Date: Fri, 10 Mar 2017 12:56:40 +0100
Subject: [atlas] More even earth distribution of measurement probes
In-Reply-To: <0cad3773-8b19-ae42-aaa0-488bb39220cc@rqc.ru>
References: <0cad3773-8b19-ae42-aaa0-488bb39220cc@rqc.ru>
Message-ID: <99127b45-208f-0782-7e84-31a151ad3c57@ripe.net>
Dear Marat,
On 10/03/17 09:47, Marat Khalili wrote:
> I'd like to check worldwide connectivity to my site. I create a new
> measurement via web-interface and add, say, 300 probes, expecting them
> to cover most world countries.
There was a hackathon project that made this possible in some way,
called "Spatial Bucketing of RIPE Atlas Probes on Map Projection", by
Julian Hammer:
"[he] wanted to solve the following problem: when scheduling
measurements from lots of probes, requesting a "random worldwide
selection" currently results in a choice that is very biased towards
Western/Northern Europe and the USA (see image without Sbucket on the left).
Julian's solution makes a more equal selection, by using the grid to
divide the globe and choose probes based on that division (see image on
the right after applying Sbucket)."
Images: https://labs.ripe.net/Members/becha/ripe-atlas-hackathon-results
Code: https://github.com/cod3monk/RIPE-Atlas-sbucket
I hope you find this useful!
Cheers,
Vesna
> However, looking at the map
> I notice that
> most are selected from Europe: there're two dozens in Netherlands (many
> with same ASNs), but only two in Australia, one in Japan and nothing in
> Brazil. Obviously, most ATLAS probes are from Europe, and selection
> algorithm does not take probe density into account.
>
> Wouldn't it be nice to have the following features in web-interface and API:
> * even distribution of probes by country or continent based on
> population, area, and other user-defined weight numbers;
> * avoiding probes with same ASNs
> ?
>
> I don't know how current algorithm works, but easiest modification would
> be two-step process: (1) randomly select country based on specified
> weights; (2) randomly select probe within country, avoiding earlier
> selected probes or ASNs and failing if none are left available; repeat
> from step 1 until necessary number of probes is selected.
>
> P.S. I tried to manually request 1 probe from each country, but stumbled
> on unrecognised country codes, countries with no probes etc. before even
> trying population-weighted distribution. Without direct access to probes
> database nice solution can be difficult to achieve via current API,
> although crude one looks possible.
>
> P.P.S. I understand this option will create more load on probes in
> less-covered countries, but since it's possible to limit selection to
> specific countries anyway this is hardly a strong argument against
> adding this feature.
>
> --
>
> With Best Regards,
> Marat Khalili
From mkh at rqc.ru Fri Mar 10 13:27:23 2017
From: mkh at rqc.ru (Marat Khalili)
Date: Fri, 10 Mar 2017 15:27:23 +0300
Subject: [atlas] More even earth distribution of measurement probes
In-Reply-To: <99127b45-208f-0782-7e84-31a151ad3c57@ripe.net>
References: <0cad3773-8b19-ae42-aaa0-488bb39220cc@rqc.ru>
<99127b45-208f-0782-7e84-31a151ad3c57@ripe.net>
Message-ID: <51e46b44-1a7e-dcb8-56c7-1c699fdc6ae3@rqc.ru>
Cool, will try it! I almost wrote my own tool already, but I didn't try
to make even spatial distribution, it is obviously more difficult than
by-country one.
--
With Best Regards,
Marat Khalili
On 10/03/17 14:56, Vesna Manojlovic wrote:
> Dear Marat,
>
> On 10/03/17 09:47, Marat Khalili wrote:
>> I'd like to check worldwide connectivity to my site. I create a new
>> measurement via web-interface and add, say, 300 probes, expecting them
>> to cover most world countries.
>
> There was a hackathon project that made this possible in some way,
> called "Spatial Bucketing of RIPE Atlas Probes on Map Projection", by
> Julian Hammer:
>
> "[he] wanted to solve the following problem: when scheduling
> measurements from lots of probes, requesting a "random worldwide
> selection" currently results in a choice that is very biased towards
> Western/Northern Europe and the USA (see image without Sbucket on the
> left).
>
> Julian's solution makes a more equal selection, by using the grid to
> divide the globe and choose probes based on that division (see image
> on the right after applying Sbucket)."
>
> Images: https://labs.ripe.net/Members/becha/ripe-atlas-hackathon-results
>
> Code: https://github.com/cod3monk/RIPE-Atlas-sbucket
>
> I hope you find this useful!
>
> Cheers,
> Vesna
>
>> However, looking at the map
>> I notice that
>> most are selected from Europe: there're two dozens in Netherlands (many
>> with same ASNs), but only two in Australia, one in Japan and nothing in
>> Brazil. Obviously, most ATLAS probes are from Europe, and selection
>> algorithm does not take probe density into account.
>>
>> Wouldn't it be nice to have the following features in web-interface
>> and API:
>> * even distribution of probes by country or continent based on
>> population, area, and other user-defined weight numbers;
>> * avoiding probes with same ASNs
>> ?
>>
>> I don't know how current algorithm works, but easiest modification would
>> be two-step process: (1) randomly select country based on specified
>> weights; (2) randomly select probe within country, avoiding earlier
>> selected probes or ASNs and failing if none are left available; repeat
>> from step 1 until necessary number of probes is selected.
>>
>> P.S. I tried to manually request 1 probe from each country, but stumbled
>> on unrecognised country codes, countries with no probes etc. before even
>> trying population-weighted distribution. Without direct access to probes
>> database nice solution can be difficult to achieve via current API,
>> although crude one looks possible.
>>
>> P.P.S. I understand this option will create more load on probes in
>> less-covered countries, but since it's possible to limit selection to
>> specific countries anyway this is hardly a strong argument against
>> adding this feature.
>>
>> --
>>
>> With Best Regards,
>> Marat Khalili
From mkh at rqc.ru Fri Mar 10 14:32:08 2017
From: mkh at rqc.ru (Marat Khalili)
Date: Fri, 10 Mar 2017 16:32:08 +0300
Subject: [atlas] More even earth distribution of measurement probes
In-Reply-To: <0cad3773-8b19-ae42-aaa0-488bb39220cc@rqc.ru>
References: <0cad3773-8b19-ae42-aaa0-488bb39220cc@rqc.ru>
Message-ID:
My solution, for the record:
https://gist.github.com/qm2k/ea5f67fcf4e3dd2208ab3bc4ee233560
--
With Best Regards,
Marat Khalili
On 10/03/17 11:47, Marat Khalili wrote:
> I'd like to check worldwide connectivity to my site. I create a new
> measurement via web-interface and add, say, 300 probes, expecting them
> to cover most world countries. However, looking at the map
> I notice
> that most are selected from Europe: there're two dozens in Netherlands
> (many with same ASNs), but only two in Australia, one in Japan and
> nothing in Brazil. Obviously, most ATLAS probes are from Europe, and
> selection algorithm does not take probe density into account.
>
> Wouldn't it be nice to have the following features in web-interface
> and API:
> * even distribution of probes by country or continent based on
> population, area, and other user-defined weight numbers;
> * avoiding probes with same ASNs
> ?
>
> I don't know how current algorithm works, but easiest modification
> would be two-step process: (1) randomly select country based on
> specified weights; (2) randomly select probe within country, avoiding
> earlier selected probes or ASNs and failing if none are left
> available; repeat from step 1 until necessary number of probes is
> selected.
>
> P.S. I tried to manually request 1 probe from each country, but
> stumbled on unrecognised country codes, countries with no probes etc.
> before even trying population-weighted distribution. Without direct
> access to probes database nice solution can be difficult to achieve
> via current API, although crude one looks possible.
>
> P.P.S. I understand this option will create more load on probes in
> less-covered countries, but since it's possible to limit selection to
> specific countries anyway this is hardly a strong argument against
> adding this feature.
>
> --
>
> With Best Regards,
> Marat Khalili
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ve2mrx at hotmail.com Sun Mar 12 02:16:33 2017
From: ve2mrx at hotmail.com (Martin Boissonneault)
Date: Sun, 12 Mar 2017 02:16:33 +0100
Subject: [atlas] Probe: Any benefits to set in DMZ?
Message-ID:
Hi!
Is there any benefit to put the Probe in a home router "DMZ"? I could not find the answer in the FAQ.
My setup is:
1- The Probe is directly connected to the ISP all-in-one router in it's DMZ (Bell Home Hub 3000, FTTH).
2- My personal router is directly connected to the ISP router, but connecting through PPPoE passthrough.
Both routers have different ISP IPs. The ISP router is used for the Fiber SFP module, TV and phone. The Probe takes internet from the ISP router, but nothing else.
Thanks,
Martin Boissonneault
Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
From danny at trisect.uk Sun Mar 12 12:05:42 2017
From: danny at trisect.uk (Danny Horne)
Date: Sun, 12 Mar 2017 11:05:42 +0000
Subject: [atlas] Probe: Any benefits to set in DMZ?
In-Reply-To:
References:
Message-ID:
> Hi!
> Is there any benefit to put the Probe in a home router "DMZ"? I could not
> find the answer in the FAQ.
>
> My setup is:
> 1- The Probe is directly connected to the ISP all-in-one router in it's DMZ (Bell
> Home Hub 3000, FTTH).
> 2- My personal router is directly connected to the ISP router, but connecting
> through PPPoE passthrough.
>
> Both routers have different ISP IPs. The ISP router is used for the Fiber SFP
> module, TV and phone. The Probe takes internet from the ISP router, but
> nothing else.
>
> Thanks,
> Martin Boissonneault
>
Based on this part of the FAQ, I don't personally see the point in going to such extremes, unless for some reason you really need to hide your own IP (though your ISP has probably given you a subnet, so not difficult to work out the other IPs in that subnet)
https://atlas.ripe.net/about/faq/#security-and-privacy
From mkh at rqc.ru Sun Mar 12 13:34:15 2017
From: mkh at rqc.ru (Marat Khalili)
Date: Sun, 12 Mar 2017 15:34:15 +0300
Subject: [atlas] Probe: Any benefits to set in DMZ?
In-Reply-To:
References:
Message-ID:
ATLAS network will get hacked one day, and by running probe in a separate segment (DMZ, guest LAN or whatever) you'll deny bad guys access to devices in your main LAN.
--
With Best Regards,
Marat Khalili
On March 12, 2017 4:16:33 AM GMT+03:00, Martin Boissonneault wrote:
>Hi!
>Is there any benefit to put the Probe in a home router "DMZ"? I could
>not find the answer in the FAQ.
>
> My setup is:
>1- The Probe is directly connected to the ISP all-in-one router in it's
>DMZ (Bell Home Hub 3000, FTTH).
>2- My personal router is directly connected to the ISP router, but
>connecting through PPPoE passthrough.
>
>Both routers have different ISP IPs. The ISP router is used for the
>Fiber SFP module, TV and phone. The Probe takes internet from the ISP
>router, but nothing else.
>
>Thanks,
>Martin Boissonneault
>
>Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bortzmeyer at nic.fr Sun Mar 12 15:54:51 2017
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Sun, 12 Mar 2017 15:54:51 +0100
Subject: [atlas] Trivia of the day: Atlas probes and alternative DNS roots
Message-ID: <20170312145451.GA1026@sources.org>
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 #7865872 #7865873
From mkh at rqc.ru Mon Mar 13 07:54:01 2017
From: mkh at rqc.ru (Marat Khalili)
Date: Mon, 13 Mar 2017 09:54:01 +0300
Subject: [atlas] Lowercase country codes in the probes database
Message-ID:
While using use probes database at
ftp://ftp.ripe.net/ripe/atlas/probes/archive/ I noticed that 33 probes
have country_code values in lower case (e.g. "ru" instead of "RU"), some
in "Connected" state. When trying to distribute probes evenly among
available countries it obviously affects the result. Of course, it's
easy to work around once you are aware of this 'feature', but I only
found the problem by chance.
I wonder what's the story behind this and can this be fixed?
(Web-interface doesn't seem to be affected.)
--
With Best Regards,
Marat Khalili
From robert at ripe.net Mon Mar 13 09:51:09 2017
From: robert at ripe.net (Robert Kisteleki)
Date: Mon, 13 Mar 2017 09:51:09 +0100
Subject: [atlas] Probe: Any benefits to set in DMZ?
In-Reply-To:
References:
Message-ID: <03b384e7-79b5-f917-99f4-de0ad417d9b4@ripe.net>
On 2017-03-12 2:16, Martin Boissonneault wrote:
> Hi!
> Is there any benefit to put the Probe in a home router "DMZ"? I could not find the answer in the FAQ.
>
> My setup is:
> 1- The Probe is directly connected to the ISP all-in-one router in it's DMZ (Bell Home Hub 3000, FTTH).
> 2- My personal router is directly connected to the ISP router, but connecting through PPPoE passthrough.
>
> Both routers have different ISP IPs. The ISP router is used for the Fiber SFP module, TV and phone. The Probe takes internet from the ISP router, but nothing else.
>
> Thanks,
> Martin Boissonneault
Hi,
The probe works fine in a DMZ, as long as outgoing connections are
permitted. It is perfectly fine to put it there, if it's not a hassle to do so.
Regards,
Robert
From ve2mrx at hotmail.com Mon Mar 13 09:54:01 2017
From: ve2mrx at hotmail.com (Martin Boissonneault)
Date: Mon, 13 Mar 2017 09:54:01 +0100
Subject: [atlas] Probe: Any benefits to set in DMZ?
In-Reply-To:
Message-ID:
On 2017-03-12 12:05:42 CET, Danny Horne wrote:
> Based on this part of the FAQ, I don't personally see the point in going to such extremes, unless for some reason you really need to hide your own IP (though your ISP has probably given you a subnet, so not difficult to work out the other IPs in that subnet)
>
> https://atlas.ripe.net/about/faq/#security-and-privacy
Actually, my ISP does give single a single IP per PPPoE connection. One for their multifunction Home Hub (Phone, TV, Internet/WiFi) and one for my personal router passing through their modem. Both are in different subnets. Hacking the Probe or the ISP router will not give access to my home network. It's protected from another router's firewall, and on another IP. And since my router has it's own PPPoE connection (and IP), no double-NAT.
My original question was meant from a measurement point of view. Is there a benefit FOR THE PROBE to be _in a HOME router_ "DMZ-kinda-thing"?
Home routers don't have true DMZs, the DMZ is not completely on the WAN side of the router usually. It's confirmed by my probe's local IP being on the LAN side even while being in the pseudo-"DMZ". If it was a true DMZ, it would be the WAN IP.
Martin
Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
From michael.reutter at gmail.com Mon Mar 13 10:28:34 2017
From: michael.reutter at gmail.com (Michael Reutter)
Date: Mon, 13 Mar 2017 09:28:34 +0000
Subject: [atlas] Surplus RIPE Atlas credits
Message-ID:
Hi everyone,
I host a probe but at the moment I do not create measurements. As such, I
have a large surplus of unused credits. Is anyone in need of credits and
would like for me to transfer them?
Best,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From pdeweerd at ripe.net Mon Mar 13 16:57:45 2017
From: pdeweerd at ripe.net (Paul de Weerd)
Date: Mon, 13 Mar 2017 16:57:45 +0100
Subject: [atlas] RIPE Atlas Infrastructure Maintenance (14 March)
Message-ID: <211270463f8bd7d48fac86958a8c7356@ripe.net>
Dear all,
We'll carry out maintenance work on the core RIPE Atlas and RIPEstat
infrastructure tomorrow (14 March 2017), approximately between 09:00 and
11:00 UTC+1. As a result, we will switch over to the reduced data set,
limiting the amount of history available from the service. This affects
RIPE Atlas, RIPEstat, RIS and DNSMON.
We apologise for the inconvenience.
Best regards,
Paul de Weerd
Senior Systems Engineer
RIPE NCC
From ripe-atlas at johnbond.org Tue Mar 14 14:49:36 2017
From: ripe-atlas at johnbond.org (John)
Date: Tue, 14 Mar 2017 13:49:36 +0000
Subject: [atlas] Fwd: [mat-wg] Atlas: DNS TCP Errors
In-Reply-To: <817f8192-ea60-cf2b-4b01-ec9ac838f746@johnbond.org>
References: <817f8192-ea60-cf2b-4b01-ec9ac838f746@johnbond.org>
Message-ID:
Hello Atlas,
feature request, when preforming DNS queries over TCP would it be
possible for the probe to differentiate between a timeout and a TCP
Reset. Currently the result just records the following when it gets a
reset[1].
`error.timeout: 5000`
A similar feature to record ICMP prohibited for udp queries would also
be useful but likely much harder.
Thanks John
[1]https://atlas.ripe.net/api/v2/measurements/7859749/results?start=1488844800&stop=1488931199&format=json
From camin at ripe.net Tue Mar 14 16:41:26 2017
From: camin at ripe.net (Chris Amin)
Date: Tue, 14 Mar 2017 16:41:26 +0100
Subject: [atlas] Lowercase country codes in the probes database
In-Reply-To:
References:
Message-ID: <9c2b9d2b-2555-3cc7-1d2a-be5d6ede8557@ripe.net>
Dear Marat,
You're right, those 33 probes should have been consistent with the
others. We have corrected them in the database so you should now only
see upper case country codes in all future probe archives (previous
archives have not been rewritten). We believe that this was a historic
artifact and will not happen again, but please let us know if you notice
any further inconsistencies.
Kind regards,
Chris Amin
RIPE NCC
On 13/03/2017 07:54, Marat Khalili wrote:
> While using use probes database at
> ftp://ftp.ripe.net/ripe/atlas/probes/archive/ I noticed that 33 probes
> have country_code values in lower case (e.g. "ru" instead of "RU"), some
> in "Connected" state. When trying to distribute probes evenly among
> available countries it obviously affects the result. Of course, it's
> easy to work around once you are aware of this 'feature', but I only
> found the problem by chance.
>
> I wonder what's the story behind this and can this be fixed?
>
> (Web-interface doesn't seem to be affected.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
From philip.homburg at ripe.net Tue Mar 14 16:45:15 2017
From: philip.homburg at ripe.net (Philip Homburg)
Date: Tue, 14 Mar 2017 16:45:15 +0100
Subject: [atlas] Fwd: [mat-wg] Atlas: DNS TCP Errors
In-Reply-To:
References: <817f8192-ea60-cf2b-4b01-ec9ac838f746@johnbond.org>
Message-ID:
Hi John,
On 2017/03/14 14:49 , John wrote:
> feature request, when preforming DNS queries over TCP would it be
> possible for the probe to differentiate between a timeout and a TCP
> Reset. Currently the result just records the following when it gets a
> reset[1].
>
> `error.timeout: 5000`
I'll create a ticket for that. I have no idea about the ETA at the moment.
> A similar feature to record ICMP prohibited for udp queries would also
> be useful but likely much harder.
I wonder if the retry option would help here. The second send should get
an error from the kernel if the previous one resulted in an error ICMP.
Actually getting the ICMP is possibly too hard, but a send error may
help a bit. But it requires some experimenting to see if this approach
would work.
Philip
From ripe-atlas at johnbond.org Tue Mar 14 22:37:16 2017
From: ripe-atlas at johnbond.org (John)
Date: Tue, 14 Mar 2017 21:37:16 +0000
Subject: [atlas] Fwd: [mat-wg] Atlas: DNS TCP Errors
In-Reply-To:
References: <817f8192-ea60-cf2b-4b01-ec9ac838f746@johnbond.org>
Message-ID: <86500146-2825-3862-7e2e-2833c3a3a3ac@johnbond.org>
Hi Philip,
On 14/03/2017 15:45, Philip Homburg wrote:
> Hi John,
>
> On 2017/03/14 14:49 , John wrote:
>> feature request, when preforming DNS queries over TCP would it be
>> possible for the probe to differentiate between a timeout and a TCP
>> Reset. Currently the result just records the following when it gets a
>> reset[1].
>>
>> `error.timeout: 5000`
>
> I'll create a ticket for that. I have no idea about the ETA at the moment.
Awesome thanks, no need for ETA just wanted to get it on the radar
>> A similar feature to record ICMP prohibited for udp queries would also
>> be useful but likely much harder.
>
> I wonder if the retry option would help here. The second send should get
> an error from the kernel if the previous one resulted in an error ICMP.
>
> Actually getting the ICMP is possibly too hard, but a send error may
> help a bit. But it requires some experimenting to see if this approach
> would work.
a bit to low level, kernel, socket programing for me but a quick google
produces this if it helps
"""
Normally, UDP pretty much ignores ICMP errors, so if you want to see
them, you need to open a raw socket to receive all ICMP packets and look
for ones relevant to your socket.
On Linux, at least, an alternative is to set the IP_RECVERR socket
option. If you do that, you can do a recvmsg with the MSG_ERRQUEUE flag
set to get any ICMP (or other) errors associated with your socket. This
has the advantage of not requiring elevated privileges or a second socket.
"""
http://stackoverflow.com/questions/23118113/c-sockets-send-udp-and-process-icmp-reply-from-router
Thanks
From lists at ohlmeier.org Tue Mar 14 22:58:02 2017
From: lists at ohlmeier.org (Nils Ohlmeier)
Date: Tue, 14 Mar 2017 14:58:02 -0700
Subject: [atlas] Fwd: [mat-wg] Atlas: DNS TCP Errors
In-Reply-To: <86500146-2825-3862-7e2e-2833c3a3a3ac@johnbond.org>
References: <817f8192-ea60-cf2b-4b01-ec9ac838f746@johnbond.org>
<86500146-2825-3862-7e2e-2833c3a3a3ac@johnbond.org>
Message-ID:
On 3/14/17 14:37, John wrote:
> """
> Normally, UDP pretty much ignores ICMP errors, so if you want to see
> them, you need to open a raw socket to receive all ICMP packets and look
> for ones relevant to your socket.
>
> On Linux, at least, an alternative is to set the IP_RECVERR socket
> option. If you do that, you can do a recvmsg with the MSG_ERRQUEUE flag
> set to get any ICMP (or other) errors associated with your socket. This
> has the advantage of not requiring elevated privileges or a second socket.
> """
>
> http://stackoverflow.com/questions/23118113/c-sockets-send-udp-and-process-icmp-reply-from-router
The connected UDP socket (second answer) should work fine on Linux to
receive ICMP errors for rejected UDP messages.
Best
Nils
From bortzmeyer at nic.fr Mon Mar 20 17:07:19 2017
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Mon, 20 Mar 2017 17:07:19 +0100
Subject: [atlas] Cannot understand the daily limit
Message-ID: <20170320160719.kibcy2o4uubi5z26@nic.fr>
RIPE Atlas just denied me a measurement:
"{"error":{"status":400,"code":104,"detail":"Executing this measurement request would violate your maximum daily spending limit of 1000000 credits. Please stop some of your currently running measurements and try again.","title":""}}"
I have one permanent measurement, which takes, according to
, 3400 credits/hour
(81600/day). Otherwise, I ran only one-off measurements, most taking <
1000 credits.
How could I hit a limit of ONE MILLION per day?
From spascou at gmail.com Mon Mar 20 18:38:05 2017
From: spascou at gmail.com (Sylvain Pascou)
Date: Mon, 20 Mar 2017 18:38:05 +0100
Subject: [atlas] Starting again a stopped custom measurement
Message-ID:
Hello,
This might seem like a silly question but I've found no way, whether through the Web UI or the POST API, to start a measurement that I have previously accidentally stopped.
Is this a problem or simply a not-implemented feature?
Sylvain
Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
From vnaumov at ripe.net Tue Mar 21 09:25:36 2017
From: vnaumov at ripe.net (Viktor Naumov)
Date: Tue, 21 Mar 2017 09:25:36 +0100
Subject: [atlas] Cannot understand the daily limit
In-Reply-To: <20170320160719.kibcy2o4uubi5z26@nic.fr>
References: <20170320160719.kibcy2o4uubi5z26@nic.fr>
Message-ID:
Hi Stephane,
It would be very helpful if you would share your measurement definition.
WBR
/vty
On 3/20/17 5:07 PM, Stephane Bortzmeyer wrote:
> RIPE Atlas just denied me a measurement:
>
> "{"error":{"status":400,"code":104,"detail":"Executing this measurement request would violate your maximum daily spending limit of 1000000 credits. Please stop some of your currently running measurements and try again.","title":""}}"
>
> I have one permanent measurement, which takes, according to
> , 3400 credits/hour
> (81600/day). Otherwise, I ran only one-off measurements, most taking <
> 1000 credits.
>
> How could I hit a limit of ONE MILLION per day?
>
From bortzmeyer at nic.fr Tue Mar 21 09:50:07 2017
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 21 Mar 2017 09:50:07 +0100
Subject: [atlas] Cannot understand the daily limit
In-Reply-To:
References: <20170320160719.kibcy2o4uubi5z26@nic.fr>
Message-ID: <20170321085007.boef357tbeocbwen@nic.fr>
On Tue, Mar 21, 2017 at 09:25:36AM +0100,
Viktor Naumov wrote
a message of 20 lines which said:
> It would be very helpful if you would share your measurement definition.
For instance:
{'definitions': [{'query_class': 'IN', 'description': 'DNS resolution of www.afnic.fr', 'af': 4, 'query_argument': 'www.afnic.fr', 'query_type': 'AAAA', 'type': 'dns', 'is_oneoff': True, 'recursion_desired': True, 'use_probe_resolver': True}], 'probes': [{'requested': 300, 'type': 'area', 'value': 'WW', 'tags': {'include': ['system-resolves-a-correctly', 'system-resolves-aaaa-correctly']}}]}
=>
Status 400, reason "{"error":{"status":400,"code":104,"detail":"Executing this measurement request would violate your maximum daily spending limit of 1000000 credits. Please stop some of your currently running measurements and try again.","title":""}}"
My RIPE account is bortzmeyer+ripe at nic.fr
From camin at ripe.net Tue Mar 21 11:35:12 2017
From: camin at ripe.net (Chris Amin)
Date: Tue, 21 Mar 2017 11:35:12 +0100
Subject: [atlas] Starting again a stopped custom measurement
In-Reply-To:
References:
Message-ID: <6bb8e8d3-eb2c-0afd-d4e7-4327cbfbd76b@ripe.net>
On 20/03/2017 18:38, Sylvain Pascou wrote:
> Hello,
>
> This might seem like a silly question but I've found no way, whether through the Web UI or the POST API, to start a measurement that I have previously accidentally stopped.
>
> Is this a problem or simply a not-implemented feature?
Dear Sylvain,
We do not support resuming a stopped measurement -- once a measurement
is stopped it is frozen for good. The closest thing you can do is make a
new POST request to the API based on the original measurement
specification, but this will create a measurement with a new measurement ID.
Can I ask how you accidentally stopped the measurement? If it was
through the website, perhaps we need to improve the UI to make it harder
for mistakes to happen.
Kind regards,
Chris Amin
RIPE NCC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
From vnaumov at ripe.net Tue Mar 21 12:30:05 2017
From: vnaumov at ripe.net (Viktor Naumov)
Date: Tue, 21 Mar 2017 12:30:05 +0100
Subject: [atlas] Cannot understand the daily limit
In-Reply-To: <20170321085007.boef357tbeocbwen@nic.fr>
References: <20170320160719.kibcy2o4uubi5z26@nic.fr>
<20170321085007.boef357tbeocbwen@nic.fr>
Message-ID: <35a56f6f-e9de-02c2-363d-fb13cf4dd0d1@ripe.net>
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 {"is_oneoff": true, "definitions": [....
/vty
On 3/21/17 9:50 AM, Stephane Bortzmeyer wrote:
> On Tue, Mar 21, 2017 at 09:25:36AM +0100,
> Viktor Naumov wrote
> a message of 20 lines which said:
>
>> It would be very helpful if you would share your measurement definition.
> For instance:
> {'definitions': [{'query_class': 'IN', 'description': 'DNS resolution of www.afnic.fr', 'af': 4, 'query_argument': 'www.afnic.fr', 'query_type': 'AAAA', 'type': 'dns', 'is_oneoff': True, 'recursion_desired': True, 'use_probe_resolver': True}], 'probes': [{'requested': 300, 'type': 'area', 'value': 'WW', 'tags': {'include': ['system-resolves-a-correctly', 'system-resolves-aaaa-correctly']}}]}
>
> =>
> Status 400, reason "{"error":{"status":400,"code":104,"detail":"Executing this measurement request would violate your maximum daily spending limit of 1000000 credits. Please stop some of your currently running measurements and try again.","title":""}}"
>
> My RIPE account is bortzmeyer+ripe at nic.fr
>
From bortzmeyer at nic.fr Tue Mar 21 14:41:41 2017
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 21 Mar 2017 14:41:41 +0100
Subject: [atlas] Cannot understand the daily limit
In-Reply-To: <35a56f6f-e9de-02c2-363d-fb13cf4dd0d1@ripe.net>
References: <20170320160719.kibcy2o4uubi5z26@nic.fr>
<20170321085007.boef357tbeocbwen@nic.fr>
<35a56f6f-e9de-02c2-363d-fb13cf4dd0d1@ripe.net>
Message-ID: <20170321134141.fbx5yc7zwkqgwu4e@nic.fr>
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 {"is_oneoff": true,
> "definitions": [....
It worked before, I guess it changed with API v2. OK, I modify.
From bortzmeyer at nic.fr Tue Mar 21 15:11:46 2017
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 21 Mar 2017 15:11:46 +0100
Subject: [atlas] Cannot understand the daily limit
In-Reply-To: <35a56f6f-e9de-02c2-363d-fb13cf4dd0d1@ripe.net>
References: <20170320160719.kibcy2o4uubi5z26@nic.fr>
<20170321085007.boef357tbeocbwen@nic.fr>
<35a56f6f-e9de-02c2-363d-fb13cf4dd0d1@ripe.net>
Message-ID: <20170321141146.vksyisz2sfts3ams@nic.fr>
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 {"is_oneoff": true,
> "definitions": [....
OK, it works, thanks, I can now ask measurements with a lot of probes.
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 one-off measurement" (otherwise, I would have burned all my
credits for a long time!)
From bortzmeyer at nic.fr Tue Mar 21 16:08:17 2017
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 21 Mar 2017 16:08:17 +0100
Subject: [atlas] Trivia of the day: Atlas probes and alternative DNS
roots
In-Reply-To: <20170312145451.GA1026@sources.org>
References: <20170312145451.GA1026@sources.org>
Message-ID: <20170321150817.qy7o7jo5vx7ayaxb@nic.fr>
On Sun, Mar 12, 2017 at 03:54:51PM +0100,
Stephane Bortzmeyer wrote
a message of 7 lines which said:
> 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.
Note that it may not be a conscious choice by the probe's DNS resolver
operator: it could be hijacking.
For instance, probe 32001 gets an answer from the root name server B
in 3 ms, while traceroute shows a correct delay (B-root is only in the
USA). And this answer is for the OpenNIC root, so this answer is
certainly not from the real B-root.
(This operator, AS 23860, does other funny things.)
From bortzmeyer at nic.fr Tue Mar 21 17:10:02 2017
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 21 Mar 2017 17:10:02 +0100
Subject: [atlas] DNS over TCP problems?
Message-ID: <20170321161002.v4w3cwxhxjodwson@nic.fr>
[I did not test it myself.]
-------------- next part --------------
An embedded message was scrubbed...
From: Jake Zack
Subject: FW: Issues with RIPE ATLAS?
Date: Tue, 21 Mar 2017 15:29:22 +0000
Size: 9753
URL:
From bortzmeyer at nic.fr Tue Mar 21 17:14:16 2017
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 21 Mar 2017 17:14:16 +0100
Subject: [atlas] Cannot understand the daily limit
In-Reply-To: <20170321141146.vksyisz2sfts3ams@nic.fr>
References: <20170320160719.kibcy2o4uubi5z26@nic.fr>
<20170321085007.boef357tbeocbwen@nic.fr>
<35a56f6f-e9de-02c2-363d-fb13cf4dd0d1@ripe.net>
<20170321141146.vksyisz2sfts3ams@nic.fr>
Message-ID: <20170321161415.jr4iimgay27zt5gw@nic.fr>
On Tue, Mar 21, 2017 at 03:11:46PM +0100,
Stephane Bortzmeyer 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 one-off measurement" (otherwise, I would have
> burned all my credits for a long time!)
And the official documentation disagrees with
you.
lists is_oneoff both at the top-level of the JSON object, and under
"definitions".
From bortzmeyer at nic.fr Tue Mar 21 17:25:46 2017
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 21 Mar 2017 17:25:46 +0100
Subject: [atlas] DNS over TCP problems?
In-Reply-To: <20170321161002.v4w3cwxhxjodwson@nic.fr>
References: <20170321161002.v4w3cwxhxjodwson@nic.fr>
Message-ID: <20170321162546.r7oax4hehsqcobpm@nic.fr>
On Tue, Mar 21, 2017 at 05:10:02PM +0100,
Stephane Bortzmeyer 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_pls=0-10-10-50-100&dnsmon.session.exclude-errors=true&dnsmon.type=zone-servers&dnsmon.zone=fr.&dnsmon.maxProbes=undefined&dnsmon.startTime=1488974400&dnsmon.endTime=1490112000&dnsmon.filterProbes=false&dnsmon.ipVersion=both&dnsmon.isTcp=true
From philip.homburg at ripe.net Tue Mar 21 17:57:15 2017
From: philip.homburg at ripe.net (Philip Homburg)
Date: Tue, 21 Mar 2017 17:57:15 +0100
Subject: [atlas] DNS over TCP problems?
In-Reply-To: <20170321162546.r7oax4hehsqcobpm@nic.fr>
References: <20170321161002.v4w3cwxhxjodwson@nic.fr>
<20170321162546.r7oax4hehsqcobpm@nic.fr>
Message-ID: <90f9f576-4d11-8299-9a0b-0dcf9a4fa9d1@ripe.net>
Hi Stephane,
On 2017/03/21 17:25 , Stephane Bortzmeyer wrote:
> According to DNSmon, there is indeed a problem since 14 March:
>
> https://atlas.ripe.net/dnsmon/group/fr.?dnsmon.session.color_range_pls=0-10-10-50-100&dnsmon.session.exclude-errors=true&dnsmon.type=zone-servers&dnsmon.zone=fr.&dnsmon.maxProbes=undefined&dnsmon.startTime=1488974400&dnsmon.endTime=1490112000&dnsmon.filterProbes=false&dnsmon.ipVersion=both&dnsmon.isTcp=true
Unfortunately, a debug statement was left behind in the DNS over TCP
code path. This was not noticed until that code was deployed on the
anchors and started affecting DNSMON.
The patch is simply to delete the offending line and, if all goes well,
will be rolled out on the anchors in the next few days.
Philip
From bortzmeyer at nic.fr Tue Mar 21 19:10:40 2017
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 21 Mar 2017 19:10:40 +0100
Subject: [atlas] DNS over TCP problems?
In-Reply-To: <90f9f576-4d11-8299-9a0b-0dcf9a4fa9d1@ripe.net>
References: <20170321161002.v4w3cwxhxjodwson@nic.fr>
<20170321162546.r7oax4hehsqcobpm@nic.fr>
<90f9f576-4d11-8299-9a0b-0dcf9a4fa9d1@ripe.net>
Message-ID: <20170321181040.7hhopkojaxry2rsd@nic.fr>
On Tue, Mar 21, 2017 at 05:57:15PM +0100,
Philip Homburg wrote
a message of 16 lines which said:
> The patch is simply to delete the offending line and, if all goes well,
> will be rolled out on the anchors in the next few days.
What about the other probes?
From philip.homburg at ripe.net Tue Mar 21 19:41:41 2017
From: philip.homburg at ripe.net (Philip Homburg)
Date: Tue, 21 Mar 2017 19:41:41 +0100
Subject: [atlas] DNS over TCP problems?
In-Reply-To: <20170321181040.7hhopkojaxry2rsd@nic.fr>
References: <20170321161002.v4w3cwxhxjodwson@nic.fr>
<20170321162546.r7oax4hehsqcobpm@nic.fr>
<90f9f576-4d11-8299-9a0b-0dcf9a4fa9d1@ripe.net>
<20170321181040.7hhopkojaxry2rsd@nic.fr>
Message-ID:
On 2017/03/21 19:10 , Stephane Bortzmeyer wrote:
> On Tue, Mar 21, 2017 at 05:57:15PM +0100,
> Philip Homburg wrote
> a message of 16 lines which said:
>
>> The patch is simply to delete the offending line and, if all goes well,
>> will be rolled out on the anchors in the next few days.
>
> What about the other probes?
The other probes as soon as possible. But releasing probe firmware is a
long process.
So both are in progress at the moment. But it is easier to rush a
release on anchors than on probes.
From spascou at gmail.com Wed Mar 22 00:03:13 2017
From: spascou at gmail.com (Sylvain Pascou)
Date: Wed, 22 Mar 2017 00:03:13 +0100
Subject: [atlas] Starting again a stopped custom measurement
In-Reply-To: <6bb8e8d3-eb2c-0afd-d4e7-4327cbfbd76b@ripe.net>
Message-ID:
Thanks for your answer; the accidental stop of the measurement was a poor misclick, nothing wrong with the UI imho.
I've seen recent news about why it'd be difficult to implement a delete function for the measurements, so I wanted to restart my measurement rather than create a new one and clog the UDM list. Doesn't really matter though.
Sylvain
Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
From jdenhertog at ripe.net Wed Mar 22 09:29:33 2017
From: jdenhertog at ripe.net (Jasper den Hertog)
Date: Wed, 22 Mar 2017 09:29:33 +0100
Subject: [atlas] Cannot understand the daily limit
In-Reply-To: <20170321161415.jr4iimgay27zt5gw@nic.fr>
References: <20170320160719.kibcy2o4uubi5z26@nic.fr>
<20170321085007.boef357tbeocbwen@nic.fr>
<35a56f6f-e9de-02c2-363d-fb13cf4dd0d1@ripe.net>
<20170321141146.vksyisz2sfts3ams@nic.fr>
<20170321161415.jr4iimgay27zt5gw@nic.fr>
Message-ID:
Stephane,
You?re right. The official documentation suggests to put the ?is_oneoff? flag inside the ?definitions? object of the request.
We?ll adapt the documentation to say we prefer the flag to be in the root object and we will promote a nested is_oneoff to the root object if it?s not clashing with other measurements in the request object.
greetings,
Jasper
> On 21 Mar 2017, at 17:14, Stephane Bortzmeyer wrote:
>
> On Tue, Mar 21, 2017 at 03:11:46PM +0100,
> Stephane Bortzmeyer 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 one-off measurement" (otherwise, I would have
>> burned all my credits for a long time!)
>
> And the official documentation disagrees with
> you.
> lists is_oneoff both at the top-level of the JSON object, and under
> "definitions".
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2619 bytes
Desc: not available
URL:
From felix.maurer at comsys.rwth-aachen.de Wed Mar 22 16:58:33 2017
From: felix.maurer at comsys.rwth-aachen.de (Felix Konstantin Maurer)
Date: Wed, 22 Mar 2017 16:58:33 +0100
Subject: [atlas] Measuring SCTP and DCCP compatibility
Message-ID: <1626925.CqUR9mmYq3@maufl-work>
Hi,
I'm interested in measuring the support of new transport protocols in consumer
routers. As IPv6 does not need rely on NAT anymore, most routers probably only
have a firewall for IPv6 traffic. I assume that these firewalls drop traffic they do
not understand, but I'm curious to see if it is actually true, or whether we
have the possibility to use new transport protocols now.
As far as I can see, there are only a limited number of possible measurements
possible with Atlas probes. Do you think they could be extended to be more
flexible and for example allow measurements using SCTP?
Regards
Felix
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL:
From adavies at ripe.net Thu Mar 23 10:00:53 2017
From: adavies at ripe.net (Alun Davies)
Date: Thu, 23 Mar 2017 10:00:53 +0100
Subject: [atlas] New on RIPE Labs: Update on First Five Sponsored RIPE Atlas
Anchors
Message-ID:
Hello all,
We just released a RIPE Labs article giving an update on the RIPE NCC?s campaign to sponsor fifteen RIPE Atlas anchors:
https://labs.ripe.net/Members/alun_davies/update-first-five-sponsored-ripe-atlas-anchors
Best regards,
Alun Davies
RIPE NCC
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2607 bytes
Desc: not available
URL:
From mostafa.shahdadi at icloud.com Thu Mar 23 12:07:02 2017
From: mostafa.shahdadi at icloud.com (mostafa)
Date: Thu, 23 Mar 2017 15:37:02 +0430
Subject: [atlas] ipad air
Message-ID: <458C3B03-397B-403F-9096-B663DE28CD89@icloud.com>
Sent from my iPad