From BECHA at ripe.net Thu Oct 1 11:22:44 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 1 Oct 2015 11:22:44 +0200 Subject: [atlas] Iran and K-root - The Rest of the Story In-Reply-To: <560CF66D.8020804@ripe.net> References: <560CF66D.8020804@ripe.net> Message-ID: <560CFB64.50807@ripe.net> Dear colleagues, Dyn Research published an article on K-root recently. Here we would like to augment the picture with data from RIPE Atlas in order to provide a more complete picture of the effect of the K-root node in Iran. Please find the results on RIPE Labs: https://labs.ripe.net/Members/emileaben/iran-and-k-root-the-rest-of-the-story Kind regards, Vesna From mgalante at ripe.net Thu Oct 1 15:19:33 2015 From: mgalante at ripe.net (Michela Galante) Date: Thu, 1 Oct 2015 15:19:33 +0200 Subject: [atlas] GEMNET LLC (Ulaanbaatar, Mongolia) has joined RIPE Atlas Anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called mn-uln-as45204 and it is hosted by GEMNET LLC in Ulaanbaatar, Mongolia. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team atlas at ripe.net From BECHA at ripe.net Thu Oct 1 16:08:08 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 1 Oct 2015 16:08:08 +0200 Subject: [atlas] RIPE Atlas tools Hackathon - deadline 6th October In-Reply-To: <560AA622.5050903@ripe.net> References: <560AA622.5050903@ripe.net> Message-ID: <560D3E48.40901@ripe.net> Hi all, just a reminder -- we need to know how many people are coming to the hackathon, so we need to choose between people who apply; and we need to inform the successful applicants in time for them to buy tickets... so we will *close the application* on Tuesday, 6th October, 2015 If you are interested, please apply in time: https://atlas.ripe.net/hackathon/tools-2015/#!application-form Thanks, Vesna On 29-sep.-15 16:54, Vesna Manojlovic wrote: > Calling all software developers, designers and network operators! > > The next RIPE Atlas hackathon takes place 14-15 November in Bucharest, > right before RIPE 71. > > We're looking for creative thinkers to help us find new ways to use RIPE > Atlas data to monitor networks and troubleshoot issues as well as ways > to improve the existing toolset. > > Is this you? Then we want to hear from you! > > ----------------------- > How to Apply > ----------------------- > > The application form is online at: > https://atlas.ripe.net/hackathon/tools-2015/#!application-form > > *The deadline to apply is Tuesday, 6 October* > > Successful applicants will: > > - Work alongside RIPE Atlas engineers > - Get to know others in your field > - Contribute to the shared code > - Exchange knowledge and experience > > All source code developed during the hackathon will be publicly licensed > and available on GitHub, and will be free for the entire community to use. > > ---------------------- > Hackathon details > --------------------- > > Date: 14-15 November 2015 > Time: Saturday 09:00-19:00, Sunday 09:00-21:00 (including party) > Location: JW Marriott Bucharest Grand Hotel, Bucharest, Romania > > Applicants will hear back from the jury on 12 October so that travel > arrangements can be made on time. > > Find out more on RIPE Labs: > https://labs.ripe.net/Members/becha/join-the-ripe-atlas-tools-hackathon > > -------------------- > Call for Sponsors > ------------------- > > We are still looking for sponsors! Is your organisation interested in > supporting our efforts? Please email me promptly and directly ? thank you! > > I look forward to seeing you there! > > Regards, > Vesna > > From camin at ripe.net Fri Oct 2 11:48:55 2015 From: camin at ripe.net (Chris Amin) Date: Fri, 2 Oct 2015 11:48:55 +0200 Subject: [atlas] RIPE Atlas probe archive not currently working Message-ID: <560E5307.6030708@ripe.net> Dear RIPE Atlas users, We are aware that the archive of RIPE Atlas probe metadata has not been available since code changes on Wednesday afternoon. This affects both the archive API at /api/v1/probe-archive/ and recent days in the FTP archive at http://ftp.ripe.net/ripe/atlas/probes/. If you only require old archives (Tuesday 29th September and older), you can fetch them from the FTP site as usual. We are working on restoring this functionality as quickly as possible. Please accept our apologies for any inconvenience that this may have caused. Kind regards, Chris Amin RIPE NCC From camin at ripe.net Fri Oct 2 16:26:08 2015 From: camin at ripe.net (Chris Amin) Date: Fri, 2 Oct 2015 16:26:08 +0200 Subject: [atlas] RIPE Atlas probe archive working again In-Reply-To: <560E5307.6030708@ripe.net> References: <560E5307.6030708@ripe.net> Message-ID: <560E9400.2070102@ripe.net> Dear RIPE Atlas users, The probe archive API is now working again, and the missing days have been back filled on the FTP server. Please let me know if you have any other issues. Apologies again for any inconvenience caused. Kind regards, Chris Amin RIPE NCC On 02/10/2015 11:48, Chris Amin wrote: > Dear RIPE Atlas users, > > We are aware that the archive of RIPE Atlas probe metadata has not been > available since code changes on Wednesday afternoon. This affects both > the archive API at /api/v1/probe-archive/ and recent days in the FTP > archive at http://ftp.ripe.net/ripe/atlas/probes/. If you only require > old archives (Tuesday 29th September and older), you can fetch them from > the FTP site as usual. > > We are working on restoring this functionality as quickly as possible. > Please accept our apologies for any inconvenience that this may have caused. > > 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 gary at garygapinski.com Fri Oct 2 18:56:00 2015 From: gary at garygapinski.com (Gary Gapinski) Date: Fri, 2 Oct 2015 12:56:00 -0400 Subject: [atlas] probe probed Message-ID: <560EB720.2080103@garygapinski.com> Saw my first IPv6 port scan recently, targeting my domestic Atlas probe. Originated from Shodan, first seen 2015-09-30T2017Z, and again ~24 hours later. At the moment, the probe is behind a stateful firewall (which dropped the traffic). Does it make any difference if it were moved to be completely exposed? (I've often wondered whether this should be the case to ensure proper function.) It is behind (filtered) NAT on the IPv4 side. Regards, Gary From robert at ripe.net Fri Oct 2 19:13:40 2015 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 02 Oct 2015 19:13:40 +0200 Subject: [atlas] probe probed In-Reply-To: <560EB720.2080103@garygapinski.com> References: <560EB720.2080103@garygapinski.com> Message-ID: <560EBB44.8060005@ripe.net> On 2015-10-02 18:56, Gary Gapinski wrote: > Saw my first IPv6 port scan recently, targeting my domestic Atlas probe. > > Originated from Shodan, first seen 2015-09-30T2017Z, and again ~24 hours later. > > At the moment, the probe is behind a stateful firewall (which dropped the > traffic). Does it make any difference if it were moved to be completely > exposed? (I've often wondered whether this should be the case to ensure > proper function.) It is behind (filtered) NAT on the IPv4 side. > > Regards, > > Gary Hello, The RIPE Atlas probes don't offer any real services, apart from a basic TCP/IP that answers ping requests, for example. A port scan, even locally, should result in no useful results. Some people put the probe behind the firewall (*) because that seems to be a good idea, others put it in the DMZ so that the probe is not on the same LAN as other devices, some people put it outside the firewall. From the functional point of view, it's really all the same. (*) in this case the firewall should be such that it allows measurements -- i.e. outgoing TCP/IP and responses to these Hope this helps, Robert From BECHA at ripe.net Mon Oct 5 11:11:07 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 5 Oct 2015 11:11:07 +0200 Subject: [atlas] Deadline for the hackathon *tomorrow* (RIPE Atlas tools, weekend before RIPE71) In-Reply-To: <560AA622.5050903@ripe.net> References: <560AA622.5050903@ripe.net> Message-ID: <56123EAB.1090004@ripe.net> Dear colleagues, please notice that we are going to close the application for the hackathon tomorrow (6th October). This is in order to be able to organise all the logistics with the venue, and so that the selected participants have enough time to arrange their travel & accommodation. See more info below. Regards, Vesna -------- Forwarded Message -------- Subject: [atlas] Join RIPE Atlas Hackathon - 14-15 November - Bucharest Date: Tue, 29 Sep 2015 16:54:26 +0200 From: Vesna Manojlovic To: RIPE Atlas People Calling all software developers, designers and network operators! The next RIPE Atlas hackathon takes place 14-15 November in Bucharest, right before RIPE 71. We're looking for creative thinkers to help us find new ways to use RIPE Atlas data to monitor networks and troubleshoot issues as well as ways to improve the existing toolset. Is this you? Then we want to hear from you! ----------------------- How to Apply ----------------------- The application form is online at: https://atlas.ripe.net/hackathon/tools-2015/#!application-form *The deadline to apply is Tuesday, 6 October* Successful applicants will: - Work alongside RIPE Atlas engineers - Get to know others in your field - Contribute to the shared code - Exchange knowledge and experience All source code developed during the hackathon will be publicly licensed and available on GitHub, and will be free for the entire community to use. ---------------------- Hackathon details --------------------- Date: 14-15 November 2015 Time: Saturday 09:00-19:00, Sunday 09:00-21:00 (including party) Location: JW Marriott Bucharest Grand Hotel, Bucharest, Romania Applicants will hear back from the jury on 12 October so that travel arrangements can be made on time. Find out more on RIPE Labs: https://labs.ripe.net/Members/becha/join-the-ripe-atlas-tools-hackathon -------------------- Call for Sponsors ------------------- We are still looking for sponsors! Is your organisation interested in supporting our efforts? Please email me promptly and directly ? thank you! I look forward to seeing you there! Regards, Vesna From lorenzo at google.com Wed Oct 7 07:01:32 2015 From: lorenzo at google.com (Lorenzo Colitti) Date: Wed, 7 Oct 2015 14:01:32 +0900 Subject: [atlas] Permanent private measurement Message-ID: Hi Atlas folks, I'd like to use my probe to monitor the status of my home Internet connection by continuously pinging my ISP's network (which is not the first or second hop in traceroute, but something like the sixth) and perhaps www.google.com. Is there a way to do this easily using the existing UI and tools? I couldn't find any existing measurements for this. I can look at the built-in v4 and v6 measurements for K-root, which is normally very close to me, but that's not 100% representative of the status of my Internet connection because it also measures the peering exchange link between my ISP and K-root. Cheers, Lorenzo -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristel at iij.ad.jp Wed Oct 7 07:17:27 2015 From: cristel at iij.ad.jp (Pelsser Cristel) Date: Wed, 7 Oct 2015 14:17:27 +0900 Subject: [atlas] Permanent private measurement In-Reply-To: References: Message-ID: Hi Lorenzo, > On Oct 7, 2015, at 2:01 PM, Lorenzo Colitti wrote: > > Hi Atlas folks, > > I'd like to use my probe to monitor the status of my home Internet connection by continuously pinging my ISP's network (which is not the first or second hop in traceroute, but something like the sixth) and perhaps www.google.com . Is there a way to do this easily using the existing UI and tools? You can do a traceroute and configure the TTL (Maximum hops) to 6. > > I couldn't find any existing measurements for this. I can look at the built-in v4 and v6 measurements for K-root, which is normally very close to me, but that's not 100% representative of the status of my Internet connection because it also measures the peering exchange link between my ISP and K-root. > > Cheers, > Lorenzo Cristel -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristel at iij.ad.jp Wed Oct 7 07:18:28 2015 From: cristel at iij.ad.jp (Pelsser Cristel) Date: Wed, 7 Oct 2015 14:18:28 +0900 Subject: [atlas] Permanent private measurement In-Reply-To: References: Message-ID: <9F2F4343-590D-458E-9638-57F871BBC425@iij.ad.jp> > On Oct 7, 2015, at 2:17 PM, Pelsser Cristel wrote: > > Hi Lorenzo, >> On Oct 7, 2015, at 2:01 PM, Lorenzo Colitti > wrote: >> >> Hi Atlas folks, >> >> I'd like to use my probe to monitor the status of my home Internet connection by continuously pinging my ISP's network (which is not the first or second hop in traceroute, but something like the sixth) and perhaps www.google.com . Is there a way to do this easily using the existing UI and tools? > You can do a traceroute and configure the TTL (Maximum hops) to 6. The first hop also needs to be set to 6. >> >> I couldn't find any existing measurements for this. I can look at the built-in v4 and v6 measurements for K-root, which is normally very close to me, but that's not 100% representative of the status of my Internet connection because it also measures the peering exchange link between my ISP and K-root. >> >> Cheers, >> Lorenzo > > Cristel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorenzo at google.com Wed Oct 7 08:43:57 2015 From: lorenzo at google.com (Lorenzo Colitti) Date: Wed, 7 Oct 2015 15:43:57 +0900 Subject: [atlas] Permanent private measurement In-Reply-To: References: Message-ID: On Wed, Oct 7, 2015 at 2:17 PM, Pelsser Cristel wrote: > I'd like to use my probe to monitor the status of my home Internet > connection by continuously pinging my ISP's network (which is not the first > or second hop in traceroute, but something like the sixth) and perhaps > www.google.com. Is there a way to do this easily using the existing UI > and tools? > > You can do a traceroute and configure the TTL (Maximum hops) to 6. > Thanks. In the end I hardcoded the IPv6 address for the ISP gateway, since I haven't seen it change often. I suppose I'll live to regret this. The main part of my question was "how do I set up a measurement on my own probe that runs forever" and I think the answer is "just use a user measurement". I ended up setting up three ping measurements, each one sending 4 packets each spaced by 15000ms, every minute, because that's what will fit in my credit income. It's strange that I can't send one ping every 15 seconds, but there you are. Also, the visualization is not as nice as the built-in measurements (why?) but it seems to do what I want. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Wed Oct 7 09:01:39 2015 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 07 Oct 2015 09:01:39 +0200 Subject: [atlas] Permanent private measurement In-Reply-To: References: Message-ID: <5614C353.4030306@ripe.net> > It's strange that I can't send one ping every 15 seconds, but there you are. > Also, the visualization is not as nice as the built-in measurements (why?) > but it seems to do what I want. If you could be a bit more specific (which visualisation?) then we can check what we can do about it. Generally speaking, the visualisations for built-ins need a somewhat different strategy than for UDMs, since we always expect a lot of results there. Also, the newly introduced latencymon is probably your best choice for this kind of viz. See https://labs.ripe.net/Members/massimo_candela/new-ripe-atlas-tool-latencymon Cheers, Robert From thiago.ayub at upx.com.br Thu Oct 8 03:28:27 2015 From: thiago.ayub at upx.com.br (Thiago Ayub) Date: Wed, 7 Oct 2015 22:28:27 -0300 Subject: [atlas] 3rd generation probe doesn't appear as online Message-ID: Hi, I receive a week ago our first probe but I'm unable to make it appear as online at the website. I can see it requests DHCP, it gets an IP address (NATed), it does some measurements (like HTTP and NTP) successufly but at atlas.ripe.net it is listed as 'Never online'. It rebooted around 3 times in the last week and each time was kept as least 24h in a row with no power down or cable disconnect. The MAC ADDRESS at the website matches with the MAC ADDRESS labeled in the probe. How should I proceed to get this fixed? Best regards, Thiago Ayub From lorenzo at google.com Thu Oct 8 03:55:37 2015 From: lorenzo at google.com (Lorenzo Colitti) Date: Thu, 8 Oct 2015 10:55:37 +0900 Subject: [atlas] Permanent private measurement In-Reply-To: <5614C353.4030306@ripe.net> References: <5614C353.4030306@ripe.net> Message-ID: On Wed, Oct 7, 2015 at 4:01 PM, Robert Kisteleki wrote: > > It's strange that I can't send one ping every 15 seconds, but there you > are. > > Also, the visualization is not as nice as the built-in measurements > (why?) > > but it seems to do what I want. > > If you could be a bit more specific (which visualisation?) then we can > check > what we can do about it. What I am really trying to do is what the built-in measurements do - run continuous measurements, from my probe only, to relevant targets on the Internet. I want to do this so I can measure the performance and reliability of my last-mile connectivity without factoring in any peering latency or anything else. I think this is what the built-in "traceroute second hop" measurement is intended to do, but that doesn't work for me because I (and the rest of my ISP's customers) am a variable number of hops away from the Internet. This is because the NTT NGN, unlike most unbundled access networks which use tunneling technologies such as L2TP or PPPoE, uses native IPv6. So the number of hops between customer and ISP network depends on NGN topology and routing. I worked around this by setting up a UDM that sends pings, but that's a bit of a hacky substitute, and as you say, the UDM visualizations aren't really geared to this use case. Also, the newly introduced latencymon is probably your best choice for this > kind of viz. See > > https://labs.ripe.net/Members/massimo_candela/new-ripe-atlas-tool-latencymon Latencymon sort of works (as does seismograph), but it's definitely not as nice as the built-in measurement UI. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vnaumov at ripe.net Thu Oct 8 08:18:43 2015 From: vnaumov at ripe.net (Viktor Naumov) Date: Thu, 8 Oct 2015 08:18:43 +0200 Subject: [atlas] 3rd generation probe doesn't appear as online In-Reply-To: References: Message-ID: <56160AC3.3080408@ripe.net> Hi Thiago, If you're sure that the probe gets IP, can you also make sure that the probe can do tcp/443 to outside world and DNS is working? I do not see any connection attempts from your probe to our infrastructure. Cheers! /vty On 10/8/15 3:28 AM, Thiago Ayub wrote: > Hi, > > > I receive a week ago our first probe but I'm unable to make it appear > as online at the website. I can see it requests DHCP, it gets an IP > address (NATed), it does some measurements (like HTTP and NTP) > successufly but at atlas.ripe.net it is listed as 'Never online'. It > rebooted around 3 times in the last week and each time was kept as > least 24h in a row with no power down or cable disconnect. > > The MAC ADDRESS at the website matches with the MAC ADDRESS labeled in > the probe. > > How should I proceed to get this fixed? > > > Best regards, > > > Thiago Ayub > From dgabad at gmail.com Thu Oct 8 08:33:36 2015 From: dgabad at gmail.com (Daniel Gomez) Date: Thu, 8 Oct 2015 08:33:36 +0200 Subject: [atlas] Permanent private measurement In-Reply-To: References: <5614C353.4030306@ripe.net> Message-ID: Morning Lorenzo, If I've understood your problem, you have already found a way to make the measurements from your probe but you don't like how the results are plotted. There is a GIT repository from Atlas with examples about how to get the results in json format and print them using rrdtool. You can even use a nice JavaScript library or import them to nagios or zabbix. Regards, Daniel Am 08.10.2015 3:56 vorm. schrieb "Lorenzo Colitti" : > On Wed, Oct 7, 2015 at 4:01 PM, Robert Kisteleki wrote: > >> > It's strange that I can't send one ping every 15 seconds, but there you >> are. >> > Also, the visualization is not as nice as the built-in measurements >> (why?) >> > but it seems to do what I want. >> >> If you could be a bit more specific (which visualisation?) then we can >> check >> what we can do about it. > > > What I am really trying to do is what the built-in measurements do - run > continuous measurements, from my probe only, to relevant targets on the > Internet. I want to do this so I can measure the performance and > reliability of my last-mile connectivity without factoring in any peering > latency or anything else. > > I think this is what the built-in "traceroute second hop" measurement is > intended to do, but that doesn't work for me because I (and the rest of my > ISP's customers) am a variable number of hops away from the Internet. This > is because the NTT NGN, unlike most unbundled access networks which use > tunneling technologies such as L2TP or PPPoE, uses native IPv6. So the > number of hops between customer and ISP network depends on NGN topology and > routing. > > I worked around this by setting up a UDM that sends pings, but that's a > bit of a hacky substitute, and as you say, the UDM visualizations aren't > really geared to this use case. > > Also, the newly introduced latencymon is probably your best choice for this >> kind of viz. See >> >> https://labs.ripe.net/Members/massimo_candela/new-ripe-atlas-tool-latencymon > > > Latencymon sort of works (as does seismograph), but it's definitely not as > nice as the built-in measurement UI. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From remaker at gmail.com Thu Oct 8 03:36:35 2015 From: remaker at gmail.com (Phillip Remaker) Date: Wed, 7 Oct 2015 18:36:35 -0700 Subject: [atlas] 3rd generation probe doesn't appear as online In-Reply-To: References: Message-ID: Most of the time I see this happen with there is too little power applied to the USB power. How are you powering it? On Wed, Oct 7, 2015 at 6:28 PM, Thiago Ayub wrote: > Hi, > > > I receive a week ago our first probe but I'm unable to make it appear > as online at the website. I can see it requests DHCP, it gets an IP > address (NATed), it does some measurements (like HTTP and NTP) > successufly but at atlas.ripe.net it is listed as 'Never online'. It > rebooted around 3 times in the last week and each time was kept as > least 24h in a row with no power down or cable disconnect. > > The MAC ADDRESS at the website matches with the MAC ADDRESS labeled in > the probe. > > How should I proceed to get this fixed? > > > Best regards, > > > Thiago Ayub > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danny at danysek.cz Thu Oct 8 10:08:23 2015 From: danny at danysek.cz (Daniel Suchy) Date: Thu, 8 Oct 2015 10:08:23 +0200 Subject: [atlas] 3rd generation probe doesn't appear as online In-Reply-To: References: Message-ID: <56162477.6000505@danysek.cz> Hello, dead external USB flash can be also one of reasons (I had such issue). You can try replace it with new one. With regards, Daniel On 8.10.2015 03:28, Thiago Ayub wrote: > Hi, > > > I receive a week ago our first probe but I'm unable to make it appear > as online at the website. I can see it requests DHCP, it gets an IP > address (NATed), it does some measurements (like HTTP and NTP) > successufly but at atlas.ripe.net it is listed as 'Never online'. It > rebooted around 3 times in the last week and each time was kept as > least 24h in a row with no power down or cable disconnect. > > The MAC ADDRESS at the website matches with the MAC ADDRESS labeled in > the probe. > > How should I proceed to get this fixed? > > > Best regards, > > > Thiago Ayub > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4233 bytes Desc: S/MIME Cryptographic Signature URL: From gert at space.net Thu Oct 8 10:20:14 2015 From: gert at space.net (Gert Doering) Date: Thu, 8 Oct 2015 10:20:14 +0200 Subject: [atlas] 3rd generation probe doesn't appear as online In-Reply-To: <56162477.6000505@danysek.cz> References: <56162477.6000505@danysek.cz> Message-ID: <20151008082014.GB84167@Space.Net> Hi, On Thu, Oct 08, 2015 at 10:08:23AM +0200, Daniel Suchy wrote: > dead external USB flash can be also one of reasons (I had such issue). > You can try replace it with new one. Yeah, the v3 probes seem to be a bit flakey in that regard - I have 3 of them, and two had flash that the box just did not like (but which seems to be working nicely elsewhere). Flash replaced, box happy. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5023 bytes Desc: not available URL: From daniel.karrenberg at ripe.net Thu Oct 8 10:31:33 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 8 Oct 2015 10:31:33 +0200 Subject: [atlas] 3rd generation probe doesn't appear as online In-Reply-To: <20151008082014.GB84167@Space.Net> References: <56162477.6000505@danysek.cz> <20151008082014.GB84167@Space.Net> Message-ID: <561629E5.40107@ripe.net> Actually both the power and the USB memory issues can be related. I have "repaired" non-working flash by changing the power supply. Daniel From thiago.ayub at upx.com.br Thu Oct 8 14:54:55 2015 From: thiago.ayub at upx.com.br (Thiago Ayub) Date: Thu, 8 Oct 2015 09:54:55 -0300 Subject: [atlas] 3rd generation probe doesn't appear as online In-Reply-To: <56162477.6000505@danysek.cz> References: <56162477.6000505@danysek.cz> Message-ID: Hi, How can I repair the flash memory? Is there an image file online I can download it and write it to a new flash memory and insert it at the TP-Link device? Best regards, Thiago Ayub -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu Oct 8 14:58:31 2015 From: gert at space.net (Gert Doering) Date: Thu, 8 Oct 2015 14:58:31 +0200 Subject: [atlas] 3rd generation probe doesn't appear as online In-Reply-To: References: <56162477.6000505@danysek.cz> Message-ID: <20151008125831.GR84167@Space.Net> Hi, On Thu, Oct 08, 2015 at 09:54:55AM -0300, Thiago Ayub wrote: > How can I repair the flash memory? Is there an image file online I can > download it and write it to a new flash memory and insert it at the > TP-Link device? Turn off, remove flash stick, turn off (it will now boot from internal memory), after a few minutes, insert new flash stick, wait. For me, this was usually sufficient to get the boxes back to live. Also, you can look on the "my probes" page under "network", all the way down, for the last SOS DNS messages the probe sent - it will usually tell the system (via queries like "INO-USB.$probeid....ripe.net") what is wrong. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From robert at ripe.net Thu Oct 8 15:10:48 2015 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 08 Oct 2015 15:10:48 +0200 Subject: [atlas] 3rd generation probe doesn't appear as online In-Reply-To: <20151008125831.GR84167@Space.Net> References: <56162477.6000505@danysek.cz> <20151008125831.GR84167@Space.Net> Message-ID: <56166B58.5020500@ripe.net> > Also, you can look on the "my probes" page under "network", all the > way down, for the last SOS DNS messages the probe sent - it will usually > tell the system (via queries like "INO-USB.$probeid....ripe.net") > what is wrong. FYI: the log of these queries is exposed in the UI, at the bottom of the network tab of your probe status page. Cheers, Robert From vnaumov at ripe.net Thu Oct 8 15:43:20 2015 From: vnaumov at ripe.net (Viktor Naumov) Date: Thu, 8 Oct 2015 15:43:20 +0200 Subject: [atlas] 3rd generation probe doesn't appear as online In-Reply-To: <56166B58.5020500@ripe.net> References: <56162477.6000505@danysek.cz> <20151008125831.GR84167@Space.Net> <56166B58.5020500@ripe.net> Message-ID: <561672F8.40609@ripe.net> That's the thing. There are no even SOS messages from that probe. In such cases one should double check the tcp/443 and DNS working before starting fiddling with the hardware. /vty On 10/8/15 3:10 PM, Robert Kisteleki wrote: >> Also, you can look on the "my probes" page under "network", all the >> way down, for the last SOS DNS messages the probe sent - it will usually >> tell the system (via queries like "INO-USB.$probeid....ripe.net") >> what is wrong. > FYI: the log of these queries is exposed in the UI, at the bottom of the > network tab of your probe status page. > > Cheers, > Robert > From alarig at grifon.fr Sat Oct 10 20:15:37 2015 From: alarig at grifon.fr (Alarig Le Lay) Date: Sat, 10 Oct 2015 20:15:37 +0200 Subject: [atlas] IPv6 only Message-ID: <20151010181537.GI4724@drscott.swordarmor.fr> Hi, Are the probes able to run on an IPv6 only network? I?ve configured one and left the default IPv4 configuration (i.e. DHCP) but the probe is not marked as running in the web interface. Regards, -- Alarig Le Lay -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From robert at ripe.net Sun Oct 11 11:04:56 2015 From: robert at ripe.net (Robert Kisteleki) Date: Sun, 11 Oct 2015 11:04:56 +0200 Subject: [atlas] IPv6 only In-Reply-To: <20151010181537.GI4724@drscott.swordarmor.fr> References: <20151010181537.GI4724@drscott.swordarmor.fr> Message-ID: <561A2638.5030801@ripe.net> On 2015-10-10 20:15, Alarig Le Lay wrote: > Hi, > > Are the probes able to run on an IPv6 only network? I?ve configured one > and left the default IPv4 configuration (i.e. DHCP) but the probe is not > marked as running in the web interface. > > Regards, Hi, The short answer is yes, the longer one is in the FAQ: https://atlas.ripe.net/about/faq/#i-have-an-ipv6-only-network-will-the-probe-work-on-it Regards, Robert From John_Brzozowski at Cable.Comcast.com Mon Oct 12 02:53:26 2015 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Mon, 12 Oct 2015 00:53:26 +0000 Subject: [atlas] More built in IPv6 tests Message-ID: Would it be possible to include some new built in measurements for the following: * IPv6 only capable * IPv6 preferred (and perhaps IPv6 capable, this is different than IPv6 only capable above) * Compare IPv4 and IPv6 performance over HTTP John +1-484-962-0060 -----Original Message----- From: ripe-atlas on behalf of Robert Kisteleki Organization: RIPE NCC Date: Sunday, October 11, 2015 at 05:04 To: Alarig Le Lay , "ripe-atlas at ripe.net" Subject: Re: [atlas] IPv6 only >On 2015-10-10 20:15, Alarig Le Lay wrote: >> Hi, >> >> Are the probes able to run on an IPv6 only network? I?ve configured one >> and left the default IPv4 configuration (i.e. DHCP) but the probe is not >> marked as running in the web interface. >> >> Regards, > >Hi, > >The short answer is yes, the longer one is in the FAQ: >https://atlas.ripe.net/about/faq/#i-have-an-ipv6-only-network-will-the-pro >be-work-on-it > >Regards, >Robert > > From mgalante at ripe.net Wed Oct 14 16:32:00 2015 From: mgalante at ripe.net (Michela Galante) Date: Wed, 14 Oct 2015 16:32:00 +0200 Subject: [atlas] New on RIPE Labs: Researching F-root Anycast Placement Using RIPE Atlas Message-ID: Dear colleagues, Please find a new article on RIPE Labs: https://labs.ripe.net/Members/ray_bellis/researching-f-root-anycast-placement-using-ripe-atlas In order to expand the reach of F-root, Ray Bellis looked at where queries to F-root are coming from and where it would make most sense to place new nodes. As a first step, Ray looked at the existing nodes to see how they behave and if there is anything that can be improved. He used RIPE Atlas to do this. Kind regards, Michela Galante RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From brak at gameservers.com Fri Oct 16 01:08:02 2015 From: brak at gameservers.com (Brian Rak) Date: Thu, 15 Oct 2015 19:08:02 -0400 Subject: [atlas] [Feature Request] Show probe address on failure notifications Message-ID: <562031D2.9090607@gameservers.com> I recently received one an email indicating one of my probes is offline: This is the second reminder that your probe (#20689 ) is not connected to our infrastructure and has been disconnected since 2015-09-14 09:37 UTC. Could you please check whether everything is set up correctly on your side? If it is, and your probe is still reported as disconnected when you log in at https://atlas.ripe.net, please reply to this email so that we can follow up. Is there any way these can be modified to include further information (like the probe's address, or basically anything about it)? Probe 20689 means nothing to me, so I have to log in to take a look at exactly what it is, and where I need to go to fix it. From dquinn at ripe.net Fri Oct 16 11:16:58 2015 From: dquinn at ripe.net (Daniel Quinn) Date: Fri, 16 Oct 2015 11:16:58 +0200 Subject: [atlas] [Feature Request] Show probe address on failure notifications In-Reply-To: <562031D2.9090607@gameservers.com> References: <562031D2.9090607@gameservers.com> Message-ID: <5620C08A.1040905@ripe.net> We can do better than that. You already have the option to name your probe whatever you like, so you can label it ?The one in Dad?s basement? and then the next time you get that email, it?ll include the name instead of just ?Probe #20689?. So, to edit the probe name, just log into RIPE Atlas go to your probe page , then click the |Edit| button (screenshot attached). The form that appears includes a |Name:| field. Fill that in with whatever you like and then click |Save|. The new name is now applied, and will appear at the top of the page the next time you visit. All emails that mention this probe will now use this new name. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20689.png Type: image/png Size: 21179 bytes Desc: not available URL: From brak at gameservers.com Fri Oct 16 17:23:21 2015 From: brak at gameservers.com (Brian Rak) Date: Fri, 16 Oct 2015 11:23:21 -0400 Subject: [atlas] [Feature Request] Show probe address on failure notifications In-Reply-To: <5620C08A.1040905@ripe.net> References: <562031D2.9090607@gameservers.com> <5620C08A.1040905@ripe.net> Message-ID: <56211669.2070304@gameservers.com> Ah, that's very helpful. Thanks. On 10/16/2015 5:16 AM, Daniel Quinn wrote: > > We can do better than that. You already have the option to name your > probe whatever you like, so you can label it ?The one in Dad?s > basement? and then the next time you get that email, it?ll include the > name instead of just ?Probe #20689?. > > So, to edit the probe name, just log into RIPE Atlas go to your probe > page , then click the |Edit| > button (screenshot attached). The form that appears includes a |Name:| > field. Fill that in with whatever you like and then click |Save|. The > new name is now applied, and will appear at the top of the page the > next time you visit. All emails that mention this probe will now use > this new name. > > ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.brewer at gmail.com Mon Oct 19 06:00:47 2015 From: jon.brewer at gmail.com (Jonathan Brewer) Date: Mon, 19 Oct 2015 17:00:47 +1300 Subject: [atlas] Private Probes: What's the Point Message-ID: Hi All, I've run into a few probes marked private, and when I've found & asked the owners, they didn't realise they'd done anything restrictive or harmful to researchers by marking their probes private. Intrigued at this phenomena, I had a look at the probe metadata. Right now I think there are 1,534 Atlas probes that are active and connected to the network, but marked private. What's the point of having private probes in the network? Do their hosts still earn credits they can use on public probes? Should they be? Are private probe hosts helping the project? The FAQ says nothing about private probes, so I thought I would ask here. Thanks, Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sneuner.org Mon Oct 19 10:31:19 2015 From: sebastian at sneuner.org (Sebastian Neuner) Date: Mon, 19 Oct 2015 10:31:19 +0200 Subject: [atlas] filter ping results by AS Message-ID: <5624AA57.2040604@sneuner.org> Hi there, I'm currently trying to figure out, how I can get all ping results to(/from) my AS within a certain time frame, to run some statistics. The REST-API documentation [0] states, that measurements can be filtered by dst_asn, but it doesn't seem to influence the results I'm getting: > filter: { > 'start_time__gt': 1445231337, > 'type': 'ping', > 'dst_asn': 553 > } > > dst_asn dst_name > -------------------------------------------- > 2607 sk-bts-as2607.anchors.atlas.ripe.net > 2602 lu-lux-as2602.anchors.atlas.ripe.net > 16154 88.213.204.251 > 1853 at-vie-as1853.anchors.atlas.ripe.net > 8608 195.18.114.5 > 32475 www.siteground.com > 12322 78.194.137.59 > None ch-zrh-as559.anchors.atlas.ripe.net Also, why do some measurements have no dst_asn? Regards, Sebastian [0] https://atlas.ripe.net/docs/rest/ From dquinn at ripe.net Mon Oct 19 12:25:19 2015 From: dquinn at ripe.net (Daniel Quinn) Date: Mon, 19 Oct 2015 12:25:19 +0200 Subject: [atlas] filter ping results by AS In-Reply-To: <5624AA57.2040604@sneuner.org> References: <5624AA57.2040604@sneuner.org> Message-ID: <5624C50F.1050401@ripe.net> We're working on migrating some of our API code and it looks like you bumped into something I missed when doing that migration. The good news though, is that now that you've found it, I've fixed it and you can now do API calls like this again: https://atlas.ripe.net/api/v1/measurement/?dst_asn=3333 As for the measurements that don't have an ASN value, we're looking into that, but there are a number of legitimate reasons for their not having one, including having no target specified (some DNS measurements for example). From sebastian at sneuner.org Mon Oct 19 13:06:42 2015 From: sebastian at sneuner.org (Sebastian Neuner) Date: Mon, 19 Oct 2015 13:06:42 +0200 Subject: [atlas] filter ping results by AS In-Reply-To: <5624C50F.1050401@ripe.net> References: <5624AA57.2040604@sneuner.org> <5624C50F.1050401@ripe.net> Message-ID: <5624CEC2.30708@sneuner.org> Awesome, thank you for the quick fix! Is there (or will there be) some kind of shortcut for fetching results, without filtering for the corresponding measurement definitions first? Regards, Sebastian On 19.10.2015 12:25, Daniel Quinn wrote: > We're working on migrating some of our API code and it looks like you > bumped into something I missed when doing that migration. The good news > though, is that now that you've found it, I've fixed it and you can now > do API calls like this again: > > https://atlas.ripe.net/api/v1/measurement/?dst_asn=3333 > > As for the measurements that don't have an ASN value, we're looking into > that, but there are a number of legitimate reasons for their not having > one, including having no target specified (some DNS measurements for > example). From dquinn at ripe.net Mon Oct 19 15:22:10 2015 From: dquinn at ripe.net (Daniel Quinn) Date: Mon, 19 Oct 2015 15:22:10 +0200 Subject: [atlas] filter ping results by AS In-Reply-To: <5624CEC2.30708@sneuner.org> References: <5624AA57.2040604@sneuner.org> <5624C50F.1050401@ripe.net> <5624CEC2.30708@sneuner.org> Message-ID: <5624EE82.40703@ripe.net> It?s not on our List of Things to Do, no. The difficulty is in the massive amounts of data ? there?s simply no easy way to fetch arbitrary results from such a large data store based on arbitrary lookup values. Currently we store data keyed by measurement id, probe id, and time, and that covers most of the use-cases. You should know however that we do supply weekly dump files of measurement meta data, so you can use these to prepare your results queries without beating the crap out of our API service :-) ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jeroen at hltools.com Tue Oct 20 10:39:29 2015 From: Jeroen at hltools.com (Jeroen Bogers) Date: Tue, 20 Oct 2015 08:39:29 +0000 Subject: [atlas] Prove v3 not connecting after powercyle Message-ID: <048622d49c4846d0b037b7113dc680d0@ex02.pc-online.local> Hi all, Two days ago I had to powercycle some of my network equipment, including my Atlas V3 probe. After the powercycle, the probe did not come back online. After booting, the first and second light (power and the one next to it) remain lit (not blinking). This is not a state that is listed in the FAQ: https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean The only status that comes close is the 'Running from built-in flash' state, but led 2 should be blinking then? Does someone here have an idea what is wrong with my probe (and how to fix it)? I already tried connecting it to a different network port and power source, but this did not make any difference. The switch port the probe is connected to does light up, so the Ethernet port seems to be functioning. With kind regards, Jeroen Bogers -------------- next part -------------- An HTML attachment was scrubbed... URL: From woeber at cc.univie.ac.at Tue Oct 20 18:36:04 2015 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Tue, 20 Oct 2015 17:36:04 +0100 Subject: [atlas] Private Probes: What's the Point In-Reply-To: References: Message-ID: <56266D74.9040409@cc.univie.ac.at> Hi Jon! On 2015-10-19 05:00, Jonathan Brewer wrote: > Hi All, > > I've run into a few probes marked private, and when I've found & asked the owners, > they didn't realise they'd done anything restrictive or harmful to researchers by > marking their probes private. > > Intrigued at this phenomena, I had a look at the probe metadata. Right now I think > there are 1,534 Atlas probes that are active and connected to the network, but > marked private. > > What's the point of having private probes in the network? Do their hosts still" > earn credits they can use on public probes? Should they be? Are private probe > hosts helping the project? IIRC, we did have quite a bit on the topic of labelling probes as "private", but I would have to do some digging to find the references to that discussion.. But before chiming in ith my personal point of view, may I ask the Atlas Team to summarize what the effects of "private" are. I seem to remember that private probes *do* participate in the built-in measurements. I may be wron, though. > The FAQ says nothing about private probes, so I thought I would ask here. I think it is pretty useful to have another look at that setting. > Thanks, > > Jon Cheers, Wilfried From james.cutler at consultant.com Tue Oct 20 20:03:58 2015 From: james.cutler at consultant.com (James R Cutler) Date: Tue, 20 Oct 2015 14:03:58 -0400 Subject: [atlas] Private Probes: What's the Point In-Reply-To: <56266D74.9040409@cc.univie.ac.at> References: <56266D74.9040409@cc.univie.ac.at> Message-ID: <64D15CD4-89B8-42EF-8599-16A7EA509D3C@consultant.com> > On Oct 20, 2015, at 12:36 PM, Wilfried Woeber wrote: > > Hi Jon! > > On 2015-10-19 05:00, Jonathan Brewer wrote: >> Hi All, >> >> I've run into a few probes marked private, and when I've found & asked the owners, >> they didn't realise they'd done anything restrictive or harmful to researchers by >> marking their probes private. >> >> Intrigued at this phenomena, I had a look at the probe metadata. Right now I think >> there are 1,534 Atlas probes that are active and connected to the network, but >> marked private. >> >> What's the point of having private probes in the network? Do their hosts still" >> earn credits they can use on public probes? Should they be? Are private probe >> hosts helping the project? > > IIRC, we did have quite a bit on the topic of labelling probes as "private", but > I would have to do some digging to find the references to that discussion.. > > But before chiming in ith my personal point of view, may I ask the Atlas Team > to summarize what the effects of "private" are. I seem to remember that private > probes *do* participate in the built-in measurements. I may be wron, though. > >> The FAQ says nothing about private probes, so I thought I would ask here. > > I think it is pretty useful to have another look at that setting. > >> Thanks, >> >> Jon > > Cheers, > Wilfried > My understanding is that my private probe participates in built-in measurements but is not open to the world. My small network is not designed to serve as a target for the world. James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From becha at ripe.net Wed Oct 21 14:35:40 2015 From: becha at ripe.net (Vesna Manojlovic) Date: Wed, 21 Oct 2015 14:35:40 +0200 Subject: [atlas] Public vs. Non-Public Probes Message-ID: <35C31958-F23B-4BDE-8E54-5130DC39B19F@ripe.net> Hi Jonathan and others, Thanks for bringing this point up again. I hope others will feel free to join in the discussion. As Wilfried mentioned, we did have a discussion about public and non-public probes some time ago. Here are the relevant posts: RIPE Labs article proposing making RIPE Atlas probes and measurements more public: https://labs.ripe.net/Members/becha/proposing-making-ripe-atlas-data-more-public Discussion on the ripe-atlas list: https://www.ripe.net/ripe/mail/archives/mat-wg/2013-December/000399.html Conclusion: https://www.ripe.net/ripe/mail/archives/mat-wg/2014-March/000436.html Consequences: new terms & conditions, with more clarification on this topic: https://labs.ripe.net/Members/becha/ripe-atlas-moving-to-production-service & https://atlas.ripe.net/legal/terms-conditions/ As you can see from the discussions above, some RIPE Atlas users felt it was important to retain the choice of marking their probes ?non-public?. We do encourage all RIPE Atlas users to mark their probes ?public? for the greatest benefit to the community, and the majority of probes are public. However, non-public probes are still used both for built-in measurements and user-defined measurements; they are just not listed on the web or API. Once a user decides to plug a probe into their network, IP address information can no longer remain "private". This is why we prefer to refer to them as ?non-public? probes rather than truly ?private? probes. Of course, we care very much about protecting probe hosts? privacy and we never make personal information like email addresses or MAC addresses public. There is some more information about this in the FAQs on the RIPE Atlas website under the answers to "Will my IP address show up in measurements done by my probe?? and "Is the measurement data made public??, but the RIPE Labs article referenced above contains the most detailed information on the topic. Thanks again for your thoughts on this, and please let us know if you have any other questions or comments. Regards, Vesna From woeber at cc.univie.ac.at Thu Oct 22 16:10:19 2015 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Thu, 22 Oct 2015 15:10:19 +0100 Subject: [atlas] Public vs. Non-Public Probes In-Reply-To: <35C31958-F23B-4BDE-8E54-5130DC39B19F@ripe.net> References: <35C31958-F23B-4BDE-8E54-5130DC39B19F@ripe.net> Message-ID: <5628EE4B.8050800@cc.univie.ac.at> Thanks, Vesna and Team, for digging up the references! Wifried (from ICANN54 at Dublin) From dquinn at ripe.net Thu Oct 22 16:35:44 2015 From: dquinn at ripe.net (Daniel Quinn) Date: Thu, 22 Oct 2015 16:35:44 +0200 Subject: [atlas] Private Probes: What's the Point In-Reply-To: <64D15CD4-89B8-42EF-8599-16A7EA509D3C@consultant.com> References: <56266D74.9040409@cc.univie.ac.at> <64D15CD4-89B8-42EF-8599-16A7EA509D3C@consultant.com> Message-ID: <5628F440.3000004@ripe.net> Hi James, I just wanted to clarify a few points about how the probes work in response to your comment. All RIPE Atlas probes, even those not marked ?public?, are available to be used in both built-in and user-defined measurements *as sources*. Many probes are not hosted on the open Internet, so they make for lousy targets. In most cases, they're hosted on internal networks, so they're often not ?targetable? at all. More importantly, hosting a probe does not make your network (which already exists on the open Internet) any more or less likely to be the target of a measurement. And in terms of outgoing traffic, the probe generates next to nothing (typically a few Kb/s, even when it?s being used for user-defined measurements). You can learn more about this from the FAQs: https://atlas.ripe.net/about/faq/ Please let us know if you have any other questions. Regards, Daniel Quinn From wenqin.shao at telecom-paristech.fr Thu Oct 22 17:00:38 2015 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Thu, 22 Oct 2015 17:00:38 +0200 Subject: [atlas] Private Probes: What's the Point In-Reply-To: <5628F440.3000004@ripe.net> References: <56266D74.9040409@cc.univie.ac.at> <64D15CD4-89B8-42EF-8599-16A7EA509D3C@consultant.com> <5628F440.3000004@ripe.net> Message-ID: Dear list, Talking about how public and non-public probe participates in built-in and user-defined measurement, a possible scenario has come to my mind (maybe it?s not really relevant to what you are discussing right now). Here goes the case: I host a probe and it is required to participate in a UDM involving sensitive destinations, say DNS measurement to ISIS?s site (could be interesting and useful in certain senses), which however might violet my local security policies. As a consequence, the big brother might knock at my door and invite me for a coffee?or something more serious. My question is, if that happens, am I really responsible for that and whether it is possible to avoid participating in certain risky measurements. Possibly I wrong too much. Best regards, wenqin > On 22 Oct 2015, at 16:35, Daniel Quinn wrote: > > Hi James, > > I just wanted to clarify a few points about how the probes work in response to your comment. > > All RIPE Atlas probes, even those not marked ?public?, are available to be used in both built-in and user-defined measurements *as sources*. > > Many probes are not hosted on the open Internet, so they make for lousy targets. In most cases, they're hosted on internal networks, so they're often not ?targetable? at all. More importantly, hosting a probe does not make your network (which already exists on the open Internet) any more or less likely to be the target of a measurement. > > And in terms of outgoing traffic, the probe generates next to nothing (typically a few Kb/s, even when it?s being used for user-defined measurements). > > You can learn more about this from the FAQs: > https://atlas.ripe.net/about/faq/ > > Please let us know if you have any other questions. > > Regards, > > Daniel Quinn > From wenqin.shao at telecom-paristech.fr Thu Oct 22 17:07:13 2015 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Thu, 22 Oct 2015 17:07:13 +0200 Subject: [atlas] Private Probes: What's the Point In-Reply-To: References: <56266D74.9040409@cc.univie.ac.at> <64D15CD4-89B8-42EF-8599-16A7EA509D3C@consultant.com> <5628F440.3000004@ripe.net> Message-ID: For example there are discussion these days concerning this paper: http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p653.pdf https://readings.owlfolio.org/2015/encore-lightweight-measurement-web-censorship/ I wonder if Atlas platform has similar concerns as well. Best regards, weqnin > On 22 Oct 2015, at 17:00, Wenqin SHAO wrote: > > Dear list, > > Talking about how public and non-public probe participates in built-in and user-defined measurement, a possible scenario has come to my mind (maybe it?s not really relevant to what you are discussing right now). Here goes the case: > > I host a probe and it is required to participate in a UDM involving sensitive destinations, say DNS measurement to ISIS?s site (could be interesting and useful in certain senses), which however might violet my local security policies. As a consequence, the big brother might knock at my door and invite me for a coffee?or something more serious. > > My question is, if that happens, am I really responsible for that and whether it is possible to avoid participating in certain risky measurements. > > Possibly I wrong too much. > > Best regards, > wenqin > >> On 22 Oct 2015, at 16:35, Daniel Quinn wrote: >> >> Hi James, >> >> I just wanted to clarify a few points about how the probes work in response to your comment. >> >> All RIPE Atlas probes, even those not marked ?public?, are available to be used in both built-in and user-defined measurements *as sources*. >> >> Many probes are not hosted on the open Internet, so they make for lousy targets. In most cases, they're hosted on internal networks, so they're often not ?targetable? at all. More importantly, hosting a probe does not make your network (which already exists on the open Internet) any more or less likely to be the target of a measurement. >> >> And in terms of outgoing traffic, the probe generates next to nothing (typically a few Kb/s, even when it?s being used for user-defined measurements). >> >> You can learn more about this from the FAQs: >> https://atlas.ripe.net/about/faq/ >> >> Please let us know if you have any other questions. >> >> Regards, >> >> Daniel Quinn >> > > From daniel.karrenberg at ripe.net Thu Oct 22 17:17:09 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 22 Oct 2015 17:17:09 +0200 Subject: [atlas] Private Probes: What's the Point In-Reply-To: References: <56266D74.9040409@cc.univie.ac.at> <64D15CD4-89B8-42EF-8599-16A7EA509D3C@consultant.com> <5628F440.3000004@ripe.net> Message-ID: <5628FDF5.7040502@ripe.net> Wengin, Thank you for your good question. This is exactly why we allow HTTP measurements only to well defined targets. So far we assume that DNS queries are not harmful. Since we cannot know what is "risky" in all places there is little else we can do. Would you have more peace of mind if you could opt out of DNS the probe doing DNS queries related to measurements altogether? On the positive side: Should any host get in trouble we commit to go back to our logs/results and testify that the traffic was originated by our probe. Of course we cannot tell you what your local authorities will hold you responsible for. Would a ping to a certain address get you in trouble? So if you are *really* *really* concerned about this you should not host a probe. Daniel On 22.10.15 17:00 , Wenqin SHAO wrote: > Dear list, > > Talking about how public and non-public probe participates in built-in and user-defined measurement, a possible scenario has come to my mind (maybe it?s not really relevant to what you are discussing right now). Here goes the case: > > I host a probe and it is required to participate in a UDM involving sensitive destinations, say DNS measurement to ISIS?s site (could be interesting and useful in certain senses), which however might violet my local security policies. As a consequence, the big brother might knock at my door and invite me for a coffee?or something more serious. > > My question is, if that happens, am I really responsible for that and whether it is possible to avoid participating in certain risky measurements. > > Possibly I wrong too much. > > Best regards, > wenqin > >> On 22 Oct 2015, at 16:35, Daniel Quinn wrote: >> >> Hi James, >> >> I just wanted to clarify a few points about how the probes work in response to your comment. >> >> All RIPE Atlas probes, even those not marked ?public?, are available to be used in both built-in and user-defined measurements *as sources*. >> >> Many probes are not hosted on the open Internet, so they make for lousy targets. In most cases, they're hosted on internal networks, so they're often not ?targetable? at all. More importantly, hosting a probe does not make your network (which already exists on the open Internet) any more or less likely to be the target of a measurement. >> >> And in terms of outgoing traffic, the probe generates next to nothing (typically a few Kb/s, even when it?s being used for user-defined measurements). >> >> You can learn more about this from the FAQs: >> https://atlas.ripe.net/about/faq/ >> >> Please let us know if you have any other questions. >> >> Regards, >> >> Daniel Quinn >> > > > From daniel.karrenberg at ripe.net Thu Oct 22 17:26:46 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 22 Oct 2015 17:26:46 +0200 Subject: [atlas] Private Probes: What's the Point In-Reply-To: References: <56266D74.9040409@cc.univie.ac.at> <64D15CD4-89B8-42EF-8599-16A7EA509D3C@consultant.com> <5628F440.3000004@ripe.net> Message-ID: <56290036.7000503@ripe.net> Im my, biased, opinion Atlas is has significantly less ethical issues. Atlas is not running on the user's system or browser and we do much less than could be done with javascript. So Atlas measurement traffic looks very much less like it is coming from the user and the user is not exposed to content/malware through Atlas. Daniel On 22.10.15 17:07 , Wenqin SHAO wrote: > For example there are discussion these days concerning this paper: > > http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p653.pdf > https://readings.owlfolio.org/2015/encore-lightweight-measurement-web-censorship/ > From wenqin.shao at telecom-paristech.fr Thu Oct 22 17:33:55 2015 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Thu, 22 Oct 2015 17:33:55 +0200 Subject: [atlas] Private Probes: What's the Point In-Reply-To: <5628FDF5.7040502@ripe.net> References: <56266D74.9040409@cc.univie.ac.at> <64D15CD4-89B8-42EF-8599-16A7EA509D3C@consultant.com> <5628F440.3000004@ripe.net> <5628FDF5.7040502@ripe.net> Message-ID: <3351C43A-3CF0-4B24-90FA-A218E3133FAC@telecom-paristech.fr> Hello Daniel, Thank you very much for you quick response. I personally am not very much concerned. The possibility just came into my mind. I plan to move my recently obtained probe into a Academic network in China, where the hosting institution there shall take the responsibility for all consequences, instead of putting it my parents? living room. One other issue with security policies is that sometime one wouldn?t learn these rules if one hadn?t violet them in first place. Regards, Wenqin > On 22 Oct 2015, at 17:17, Daniel Karrenberg wrote: > > Wengin, > > Thank you for your good question. > > This is exactly why we allow HTTP measurements only to well defined > targets. So far we assume that DNS queries are not harmful. Since we > cannot know what is "risky" in all places there is little else we can > do. Would you have more peace of mind if you could opt out of DNS the > probe doing DNS queries related to measurements altogether? > > On the positive side: Should any host get in trouble we commit to go > back to our logs/results and testify that the traffic was originated by > our probe. > > Of course we cannot tell you what your local authorities will hold you > responsible for. Would a ping to a certain address get you in trouble? > So if you are *really* *really* concerned about this you should not host > a probe. > > Daniel > > On 22.10.15 17:00 , Wenqin SHAO wrote: >> Dear list, >> >> Talking about how public and non-public probe participates in built-in and user-defined measurement, a possible scenario has come to my mind (maybe it?s not really relevant to what you are discussing right now). Here goes the case: >> >> I host a probe and it is required to participate in a UDM involving sensitive destinations, say DNS measurement to ISIS?s site (could be interesting and useful in certain senses), which however might violet my local security policies. As a consequence, the big brother might knock at my door and invite me for a coffee?or something more serious. >> >> My question is, if that happens, am I really responsible for that and whether it is possible to avoid participating in certain risky measurements. >> >> Possibly I wrong too much. >> >> Best regards, >> wenqin >> >>> On 22 Oct 2015, at 16:35, Daniel Quinn wrote: >>> >>> Hi James, >>> >>> I just wanted to clarify a few points about how the probes work in response to your comment. >>> >>> All RIPE Atlas probes, even those not marked ?public?, are available to be used in both built-in and user-defined measurements *as sources*. >>> >>> Many probes are not hosted on the open Internet, so they make for lousy targets. In most cases, they're hosted on internal networks, so they're often not ?targetable? at all. More importantly, hosting a probe does not make your network (which already exists on the open Internet) any more or less likely to be the target of a measurement. >>> >>> And in terms of outgoing traffic, the probe generates next to nothing (typically a few Kb/s, even when it?s being used for user-defined measurements). >>> >>> You can learn more about this from the FAQs: >>> https://atlas.ripe.net/about/faq/ >>> >>> Please let us know if you have any other questions. >>> >>> Regards, >>> >>> Daniel Quinn >>> >> >> >> > From wenqin.shao at telecom-paristech.fr Thu Oct 22 17:42:37 2015 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Thu, 22 Oct 2015 17:42:37 +0200 Subject: [atlas] Private Probes: What's the Point In-Reply-To: <56290036.7000503@ripe.net> References: <56266D74.9040409@cc.univie.ac.at> <64D15CD4-89B8-42EF-8599-16A7EA509D3C@consultant.com> <5628F440.3000004@ripe.net> <56290036.7000503@ripe.net> Message-ID: I totally agree with you on the point that no actual content is involved in Atlas measurements. In that sense, Atlas is in deed much less problematic than the work on web censorship. However, I recall (I tried and failed to find the reference for the moment being) that in France, some type of metadata might be as well sensitive, say a URL, and that?s why I mentioned DNS measurements previously. Wenqin > On 22 Oct 2015, at 17:26, Daniel Karrenberg wrote: > > > Im my, biased, opinion Atlas is has significantly less ethical issues. > Atlas is not running on the user's system or browser and we do much less > than could be done with javascript. So Atlas measurement traffic looks > very much less like it is coming from the user and the user is not > exposed to content/malware through Atlas. > > Daniel > > On 22.10.15 17:07 , Wenqin SHAO wrote: >> For example there are discussion these days concerning this paper: >> >> http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p653.pdf >> https://readings.owlfolio.org/2015/encore-lightweight-measurement-web-censorship/ >> > From daniel.karrenberg at ripe.net Thu Oct 22 17:48:27 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 22 Oct 2015 17:48:27 +0200 Subject: [atlas] Private Probes: What's the Point In-Reply-To: <3351C43A-3CF0-4B24-90FA-A218E3133FAC@telecom-paristech.fr> References: <56266D74.9040409@cc.univie.ac.at> <64D15CD4-89B8-42EF-8599-16A7EA509D3C@consultant.com> <5628F440.3000004@ripe.net> <5628FDF5.7040502@ripe.net> <3351C43A-3CF0-4B24-90FA-A218E3133FAC@telecom-paristech.fr> Message-ID: <5629054B.7080902@ripe.net> Wenquin, apologies for mis-spelling you name. I need a bigger font or new glasses ;-). What I forgot to say in comparison with Encore because it was so obvious is this: of course the really big ethical problem with Encore is that the users participate without knowing about it. With Atlas the host of course indicates consent by hosting the probe and agreeing to Atlas rules. So I sure hope that you inform the hosting institution about the probe. ;-). Daniel PS: Personally I have been consciously ignorant of rules quite frequently and relied on my moral compass. However we all know that there are places where the consequences of ignoring rules can be quite unpleasant these days. :-(. On 22.10.15 17:33 , Wenqin SHAO wrote: > Hello Daniel, > > Thank you very much for you quick response. > > I personally am not very much concerned. The possibility just came into my mind. > I plan to move my recently obtained probe into a Academic network in China, where the hosting institution there shall take the responsibility for all consequences, instead of putting it my parents? living room. > > One other issue with security policies is that sometime one wouldn?t learn these rules if one hadn?t violet them in first place. > > Regards, > Wenqin > > > >> On 22 Oct 2015, at 17:17, Daniel Karrenberg wrote: >> >> Wengin, >> >> Thank you for your good question. >> >> This is exactly why we allow HTTP measurements only to well defined >> targets. So far we assume that DNS queries are not harmful. Since we >> cannot know what is "risky" in all places there is little else we can >> do. Would you have more peace of mind if you could opt out of DNS the >> probe doing DNS queries related to measurements altogether? >> >> On the positive side: Should any host get in trouble we commit to go >> back to our logs/results and testify that the traffic was originated by >> our probe. >> >> Of course we cannot tell you what your local authorities will hold you >> responsible for. Would a ping to a certain address get you in trouble? >> So if you are *really* *really* concerned about this you should not host >> a probe. >> >> Daniel >> >> On 22.10.15 17:00 , Wenqin SHAO wrote: >>> Dear list, >>> >>> Talking about how public and non-public probe participates in built-in and user-defined measurement, a possible scenario has come to my mind (maybe it?s not really relevant to what you are discussing right now). Here goes the case: >>> >>> I host a probe and it is required to participate in a UDM involving sensitive destinations, say DNS measurement to ISIS?s site (could be interesting and useful in certain senses), which however might violet my local security policies. As a consequence, the big brother might knock at my door and invite me for a coffee?or something more serious. >>> >>> My question is, if that happens, am I really responsible for that and whether it is possible to avoid participating in certain risky measurements. >>> >>> Possibly I wrong too much. >>> >>> Best regards, >>> wenqin >>> >>>> On 22 Oct 2015, at 16:35, Daniel Quinn wrote: >>>> >>>> Hi James, >>>> >>>> I just wanted to clarify a few points about how the probes work in response to your comment. >>>> >>>> All RIPE Atlas probes, even those not marked ?public?, are available to be used in both built-in and user-defined measurements *as sources*. >>>> >>>> Many probes are not hosted on the open Internet, so they make for lousy targets. In most cases, they're hosted on internal networks, so they're often not ?targetable? at all. More importantly, hosting a probe does not make your network (which already exists on the open Internet) any more or less likely to be the target of a measurement. >>>> >>>> And in terms of outgoing traffic, the probe generates next to nothing (typically a few Kb/s, even when it?s being used for user-defined measurements). >>>> >>>> You can learn more about this from the FAQs: >>>> https://atlas.ripe.net/about/faq/ >>>> >>>> Please let us know if you have any other questions. >>>> >>>> Regards, >>>> >>>> Daniel Quinn >>>> >>> >>> >>> >> > > From marty at martystrong.co.uk Thu Oct 22 23:30:28 2015 From: marty at martystrong.co.uk (Marty Strong) Date: Thu, 22 Oct 2015 22:30:28 +0100 Subject: [atlas] Dead probes Message-ID: Hi, I've got 1 or 2 dead probes, they power on but I see no mac address from them. They have the first 2 lights on, but none of the others. I don't see this combination listed on https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean Has anybody else come across this issue? Anybody know what the light combination means? Marty -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Fri Oct 23 09:04:28 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 23 Oct 2015 09:04:28 +0200 Subject: [atlas] Anchors and NTP back to the future Message-ID: <20151023070428.GA25889@nic.fr> Some anchors appear to be reachable with NTP but most of them are not. I guess it means the anchor always has a NTP server (and I assume it is on purpose) but many networks filter it. What is the good recommanded practice? Specially in the light of the Back to the Future attack From BECHA at ripe.net Fri Oct 23 11:17:18 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 23 Oct 2015 11:17:18 +0200 Subject: [atlas] Asociatia Interlan (Bucharest, Romania) has joined RIPE Atlas Anchors In-Reply-To: References: Message-ID: <5629FB1E.3040505@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called ro-buh-as39107, hosted by Asociatia Interlan. This is a first anchor in Romania, and will provide useful country-wide and regional measurements results for the upcoming RIPE71 meeting. This is also a 150th anchor in total! Congratulations! In addition to the anchoring measurements (ping, ping6, traceroute and traceroute6), scheduled towards this anchor from all the other anchors as well as several hundred probes, there are now also HTTP measurements that can be accessed from here: https://atlas.ripe.net/probes/6154/#!tab-udms Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team atlas at ripe.net From bortzmeyer at nic.fr Fri Oct 23 11:34:50 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 23 Oct 2015 11:34:50 +0200 Subject: [atlas] Private Probes: What's the Point In-Reply-To: References: <56266D74.9040409@cc.univie.ac.at> <64D15CD4-89B8-42EF-8599-16A7EA509D3C@consultant.com> <5628F440.3000004@ripe.net> <56290036.7000503@ripe.net> Message-ID: <20151023093450.GA11152@nic.fr> On Thu, Oct 22, 2015 at 05:42:37PM +0200, Wenqin SHAO wrote a message of 33 lines which said: > I recall (I tried and failed to find the reference for the moment > being) that in France, some type of metadata might be as well > sensitive, say a URL, My talk at the France-IX General Assembly mentioned RIPE Atlas probes and their use in France to monitor DNS censorship. From bortzmeyer at nic.fr Fri Oct 23 11:41:50 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 23 Oct 2015 11:41:50 +0200 Subject: [atlas] Asociatia Interlan (Bucharest, Romania) has joined RIPE Atlas Anchors In-Reply-To: <5629FB1E.3040505@ripe.net> References: <5629FB1E.3040505@ripe.net> Message-ID: <20151023094150.GB11152@nic.fr> On Fri, Oct 23, 2015 at 11:17:18AM +0200, Vesna Manojlovic wrote a message of 32 lines which said: > The new anchor is called ro-buh-as39107, hosted by Asociatia > Interlan. Its DNS service seems broken: % dig @ro-buh-as39107.anchors.atlas.ripe.net ANY dns.ro-buh-as39107.anchors.atlas.ripe.net ; <<>> DiG 9.10.2-P2 <<>> @ro-buh-as39107.anchors.atlas.ripe.net ANY dns.ro-buh-as39107.anchors.atlas.ripe.net ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32089 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;dns.ro-buh-as39107.anchors.atlas.ripe.net. IN ANY ;; Query time: 49 msec ;; SERVER: 2a00:ff0:1234:3::2#53(2a00:ff0:1234:3::2) ;; WHEN: Fri Oct 23 11:41:10 CEST 2015 ;; MSG SIZE rcvd: 70 From philip.homburg at ripe.net Fri Oct 23 11:54:42 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 23 Oct 2015 11:54:42 +0200 Subject: [atlas] Dead probes In-Reply-To: References: Message-ID: <562A03E2.2020406@ripe.net> On 2015/10/22 23:30 , Marty Strong wrote: > I've got 1 or 2 dead probes, they power on but I see no mac address from > them. They have the first 2 lights on, but none of the others. > > I don't see this combination listed > on https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean > > Has anybody else come across this issue? Anybody know what the light > combination means? Hi, That a weird thing that is showing up recently. I have no clear idea what is causing it. Something is wrong with the filesystem on the USB stick that prevents the probe from booting properly. What normally cures it is to connect the probe to power and network without the USB stick, wait for about 10 minutes and then insert the USB stick. Philip From marty at martystrong.co.uk Fri Oct 23 12:29:18 2015 From: marty at martystrong.co.uk (Marty Strong) Date: Fri, 23 Oct 2015 11:29:18 +0100 Subject: [atlas] Dead probes In-Reply-To: <562A03E2.2020406@ripe.net> References: <562A03E2.2020406@ripe.net> Message-ID: It worked! Your probe #16587 upgraded its firmware from version 3.3.8 to version 4720 > October 23, 2015 10:20 Thanks! On 23 October 2015 at 10:54, Philip Homburg wrote: > On 2015/10/22 23:30 , Marty Strong wrote: > > I've got 1 or 2 dead probes, they power on but I see no mac address from > > them. They have the first 2 lights on, but none of the others. > > > > I don't see this combination listed > > on > https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean > > > > Has anybody else come across this issue? Anybody know what the light > > combination means? > > Hi, > > That a weird thing that is showing up recently. I have no clear idea > what is causing it. Something is wrong with the filesystem on the USB > stick that prevents the probe from booting properly. > > What normally cures it is to connect the probe to power and network > without the USB stick, wait for about 10 minutes and then insert the USB > stick. > > Philip > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gboonie at gmail.com Fri Oct 23 21:25:13 2015 From: gboonie at gmail.com (gboonie) Date: Fri, 23 Oct 2015 21:25:13 +0200 Subject: [atlas] traceroute - view latest results Message-ID: <562A8999.3040300@gmail.com> What should the blue 'i' do at the right side of a traceroute measurement? Hovering over it shows a 'view lastest results' message. For example in this measurement: https://atlas.ripe.net/measurements/2845726/#!probes I'm hoping it will soon display all the hops of a traceroute. Just like the traceroutes of the built-in measurements. Just like: Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: giiefehh.png Type: image/png Size: 3385 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: aagbfibc.png Type: image/png Size: 41760 bytes Desc: not available URL: From Jeroen at hltools.com Fri Oct 23 22:55:14 2015 From: Jeroen at hltools.com (Jeroen Bogers) Date: Fri, 23 Oct 2015 20:55:14 +0000 Subject: [atlas] Dead probes In-Reply-To: <562A03E2.2020406@ripe.net> References: <562A03E2.2020406@ripe.net> Message-ID: Hello, My probe had the same issue (see the message I sent about it earlier). The fix Philip mentions repaired the issue for me as well. The probe failed after I had to powercycle some of my network equipment (including the probe). What happened with your probes Marty before they failed? Maybe there is a common cause? With kind regards, Jeroen Bogers -----Original Message----- From: ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Philip Homburg Sent: Friday, October 23, 2015 11:55 To: ripe-atlas at ripe.net Subject: Re: [atlas] Dead probes On 2015/10/22 23:30 , Marty Strong wrote: > I've got 1 or 2 dead probes, they power on but I see no mac address > from them. They have the first 2 lights on, but none of the others. > > I don't see this combination listed > on > https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-th > e-probe-mean > > Has anybody else come across this issue? Anybody know what the light > combination means? Hi, That a weird thing that is showing up recently. I have no clear idea what is causing it. Something is wrong with the filesystem on the USB stick that prevents the probe from booting properly. What normally cures it is to connect the probe to power and network without the USB stick, wait for about 10 minutes and then insert the USB stick. Philip From sebastian at sneuner.org Sat Oct 24 19:26:37 2015 From: sebastian at sneuner.org (Sebastian Neuner) Date: Sat, 24 Oct 2015 19:26:37 +0200 Subject: [atlas] filter ping results by AS In-Reply-To: <5624EE82.40703@ripe.net> References: <5624AA57.2040604@sneuner.org> <5624C50F.1050401@ripe.net> <5624CEC2.30708@sneuner.org> <5624EE82.40703@ripe.net> Message-ID: <562BBF4D.1020308@sneuner.org> So, I figured that I don't have hundreds of TB of storage and dismissed the idea of fetching all the results :-) I got the probe- and measurement dumps and threw them in a database, but it would still be nice for me to fetch some results by source-AS. The participation-request-log API won't give me results filtered by probe_id: > {"detail": "You do not have permission to perform this action."} Are there any participation-request-log dumps, too? Or is there some other way to do this? Regards, Sebastian On 19.10.2015 15:22, Daniel Quinn wrote: > It?s not on our List of Things to Do, no. The difficulty is in the > massive amounts of data ? there?s simply no easy way to fetch arbitrary > results from such a large data store based on arbitrary lookup values. > > Currently we store data keyed by measurement id, probe id, and time, and > that covers most of the use-cases. > > You should know however that we do supply weekly dump files > of measurement meta data, > so you can use these to prepare your results queries without beating the > crap out of our API service :-) > > ? From marty at martystrong.co.uk Sat Oct 24 21:11:10 2015 From: marty at martystrong.co.uk (Marty Strong) Date: Sat, 24 Oct 2015 20:11:10 +0100 Subject: [atlas] Dead probes In-Reply-To: References: <562A03E2.2020406@ripe.net> Message-ID: <93B85F11-25A2-4DB4-8625-249C890BBDA5@martystrong.co.uk> As far as I know they were unplugged in order to move location. One of them certainly was, the other I'm not so sure of. Sent from my iPhone > On 23 Oct 2015, at 21:55, Jeroen Bogers wrote: > > Hello, > > My probe had the same issue (see the message I sent about it earlier). The fix Philip mentions repaired the issue for me as well. > The probe failed after I had to powercycle some of my network equipment (including the probe). What happened with your probes Marty before they failed? Maybe there is a common cause? > > With kind regards, > Jeroen Bogers > > -----Original Message----- > From: ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Philip Homburg > Sent: Friday, October 23, 2015 11:55 > To: ripe-atlas at ripe.net > Subject: Re: [atlas] Dead probes > >> On 2015/10/22 23:30 , Marty Strong wrote: >> I've got 1 or 2 dead probes, they power on but I see no mac address >> from them. They have the first 2 lights on, but none of the others. >> >> I don't see this combination listed >> on >> https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-th >> e-probe-mean >> >> Has anybody else come across this issue? Anybody know what the light >> combination means? > > Hi, > > That a weird thing that is showing up recently. I have no clear idea what is causing it. Something is wrong with the filesystem on the USB stick that prevents the probe from booting properly. > > What normally cures it is to connect the probe to power and network without the USB stick, wait for about 10 minutes and then insert the USB stick. > > Philip > From jeroen at dckd.nl Sat Oct 24 22:39:57 2015 From: jeroen at dckd.nl (Jeroen van der Ham) Date: Sat, 24 Oct 2015 22:39:57 +0200 Subject: [atlas] Private Probes: What's the Point In-Reply-To: <5629054B.7080902@ripe.net> References: <56266D74.9040409@cc.univie.ac.at> <64D15CD4-89B8-42EF-8599-16A7EA509D3C@consultant.com> <5628F440.3000004@ripe.net> <5628FDF5.7040502@ripe.net> <3351C43A-3CF0-4B24-90FA-A218E3133FAC@telecom-paristech.fr> <5629054B.7080902@ripe.net> Message-ID: <1AEED1D7-7A8A-495C-B4DD-42596FAA7AEB@dckd.nl> Hi, > On 22 Oct 2015, at 17:48, Daniel Karrenberg wrote: > > What I forgot to say in comparison with Encore because it was so obvious > is this: of course the really big ethical problem with Encore is that > the users participate without knowing about it. With Atlas the host of > course indicates consent by hosting the probe and agreeing to Atlas > rules. So I sure hope that you inform the hosting institution about the > probe. ;-). There?s much discussion on the Encore measurement and similar research efforts on measuring censorship. I missed this discussion here, but actually pointed to the Atlas infrastructure regarding sensible rules on bandwidth usage. I think there is not much issue for Atlas, as you say, Atlas is a voluntary effort. Besides that, most hosts of Atlas probes are probably knowledgeable on networking, and network measurements. These people should know what they are getting into. > PS: Personally I have been consciously ignorant of rules quite > frequently and relied on my moral compass. However we all know that > there are places where the consequences of ignoring rules can be quite > unpleasant these days. :-(. My impression is also that many many more people are getting into networking, network and Internet research. Many are from a new generation that did not experience the evolution of the Internet. Because of that, they may not have developed the same set of values that the older generation had. This means that these values now should be made explicit, which is a very hard thing to do? but I think it?s a very interesting process :) Jeroen. From dquinn at ripe.net Mon Oct 26 11:47:56 2015 From: dquinn at ripe.net (Daniel Quinn) Date: Mon, 26 Oct 2015 11:47:56 +0100 Subject: [atlas] filter ping results by AS In-Reply-To: <562BBF4D.1020308@sneuner.org> References: <5624AA57.2040604@sneuner.org> <5624C50F.1050401@ripe.net> <5624CEC2.30708@sneuner.org> <5624EE82.40703@ripe.net> <562BBF4D.1020308@sneuner.org> Message-ID: <562E04DC.80209@ripe.net> If I?m understanding your situation correctly, you want to see a list of measurements that include probes from a particular AS as their source. At present, there?s no easy way to make a single API call to get that, but you could synthesise that information by comparing two reasonably small bodies of data. There are two bulk data downloads that you can use for this: measurement metadata (already mentioned, updated weekly) and the probe data (daily). Basically, you need to do three things: * *Compile a list of probe ids that represent probes within the AS you want*. You can do this by looping over the probes in the daily dump and capturing the id for any probe that has |asn_v4| or |asn_v6| equal to the AS in question. * *Compile a list of measurements using these probes*. You can do this by looping over the list of measurements, capturing the ids of measurements that have the aforementioned probe ids in the |probes| list. * Fetch the probe-specific data from the API using both ids: |https://atlas.ripe.net/api/v1/measurement/**measurement_id**/result/?prb_id=**probe_id**,**probe_id**&format=txt | The above call will return all of the results for measurement |#${measurement_id}|, but only for probes with one of those two ids. That last bit, |format=txt| will ensure that the returning data is in bite-sized chunks so you don?t gobble up 30gb of memory just to parse what comes out. Write that in a loop /with a reasonable wait time between each request or we?ll get mad at you/ and you?ve got a decent body of data to work with. Note that there?s no reason to fetch the entire history of a measurement either. You can always pass |start=| to the above URL and it?ll only give you results returned since that date. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From astrikos at ripe.net Mon Oct 26 14:36:09 2015 From: astrikos at ripe.net (Andreas Strikos) Date: Mon, 26 Oct 2015 14:36:09 +0100 Subject: [atlas] traceroute - view latest results In-Reply-To: <562A8999.3040300@gmail.com> References: <562A8999.3040300@gmail.com> Message-ID: <562E2C49.9000604@ripe.net> Hi Dave, that was its function yet, but it seems something broke it with one of our last releases. It should be working now as before. Regards, Andreas On 23/10/15 21:25, gboonie wrote: > What should the blue 'i' do at the right side of a traceroute > measurement? Hovering over it shows a 'view lastest results' message. > > > > For example in this measurement: > https://atlas.ripe.net/measurements/2845726/#!probes > > I'm hoping it will soon display all the hops of a traceroute. Just > like the traceroutes of the built-in measurements. > > Just like: > > > Thanks, > Dave > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 3385 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 41760 bytes Desc: not available URL: From sebastian at sneuner.org Mon Oct 26 16:20:29 2015 From: sebastian at sneuner.org (Sebastian Neuner) Date: Mon, 26 Oct 2015 16:20:29 +0100 Subject: [atlas] filter ping results by AS In-Reply-To: <562E04DC.80209@ripe.net> References: <5624AA57.2040604@sneuner.org> <5624C50F.1050401@ripe.net> <5624CEC2.30708@sneuner.org> <5624EE82.40703@ripe.net> <562BBF4D.1020308@sneuner.org> <562E04DC.80209@ripe.net> Message-ID: <562E44BD.1050707@sneuner.org> On 26.10.2015 11:47, Daniel Quinn wrote: > Fetch the probe-specific data from the API using both ids: Oh, I didn't know that it is possible to filter results by probe ID (and/or time). You should add a "result" section to the API docs. That'll make it much easier/faster for me (and the Atlas API) ;-) Thanks! Regards, Sebastian From dquinn at ripe.net Mon Oct 26 16:42:21 2015 From: dquinn at ripe.net (Daniel Quinn) Date: Mon, 26 Oct 2015 16:42:21 +0100 Subject: [atlas] filter ping results by AS In-Reply-To: <562E44BD.1050707@sneuner.org> References: <5624AA57.2040604@sneuner.org> <5624C50F.1050401@ripe.net> <5624CEC2.30708@sneuner.org> <5624EE82.40703@ripe.net> <562BBF4D.1020308@sneuner.org> <562E04DC.80209@ripe.net> <562E44BD.1050707@sneuner.org> Message-ID: <562E49DD.1030406@ripe.net> Actually, all of this is detailed toward the bottom of the REST docs: https://atlas.ripe.net/docs/rest/ But it's not exactly clear. I'll add to our queue-of-things-to-do that we need to clean up the formatting and add a section header there. From gboonie at gmail.com Mon Oct 26 20:04:37 2015 From: gboonie at gmail.com (gboonie) Date: Mon, 26 Oct 2015 20:04:37 +0100 Subject: [atlas] traceroute - view latest results In-Reply-To: <562E2C49.9000604@ripe.net> References: <562A8999.3040300@gmail.com> <562E2C49.9000604@ripe.net> Message-ID: <562E7945.6050509@gmail.com> Hi Andreas, That does exactly what I hoped it would do. How can a user keep himself informed of these improvements? Is there another mailing lost? I saw that also the DNS response info has improved. Thanks for that too. Regards, Dave Op 26-10-2015 om 14:36 schreef Andreas Strikos: > Hi Dave, > > that was its function yet, but it seems something broke it with one of > our last releases. > It should be working now as before. > > Regards, > Andreas > On 23/10/15 21:25, gboonie wrote: >> What should the blue 'i' do at the right side of a traceroute >> measurement? Hovering over it shows a 'view lastest results' message. >> >> >> >> For example in this measurement: >> https://atlas.ripe.net/measurements/2845726/#!probes >> >> I'm hoping it will soon display all the hops of a traceroute. Just >> like the traceroutes of the built-in measurements. >> >> Just like: >> >> >> Thanks, >> Dave >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 3385 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 41760 bytes Desc: not available URL: From astrikos at ripe.net Tue Oct 27 12:33:19 2015 From: astrikos at ripe.net (Andreas Strikos) Date: Tue, 27 Oct 2015 12:33:19 +0100 Subject: [atlas] traceroute - view latest results In-Reply-To: <562E7945.6050509@gmail.com> References: <562A8999.3040300@gmail.com> <562E2C49.9000604@ripe.net> <562E7945.6050509@gmail.com> Message-ID: <562F60FF.10805@ripe.net> Hi Dave, we do have an announcements page with RSS feed [1], which we try to keep updated but it's not always very detailed. We follow a weekly release of new features/improvements/ fixes, so new staff come out every week. Regards, Andreas [1] https://atlas.ripe.net/about/announcements/ On 26/10/15 20:04, gboonie wrote: > Hi Andreas, > > That does exactly what I hoped it would do. > > How can a user keep himself informed of these improvements? Is there > another mailing lost? > > I saw that also the DNS response info has improved. Thanks for that too. > > Regards, > Dave > > > Op 26-10-2015 om 14:36 schreef Andreas Strikos: >> Hi Dave, >> >> that was its function yet, but it seems something broke it with one >> of our last releases. >> It should be working now as before. >> >> Regards, >> Andreas >> On 23/10/15 21:25, gboonie wrote: >>> What should the blue 'i' do at the right side of a traceroute >>> measurement? Hovering over it shows a 'view lastest results' message. >>> >>> >>> >>> For example in this measurement: >>> https://atlas.ripe.net/measurements/2845726/#!probes >>> >>> I'm hoping it will soon display all the hops of a traceroute. Just >>> like the traceroutes of the built-in measurements. >>> >>> Just like: >>> >>> >>> Thanks, >>> Dave >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 3385 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 41760 bytes Desc: not available URL: From v.bajpai at jacobs-university.de Tue Oct 27 13:22:42 2015 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Tue, 27 Oct 2015 12:22:42 +0000 Subject: [atlas] traceroute - view latest results In-Reply-To: <562F60FF.10805@ripe.net> References: <562A8999.3040300@gmail.com> <562E2C49.9000604@ripe.net> <562E7945.6050509@gmail.com> <562F60FF.10805@ripe.net> Message-ID: <4E075EAD-2AE9-4836-B55D-8A7906334225@jacobs-university.de> > On 27 Oct 2015, at 12:33, Andreas Strikos wrote: > > we do have an announcements page with RSS feed [1], which we try to keep updated but it's not always very detailed. > We follow a weekly release of new features/improvements/ fixes, so new staff come out every week. I personally would love feature / bugfix announcements on the list. Do we think it would be useful to relay them here as well? > Regards, > Andreas > > [1] https://atlas.ripe.net/about/announcements Best, Vaibhav ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com ===================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From colinj at mx5.org.uk Tue Oct 27 13:52:41 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Tue, 27 Oct 2015 12:52:41 +0000 Subject: [atlas] traceroute - view latest results In-Reply-To: <4E075EAD-2AE9-4836-B55D-8A7906334225@jacobs-university.de> References: <562A8999.3040300@gmail.com> <562E2C49.9000604@ripe.net> <562E7945.6050509@gmail.com> <562F60FF.10805@ripe.net> <4E075EAD-2AE9-4836-B55D-8A7906334225@jacobs-university.de> Message-ID: useful for announcement info to list as that is what I read Colin > On 27 Oct 2015, at 12:22, Bajpai, Vaibhav wrote: > > >> On 27 Oct 2015, at 12:33, Andreas Strikos wrote: >> >> we do have an announcements page with RSS feed [1], which we try to keep updated but it's not always very detailed. >> We follow a weekly release of new features/improvements/ fixes, so new staff come out every week. > > I personally would love feature / bugfix announcements on the list. > Do we think it would be useful to relay them here as well? > >> Regards, >> Andreas >> >> [1] https://atlas.ripe.net/about/announcements > > Best, Vaibhav > > ===================================================== > Vaibhav Bajpai > > Room 91, Research I > School of Engineering and Sciences > Jacobs University Bremen, Germany > > www.vaibhavbajpai.com > ===================================================== > From ismael at zattoo.com Tue Oct 27 15:17:52 2015 From: ismael at zattoo.com (Ismael Carmona) Date: Tue, 27 Oct 2015 15:17:52 +0100 Subject: [atlas] Probe not appearing in the Atlas Message-ID: Hello, We have the probe #24142, it gets DHCP fine (91.123.100.8) and we can ping it and see with sflow that it perform requests to external servers but we cannot find it online in the atlas. We already tried rebooting it. Any idea how we can make it appear online in the atlas page? Thank you, Ismael -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicsata at gmail.com Wed Oct 28 08:53:10 2015 From: magicsata at gmail.com (Alistair Mackenzie) Date: Wed, 28 Oct 2015 07:53:10 +0000 Subject: [atlas] Probe not appearing in the Atlas In-Reply-To: References: Message-ID: How long has it been online? Mine took around 36 hours to appear. On 28 Oct 2015 7:30 am, "Ismael Carmona" wrote: > Hello, > > We have the probe #24142, it gets DHCP fine (91.123.100.8) and we can > ping it and see with sflow that it perform requests to external servers but > we cannot find it online in the atlas. > > We already tried rebooting it. > > Any idea how we can make it appear online in the atlas page? > > Thank you, > Ismael > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vnaumov at ripe.net Wed Oct 28 09:31:35 2015 From: vnaumov at ripe.net (Viktor Naumov) Date: Wed, 28 Oct 2015 09:31:35 +0100 Subject: [atlas] Probe not appearing in the Atlas In-Reply-To: References: Message-ID: <563087E7.7060905@ripe.net> Hi, Looks like it has DNS problem. I do not see SOS messages from it, but I see it connects to our infrastructure but probably fails to resolve our controller. In addition it triggered a bug i just fixed that prevented it to register successfully. Only new or log time disconnected probes with DNS problems were affected. Cheers, /vty On 10/27/15 3:17 PM, Ismael Carmona wrote: > Hello, > > We have the probe #24142, it gets DHCP fine (91.123.100.8) and we can > ping it and see with sflow that it perform requests to external > servers but we cannot find it online in the atlas. > > We already tried rebooting it. > > Any idea how we can make it appear online in the atlas page? > > Thank you, > Ismael > From anandb at ripe.net Wed Oct 28 10:02:42 2015 From: anandb at ripe.net (Anand Buddhdev) Date: Wed, 28 Oct 2015 10:02:42 +0100 Subject: [atlas] Asociatia Interlan (Bucharest, Romania) has joined RIPE Atlas Anchors In-Reply-To: <20151023094150.GB11152@nic.fr> References: <5629FB1E.3040505@ripe.net> <20151023094150.GB11152@nic.fr> Message-ID: <56308F32.2090709@ripe.net> On 23/10/15 11:41, Stephane Bortzmeyer wrote: Hi St?phane, >> The new anchor is called ro-buh-as39107, hosted by Asociatia >> Interlan. > > Its DNS service seems broken: Thanks for noticing and informing us. There was an error in our configuration. We have fixed it. Regards, Anand Buddhdev RIPE NCC From mgalante at ripe.net Wed Oct 28 12:23:51 2015 From: mgalante at ripe.net (Michela Galante) Date: Wed, 28 Oct 2015 12:23:51 +0100 Subject: [atlas] Leaseweb Network (US, Manassas and San Francisco) have joined RIPE Atlas anchors Message-ID: <884A944D-82CC-4B4A-B3B2-1634659F5880@ripe.net> Dear RIPE Atlas users, We're happy to announce that two more RIPE Atlas anchors have joined the network and are now available as targets for probe hosts conducting their own user-defined measurements. The new anchors, both hosted by Leaseweb Network in United States, are: us-mnz-as30633, in Manassas (Virginia) us-sfo-as7203, in San Francisco (California) Congratulations to Leaseweb Network for their third and fourth anchor online! Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards these anchors from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From oliver.haake at eunetworks.com Wed Oct 28 16:44:59 2015 From: oliver.haake at eunetworks.com (Oliver Haake) Date: Wed, 28 Oct 2015 16:44:59 +0100 Subject: [atlas] Dead probes In-Reply-To: <562A03E2.2020406@ripe.net> References: <562A03E2.2020406@ripe.net> Message-ID: <5630ED7B.7020207@eunetworks.com> Hey, Thank you for that short HOWTO. I almost recovered two probes like that. One of the two probes got stuck with "USB-READONLY". But swapping the USB sticks did the trick then. Cheers, Oliver On 23.10.2015 11:54, Philip Homburg wrote: > On 2015/10/22 23:30 , Marty Strong wrote: >> I've got 1 or 2 dead probes, they power on but I see no mac address from >> them. They have the first 2 lights on, but none of the others. >> >> I don't see this combination listed >> on https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean >> >> Has anybody else come across this issue? Anybody know what the light >> combination means? > > Hi, > > That a weird thing that is showing up recently. I have no clear idea > what is causing it. Something is wrong with the filesystem on the USB > stick that prevents the probe from booting properly. > > What normally cures it is to connect the probe to power and network > without the USB stick, wait for about 10 minutes and then insert the USB > stick. > > Philip > -- Oliver Haake | Tier3 Network Engineer | euNetworks Theodor-Heuss-Allee 112 | 60486 Frankfurt/Main +49 69 905 542 49 office F?r weitere Informationen ?ber euNetworks oder f?r Informationen ?ber unsere Unternehmen, darunter euNetworks GmbH, besuchen Sie bitte unsere Webseite www.eunetworks.de. Diese E-Mail und oder Anh?nge k?nnen vertrauliche und/oder gesetzlich privilegierte Information enthalten. Wenn Sie nicht der beabsichtigte Empf?nger sind, l?schen Sie bitte die E-Mail, ohne sie zu lesen, und benachrichtigen Sie den Absender. euNetworks GmbH Gesch?ftsf?hrer: Joachim Piroth Sueleyman Karaman Myriam Buchheister Amtsgericht Frankfurt am Main HRB 88224 Steuernummer 04523251638 Umsatzsteuer ID: DE 201 739 716 From woeber at cc.univie.ac.at Wed Oct 28 17:30:49 2015 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Wed, 28 Oct 2015 17:30:49 +0100 Subject: [atlas] Dead probes - slightly OT In-Reply-To: <562A03E2.2020406@ripe.net> References: <562A03E2.2020406@ripe.net> Message-ID: <5630F839.1020506@cc.univie.ac.at> So, just out of curiosity... On 2015-10-23 11:54, Philip Homburg wrote: >[...] > What normally cures it is to connect the probe to power and network > without the USB stick, wait for about 10 minutes and then insert the USB > stick. This seems to imply that the probes can bootstrap (off the 'net?) without the USB stick present ? If this is the case, what is the USB stick used for? > Philip Wilfried From michael.auss at gmail.com Wed Oct 28 17:40:10 2015 From: michael.auss at gmail.com (=?UTF-8?B?TWljaGFlbCBBdcOf?=) Date: Wed, 28 Oct 2015 17:40:10 +0100 Subject: [atlas] Dead probes - slightly OT In-Reply-To: <5630F839.1020506@cc.univie.ac.at> References: <562A03E2.2020406@ripe.net> <5630F839.1020506@cc.univie.ac.at> Message-ID: I think it is for storage - my usb stick broke down, i replaced it with my own usb stick and it bootstrapped completely from baremetal... Michael 2015-10-28 17:30 GMT+01:00 Wilfried Woeber : > > So, just out of curiosity... > > On 2015-10-23 11:54, Philip Homburg wrote: > >[...] > > What normally cures it is to connect the probe to power and network > > without the USB stick, wait for about 10 minutes and then insert the USB > > stick. > > This seems to imply that the probes can bootstrap (off the 'net?) without > the USB stick present ? If this is the case, what is the USB stick used > for? > > > Philip > > Wilfried > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed Oct 28 17:50:59 2015 From: gert at space.net (Gert Doering) Date: Wed, 28 Oct 2015 17:50:59 +0100 Subject: [atlas] Dead probes - slightly OT In-Reply-To: <5630F839.1020506@cc.univie.ac.at> References: <562A03E2.2020406@ripe.net> <5630F839.1020506@cc.univie.ac.at> Message-ID: <20151028165059.GE70452@Space.Net> hi, On Wed, Oct 28, 2015 at 05:30:49PM +0100, Wilfried Woeber wrote: > This seems to imply that the probes can bootstrap (off the 'net?) without > the USB stick present ? If this is the case, what is the USB stick used for? As far as I understand from the "firmware upgraded"-messages, the internal flash has some sort of immutable emergency recovery firmware on it, which is good enough to pull an upgrade from the master, install to USB stick, and reboot into it. Or so. And, for measurement data :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From newsboonie at gmail.com Wed Oct 28 22:17:29 2015 From: newsboonie at gmail.com (newsboonie) Date: Wed, 28 Oct 2015 22:17:29 +0100 Subject: [atlas] 'new set wizzard' broken? Message-ID: <56313B69.3040600@gmail.com> Hi, It seems the 'new set wizzard' for selecting probes is not working anymore. It does show the map but the input box is missing. Is it just me or is it broken? Thanks, Dave From philip.homburg at ripe.net Thu Oct 29 09:24:46 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 29 Oct 2015 09:24:46 +0100 Subject: [atlas] Dead probes - slightly OT In-Reply-To: <20151028165059.GE70452@Space.Net> References: <562A03E2.2020406@ripe.net> <5630F839.1020506@cc.univie.ac.at> <20151028165059.GE70452@Space.Net> Message-ID: <5631D7CE.7070806@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015/10/28 17:50 , Gert Doering wrote: > On Wed, Oct 28, 2015 at 05:30:49PM +0100, Wilfried Woeber wrote: >> This seems to imply that the probes can bootstrap (off the 'net?) >> without the USB stick present ? If this is the case, what is the >> USB stick used for? > > As far as I understand from the "firmware upgraded"-messages, the > internal flash has some sort of immutable emergency recovery > firmware on it, which is good enough to pull an upgrade from the > master, install to USB stick, and reboot into it. Or so. > > And, for measurement data :-) Close enough :-) The tp-link comes with 4 MB flash. This not enough to store the measurement code let alone also storing measurement results as well. Worse, if a power failure happens at the wrong moment during an upgrade of the internal flash then the tp-link is bricked. So the architecture we came up with is that the tp-link boots from internal flash and then either sets it root directory to the USB flash stick and runs from that or if an 'empty' USB flash is detected, downloads firmware from a controller and writes it to the flash. This way, updating the code on the USB flash is completely safe. If something goes wrong it is just a matter of asking the probe host to perform the procedure to get the USB stick to be re-initialized. We can and have updated the firmware on the built-in flash. But that's quite rare and there is the risk that it may brick some probe. Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWMdfOAAoJEPr6076EDopy8QUP/0WF3Jls3Ilz7QYRs4gCegbI VI6yUsOlrLUTWpMsjmqhFML/1c3s+dUdkRnHg5jL4RvTLsUgDdW38O5VSoPEah6P HF9jIyUS2rIHz0H3G2pk3rCkjso+r9FI1W+BLYCvb0Fk2qBlkTFjVYIPHqFQITbz gJ+pz+H1PHpzTBpZtCcGOQvIeSXE3BV4sU8dTKSU+EcCOl5eSCSu9cAP+OgrHWiw iL+T7RLxIn2BcjAHKljgFh15vHaoH3FN7Egc1DoixozmVw242LpiCUqdc/FvORlp X75I32KJr8jb/0GSQF8NTzNbRVd6tMIQCGLgRQYXjWMg3Ig0D5QUSrZ5yHpg6XuW wBJGE1obw9P8wXwLUW8ZHu3tqmmx2OCKFluQwUzhKgH7TmxIfuQcA2zyCYGYaAIO oLDl49umrR3q4GRVZhTeC6SVpx6tK4U2kBeZjYgu/XOmYNj76sfJgekcXjMa6Hsn /x8u5mIQSJhiINa1ovm8QaxCOR2zX1BiphqlP8NGT/dtki6CGyvuKoHg1yrYqcnt aYXzt4xZS9kiwV/jS/cF7Y+SgaAwAovCit5UyukWeohhJw1ZYDai0WRGLHd5hqw0 bZnIPjawDPDbnWCVMfcBBMu/SxsQzEuqkm8cWHkEwfkGRmViAcpw0x7HwjsTpfXA WuptOiuF3CHaFRKn+IKf =DUtO -----END PGP SIGNATURE----- From mcandela at ripe.net Thu Oct 29 09:49:03 2015 From: mcandela at ripe.net (Massimo Candela) Date: Thu, 29 Oct 2015 09:49:03 +0100 Subject: [atlas] 'new set wizzard' broken? In-Reply-To: <56313B69.3040600@gmail.com> References: <56313B69.3040600@gmail.com> Message-ID: Hi Dave, Yes, I see the error too. I will fix it asap. Thanks for the email! Ciao, Massimo On 28 Oct 2015, at 22:17, newsboonie wrote: > Hi, > > It seems the 'new set wizzard' for selecting probes is not working anymore. It does show the map but the input box is missing. > > Is it just me or is it broken? > > Thanks, > Dave > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From mcandela at ripe.net Thu Oct 29 11:38:30 2015 From: mcandela at ripe.net (Massimo Candela) Date: Thu, 29 Oct 2015 11:38:30 +0100 Subject: [atlas] 'new set wizzard' broken? In-Reply-To: References: <56313B69.3040600@gmail.com> Message-ID: <67ECFEE4-324E-4A5A-AA9F-FCF922DD7BE9@ripe.net> Fixed! Ciao, Massimo On 29 Oct 2015, at 09:49, Massimo Candela wrote: > Hi Dave, > Yes, I see the error too. I will fix it asap. > > Thanks for the email! > > Ciao, > Massimo > > On 28 Oct 2015, at 22:17, newsboonie wrote: > >> Hi, >> >> It seems the 'new set wizzard' for selecting probes is not working anymore. It does show the map but the input box is missing. >> >> Is it just me or is it broken? >> >> Thanks, >> Dave >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From woeber at cc.univie.ac.at Thu Oct 29 13:43:49 2015 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Thu, 29 Oct 2015 13:43:49 +0100 Subject: [atlas] Dead probes - slightly OT In-Reply-To: <5631D7CE.7070806@ripe.net> References: <562A03E2.2020406@ripe.net> <5630F839.1020506@cc.univie.ac.at> <20151028165059.GE70452@Space.Net> <5631D7CE.7070806@ripe.net> Message-ID: <56321485.7000708@cc.univie.ac.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philip, thanks for the explanation! Wilfried -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWMhRuAAoJEPMGt0I/M2zSRSQP/AzOPEcdiLN3FAXgKi0MyuSC ASKChSMRIW3Wg1BCxdJP3mDSGAIXOxraaSOsYf5D+LozJEgm9Kj9dfqDvEZVwpmq w/F/AaGgiTcvPVIaJ+M5czRIew40DoddNjxnGVCvFkg1YFo4tbJqInca72WvPnXi wnJhbmeHoWwGOAjGWSNu5yi/NahluPJ7G7HO7m40jYt9qvJiAYWYqGB418aSFY6G fUZbvgQ3TQZaXtXK7Ykw0IqTGKIQTSid2Jqpq9xBlqTDrOae/xidN41G2jDEuLKy PIZhnUIxmy02hfbhjAWDbSs+/3I9CiRChrsdmISzXSsOuwBz6mRIzg0/dmVd60ry xJdkYT1pgDVCAAtmrBoTyuPjOpzSoTSM+BXuzaf+ZgOintnlCvqyAzLUX8Ln0j1s F/49+RbNrHDKvysVRm94kqLXxeGROBJ7+wYCpfkCzLyKcmlLfS8/UAFU1AzcPceb /WUqPuK7CSiSye0MGFSUmQGhxucRm18teuZdNq/0u44l5W3M2c34xmUkc4KXcr1E uMmtnzaVMxX0jMWnD+JPZ7M9J692gvr198I0WhYPK22FpRJ1vgimpSgDRkP8yXoP aSFQGFT4qedokrzex5Ctb+Vpeq6Q9VxCxIDxCjMEnIGyZo3sMTimducVOLpGMsnP dfcjtAus5F8FNZEHBXY6 =Q4lG -----END PGP SIGNATURE----- From mgalante at ripe.net Thu Oct 29 15:40:27 2015 From: mgalante at ripe.net (Michela Galante) Date: Thu, 29 Oct 2015 15:40:27 +0100 Subject: [atlas] Next week: webinar on "Advanced RIPE Atlas Usage" Message-ID: <932EF53E-F069-410E-9CEA-E69CA265DBA9@ripe.net> Dear colleagues, On Thursday 5 November, 1:30 PM Amsterdam time we are hosting, for the 4th time, webinar on "Advanced RIPE Atlas Usage", aiming to teach network operators how to use RIPE Atlas measurements for network monitoring and troubleshooting. Register now at: https://lirportal.ripe.net/training/register/courseCode/WEB20150046 Web-registration is *only* possible for LIRs (RIPE NCC members). Non-members of RIPE NCC (people who do not have "Reg-ID") can email training at ripe.net and be manually registered. More details below. -------------------------- https://www.ripe.net/support/training/learn-online/webinars/advanced-ripe-atlas-usage-webinar This is part of the series of interactive on-line learning sessions, that give you the opportunity to learn and interact with trainers without leaving your desk, as well as for hands-on practice, and to get your questions answered by developers. Learn how to: - Use RIPE Atlas measurements for network monitoring and troubleshooting - Use API calls for measurement creation - Integrate RIPE Atlas with existing monitoring systems Webinars start at 12:30 UTC, and take about one hour. ----------------------------- We look forward to seeing you online. Kind regards, Michela Galante and Vesna Manojlovic RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From v.bajpai at jacobs-university.de Thu Oct 29 16:12:34 2015 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Thu, 29 Oct 2015 15:12:34 +0000 Subject: [atlas] ntp built-in measurements? Message-ID: <2E2315C0-0376-4CC0-9D8C-47FBA5D4F2E6@jacobs-university.de> Dear RIPE Atlas, Do the probes not run (new) NTP measurements as built-in measurements? ? I was glancing over the measurement data pushed by my probe, but I do not see any NTP measurement data. Although, when I try to provision a UDM, I do get an option to schedule an NTP measurement. Thanks! Best, Vaibhav ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com ===================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From oliver.haake at eunetworks.com Thu Oct 29 16:56:19 2015 From: oliver.haake at eunetworks.com (Oliver Haake) Date: Thu, 29 Oct 2015 16:56:19 +0100 Subject: [atlas] Sharing credits with colleagues Message-ID: <563241A3.3080202@eunetworks.com> Hey there, I'm very curious if you guys have an ETA for the "Sharing credits with colleagues" feature. Any ideas? Cheers, Oliver From philip.homburg at ripe.net Thu Oct 29 17:06:43 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 29 Oct 2015 17:06:43 +0100 Subject: [atlas] ntp built-in measurements? In-Reply-To: <2E2315C0-0376-4CC0-9D8C-47FBA5D4F2E6@jacobs-university.de> References: <2E2315C0-0376-4CC0-9D8C-47FBA5D4F2E6@jacobs-university.de> Message-ID: <56324413.8000107@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015/10/29 16:12 , Bajpai, Vaibhav wrote: > Do the probes not run (new) NTP measurements as built-in > measurements? ? I was glancing over the measurement data pushed by > my probe, but I do not see any NTP measurement data. Although, when > I try to provision a UDM, I do get an option to schedule an NTP > measurement. Hi, I'm running a few NTP measurements on all probes (frequency 900). So it would be weird if you probe doesn't have them. What target where you trying? Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWMkQTAAoJEPr6076EDopypbEP/03+jG0Z0fTlyBD+nhE35gBR 4RVp3lmQdPDYtlT0xLIM5sWBgaK37Twwqlpid70/aaKLMVKaHL3M2f/zeL7Spfcd ndhCpdFY3PI86GEEIQ3XmOFJKj/BQQ9Hg6/+pFzK93MeODOU3oC+pC1Bt64pQXOk TKa72MxG+drw8EyD8yH7N+J+xYzwPlBiDj7rlwaNHueN7DGlZCX+3KeQcrJhEz2d UVMyjZspSEruQjAxHvMyf4TwzV/z98q1atbfO2leCHda8udp+Nn+cAwDI/BdISyZ BAItfcCKZLpivMOvaFYsTx0vbwxCiSm4F7lEgZ+YRYvqylgsTa6B3DFzHdPezlnN k14YDqM0c+SmWUvZmZSuUnAboV5Q6FEXjNPNDXYtMLf6T9SzSnHIPYnVJUteKr+j 7BmToSCL8vgwPG8A7YfS4PB7LzSl9QjAUIY+hPddMoQak+ELUkMhAA59LfKB6Zzx MlcIpka/ZKLiy0x4+0287zn170qVA7hc9st+T/NER+SUqd9RHCOJAs8kFaIQ/h26 3B3HZkkI+nZwMfKZxS3CXmj9TXkGIZyVw7CCu0ooOTY9bD1+uOudCKNTdg2VjaNb RqKdeYb0YMhgSf3ShWU2WsItTYMgC9CRuIknMb+ygHiZTsYLCYZlaCc+DaMvHPW8 RsKcsmbaaQAkuh7wszMQ =5C+K -----END PGP SIGNATURE----- From michabailey at gmail.com Fri Oct 30 12:22:14 2015 From: michabailey at gmail.com (Micha Bailey) Date: Fri, 30 Oct 2015 13:22:14 +0200 Subject: [atlas] Question about the hardware Message-ID: I just got my Probe, and I was wondering what the thought/planning process was when they were designed. Why use a $40 wireless router/access point? I would have thought that cheaper options would be available that provide the requirements (processor and a network port). -------------- next part -------------- An HTML attachment was scrubbed... URL: From rm at romanrm.net Fri Oct 30 12:47:36 2015 From: rm at romanrm.net (Roman Mamedov) Date: Fri, 30 Oct 2015 16:47:36 +0500 Subject: [atlas] Question about the hardware In-Reply-To: References: Message-ID: <20151030164736.73e834bc@natsu> On Fri, 30 Oct 2015 13:22:14 +0200 Micha Bailey wrote: > I just got my Probe, and I was wondering what the thought/planning process > was when they were designed. Why use a $40 wireless router/access point? I > would have thought that cheaper options would be available that provide the > requirements (processor and a network port). I don't have a new style probe, but don't they use a device like this? http://embeddedtimes.blogspot.de/2011/09/tp-link-tl-wr703n-tiny-linux-capable.html It was $23 even back in 2011, and today can be found for around $20 including shipping. http://www.aliexpress.com/item/New-TP-Link-TL-WR703N-Ultra-Mini-Portable-3G-802-11b-150Mbps-WiFi-Wireless-Router-TL/32339229235.html Should be even cheaper if you order in bulk, as the probe designers likely did. -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From robert at ripe.net Fri Oct 30 14:15:54 2015 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 30 Oct 2015 22:15:54 +0900 Subject: [atlas] Question about the hardware In-Reply-To: <20151030164736.73e834bc@natsu> References: <20151030164736.73e834bc@natsu> Message-ID: <56336D8A.3060506@ripe.net> On 2015-10-30 20:47, Roman Mamedov wrote: > On Fri, 30 Oct 2015 13:22:14 +0200 > Micha Bailey wrote: > >> I just got my Probe, and I was wondering what the thought/planning process >> was when they were designed. Why use a $40 wireless router/access point? I >> would have thought that cheaper options would be available that provide the >> requirements (processor and a network port). > > I don't have a new style probe, but don't they use a device like this? > http://embeddedtimes.blogspot.de/2011/09/tp-link-tl-wr703n-tiny-linux-capable.html > It was $23 even back in 2011, and today can be found for around $20 including > shipping. > http://www.aliexpress.com/item/New-TP-Link-TL-WR703N-Ultra-Mini-Portable-3G-802-11b-150Mbps-WiFi-Wireless-Router-TL/32339229235.html > Should be even cheaper if you order in bulk, as the probe designers likely did. The 702/703 don't have enough local storage for our case and don't have USB ports either -- otherwise I think they are basically the same as the MR3020 which we use as v3 probe. Cheers, Robert From rm at romanrm.net Fri Oct 30 15:49:35 2015 From: rm at romanrm.net (Roman Mamedov) Date: Fri, 30 Oct 2015 19:49:35 +0500 Subject: [atlas] Question about the hardware In-Reply-To: <56336D8A.3060506@ripe.net> References: <20151030164736.73e834bc@natsu> <56336D8A.3060506@ripe.net> Message-ID: <20151030194935.19921b05@natsu> On Fri, 30 Oct 2015 22:15:54 +0900 Robert Kisteleki wrote: > The 702/703 don't have enough local storage for our case and don't have USB > ports either -- otherwise I think they are basically the same as the MR3020 > which we use as v3 probe. The 703N does have the same 4MB storage as MR3020, and it does have one USB port. Aside from having just one LED instead of three, and no fancy 3-position switch, the 703N seems pretty much identical to MR3020. But it was only officially released in the Chinese market. http://wiki.openwrt.org/toh/tp-link/tl-mr3020 http://wiki.openwrt.org/toh/tp-link/tl-wr703n -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: