- ripe-atlas - mailman.ripe.net

Crediting for probe uptime
by Robert Kisteleki 23 Aug '13

23 Aug '13

Dear All, In the last two days we noticed a hickup in the crediting procedure (the one that gives credits to probe hosts and sponsors). We believe the proper fix is in place now. We just finished crediting everyone for the time period in question, which means all of the probes generated more than usual credits -- compensating for the missing ones lately, and some interest :-) We apologise for the inconvenience this may have caused. Regards, Robert Kisteleki

1 0

On RIPE Labs: Future of the RIPE NCC technical services
by Vesna Manojlovic 23 Aug '13

23 Aug '13

Dear colleagues, please take a look at the Labs article by Kaveh Ranjbar, which touches upon the future of the RIPE Atlas services: https://labs.ripe.net/Members/kranjbar/future-of-ripe-ncc-technical-services Regards, Vesna

1 0

IPv6 Report - Blank
by Tom Kacprzynski 22 Aug '13

22 Aug '13

Hello, Is anyone else having the issue of downloading IPv6 measurement reports? I ran few of them and the file is empty. I tried downloading both formats JSON and Fragment. I also tried downloading the public measurement without any luck either. Thanks -- *Tom Kacprzynski*

2 2

Geo locations confirmed
by Marco Davids (SIDN) 20 Aug '13

20 Aug '13

Hi, Are any of the geo-locations of Atlas probes confirmed, double-checked, or verified by RIPE? Or do we just have to take for granted, whatever the owner of the probe enters in the probe's settings ? Thanks, -- Marco

2 1

v3 Probe got disconnected and won't reconnect
by Axel Fischer 14 Aug '13

14 Aug '13

Hi, on 2013-08-11 at 05:15:30 UTC one of our probes (ID: 11707) got disconnected. It is connected via a switch to a router within our network. I can see the link up (it remained up all the time) but see the 3rd LED (Network Test) and 4th LED (Connecting) blinking. The MAC was visible on the switch port and router. I powercycled the probe but no change except that the MAC is no longer visible on the router. With a laptop instead of the probe it works fine. Is the probe broken? How can this state be fixed? Regards, Axel -- Axel Fischer Network Engineer 1&1 Internet AG Brauerstrasse 48 D-76135 Karlsruhe http://www.1und1.de (AS8560) Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 6484 Vorstand: Ralph Dommermuth, Frank Einhellinger, Robert Hoffmann, Andreas Hofmann, Markus Huhn, Hans-Henning Kettler, Uwe Lamnek, Jan Oetjen, Christian Würst Aufsichtsratsvorsitzender: Michael Scheeren Member of United Internet Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese Email. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This E-Mail may contain confidential and/or privileged information. If you are not the intended recipient of this E-Mail, you are hereby notified that saving, distribution or use of the content of this E-Mail in any way is prohibited. If you have received this E-Mail in error, please notify the sender and delete the E-Mail.

3 2

Probe sharing
by Martin Stanislav 08 Aug '13

08 Aug '13

Hi, This spring RIPE Atlas update [1] introduced a new feature called probe sharing. Probe sharing should work for colleagues within the same LIR and is to be set via: "My Probes" -> "Probe's Settings" -> "General Configuration" -> Select your LIR in the "Share with" field. I've set the "Share with" field to our LIR ID for all three local probes. But a colleague of mine, in spite of being able to login to the Lirportal, sees an error message below every time he tries to access the probe list at https://atlas.ripe.net/atlas/myprobes.html The error message: "You are not logged in as a RIPE NCC member". Is there anything I've missed? Possible delay in privilege propagation from the Lirportal to Atlas section? Thanks. Martin [1] https://labs.ripe.net/Members/kistel/new-ripe-atlas-features-april-2013

4 4

Multiple Probe v3 Disconnects
by David Churchill 08 Aug '13

08 Aug '13

I just received my v3 probe 3 days ago and I've noticed on the status page that that there are quite a few disconnects: Disconnect at: Connected time: Disconnected time: (still connected) 0d, 0h, 30m (still connected) 2013-08-08 11:37:44 UTC 0d, 0h, 38m 0d, 0h, 2m 2013-08-08 10:49:09 UTC 0d, 1h, 14m 0d, 0h, 10m 2013-08-08 09:31:38 UTC 0d, 2h, 2m 0d, 0h, 3m 2013-08-08 07:25:41 UTC 0d, 1h, 22m 0d, 0h, 3m 2013-08-08 05:53:24 UTC 0d, 1h, 26m 0d, 0h, 9m 2013-08-08 04:24:56 UTC 0d, 2h, 23m 0d, 0h, 2m 2013-08-08 01:57:23 UTC 0d, 1h, 18m 0d, 0h, 4m 2013-08-08 00:35:09 UTC 0d, 0h, 26m 0d, 0h, 3m 2013-08-08 00:05:53 UTC 0d, 1h, 25m 0d, 0h, 2m 2013-08-07 22:37:14 UTC 0d, 1h, 12m 0d, 0h, 3m 2013-08-07 21:20:56 UTC 0d, 0h, 4m 0d, 0h, 4m 2013-08-07 21:11:44 UTC 0d, 2h, 9m 0d, 0h, 4m 2013-08-07 18:59:32 UTC 0d, 0h, 39m 0d, 0h, 2m 2013-08-07 18:18:40 UTC 0d, 6h, 12m 0d, 0h, 1m 2013-08-07 12:03:56 UTC 0d, 12h, 42m 0d, 0h, 1m 2013-08-06 23:19:16 UTC 0d, 0h, 4m 0d, 0h, 2m 2013-08-06 23:15:08 UTC 0d, 0h, 2m 0d, 0h, 0m 2013-08-06 23:05:16 UTC 0d, 4h, 45m 0d, 0h, 7m 2013-08-06 18:17:13 UTC 0d, 1h, 54m 0d, 0h, 2m 2013-08-06 16:18:39 UTC 0d, 0h, 45m 0d, 0h, 3m 2013-08-06 15:32:39 UTC 0d, 0h, 41m 0d, 0h, 0m 2013-08-06 14:50:33 UTC 0d, 2h, 32m 0d, 0h, 0m 2013-08-06 05:51:43 UTC 0d, 6h, 47m 0d, 6h, 25m Is this something I should be concerned about? If so, could it have to do with the fact that my probe is plugged into a 10/100/1000 MBit switch (I saw an earlier thread that suggested this might be an issue)? If the Gigabit switch is a problem, would it help if I cascade a 10/100 switch off one of the Gigabit switch's ports, or off one of my router's ports (which are all Gigabit) and then plug the probe into that 10/100 switch? Finally, I'm using a cell phone charger for power, it's 5V, mini-usb, I don't think that should cause an issue should it? Thanks for any help, David C. Churchill 5285 Vinings Springs Trl Mableton, GA 30126 770.819.5935 d_churchill(a)comcast.net

3 4

1000Base-T not supported?
by Tore Anderson 08 Aug '13

08 Aug '13

Today I was struggling to get a v3 probe (TP-Link) connected to my network, the link just wouldn't come up. On a whim I tried connecting it to a tri-rate 10/100/100Base-T device, and lo and behold - it came alive! Only 100Mb, though. Is it really the case that the probes don't support 1GbE? The probe has «150Mb» printed on it, which strikes me as rather odd if it's limited upwards to 100Mb. Tore

3 4

RIPE Atlas maintenance on Tuesday, 6 August
by Robert Kisteleki 06 Aug '13

06 Aug '13

Dear RIPE Atlas users, We'd like to let you know that we plan to perform scheduled maintenance on the RIPE Atlas central infrastructure on Tuesday, 6 August, for a couple of hours during the day. In this period, main features including the RIPE Atlas user interface (atlas.ripe.net) data downloads and measurement scheduling functions will be unavailable. Probes will continue to work and all results will still be collected or buffered; however, during the maintenance period you will be unable to log in to the website, manage your probes/measurements, or get to result data/visualisations. We apologise for any inconvenience this may cause. Regards, Robert Kisteleki

1 1

Probe no longer on an IPv6 network?
by Rusty Dekema 05 Aug '13

05 Aug '13

Good evening, When I first installed it, probe 10555 was on a network which supports IPv6. Since then, I have moved it to a different network which does not have IPv6 access at all. Is there something I should do to let the RIPE Atlas system know that it no longer has IPv6 access? It seems like there should be, but I haven't found it. I would not like for it to be one of those probes which "thinks" it has IPv6 but actually does not... Thanks, Rusty D

2 1

adding a device
by folkert 05 Aug '13

05 Aug '13

Hi, Yesterday I received a probe-device at a conference. I entered the details in the website (which was a lot of fun: finding out the ipv4 prefix(?!) - I ended up trying a couple of entries found in the whois info of my ipv4 address, also in what format should I enter the mac-address?) but the device does not appear in the "My probes" list. Even after a couple of hours. I verified that it got an ip4-address from the dhcp server and also radvd is happily announcing the ipv6-prefix in that segment. Furthermore: I see that the probe is doing all kinds of network traffic to the internet. So the device at itself seems to work. What can be wrong? Folkert van Heusden -- Always wondered what the latency of your webserver is? Or how much more latency you get when you go through a proxy server/tor? The numbers tell the tale and with HTTPing you know them! http://www.vanheusden.com/httping/ ----------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

3 3

Registering a new probe...
by Chris Elliott 31 Jul '13

31 Jul '13

I have one probe (3690), and just received two new probes from Nathalie Trenaman, thanks to Bert Wijnen. However, either I'm just flat out missing something or the registration page is broken. I go here: https://atlas.ripe.net/register/ I ensure I'm logged in, and try to complete the registration process. No matter what, it always says: - There were some problems with your submission. Please see below However, nothing is highlighted or otherwise called out as an issue. I've tried various combinations in various fields, with no success. Here's one of the settings I've tried: - On what sort of network will you be installing the probe? * Residential/Consumer Business Network Educational Network IXP RIPE NCC Member (LIR) - Organisation Name * - What's the connection speed like on that network? * < 1 Mb/s 1-4 Mb/s 5-9 Mb/s 10-19 Mb/s 20-49 Mb/s 50-99 Mb/s 100-499 Mb/s 500-999 Mb/s > 1 Gb/s I don't know - AS Number - My network supports IPv4 - IPv4 Network Prefix - Please enter a valid prefix. - My network supports IPv6 - IPv6 Network Prefix - How did you receive your probe? * From conference/training From sponsor Other - Who is the sponsor? * - MAC Address - Location * <http://maps.google.com/maps?ll=21.351893,-102.718887&z=2&t=m&hl=en-US&mapcl…> Map data ©2013 MapLink - Terms of Use<http://www.google.com/intl/en-US_US/help/terms_maps.html> Map Satellite - I'm willing to keep the probe online 24/7 - I'm willing to make my probe visible to the public - I accept the rules of the game a.k.a. Pilot Service Rules<https://atlas.ripe.net/service-rules/> * Thanks for looking into this issue. Chris. -- Chris Elliott chelliot(a)pobox.com

2 2

HTTP or not HTTP?
by Stephane Bortzmeyer 31 Jul '13

31 Jul '13

I'm surprised to see in UDM documentation that you can do HTTP measurements: https://atlas.ripe.net/doc/udm#http-http6 But I do not find this option in the "Choose a measurement" menu of the Web interface. And it is not documented in the REST API: https://atlas.ripe.net/doc/measurement-creation-api/ > type: One of ping,traceroute,dns or sslcert So, can we do HTTP measurements with the Atlas probes?

2 3

Outdated documentation to delete
by Stephane Bortzmeyer 30 Jul '13

30 Jul '13

IMHO, the "mechanize" example in <https://atlas.ripe.net/doc/code#access_from_scripts> is useless now that we have an API and should be deleted.

1 0

Spoofing the source IP address from a probe?
by Stephane Bortzmeyer 30 Jul '13

30 Jul '13

I read in the interesting <http://www.internetsociety.org/blog/2013/06/can-we-stop-ip-spoofing-internet> about BCP38 (anti-spoofing): > Another possibility that was suggested is using RIPE Atlas probes to > probe network capabilities (or shall we say incapabilities?). AFAIK, Atlas probes cannot currently perform these tests, am I correct?

9 11

Re: [atlas] Spoofing the source IP address from a probe?
by Alex Saroyan 30 Jul '13

30 Jul '13

Hi, Probably we don't need to spoof all address space, instead only if spoofing enabled just spoof to some predefined address range. Regards. /Alex Sanjeev Gupta <ghane0(a)gmail.com> wrote: >On Tue, Jul 30, 2013 at 11:22 AM, Randy Bush <randy(a)psg.com> wrote: > >> I support this point of view. I think controlled (anti-)spoofing >> measurements performed by the RIPE NCC with the consent of >> participating probes would be a good service to the community. > >perhaps the probe owners are not the only parties with skin in the game >and whose consent would be relevant? > > >Exactly. I host probes, and since you are spoofing others, we need to ask them. > >How you do this is left as an exercise to the reader. > >-- >Sanjeev Gupta >+65 98551208 http://www.linkedin.com/in/ghane > > >

1 0

Re: [atlas] Outdated for more than one day?
by Fred Grayson 28 Jul '13

28 Jul '13

Hello, The probe ID is 10156. It is attached to a third interface on my router. The graphs have been stalled for the last four days. The probe went online on June 26 and all was well until this happened on July 24. Thanks for looking. FG On 7/28/2013 6:35 AM, Iñigo Ortiz de Urbina wrote: > Good morning Fred, > > I just took a minute to check what you shared with the list. > > My two probes and built-in measurements look just fine (i.e they are > up to date). Your issue may be a temporary error. However, if you'd > like more details on your particular probe/problem pair, I've found it > to be helpful to provide details, such as probe ID or which controller > it is attached to. > > Are you still seeing the same stalled graphs? > > Regards, > > On Sat, Jul 27, 2013 at 8:53 PM, Fred Grayson <fred_grayson(a)yahoo.com> wrote: >> Hello, >> >> Recently, all Built-in-Measurments for my probe began showing "Outdated for >> more than one day" and none of the graphs are current, most show some white >> space at the far right hand side. >> >> My Total Uptime: 99.56% (31d, 22h, 30m) and I have power cycled the device >> twice trying to solve the problem. >> >> Any ideas on how to fix this will be appreciated. >> >> Thanks, >> >> FG >> > > >

1 0

Outdated for more than one day?
by Fred Grayson 27 Jul '13

27 Jul '13

Hello, Recently, all Built-in-Measurments for my probe began showing "Outdated for more than one day" and none of the graphs are current, most show some white space at the far right hand side. My Total Uptime: 99.56% (31d, 22h, 30m) and I have power cycled the device twice trying to solve the problem. Any ideas on how to fix this will be appreciated. Thanks, FG

1 0

Ping Fails (ns.ripe.net)
by AlbyVA 23 Jul '13

23 Jul '13

In reviewing My Probe stats, it appears that (ns.ripe.net) was once able to ping the server, but now it appears to be failing. All my other ping stats under My Probe show successful pings to other servers, but for some reason ns.ripe.net is failing. Does anybody have a suggestion of what might be going on, since ping is working to all the other servers. -Alby

4 6

No address in the results when ping or traceroute fail?
by Stephane Bortzmeyer 23 Jul '13

23 Jul '13

When a ping or traceroute emasurement fails, we do not know the IP address of the probe (empty "from" and no "src_addr"), which is annoying when you want to analyze the possible causes of the failure: { "size": 20, "addr": "2620:0:2d0:200:0:0:0:7", "min": -1, "rcvd": 0, "from": "", "dst_name": "2620:0:2d0:200:0:0:0:7", "af": 6, "timestamp": 1374395985, "fw": 4520, "proto": "ICMP", "name": "www.icann.org", "prb_id": 3953, "result": [ { "error": "sendto failed: Network is unreachable" }, { "error": "sendto failed: Network is unreachable" }, { "error": "sendto failed: Network is unreachable" } ], "max": -1, "dup": 0, "avg": -1, "type": "ping", "dst_addr": "2620:0:2d0:200::7", "sent": 0, "msm_id": 1013576 },

3 6

No probe shown in My Probes list (Registered. Plugged Probe v3 to network. 1st, 3rd, 4th LEDs lighted up.)
by Arthit Suriyawongkul 22 Jul '13

22 Jul '13

Hi I'm Arthit from Bangkok. New here. The switch at the probe is now at "3G/4G". Should i change to WISP or AP? thanks, Art -- เครือข่ายพลเมืองเน็ต -- "เปิดเน็ต เปิดใจ" Thai Netizen Network -- "Open Net. Open Mind." https://www.facebook.com/thainetizen

3 4

Strange and undocumented (?) result in traceroute JSON output
by Stephane Bortzmeyer 17 Jul '13

17 Jul '13

Measurement #1013405 contains: "result": [ { "x": "*" }, { "late": 20, "ttl": 61, "from": "88.79.15.141", "size": 96 }, { "x": "*" }, { "x": "*" } While "late" is documented <https://atlas.ripe.net/doc/data_struct#v4400_traceroute>, the lack of "rtt" field is not and crashes tools like json2traceroute.py.

3 2

[UDM] What value to give to 'requested' when 'type' = 'msm'?
by Stephane Bortzmeyer 17 Jul '13

17 Jul '13

The documentation <https://atlas.ripe.net/doc/measurement-creation-api/> says: "probes": [ { "requested": 1, "type": "msm", "value": 1000002 } ] but, from my tests, if you do so, you get only one probe, whatever measurement #1000002 actually used. To get all the probes, I had to indicate a very large number in 'requested' (unless you remember or count the actual number).

2 2

IPv6 and Atlas probe v3
by Mike. 16 Jul '13

16 Jul '13

My probe works fine on IPv4, obtaining IP address, router, and DNS servers via DCHP. The IPv6 capability has me curious with two questions... I statically configured the IPv6 address via the web interface. I gave the probe an IPv6 address from my prefix, a gateway address, and the IP address of a DNS recursive server provided by my tunnel vendor. The IPv6 address shows up OK on the web interface ("Internet Address") The AS Number also shows up fine. The Gateway is "Undetermined/Unknown" The IP addr of the DNS server is listed as shown below. In the text table below the configuration info, I see: ("V" is a check, "X" is an X) Static Enabled Probe Knows Probe Uses Last Static Address Given IPv6 V V V 2001:470:xxx:xxx::xxx DNS V V X 2001:470:20::2 Question #1: Why is there an "X" for DNS in the "Probe Uses" column? Is there something wrong with that DNS server? When I query DNS from another box on the same subnet as the Atlas probe I get valid results: ; <<>> DiG 9.8.3-P4 <<>> @2001:470:20::2 atlas.ripe.net any ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19739 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;atlas.ripe.net. IN ANY ;; ANSWER SECTION: atlas.ripe.net. 5922 IN AAAA 2a01:4f8:121:30a3::78:16 atlas.ripe.net. 5911 IN A 178.63.78.16 ;; Query time: 21 msec ;; SERVER: 2001:470:20::2#53(2001:470:20::2) ;; WHEN: Mon Jul 8 12:24:01 2013 ;; MSG SIZE rcvd: 76 I also noticed this sentence at the bottom of the https://atlas.ripe.net/doc/static-config page: "...As of now, we have no way of preventing the probe from accepting RAs. So if there is an IPv6 (rogue) RA on you network, it can/will override part of the static configuration. We're unsure if this will change in the future. ..." I do have RA support on the subnet, though I would not classify it as "rogue". :) The RA provides the IPv6 prefix, prefix length, and the IPv6 address of the recursive DNS server. This RA support has been used by another box on the subnet, and it seems to work fine. Question #2: Does the Atlas v3 probe use RA if they are present? Thanks.

2 2

Just to say thank you
by Stephane Bortzmeyer 16 Jul '13

16 Jul '13

With Atlas probes, we were able (at the cost of a few credits) to solve a difficult network connectivity problem. I just wanted to say THANKS.

1 0