- ripe-atlas - mailman.ripe.net

Measurement of impact of the Russian censorship
by Max Tulyev 03 Oct '13

03 Oct '13

Hello Atlas, recently I found some of Websites was blocked in Ukraine with PutinWall outside Russia. These resources was not hosted in Russia as well. Further investigation shows that the trace to these resources are either through Russia, or (which is more interesting) through Russian-based carriers which are do filtering on their networks boundary which are outside Russia as well, for example, in Frankfurt. This is some impaced nets in Ukraine, but probably countries whole connected through Russia, like Kazakhstan, are more suffering. Is it possible to use Atlas probes to figure out impact of PutinWall to countries should not be impacted by Russian censorship? And may be the efficient of filtering inside Russia? That's the sample of censored URL: http://stervozzinka.dreamwidth.org/15580.html The task is to probe it from Atlas probes and put on map the mark is it accessible or not for the first result. The second stage is to figure out carriers do the filtering of trans-Russia connectivity. I believe it will be interesting for a lot of people. I see this test is possible, but possible only manually by the RIPE NCC staff.

1 0

Problems deleting measurements
by Klaus Darilion 03 Oct '13

03 Oct '13

Hi! I have problems with lots of measurements, I can not delete them. e.g: A) https://atlas.ripe.net/api/v1/measurement/1027747/ The status is "Failed" and in the web I can not Archive or Stop it. Also deletion via REST fails: curl -H 'Accept: application/json' -X DELETE https://atlas.ripe.net/api/v1/measurement/1027747/?key=01....6d {"error": {"code": 200, "message": "That measurement cannot be stopped."}} btw: is above REST call correct? Same problem for measurment 1012558 which is in status Stopped. B) Is "archive" in the web interface identical to "DELETE" via REST? E.g. the web interface offers me "Archive" for measurement 1029338 (and I am quite sure it would work), but the REST call fails with same result: curl -H 'Accept: application/json' -X DELETE https://atlas.ripe.net/api/v1/measurement/1029338/?key=01....d {"error": {"code": 200, "message": "That measurement cannot be stopped."}} Further, the web interface offers "Stop" and "Archive", but the REST call only offers "DELETE". So, how do I "Stop" via REST? For me it is confusing to have different terms in the web interface and REST API. C) 1031725: The measurement is currently (UTC 18:30) in status Ongoing. Start Time is UTC 19:45, Stop Time is 19:55. When I stop the measurement, the measurements stop time changes to the current time, but status is still Ongoing, and I can not Archive (not offered), but it still offers always Stop. But when I delete via REST, the measurement gets stopped (status Stopped in web interface). So does REST-DELETE is identical to "Stop" in web interface? If yes, how do I archive via REST? Further, DELETE a stopped message should not produce error "That measurement cannot be stopped.", but rather "That measurement is already stopped." D) For the web interface it would be cool to stop/archive/delete measurements more comfortable. Eg. select multiple measurements and then choose "stop and archive". Thanks Klaus Thanks Klaus

2 2

Probe uptime reporting issues
by Robert Kisteleki 01 Oct '13

01 Oct '13

Dear All, On 21 September we deployed a new software version on our core infrastructure components. Unfortunately this contained a bug that we didn't catch in time, which caused "probe uptime reports" not to be propagated properly. This affected the "monthly probe uptime reports" as well as -- in some cases -- the amount of credits received for a probe. We've fixed the bug and re-sent the missing uptime entries. Please let us know (in an email to atlas(a)ripe.net, mentioning your email address and probe ID) if you received less credits than you should have, and would like to receive compensation. In order to improve our process, we're working on an internal test suite that will help us catching these kind of errors in time. We aplogise for the inconvenience this issue may have casued. Regards, Robert Kisteleki for the RIPE Atlas team

1 0

Credits transfer no longer working?
by Stephane Bortzmeyer 30 Sep '13

30 Sep '13

Did anyone notice problems with credit transfers? I run a RIPE Atlas workshop tomorrow abnd I tried to transfer credits to attendants, people with a RIPE account, both in the same LIR and outside. Nothing is credited on their side.

4 4

finding a probe
by Randy Bush 27 Sep '13

27 Sep '13

remote hands plugged an old style probe in. i see it on the ether port they claimed, its mac is 00:80:a3:91:4b:0d (my others are all 00:20, hmmm) i plug the dhcp-issued address 198.180.152.27 into the page at https://atlas.ripe.net/register/ it tells me there is no probe there how to debug? randy

1 0

REST API Problems for DNS measurements with DO and TCP
by Klaus Darilion 26 Sep '13

26 Sep '13

Hi! I managed to create DNS measurements via the REST API, but fail to set the DO and protocol:TCP option. According to the documentation (https://atlas.ripe.net/doc/measurement-creation-api/) the relevant properties are use_EDNS0 and use_tcp. So I tried it with { "definitions": [ { "is_public": true, "is_oneoff" : false, "target": "194.0.25.13", "description": "a.dns.nic.versicherung_IP4_TCP_noDO", "type": "dns", "af": 4, "interval": 300, "use_EDNS0": false, "use_TCP": true, "use_probe_resolver": false, "use_NSID": true, "query_class": "IN", "query_type": "SOA", "query_argument": "versicherung", "udp_payload_size": 1024, "protocol": "TCP", "do": true } ], } but that does not work - the generated measurements do not use TCP and DO. When I create the measurement via the web interface and review the measurement via the REST API, I see that other properties are set: "do" and "protocol". E.g: # curl https://atlas.ripe.net/api/v1/measurement/1027747/ {"all_scheduling_requests_fulfilled": true, "can_visualise": false, "creation_time": 1380018470, "description": "TEST via WEB", "do": true, "dst_addr": "194.0.25.13", "dst_asn": "1921", "dst_name": "194.0.25.13", "interval": 240, "is_oneoff": true, "is_public": true, "msm_id": 1027747, "nsid": true, "participant_count": 1, "protocol": "TCP", "query": {"class": "IN", "type": "SOA", "value": "versicherung."}, "resolve_on_probe": false, "resolved_ips": ["194.0.25.13"], "result": "/api/v1/measurement/1027747/result/", "start_time": 1380018470, "status": {"id": 7, "name": "Failed"}, "stop_time": 1380018904, "type": {"id": 6, "name": "dns"}, "udp_payload_size": 512} So I tried to create measurements with the "do" and "protocol" properties, but these properties are again ignored. If I am doing something wrong, so please give me some hints. Otherwise the API documentation is wrong and these properties can not be set via REST, only via the web interface - and should be fixed. Thanks Klaus

3 6

IPv6, RA and static IPv6 assignment
by Mike. 19 Sep '13

19 Sep '13

Are there any plans to allow the probe's listening for RA to be disabled so that I can configure a static IPv6 address, router and DNS server without RA overwriting my values?

4 4

Add E-Mail notification when a probe is back up (for more than 60 minutes)
by Roman Mamedov 19 Sep '13

19 Sep '13

Hello, Got one of these: > Your probe 73 has been disconnected since 2013-09-19 09:26:19 UTC. > > This is an automatically generated email from RIPE Atlas. It was sent to you because you asked to be notified if your probe becomes disconnected for more than 60 minutes. > > If you want to change this, or disable this notification altogether, please go to https://atlas.ripe.net/atlas/myprobes.html, click on "My Probes" and then on probe 73. In the opened tab, select "Probe's Settings" and then "Notifications" to change your settings. > > Kind regards, > > RIPE Atlas Team > What's unusual this time, is that I did not change anything in my network setup, and I can still ping the probe both on its local v4 and global v6 addresses. So one way of action would be to unplug and replug the probe in hope that it sorts out itself; 2nd course of action would be to simply wait and see if it reconnects on its own. If I choose this, I have to keep the Atlas website open in a browser tab, refreshing from time to time to see if the readings changed to "Connected". So what baffles me about this, why can't I get a simple E-Mail notification same way as "it went down", to tell me that "ok now it's back up"? -- With respect, Roman

1 0

"Spoofing" tests.
by Warren Kumari 18 Sep '13

18 Sep '13

Apologies if this has already been discussed enlist -- I took a quick look though the archives and didn't see it. I believe that the reason for not allowing things like tests that send spoofed packets is that it might violate the AUP that participants have with their ISPs / be viewed by participants ISPs as an attack. So, what about having a checkbox in the Probe Settings that says something like: "I have no AUP with my ISP or I'm fine to violate my AUP. Run intrusive or dangerous tests on this probe" ? This would create a subset of probes that could be used for more interesting tests, an d would allow for greater visibility into things. W --- It is a mistake to think you can solve any major problem just with potatoes. --Douglas Adams

11 17

RIPE Atlas anchors update
by becha 16 Sep '13

16 Sep '13

Dear RIPE Atlas users, we are happy to share with you the results of the pilot phase of RIPE Atlas anchors, and plans for the production service. Two recent RIPE Labs article give you the details: * technical results of virtualization testing: https://labs.ripe.net/Members/romeo_zwart/further-virtualisation-testing-fo… * "mesh" measurements between all anchors, moving to smaller box and different hardware platform, and making the service for all, not only members: https://labs.ripe.net/Members/becha/ripe-atlas-anchors-pilot-summary-and-ne… We are looking forward to see you at RIPE67, MAT-WG, and in the meantime, to your comments and feedback on this list. Kind regards, Vesna -- Vesna Manojlovic BECHA(a)ripe.net Senior Community Builder @Ms_Measurements for Measurements Tools RIPE NCC http://ripe.net

1 0