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