- ripe-atlas - mailman.ripe.net

Actual measurement interval much larger than planned
by Wenqin SHAO 20 Oct '16

20 Oct '16

Dear list, I encountered some cases where the actual time interval between two neighbouring measurements being much larger than the scheduled value. Have you witnessed similar cases? I appreciate explanations on underlying reasons. Here goes an example: from ripe.atlas.cousteau import AtlasResultsRequest filters = dict(msm_id=1010, probe_ids=[16981], start=1470055258, stop=1470056217) is_success, results = AtlasResultsRequest(**filters).create() if is_success: for mes in results: print mes.get('timestamp', -1) The above code requests some built-in ping measurements (240s interval) made by probe 16981 and prints their timestamps. See below for the execution result: 1470055259 1470055499 1470055978 1470056216 Four measurements are retrieved within the given time range. I noticed that time interval between the 2nd and the 3rd measurement is 479s much larger than the planned value 240s. How come? Many thanks for your attention. Best regards, wenqin

4 9

Re: [atlas] ripe-atlas Digest, Vol 62, Issue 14
by Andre Heinrichs 19 Oct '16

19 Oct '16

On Wed, Oct 19, 2016 at 12:00 PM, <ripe-atlas-request(a)ripe.net> wrote: > Date: Tue, 18 Oct 2016 12:24:25 +0200 > From: Philip Homburg <philip.homburg(a)ripe.net> > To: ripe-atlas(a)ripe.net > Subject: Re: [atlas] probe offline - troubleshooting requested > Message-ID: <3af3a709-9198-06d7-19a1-ae367d03a58e(a)ripe.net> > Content-Type: text/plain; charset=utf-8 > > On 2016/10/18 7:46 , Andre Heinrichs wrote: >> Any ideas what I could try to get the probe reconnected? >> >> Just to be complete: Here are the last lines of the SOS history: >> 62.109.121.35 2016-10-18 05:43:27 A 3h 59m >> 62.109.121.35 2016-10-18 05:43:27 AAAA 3h 59m > > The best thing to try is to reflash the USB stick (i.e. connect the > probe without USB stick, wait for a out 10 minutes and insert the USB > stick). > > Unfortunately, corruption of the filesystem on the USB stick can result > in weird behavior, like your probe is showing. SOS works fine but it > doesn't connect. Just for the record: the probe works again after I did the USB fix Philip described. I'm guessing the status tab only showed the hint about Firewall trouble because that would have been another possible cause for the symptoms. Thanks, Andre

2 1

New on RIPE Labs: Orange Blacklisting: A Case for Measuring Censorship
by Mirjam Kuehne 19 Oct '16

19 Oct '16

Dear colleagues, Please find a short a article on measuring censorship on RIPE Labs: https://labs.ripe.net/Members/stephane_bortzmeyer/orange-blacklisting-a-cas… Kind regards, Mirjam Kuehne RIPE NCC

1 0

probe offline - troubleshooting requested
by Andre Heinrichs 18 Oct '16

18 Oct '16

Last night my probe (#29384) was declared offline after the daily Internet disconnection my FritzBox executes to keep the provider from disconnecting me after 24 hours online. According to the SOS history the probe gets DNS requests out but somehow fails to connect completely. I tried rebooting every network component i could locally get my hands on but that didn't seem to help much. The LEDs on the probe don't actually fit any of the descriptions from the FAQ: They are On, Off, fast(er) blink (at least if compared to shortly after booting (Network Test?), On, On. I'm guessing it means the network somehow managed to fail. Although I don't notice anything missing from what I did on the network this morning. Any ideas what I could try to get the probe reconnected? Just to be complete: Here are the last lines of the SOS history: 62.109.121.35 2016-10-18 05:43:27 A 3h 59m 62.109.121.35 2016-10-18 05:43:27 AAAA 3h 59m TIA, Andre, currently not in reach of the probe

2 1

Shall we continue non-public measurements in RIPE Atlas?
by Mirjam Kuehne 18 Oct '16

18 Oct '16

Dear colleagues, "Non-public measurements" is a feature of RIPE Atlas that allows users to use the infrastructure to measure things while not sharing those results with the public. Is that still a useful feature? Should it exist in the future? For more details, see this new post on RIPE Labs: https://labs.ripe.net/Members/kistel/non-public-measurements-in-ripe-atlas Please also take the polls at the end of the article. Kind regards, Mirjam Kuehne RIPE NCC

1 0

Temporary Reduction of Available History on RIPE Atlas and RIPEstat
by Romeo Zwart 18 Oct '16

18 Oct '16

Dear colleagues, Today, Tuesday, 18 October 2016, between 09:00 and 10:00 UTC, the back-end storage cluster for RIPE Atlas and RIPEstat will be switched to a backup environment. This is part of planned maintenance work. The backup facility has a more limited amount of storage space, which means that RIPEstat and RIPE Atlas, including specific applications like DNSMON and DomainMon, will not serve data older than one year. We expect this to have no impact on ongoing RIPE Atlas measurements, scheduling new measurements, or the retrieval of more recent data from RIPE Atlas, RIPEstat or DNSMON. We apologise for any inconvenience. Kind regards, Romeo Zwart

1 0

Problems with f.root-servers.net in Russia?
by Marat Khalili 18 Oct '16

18 Oct '16

Sorry for slight offtopic, but does anybody know what is up with Russian instance of F root server? I observe periods of very high packet loss since 11th of October. I used to measure my own internet connectivity pinging it, but seems like by internet works better than that of the root server. Here's a measurement with 50 Russian probes, 34 of them show "Unreachable" right now: https://atlas.ripe.net/measurements/6886549/#!probes -- -- With Best Regards, Marat Khalili

2 1

Out of date system probe tags
by Chris Amin 17 Oct '16

17 Oct '16

Dear all, Some of you have noticed that certain system tags (see below) remained applied to probes when they should have been removed. This is because the process that adds and removes these tags was temporarily disabled following the service issues that we experienced earlier in the month. This process has now been re-enabled after verifying that it was not a cause of the service downtime, and these tags have been applied correctly. The affected tags were: * Flaky connection * Firewall problem suspected * DNS problem suspected * No flash drive * Readonly flash drive * Hardware problem suspected Kind regards, Chris Amin RIPE NCC

1 0

Connect/disconnect timestamps on probe page disappeared
by Marat Khalili 13 Oct '16

13 Oct '16

Connect/disconnect timestamps on a probe page like https://atlas.ripe.net/probes/26656/#!tab-network disappeared this morning; durations still shown. Probably some problem with server side scripts? -- -- With Best Regards, Marat Khalili

2 1

firmware download test?
by Yang Yu 12 Oct '16

12 Oct '16

Hi, I have 2 probes that are connected but shown as offline even after several power cycles. I performed USB stick troubleshooting procedures by removing the USB stick and saw NO-USB SOS message. But after inserting the USB stick there wasn't any new SOS messages. Plugged the USB stick to computer and saw corrupted file system. Formatted the stick and inserted it back, still no SOS messages. What kind of filesystem layout is expected on the stick? From what I read the probe should automatically partition/format the stick. Maybe the stick is bad. I do see a good amount of packet loss between the probe's network and the registration server. How robust is the firmware download process (e.g does it abort on TCP RST)? Is there any way to manually load the firmware? Thanks. Yang

3 4

New on RIPE Labs: What Can You Do with One Million RIPE Atlas Credits?
by Mirjam Kuehne 12 Oct '16

12 Oct '16

Dear colleagues, Ever wondered what to do with all those RIPE Atlas credits you earned? Find out on RIPE Labs how you can best spend your credits to check your services' connectivity and troubleshoot potential issues. https://labs.ripe.net/Members/becha/what-can-you-do-with-one-million-ripe-a… Kind regards, Mirjam Kuehne RIPE NCC

1 0

Re: [atlas] ripe atlas probe v1 cat sylvester (Colin BT)
by Colin Johnston 10 Oct '16

10 Oct '16

smaller pic now to so hopefully auto approved :) Managed to raise over 2500 pounds for Byte Night NW (Action for Children) https://www.facebook.com/ByteNight <https://www.facebook.com/ByteNight> contact myself if want to donate Here is Sylvester on Bus to event, sleeping out and on Bus back home. yours Colin Johnston

1 0

Service downtime
by Robert Kisteleki 06 Oct '16

06 Oct '16

Hello, We seem to experience a database backend problem, rendering the whole service unavailable. We're busy fixing it and investigating the cause. Ill report on progress as soon as I have more information. Regards, Robert

1 1

ripe.atlas.net issues
by Max Mühlbronner 06 Oct '16

06 Oct '16

"Oops - this page experienced an error while loading." My atlas / My probe does not work, the checks are failing. (Since ~12 minutes) Please don't tell me that it's maintenance work again, without any announcement? ;) Max M.

5 7

SSL error on OpenIPMap
by Anurag Bhatia 04 Oct '16

04 Oct '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello everyone. Is it just me or anyone else getting SSL error on OpenIPMap? I can see that SSL cert of atlas.ripe.net is valid but when we open OpenIP Map, it calls one specific map image from fastly on HTTP resulting in "mixed content" making Chrome to throw SSL error. This is the URL of that image:http://stamen-tiles-c.a.ssl.fastly.net/toner-lite/3/5/5.png It does seems to be available on https already and so probably someone at RIPE need to update URL to call https in URL and avoid the false positive it's giving. Thanks. - -- Anurag Bhatiaanuragbhatia.com -----BEGIN PGP SIGNATURE----- Version: Mailvelope v1.5.2 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJX7qbdCRDAbdUkJF5Y4gAAP7oP/R+c7QMQEIt7c0/fLnKx IrvoSxS0RlivGHQBcQY4DcQvXNU0SsBdjUTG3hOJP/OyCERG9Uar8xRFXKAB LHrUGPa9rGdxHtJFJYL0fgKc0o0aELBkaot3unJPBRwGtp5Acyfx3Yv9CUF+ fqxq27tRnRtXklqVfYw5aWC20CC4EHEme3vv0+QsdasJ0s1mi1zehI1c60yI RQqZ35MaB9flyMyxU1L2CaKHh0BnZs0ssSxGsr/s2cfqhfu5KPzagi/obsEs 6mhwtkTPD1Y/649QAzs2E3vpZ83tn8fkExU54hHznpBy4QmNIAx7pnlwtOrX 8ou7Rn1Yt7V5NiSHGkr31sPJfMfHXErZ6NAl/Z7uPcs9+ofAkAEBh5H7pINr BFwZzX6DsqNiq1Q+F9sU385D5144Y4YE/vDIDXYXhSgbHv9NeqIph7Ceitt9 Ap4wx7eOh/8ONLddUdqf4/M0m9ORsFc4fRAhFkLCzLdUlXpDqAGGgxSFIcg4 NiInbdyZCO1Ula7TQCPR0qtTDJQ75w93wj5STM2uZjlVd5K6QUB4bmz8S/QX oEMLOSmjcWybQH+dBSJ25VVynCu7sRkSUyhyE2wwrb2adDw8pS0QMG5cyjhZ DX+XP9KGoFi6xYFCQypXO+bkSsh84OBKrxo+fFfznFTYFkDZ6yae/ZKSfC/o urP4 =coGp -----END PGP SIGNATURE-----

2 2

Inconsistent system tags
by Johannes Matheis 30 Sep '16

30 Sep '16

Hello, I got IPv6 connectivity for my probe 4365 a few days ago (2016-09-26) when I first noticed the system tag "IPv6 Doesn't Work". As the system tags aren't updated more often than every four hours I started some successful IPv6 measurements on that probe and settled back for four days. Now the probe is still flagged as IPv6 not working. In the meantime I noticed the tag "v2" but the general information tab tells me the system architecture is probev1… Actually I don't know if it's a v1 or v2, but it's still an old Lantronix one, so it's not completely wrong :-) Is there a possibility to re-trigger the assignment of the system tags for this probe or some other solution? Thanks! jomat

2 1

Initiating a TCP, UDP, and ICMP traceroutes from the same probe at the same time
by Zakaria Al-Qudah 30 Sep '16

30 Sep '16

Hi Folks, I am planning an experiment where I need each probe to perform TCP, UDP, and ICMP traceroutes at the same time. I could not see how I can do it using the Ripe Atlas website. Is there any way to do it? Best regards, Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

3 2

Making public probes’ IP addresses public in web interface
by Andreas Strikos 30 Sep '16

30 Sep '16

Hello, We made a change a few weeks ago to the RIPE Atlas web interface to align it more closely with the API. As a result, you can now see the IP addresses for public probes, regardless of whether you are a logged in user or not. This information is displayed on the public probes’ detailed information pages, under the “Network” tab. Previously, public probes' IP addresses were not shown, even for logged in users. Nothing has changed in the API or the web interface for probes that are not shared publicly. We understand that some of you were surprised by this change and we apologise for not communicating it earlier. However, I want to make it clear that the IP addresses of public probes have always been available via the API, whether you are a logged in user or not. We decided to include it via the web interface so that our users could access the same information regardless of which interface they decide to use. RIPE Atlas is meant to be a public platform that openly provides data to everyone interested. In this spirit, we encourage everyone to make their probes public. However, if you decide that you *don’t* want to share your probe publicly, you can change this setting by going to your probe’s detailed information page (go to "My Atlas" and click on your probe’s ID), clicking on the “Edit” button under the “General Information” tab, and deselecting the “Shared Publicly” box. Please note that personal information such as MAC addresses and email addresses will never be shown, regardless of whether you decide to share your probe publicly or not. You can learn more about what information is made public in RIPE Atlas in this RIPE Labs article: https://labs.ripe.net/Members/becha/proposing-making-ripe-atlas-data-more-p… Please let us know if you have any questions or concerns. Regards, Andreas Strikos RIPE NCC

1 0

Fifteen new RIPE Atlas anchors - including the first IPv4-only anchor
by Michela Galante 19 Sep '16

19 Sep '16

Dear colleagues, Fifteen new RIPE Atlas anchors have been activated since our last announcement in June, bringing the total number to 216: - us-abn-as54054, hosted by Deteque LLC in Ashburn, United States - us-sgu-as46309, hosted by Gartner Inc in Saint George, United States - lu-kay-as35733, hosted by EURid VZW in Kayl, Luxembourg - de-ham-as35258, hosted by akquinet Outsourcing in Hamburg, Germany - ua-iev-as24725, hosted by Hostmaster LLC in Kiev, Ukraine - ca-wnp-as18451, hosted by les.net in Winnipeg, Canada - de-dus-as12676, hosted by HKN GmbH in Düsseldorf, Germany - uk-lon-as34587, hosted by bet365 in London, United Kingdom - us-lax-as15133, hosted by Verizon Digital Media in Los Angeles, United States - us-lwc-as2495, hosted by KanREN Inc in Lawrence, United States - lb-bey-as12812, hosted by the American University of Beirut in Beirut, Lebanon (IPv4-only anchor) - pg-pom-as17828, hosted by Telikom PNG (sponsored by APNIC) in Port Moresby, Papua New Guinea - ch-zrh-as9092, hosted by Open Systems in Zurich, Switzerland - nl-ams-as34106, hosted by TMG/Telegraaf in Amsterdam, Netherlands - dk-hje-as39642, hosted by WNB ApS in Højer, Denmark You can find the full list of anchors, a map of their locations, a list of the hosting organisations and more information about RIPE Atlas anchors online: https://atlas.ripe.net/anchors/list/ As a follow-up to some discussion on this list, we wanted to reiterate that we made the decision to support IPv4-only anchors because the goal of RIPE Atlas is to measure as much of the Internet as possible, and right now, that includes IPv4-only networks. We also believe that measuring networks before and after they enable IPv6 provides useful data. IPv4-only anchors are clearly marked as such, and we will implement checks to ensure these anchors become IPv6-capable as soon as their ASNs begin announcing IPv6. In the meantime, the RIPE NCC will continue to actively promote IPv6 deployment through our training courses, IPv6 Act Now website, IPv6 Roadshows and other programs, and our IPv6 Program Manager will follow up with any hosts requesting an IPv4-only anchor to help them in any way possible. We believe that supporting IPv4-only anchors will provide a more comprehensive understanding of the Internet and that the entire Internet community will benefit from more measurement data. You can learn more in this RIPE Labs article: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ipv4-only-ripe-atlas-an… Interested in hosting a RIPE Atlas anchor? Learn more: https://atlas.ripe.net/get-involved/become-an-anchor-host/ We are particularly interested in deploying anchors in the Middle East, Western Asia, Latin America and Africa in order to add more geographical diversity to the measurement data. There are several organisations that want to host a RIPE Atlas anchor but don’t have the necessary funding. To learn more about sponsoring an anchor, or for any other questions, please contact us at atlas(a)ripe.net And don’t forget to let us know if you’re doing something interesting with RIPE Atlas data - we always want to hear about your use cases, research and experiences! Regards, Michela Galante RIPE NCC

1 0

"Invalid target" error for RFC 1918 space
by Yang Yu 18 Sep '16

18 Sep '16

Hi, I got "Invalid target" error when I tried to create a measurement to see how far some RFC 1918 prefixes got propagated (carrier not properly filtering customer announcement). What is considered invalid for each measurement type? Thanks. Yang

4 4

New on RIPE Labs: Using RIPE Atlas to Monitor Game Service Connectivity
by Mirjam Kuehne 14 Sep '16

14 Sep '16

Dear colleagues, Annika Wickert, a network engineer at a gaming company, describes how she used RIPE Atlas to monitor her company's services and improve their customers' experience - and even decided to become a RIPE Atlas sponsor! https://labs.ripe.net/Members/annika_wickert/using-ripe-atlas-to-monitor-ga… Kind regards, Mirjam Kuehne RIPE NCC

1 0

meaning of error message in Ping measurements
by Wenqin SHAO 13 Sep '16

13 Sep '16

Dear list, Could someone please help me figure out what these error messages in result field of ping measurement mean? - error: sendto failed: Invalid argument (related to name resolve?) - error: sendto failed: Bad file descriptor Many thanks. Best regards, wenqin

2 2

Re: [atlas] Rate limits on Atlas
by Emile Aben 09 Sep '16

09 Sep '16

On 08/09/16 14:01, Anant Shah wrote: > Hi Emile, > > Roya and I are working on a geolocation paper and want to use the atlas > probes to ping target IPs. > > I think I am hitting the rate limit on atlas even with 99 concurrent > measurements. All my measurements now show Forbidden status. Is there a > way to increase the limit? yes, ask the team at atlas(a)ripe.net (cc-ed). the folks there can extend limits (not unlimited of course, these limits are there for a reason :) ), but would need some info from you: - what is the experiment you'd like to perform - what would you want the new limit to be (and why what you want to do can't be done with the current limits and/or existing measurements) - when does your experiment end (ie. when can we put the limits back to the default) - promise us that you'll acknowledge RIPE Atlas in a paper - send us a link/copy of the paper once it's published (i hope i'm not forgetting things :) ) cheers, emile

1 0

API probe search
by Hank Nussbacher 08 Sep '16

08 Sep '16

When searching for specific ASN probes via: https://atlas.ripe.net/probes/ and entering a search like "ASxxxx", why does the API ignore the letters AS and respond with probes that have an id of yxxxx or xxxxy or ASN yxxxy? Shouldn't it be if I specify a specific string of ASxxx the response should be *only *those probes in ASxxx or at the worst also ASxxxy? Thanks, Hank

3 5

Data delays on RIPE Atlas
by Romeo Zwart 08 Sep '16

08 Sep '16

Dear colleagues, We are performing some maintenance work on the backend clusters supporting RIPE Atlas. Unexpectedly, this is having an impact on the insertion speed of new data. This means that new data insertion is behind for a few hours. The maintenance work is expected to complete before the end of the day, at which point the backlog of data will be cleared up very quickly. We apologise for any inconvenience caused. Kind regards, Romeo

1 0