January 2018 - ripe-atlas - mailman.ripe.net

Error: Only anchors may be targeted.
by Mozafary Mohammad 28 Jun '18

28 Jun '18

Hello I've got "Only anchors may be targeted." on HTTP measurement creation.Any body can advise what the problem is? Thanks

8 9

New on RIPE Labs: Announcing Daily RIPE Atlas Data Archives
by Mirjam Kuehne 02 Mar '18

02 Mar '18

Dear colleagues, In this article we present a new way to access the dataset on the RIPE Atlas platform. Instead of fetching individual results from measurements using the available APIs, you can now download files containing public measurements for a given day. Please find more details on RIPE Labs: https://labs.ripe.net/Members/petros_gigis/announcing-daily-ripe-atlas-data… Kind regards, Mirjam Kühne RIPE NCC

9 12

False positives on SSL check?
by Ruben Herold 02 Feb '18

02 Feb '18

hi, I tried to monitor on of our services running on https://login.afterbuy.de. I configured an SSL check like (Meassure ID #11090260). All probes response with: Error: timeout reading hello But the service is online and reachable. SSLabs SSL check confirmed this. So can someone explain what the error message will tell me? Thx Ruben Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 3

tag "system: IPv6 Works"
by Wolfgang S Rupprecht 29 Jan '18

29 Jan '18

I just joined the RIPE-Atlas fold with probe #35105 and am still learning the ropes. My public-facing internet servers are all IPv6-only. That means that the only meaningful measurements of my systems come from IPv6 capable probes. I was surprised to see that IPv4-only probes would be scheduled to send IPv6 pings, traceroutes, nslookups etc. Even when I added "system: IPv6 Works" to the include tags and "system: IPv6 Doesn't Work" to the exclude tags I still got some IPv4-only probes assigned. Are those tags for future use and not wired up yet? Are the IPv4-only probes I'm seeing in my test runs there because their status changed recently and previously they were IPv6 capable? -wolfgang

2 1

Connectivity Problems in China
by Klaus Darilion 27 Jan '18

27 Jan '18

Hi! I have probe #248 which was working fine for long time. Now I sent it to a friend in China. He connected it to his home DSL account but the probe is still disconnected. Are you aware of any firewall problems for probes in China? Should the be able to connect on a normal residental Internet access? Where does the probes tries to connect? (Hostname, IP) so I can try to telnet the IP:port from a normal PC. Thanks Klaus

2 1

New on RIPE Labs: Measurements as the Key to Transparency
by Mirjam Kuehne 25 Jan '18

25 Jan '18

Dear colleagues, In this new article on RIPE Labs Alexander Azimov describes how they built a tool to visualise network latency measured with RIPE Atlas. https://labs.ripe.net/Members/alexander_azimov/measurements-as-the-key-to-t… Kind regards, Mirjam Kühne RIPE NCC

1 0

Probe shown as offline although LEDs appear online
by Andre Heinrichs 25 Jan '18

25 Jan '18

Hi, My Probe #29384 has started being reported as offline although the LEDs show no problem. I’ve just tried switching to another USB stick without apparent success. The weird part is that the probe seems to not send any SOS requests as soon as it started running off the USB. I’m guessing that makes it offline. If I’m interpreting the connection & traffic graph correctly the probe is still able to return results. Any advice what I could do now would be appreciated. TIA, Andre Heinrichs

1 1

Query
by Informática IPYS 23 Jan '18

23 Jan '18

Hi, I'm Francisco Colmenares from IPYS Venezuela. I am writing to you because I have a conuslta. After having registered on the RIPE ATLAS page, connect the RIPE to the network, however when I search for the ID in the search engine that has the web page it gives me the ERROR: 101: no entries found. Is there a step I'm missing? Greetings. -- Francisco Colmenares Desarrollo web y Soporte técnico. IPYS Venezuela 0426-1991873

1 0

HTTP server configuration fix deployed to v3 anchors
by Stephen D. Strowes 22 Jan '18

22 Jan '18

Hi, Recently we identified a web server misconfiguration on our v3 anchors, such that those anchors would not respond as expected to requests with their IP literal in the URL. Requests to their FQDN worked as expected. In other words: * http://nl-ams-as3333-3.anchors.atlas.ripe.net:80/ would respond as expected, but * http://[2001:67c:2e8:3::c100:a4]:80/ would respond with a 404 status code. The configuration was fixed and deployed by around 0900UTC on 16 January, 2018. V3 anchors now respond correctly to requests issued with their IP literal in the URL. This affected HTTP measurements to v3 anchors as follows: * Before the fix was deployed, HTTP measurements to a v3 anchor with 'Resolve on probe' set to false will have used the IP literal, and thus logged a 404 status code. * HTTP measurements as above that were running when the fix was deployed will have started returning correct results part-way through their run. If the measurement is ongoing, no other action needs to be taken. * HTTP measurements with 'Resolve on probe' set to true always operated as expected. Cheers, Stephen Strowes RIPE NCC

1 0

Minor changes in the credits transactions API endpoint
by Viktor Naumov 17 Jan '18

17 Jan '18

Dear colleagues, We made some changes to the credits transactions API. The changes relate to the use of another storage back-end. * Transaction IDs are no longer used to retrieve the data. * There is no detail transaction endpoint anymore, all transactions are served as paged lists. * The main transaction endpoint remains /api/v2/credits/transactions/ Deprecated endpoints are as follows: * /api/v2/credits/transactions/<transaction_id> * /api/v2/credits/transactions/admin/<transaction_id> * /api/v2/credits/transactions/measurement/<transaction_id> * /api/v2/credits/transactions/probe/<transaction_id> The transactions endpoint reference is accessible at: https://atlas.ripe.net/docs/api/v2/reference/ Best regards, Viktor Naumov RIPE NCC

1 0