From bortzmeyer at nic.fr Mon Jul 1 12:10:47 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 1 Jul 2013 12:10:47 +0200 Subject: [atlas] [iesg-secretary@ietf.org: [lmap] WG Action: Formed Large-Scale Measurement of Broadband Performance (lmap)] Message-ID: <20130701101047.GA22634@nic.fr> It seems quite close from what Atlas is doing. Atlas documentation in a RFC, one day? :-) -------------- next part -------------- An embedded message was scrubbed... From: The IESG Subject: [lmap] WG Action: Formed Large-Scale Measurement of Broadband Performance (lmap) Date: Fri, 28 Jun 2013 09:49:27 -0700 Size: 13699 URL: From BECHA at ripe.net Mon Jul 1 15:03:29 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 01 Jul 2013 15:03:29 +0200 Subject: [atlas] Mid-summer community update Message-ID: <51D17E21.9010402@ripe.net> Dear RIPE Atlas community, you have been very active recently. I summerized it (ha! pun intended) in the RIPE Labs article, highlighting new community related features for RIPE Atlas anchor hosts, sponsors and "ambassadors". And the article has lots of pretty pictures! Share and enjoy! Warm regards, Vesna https://labs.ripe.net/Members/becha/ripe-atlas-midsummer-2013-community-update From vb.bajpai at gmail.com Wed Jul 3 18:59:06 2013 From: vb.bajpai at gmail.com (Vaibhav Bajpai) Date: Wed, 3 Jul 2013 18:59:06 +0200 Subject: [atlas] A Tutorial on Large-Scale Measurement Platforms Message-ID: Hello, We recently gave a tutorial on Large-Scale Measurement Platforms at AIMS 2013 [1]. The tutorial is available at [2]. [1] http://www.aims-conference.org/2013/labs.html [2] http://cnds.eecs.jacobs-university.de/tutorials Abstract: --------- This tutorial provides an introduction into large-scale measurement platforms. It begins by surveying active measurement studies that paved way for the deployment of such platforms. It then describes the internals of the RIPE Atlas and SamKnows platforms, their architecture and surveys the work published from insights discovered from the collected data. The first part concludes by introducing the current Large Scale Measurement of Access Network Performance (LMAP) standardisation efforts in the IETF. The second part of the tutorial provides practical training on how to virtualise an OpenWrt-based Customer Premises Equipment (CPE) and bootstrap it to register as a Measurement Agent (MA) with a controller. The MA is then used to install a measurement test, schedule the reporting of the measurement test results and use a REST API to send and retrieve the measurement results back from the collector. The tutorial also provides training on how to use the RIPE Atlas REST API to create User Defined Measurements (UDMs), and retrieve the UDM measurement results. It concludes with a description of the UDM result data structures and a brief of how programming tools can be used to analyse such data. Best Regards, Vaibhav Bajpai and Nikolay Melnikov About authors: Vaibhav Bajpai is a PhD student at Jacobs University Bremen, Germany. His research focuses on understanding the impact of network infrastructure changes using Large-Scale Measurement Platforms. http://vaibhavbajpai.com Nikolay Melnikov is a PhD student at Jacobs University Bremen, Germany. His research focuses on identification and differentiation of Internet users based on their browsing patterns and behaviors. http://nmelnikov.com From arthit at gmail.com Sat Jul 6 22:34:18 2013 From: arthit at gmail.com (Arthit Suriyawongkul) Date: Sun, 7 Jul 2013 03:34:18 +0700 Subject: [atlas] No probe shown in My Probes list (Registered. Plugged Probe v3 to network. 1st, 3rd, 4th LEDs lighted up.) Message-ID: 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 From the.lists at mgm51.com Tue Jul 9 02:24:31 2013 From: the.lists at mgm51.com (Mike.) Date: Mon, 08 Jul 2013 20:24:31 -0400 Subject: [atlas] atlas.ripe.net website reliability Message-ID: <201307082024310275.02A45F0E@smtp.24cl.home> About 20% of the time I try to access the website, the browser times out. Granted, I tend to access the website when it is the early morning hours in Europe, perhaos maintenance is being performed. Are there any plans in place to make the website more available to global viewers? From vnaumov at ripe.net Tue Jul 9 07:51:25 2013 From: vnaumov at ripe.net (Viktor Naumov) Date: Tue, 09 Jul 2013 07:51:25 +0200 Subject: [atlas] atlas.ripe.net website reliability In-Reply-To: <201307082024310275.02A45F0E@smtp.24cl.home> References: <201307082024310275.02A45F0E@smtp.24cl.home> Message-ID: <51DBA4DD.2090404@ripe.net> Hi Mike, That sounds bad. Though we didn't notice such high failure rate, neither had we complains about it. Is anyone experiencing the same? It can happen though during maintenance hours, but usually it takes no more than 2 hours and it is weekly of bi-weekly. Can you try to access other RIPE NCC websites like http://www.ripe.net ? Thank you /vty On 7/9/13 2:24 AM, Mike. wrote: > About 20% of the time I try to access the website, the browser times > out. > > Granted, I tend to access the website when it is the early morning > hours in Europe, perhaos maintenance is being performed. > > Are there any plans in place to make the website more available to > global viewers? > > > > From the.lists at mgm51.com Tue Jul 9 17:07:32 2013 From: the.lists at mgm51.com (Mike.) Date: Tue, 09 Jul 2013 11:07:32 -0400 Subject: [atlas] atlas.ripe.net website reliability In-Reply-To: <51DBA4DD.2090404@ripe.net> References: <201307082024310275.02A45F0E@smtp.24cl.home> <51DBA4DD.2090404@ripe.net> Message-ID: <201307091107320375.00919CED@smtp.24cl.home> On 7/9/2013 at 7:51 AM Viktor Naumov wrote: |Hi Mike, | |That sounds bad. Though we didn't notice such high failure rate, neither |had we complains about it. | |Is anyone experiencing the same? | |It can happen though during maintenance hours, but usually it takes no |more than 2 hours and it is weekly of bi-weekly. | |Can you try to access other RIPE NCC websites like http://www.ripe.net ? | |Thank you | |/vty | |On 7/9/13 2:24 AM, Mike. wrote: |> About 20% of the time I try to access the website, the browser times |> out. |> |> Granted, I tend to access the website when it is the early morning |> hours in Europe, perhaos maintenance is being performed. |> |> Are there any plans in place to make the website more available to |> global viewers? ============= Thanks for the reply. The next time I experience the problem, I'll try http://www.ripe.net as you suggested. From arthit at gmail.com Wed Jul 10 03:10:05 2013 From: arthit at gmail.com (Arthit Suriyawongkul) Date: Wed, 10 Jul 2013 08:10:05 +0700 Subject: [atlas] No probe shown in My Probes list (Registered. Plugged Probe v3 to network. 1st, 3rd, 4th LEDs lighted up.) In-Reply-To: References: Message-ID: > On Sat, Jul 6, 2013 at 10:34 PM, Arthit Suriyawongkul wrote: > > The switch at the probe is now at "3G/4G". > Should i change to WISP or AP? Now the probe is shown in My Probes list. But it said the last uptime is on 5 July, the day I plugged it to the network, and the uptime was only 14 minutes, and it never went up again after that. As a note, today (10 July) is the first day that I found my probe on the list. Have checked it everyday since 5 July, it was not there. On 7 July, I changed the position of switch on my probe from "3G/4G" to "AP". On 9 July, I changed it back to "3G/4G". any suggestion? thank you, art From bortzmeyer at nic.fr Wed Jul 10 14:36:57 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 10 Jul 2013 14:36:57 +0200 Subject: [atlas] atlas.ripe.net website reliability In-Reply-To: <51DBA4DD.2090404@ripe.net> References: <201307082024310275.02A45F0E@smtp.24cl.home> <51DBA4DD.2090404@ripe.net> Message-ID: <20130710123657.GA10827@nic.fr> On Tue, Jul 09, 2013 at 07:51:25AM +0200, Viktor Naumov wrote a message of 30 lines which said: > Is anyone experiencing the same? No, and I use it quite often. Why not adding HTTP tests to Atlas and monitor it from the probes? :-) From the.lists at mgm51.com Wed Jul 10 17:20:40 2013 From: the.lists at mgm51.com (Mike.) Date: Wed, 10 Jul 2013 11:20:40 -0400 Subject: [atlas] atlas.ripe.net website reliability In-Reply-To: <20130710123657.GA10827@nic.fr> References: <201307082024310275.02A45F0E@smtp.24cl.home> <51DBA4DD.2090404@ripe.net> <20130710123657.GA10827@nic.fr> Message-ID: <201307101120400774.00DAE44A@smtp.24cl.home> On 7/10/2013 at 2:36 PM Stephane Bortzmeyer wrote: |On Tue, Jul 09, 2013 at 07:51:25AM +0200, | Viktor Naumov wrote | a message of 30 lines which said: | |> Is anyone experiencing the same? | |No, and I use it quite often. | |Why not adding HTTP tests to Atlas and monitor it from the probes? :-) ============= The site's been fine since my original posting. Last week I was using the site extensively (mostly during early morning hours in Europe, as I'm on the east coast of the US) and that is when I was seeing the issues. From bortzmeyer at nic.fr Thu Jul 11 10:59:49 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 11 Jul 2013 10:59:49 +0200 Subject: [atlas] 300 probes just disappeared? Message-ID: <20130711085949.GA9509@laperouse.bortzmeyer.org> Yesterday, on the Web site, there were > 3400 probes, now: Probes connected to RIPE Atlas: 3177 From astrikos at ripe.net Thu Jul 11 11:10:48 2013 From: astrikos at ripe.net (Andreas Strikos) Date: Thu, 11 Jul 2013 11:10:48 +0200 Subject: [atlas] 300 probes just disappeared? In-Reply-To: <20130711085949.GA9509@laperouse.bortzmeyer.org> References: <20130711085949.GA9509@laperouse.bortzmeyer.org> Message-ID: <51DE7698.7080500@ripe.net> On 7/11/13 10:59 AM, Stephane Bortzmeyer wrote: > Yesterday, on the Web site, there were > 3400 probes, now: > > Probes connected to RIPE Atlas: 3177 > Hi, we are currently doing some OS patching to some of our servers and they need a reboot. So some probes had to be disconnected. The numbers will go back to normal soon. Regards, Andreas From alexsaroyan at gmail.com Thu Jul 11 13:07:51 2013 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Thu, 11 Jul 2013 15:07:51 +0400 Subject: [atlas] atlas.ripe.net website reliability In-Reply-To: <201307101120400774.00DAE44A@smtp.24cl.home> References: <201307082024310275.02A45F0E@smtp.24cl.home> <51DBA4DD.2090404@ripe.net> <20130710123657.GA10827@nic.fr> <201307101120400774.00DAE44A@smtp.24cl.home> Message-ID: <51DE9207.1040807@gmail.com> Hi, Last 3 weeks I was in US east coast and can confirm that Ripe atlas web page was slow from there. On 07/10/2013 07:20 PM, Mike. wrote: > On 7/10/2013 at 2:36 PM Stephane Bortzmeyer wrote: > > |On Tue, Jul 09, 2013 at 07:51:25AM +0200, > | Viktor Naumov wrote > | a message of 30 lines which said: > | > |> Is anyone experiencing the same? > | > |No, and I use it quite often. > | > |Why not adding HTTP tests to Atlas and monitor it from the probes? :-) > ============= > > > The site's been fine since my original posting. > > Last week I was using the site extensively (mostly during early morning > hours in Europe, as I'm on the east coast of the US) and that is when I > was seeing the issues. > > > > > > From robert at ripe.net Thu Jul 11 14:14:22 2013 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 11 Jul 2013 14:14:22 +0200 Subject: [atlas] atlas.ripe.net website reliability In-Reply-To: <51DE9207.1040807@gmail.com> References: <201307082024310275.02A45F0E@smtp.24cl.home> <51DBA4DD.2090404@ripe.net> <20130710123657.GA10827@nic.fr> <201307101120400774.00DAE44A@smtp.24cl.home> <51DE9207.1040807@gmail.com> Message-ID: <51DEA19E.6090303@ripe.net> Dear All, As a data point: we are in the process of changing the UI to a higher capacity cluster. This work is expected to be finished in the next few weeks. We'll announce the exact time of the change (as it will be done during a scheduled maintenance interval). Regards, Robert From robert at ripe.net Thu Jul 11 14:23:54 2013 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 11 Jul 2013 14:23:54 +0200 Subject: [atlas] 300 probes just disappeared? In-Reply-To: <20130711085949.GA9509@laperouse.bortzmeyer.org> References: <20130711085949.GA9509@laperouse.bortzmeyer.org> Message-ID: <51DEA3DA.80701@ripe.net> On 2013.07.11. 10:59, Stephane Bortzmeyer wrote: > Yesterday, on the Web site, there were > 3400 probes, now: > > Probes connected to RIPE Atlas: 3177 Hello, Please note that this number is not monotonically increasing. Probes come and go all the time, so small fluctuations are always expected. When we have "events" at our colo partners (network hickups, servers going down for reboots, etc.), a larger number of probes can get disconnected temporarily. They reconnect eventually -- depending on the actual issue this may take anything from a few minutes up to an hour or two. The number shown on the website always reflects the current reality (with some minutes of caching). Hope this helps, Robert From robert at ripe.net Thu Jul 11 14:31:38 2013 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 11 Jul 2013 14:31:38 +0200 Subject: [atlas] [iesg-secretary@ietf.org: [lmap] WG Action: Formed Large-Scale Measurement of Broadband Performance (lmap)] In-Reply-To: <20130701101047.GA22634@nic.fr> References: <20130701101047.GA22634@nic.fr> Message-ID: <51DEA5AA.4010003@ripe.net> On 2013.07.01. 12:10, Stephane Bortzmeyer wrote: > It seems quite close from what Atlas is doing. Atlas documentation in > a RFC, one day? :-) Indeed, although the scope is "measurement system for performance measurements of broadband access devices" which is something that Atlas is not intended to do. Nevertheless, we're following this, and even contributed to the discussions before, as the infrastructure definition part may be useful for Atlas too. Robert From rdekema at gmail.com Sun Jul 14 19:35:05 2013 From: rdekema at gmail.com (Rusty Dekema) Date: Sun, 14 Jul 2013 13:35:05 -0400 Subject: [atlas] Timeout on Ping Measurements Message-ID: Greetings, What is the default timeout on ICMPv4 user-defined measurements made on RIPE Atlas? I am guessing something like 1.2 s based on observations, but I'd like to know definitively. Also, is it possible to increase the timeout? One of the targets I have been measuring often takes a very long time to respond (due to congestion or link-layer retries) and I would like to have a high (5 second, perhaps) timeout on these pings. I haven't noticed an option to set this when setting up the measurement, but it's very possible I've overlooked something. Cheers, Rusty Dekema -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Mon Jul 15 16:13:23 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 15 Jul 2013 16:13:23 +0200 Subject: [atlas] Timeout on Ping Measurements In-Reply-To: <51E3FCBA.6040207@ripe.net> References: <51E3FCBA.6040207@ripe.net> Message-ID: <51E40383.3040609@ripe.net> On 2013/07/14 19:35 , Rusty Dekema wrote: > > What is the default timeout on ICMPv4 user-defined measurements made > on RIPE Atlas? I am guessing something like 1.2 s based on > observations, but I'd like to know definitively. It should be 1 second. > Also, is it possible to increase the timeout? One of the targets I > have been measuring often takes a very long time to respond (due to > congestion or link-layer retries) and I would like to have a high (5 > second, perhaps) timeout on these pings. I haven't noticed an option > to set this when setting up the measurement, but it's very possible > I've overlooked something. At the moment there is no option to change the ping timeout. Traceroute does have that option. Philip From bortzmeyer at nic.fr Tue Jul 16 16:21:13 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 16 Jul 2013 16:21:13 +0200 Subject: [atlas] [UDM] What value to give to 'requested' when 'type' = 'msm'? Message-ID: <20130716142113.GA29372@nic.fr> The documentation 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). From bortzmeyer at nic.fr Tue Jul 16 17:12:59 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 16 Jul 2013 17:12:59 +0200 Subject: [atlas] Just to say thank you Message-ID: <20130716151259.GA2337@nic.fr> 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. From the.lists at mgm51.com Tue Jul 16 17:23:56 2013 From: the.lists at mgm51.com (Mike.) Date: Tue, 16 Jul 2013 11:23:56 -0400 Subject: [atlas] IPv6 and Atlas probe v3 Message-ID: <201307161123560133.0096DFA7@smtp.24cl.home> 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. From philip.homburg at ripe.net Tue Jul 16 17:38:37 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 16 Jul 2013 17:38:37 +0200 Subject: [atlas] IPv6 and Atlas probe v3 In-Reply-To: <201307161123560133.0096DFA7@smtp.24cl.home> References: <201307161123560133.0096DFA7@smtp.24cl.home> Message-ID: <51E568FD.6080702@ripe.net> Hi Mike, On 2013/07/16 17:23 , Mike. wrote: > > 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? The probe constructs an /etc/resolv.conf from either DHCP or the statically configured DNS resolvers. In practice it means that DHCP will win. When the probe connects to a controller it reports which DNS resolvers it is using. So the 'X' means that the probe is not using the DNS resolver you configured but instead uses the ones from DHCP. > > "...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? Yes. If the probe receives a RA that directs the probe to configure an address then it will just do that even if it already has a statically configure IPv6 address. Philip From the.lists at mgm51.com Tue Jul 16 17:46:37 2013 From: the.lists at mgm51.com (Mike.) Date: Tue, 16 Jul 2013 11:46:37 -0400 Subject: [atlas] IPv6 and Atlas probe v3 In-Reply-To: <51E568FD.6080702@ripe.net> References: <201307161123560133.0096DFA7@smtp.24cl.home> <51E568FD.6080702@ripe.net> Message-ID: <201307161146370914.00ABA71A@smtp.24cl.home> On 7/16/2013 at 5:38 PM Philip Homburg wrote: |Hi Mike, | |On 2013/07/16 17:23 , Mike. wrote: |> |> 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? | |The probe constructs an /etc/resolv.conf from either DHCP or the |statically configured DNS resolvers. In practice it means that DHCP will |win. When the probe connects to a controller it reports which DNS |resolvers it is using. | |So the 'X' means that the probe is not using the DNS resolver you |configured but instead uses the ones from DHCP. That makes sense. |> |> "...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? | |Yes. If the probe receives a RA that directs the probe to configure an |address then it will just do that even if it already has a statically |configure IPv6 address. | ============= Excellent, that is what I wanted to occur (i.e., the probe using the prefix obtained via RA). So far, using the RA for configuration, the probe appears to be doing fine with IPv6 tasks. As a suggestion, maybe the fact that the probe can use RA to configure an IPv6 address could be mentioned in an appropriate area of the documentation or FAQ? In any case, thanks for the quick reply! Mike. From astrikos at ripe.net Wed Jul 17 09:06:26 2013 From: astrikos at ripe.net (Andreas Strikos) Date: Wed, 17 Jul 2013 09:06:26 +0200 Subject: [atlas] [UDM] What value to give to 'requested' when 'type' = 'msm'? In-Reply-To: <20130716142113.GA29372@nic.fr> References: <20130716142113.GA29372@nic.fr> Message-ID: <51E64272.7080007@ripe.net> Hi, On 7/16/13 4:21 PM, Stephane Bortzmeyer wrote: > The documentation > 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). > > Indeed if you want all probes you have to specify number bigger or equal with what the measurement had. Otherwise you will get the amount you specified. But it makes sense to have a flag to indicate that you want the exact same number. We will look into it. Thanks, Andreas From bortzmeyer at nic.fr Wed Jul 17 09:17:32 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 17 Jul 2013 09:17:32 +0200 Subject: [atlas] Strange and undocumented (?) result in traceroute JSON output Message-ID: <20130717071732.GA17666@nic.fr> Measurement #1013405 contains: "result": [ { "x": "*" }, { "late": 20, "ttl": 61, "from": "88.79.15.141", "size": 96 }, { "x": "*" }, { "x": "*" } While "late" is documented , the lack of "rtt" field is not and crashes tools like json2traceroute.py. From philip.homburg at ripe.net Wed Jul 17 10:47:56 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 17 Jul 2013 10:47:56 +0200 Subject: [atlas] Strange and undocumented (?) result in traceroute JSON output In-Reply-To: <20130717071732.GA17666@nic.fr> References: <20130717071732.GA17666@nic.fr> Message-ID: <51E65A3C.8060309@ripe.net> Hi Stephane, On 2013/07/17 9:17 , Stephane Bortzmeyer wrote: > Measurement #1013405 contains: > > "result": [ > { > "x": "*" > }, > { > "late": 20, > "ttl": 61, > "from": "88.79.15.141", > "size": 96 > }, > { > "x": "*" > }, > { > "x": "*" > } > > While "late" is documented > , the lack of > "rtt" field is not and crashes tools like json2traceroute.py. > I'll update the documentation to say that rtt won't be there for packets that are late. Philip From bortzmeyer at nic.fr Wed Jul 17 10:56:49 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 17 Jul 2013 10:56:49 +0200 Subject: [atlas] [UDM] What value to give to 'requested' when 'type' = 'msm'? In-Reply-To: <51E64272.7080007@ripe.net> References: <20130716142113.GA29372@nic.fr> <51E64272.7080007@ripe.net> Message-ID: <20130717085649.GA26555@nic.fr> On Wed, Jul 17, 2013 at 09:06:26AM +0200, Andreas Strikos wrote a message of 29 lines which said: > Indeed if you want all probes you have to specify number bigger or > equal with what the measurement had. But not any number since the code unfortunately checks that I have enough credits, even if this parameter "requested" is not used :-( {'definitions': [{'protocol': 'UDP', 'target': '217.70.190.232', 'af': 4, 'type': 'traceroute', 'is_oneoff': True, 'description': 'Traceroute 217.70.190.232 from probes of measurement #1013422'}], 'probes': [{'requested': 100000, 'type': 'msm', 'value': '1013422'}]} RIPEAtlas.RequestSubmissionError: {"error": {"code": 104, "message": "You do not have enough credit to schedule this measurement."}} It works with a lower number: {'definitions': [{'protocol': 'UDP', 'target': '217.70.190.232', 'af': 4, 'type': 'traceroute', 'is_oneoff': True, 'description': 'Traceroute 217.70.190.232 from probes of measurement #1013422'}], 'probes': [{'requested': 1000, 'type': 'msm', 'value': '1013422'}]} Measurement #1013425 Traceroute 217.70.190.232 from probes of measurement #1013422 uses 5 probes 5 probes reported Test done at 2013-07-17T08:54:47Z From wilhelm at ripe.net Wed Jul 17 11:45:46 2013 From: wilhelm at ripe.net (Rene Wilhelm) Date: Wed, 17 Jul 2013 11:45:46 +0200 Subject: [atlas] Strange and undocumented (?) result in traceroute JSON output In-Reply-To: <20130717071732.GA17666@nic.fr> References: <20130717071732.GA17666@nic.fr> Message-ID: <51E667CA.9010706@ripe.net> On 7/17/13 9:17 AM, Stephane Bortzmeyer wrote: > Measurement #1013405 contains: > > "result": [ > { > "x": "*" > }, > { > "late": 20, > "ttl": 61, > "from": "88.79.15.141", > "size": 96 > }, > { > "x": "*" > }, > { > "x": "*" > } > > While "late" is documented > , the lack of > "rtt" field is not and crashes tools like json2traceroute.py. tools like json2traceroute.py which aim to reconstruct the routing vector should be aware of responses which arrive out of order; packets which are 'late' or show 'ittl' in the result require special attention because the 'from' address listed verly likely is from a router at a different hop. json2traceroute.py could simply ignore the 'strange' results by changing the lines ... else: rtt.append(hr["rtt"]) hopfrom = hr["from"] ... to ... elif (not "late" in hr) and (not "ittl" in hr): rtt.append(hr["rtt"]) hopfrom = hr["from"] ... -- Rene From alexsaroyan at gmail.com Thu Jul 18 08:29:38 2013 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Thu, 18 Jul 2013 10:29:38 +0400 Subject: [atlas] No probe shown in My Probes list (Registered. Plugged Probe v3 to network. 1st, 3rd, 4th LEDs lighted up.) In-Reply-To: References: Message-ID: <51E78B52.40709@gmail.com> Hi, Arthit, the switch does nothing with the current firmware, so doesn't matter on which position you keep the switch. Regards. /Alex On 07/07/2013 12:34 AM, Arthit Suriyawongkul wrote: > 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 > From alexsaroyan at gmail.com Thu Jul 18 08:53:21 2013 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Thu, 18 Jul 2013 10:53:21 +0400 Subject: [atlas] Spoofing the source IP address from a probe? In-Reply-To: <942E06E5-C9AE-4752-8902-4D8AF70CC2EA@ripe.net> References: <20130612145331.GA23909@nic.fr> <42BF63F0-6D87-40CC-ADCC-A9E76B227ED8@ripe.net> <20130612154420.GA79562@gweep.net> <942E06E5-C9AE-4752-8902-4D8AF70CC2EA@ripe.net> Message-ID: <51E790E1.6030507@gmail.com> Hi, I think some hosts would like theirs probes to be used for "source IP spoofing" check, and only such probes could be used for this particular type of check. If RIPE Atlas team implement such features then probably many hosts will "enable" "Source IP spoofing check ability" on theirs probes and that can serve for community at the end. Of course overall mechanism should be in a way not make anyone to suspect that probe can do spoofing by default or probe can do any harmful thing. Alex Saroyan On 06/12/2013 10:37 PM, Daniel Karrenberg wrote: > On 12.06.2013, at 17:44 , Joe Provo wrote: > >> I would encourage those in the community who wish to be >> performing individual spoof testing (or instruct others how >> to do so) to use the easy-peasey pointy-clicky CAIDA/CSAIL >> tool: http://spoofer.cmand.org/ >> (also spoofer.csail.mit.edu, spooftest.net, etc etc) > Seconded. Using this something like this is a conscious decision of the user. I have personally run Robert Beverley's probes regularly for many years and I am proud to say that both my broadband providers have never allowed source address spoofing. This involves a conscious decision on my part taking into account local network etiquette, my relation to my providers and the local legal situation. It is very very different from the RIPE community deciding to use RIPE Atlas to do this from my network. > > Daniel From arthit at gmail.com Sun Jul 21 20:13:38 2013 From: arthit at gmail.com (Arthit Suriyawongkul) Date: Mon, 22 Jul 2013 01:13:38 +0700 Subject: [atlas] No probe shown in My Probes list (Registered. Plugged Probe v3 to network. 1st, 3rd, 4th LEDs lighted up.) In-Reply-To: <51E78B52.40709@gmail.com> References: <51E78B52.40709@gmail.com> Message-ID: Thx. My experience is that, my probe will be connected for like an hour and then disconnected. Any clue? Does it possible that my ISP notice the probe and cut the connection? On Jul 18, 2013 1:30 PM, "Alex Saroyan" wrote: > Hi, > > Arthit, the switch does nothing with the current firmware, so doesn't > matter on which position you keep the switch. > > Regards. > /Alex > > > > On 07/07/2013 12:34 AM, Arthit Suriyawongkul wrote: > >> 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 >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Sun Jul 21 21:34:38 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 21 Jul 2013 21:34:38 +0200 Subject: [atlas] No address in the results when ping or traceroute fail? Message-ID: <20130721193438.GA30850@sources.org> 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 }, From vnaumov at ripe.net Mon Jul 22 08:50:37 2013 From: vnaumov at ripe.net (Viktor Naumov) Date: Mon, 22 Jul 2013 08:50:37 +0200 Subject: [atlas] No probe shown in My Probes list (Registered. Plugged Probe v3 to network. 1st, 3rd, 4th LEDs lighted up.) In-Reply-To: References: <51E78B52.40709@gmail.com> Message-ID: <51ECD63D.6070002@ripe.net> Hi Arthit, I See you were connecting. I do not think your ISP is blocking that. You can actually check it yourself by executing. telnet tealc.atlas.ripe.net 443 If it succeeds then your have non-network related problem. Most probably it can be because of weak power supply. Some routers cannot deliver enough power through USD to feed probes. Try to get external usb power supply. WBR /vty On 7/21/13 8:13 PM, Arthit Suriyawongkul wrote: > > Thx. > My experience is that, my probe will be connected for like an hour and > then disconnected. > Any clue? > Does it possible that my ISP notice the probe and cut the connection? > > On Jul 18, 2013 1:30 PM, "Alex Saroyan" > wrote: > > Hi, > > Arthit, the switch does nothing with the current firmware, so > doesn't matter on which position you keep the switch. > > Regards. > /Alex > > > > On 07/07/2013 12:34 AM, Arthit Suriyawongkul wrote: > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Mon Jul 22 11:43:39 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 22 Jul 2013 11:43:39 +0200 Subject: [atlas] No address in the results when ping or traceroute fail? In-Reply-To: <20130721193438.GA30850@sources.org> References: <20130721193438.GA30850@sources.org> Message-ID: <51ECFECB.2020204@ripe.net> Hi Stephane, On 2013/07/21 21:34 , Stephane Bortzmeyer wrote: > 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: > > The most likely cause for this is that the probe has no IPv6 default router. The from field is filled with the address that is used to connect to the controller. If a probe doesn't have IPv6 connectivity then that is address is unknown. The src_addr is not there because of the way the linux kernel works. Most measurements use the bind system call to find out which local address will be used for outgoing packets. But if there is not route to the destination then bind will fail. Probes also report their network configuration but at the moment that is done in a format that is not easy to parse. The next firmware should fix that. Then we can see how to make that information available. Philip From bortzmeyer at nic.fr Mon Jul 22 16:20:11 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 22 Jul 2013 16:20:11 +0200 Subject: [atlas] No address in the results when ping or traceroute fail? In-Reply-To: <51ECFECB.2020204@ripe.net> References: <20130721193438.GA30850@sources.org> <51ECFECB.2020204@ripe.net> Message-ID: <20130722142011.GA15831@nic.fr> On Mon, Jul 22, 2013 at 11:43:39AM +0200, Philip Homburg wrote a message of 25 lines which said: > The most likely cause for this is that the probe has no IPv6 default > router. Well, IMHO, probes without a router should not be eligible for IPv6 measurements. > Probes also report their network configuration but at the moment > that is done in a format that is not easy to parse. The next > firmware should fix that. Then we can see how to make that > information available. It would not solve the problem since the probe may renumber between the moment you fetch the (semi-static) info and the measurement. And it is even worse for probes with multiple addresses. We really need to know the adress actually used during the measurement. From philip.homburg at ripe.net Mon Jul 22 16:29:52 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 22 Jul 2013 16:29:52 +0200 Subject: [atlas] No address in the results when ping or traceroute fail? In-Reply-To: <20130722142011.GA15831@nic.fr> References: <20130721193438.GA30850@sources.org> <51ECFECB.2020204@ripe.net> <20130722142011.GA15831@nic.fr> Message-ID: <51ED41E0.50701@ripe.net> On 2013/07/22 16:20 , Stephane Bortzmeyer wrote: > On Mon, Jul 22, 2013 at 11:43:39AM +0200, > Philip Homburg wrote > a message of 25 lines which said: > >> The most likely cause for this is that the probe has no IPv6 default >> router. > Well, IMHO, probes without a router should not be eligible for IPv6 > measurements. Yes, but that will be some future change to the system >> Probes also report their network configuration but at the moment >> that is done in a format that is not easy to parse. The next >> firmware should fix that. Then we can see how to make that >> information available. > It would not solve the problem since the probe may renumber between > the moment you fetch the (semi-static) info and the measurement. And > it is even worse for probes with multiple addresses. We really need to > know the adress actually used during the measurement. > That is easy. The probe didn't actually send any packets so there is no point in knowing the source address that wasn't used. :-) Philip From bortzmeyer at nic.fr Mon Jul 22 16:39:36 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 22 Jul 2013 16:39:36 +0200 Subject: [atlas] No address in the results when ping or traceroute fail? In-Reply-To: <51ED41E0.50701@ripe.net> References: <20130721193438.GA30850@sources.org> <51ECFECB.2020204@ripe.net> <20130722142011.GA15831@nic.fr> <51ED41E0.50701@ripe.net> Message-ID: <20130722143936.GA17566@nic.fr> On Mon, Jul 22, 2013 at 04:29:52PM +0200, Philip Homburg wrote a message of 23 lines which said: > The probe didn't actually send any packets so there is no point in > knowing the source address that wasn't used. :-) I wanted to reply to Dan Wing's criticism "I have a suspicion that many of these failures are IPv6 tunnels that have suffered bit rot. Could you analyze the IPv6 address that the Atlas probe thinks it has and split them into two categories: (a) known tunnels (e.g., Hurricane Electric, SixXS, 6to4, Teredo) versus (b) presumably "native" IPv6 addresses. " From philip.homburg at ripe.net Tue Jul 23 10:55:54 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 23 Jul 2013 10:55:54 +0200 Subject: [atlas] No address in the results when ping or traceroute fail? In-Reply-To: <20130722143936.GA17566@nic.fr> References: <20130721193438.GA30850@sources.org> <51ECFECB.2020204@ripe.net> <20130722142011.GA15831@nic.fr> <51ED41E0.50701@ripe.net> <20130722143936.GA17566@nic.fr> Message-ID: <51EE451A.50700@ripe.net> On 2013/07/22 16:39 , Stephane Bortzmeyer wrote: > On Mon, Jul 22, 2013 at 04:29:52PM +0200, > Philip Homburg wrote > a message of 23 lines which said: > >> The probe didn't actually send any packets so there is no point in >> knowing the source address that wasn't used. :-) > I wanted to reply to Dan Wing's criticism > > "I have a suspicion that many of these failures are IPv6 tunnels that > have suffered bit rot. Could you analyze the IPv6 address that the > Atlas probe thinks it has and split them into two categories: (a) > known tunnels (e.g., Hurricane Electric, SixXS, 6to4, Teredo) versus > (b) presumably "native" IPv6 addresses. " > Stephane, Well, if you can give me a list of probes for which you don't have the IPv6 address then I can look them up for you. Philip From klaus.darilion at nic.at Tue Jul 23 11:12:21 2013 From: klaus.darilion at nic.at (Klaus Darilion) Date: Tue, 23 Jul 2013 11:12:21 +0200 Subject: [atlas] No address in the results when ping or traceroute fail? In-Reply-To: <20130722143936.GA17566@nic.fr> References: <20130721193438.GA30850@sources.org> <51ECFECB.2020204@ripe.net> <20130722142011.GA15831@nic.fr> <51ED41E0.50701@ripe.net> <20130722143936.GA17566@nic.fr> Message-ID: <51EE48F5.6030301@nic.at> On 22.07.2013 16:39, Stephane Bortzmeyer wrote: > On Mon, Jul 22, 2013 at 04:29:52PM +0200, > Philip Homburg wrote > a message of 23 lines which said: > >> The probe didn't actually send any packets so there is no point in >> knowing the source address that wasn't used. :-) > I wanted to reply to Dan Wing's criticism > > "I have a suspicion that many of these failures are IPv6 tunnels that > have suffered bit rot. Could you analyze the IPv6 address that the > Atlas probe thinks it has and split them into two categories: (a) > known tunnels (e.g., Hurricane Electric, SixXS, 6to4, Teredo) versus > (b) presumably "native" IPv6 addresses. " Yes, this is annoying. Many probes have IPv6 tunnels. Probably they show the "real world" view of IPv6, but often I am interested in native IPv6. When selecting probes manually I only use probes that are located in the same AS for IPv4 and IPv6. regards Klaus From albyva at empire.org Tue Jul 23 16:11:46 2013 From: albyva at empire.org (AlbyVA) Date: Tue, 23 Jul 2013 10:11:46 -0400 Subject: [atlas] Ping Fails (ns.ripe.net) Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RipePingWorking.png Type: image/png Size: 45558 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RipePingFailing.png Type: image/png Size: 38029 bytes Desc: not available URL: From robert at ripe.net Tue Jul 23 16:21:08 2013 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 23 Jul 2013 16:21:08 +0200 Subject: [atlas] Ping Fails (ns.ripe.net) In-Reply-To: References: Message-ID: <51EE9154.4000104@ripe.net> Hello, This measurement has been discontinued since 2013-07-04, since the machine (and the name) is no longer operational. This message should also show up on the "built-in measurements" section on your probe status page. Regards, Robert On 2013.07.23. 16:11, AlbyVA wrote: > > > > 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 > > > From bortzmeyer at nic.fr Tue Jul 23 16:22:29 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 23 Jul 2013 16:22:29 +0200 Subject: [atlas] Ping Fails (ns.ripe.net) In-Reply-To: References: Message-ID: <20130723142229.GA13165@nic.fr> On Tue, Jul 23, 2013 at 10:11:46AM -0400, AlbyVA wrote a message of 1511 lines which said: > 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. IPv4 or IPv6 ? May be a wrong ACL in a firewall somewhere? traceroute from the probe may help. I tested with IPv4 on 664 probes and the success rate is 99.4 % which seems to indicate that the problem is on your side. From bortzmeyer at nic.fr Tue Jul 23 16:26:42 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 23 Jul 2013 16:26:42 +0200 Subject: [atlas] Ping Fails (ns.ripe.net) In-Reply-To: <51EE9154.4000104@ripe.net> References: <51EE9154.4000104@ripe.net> Message-ID: <20130723142642.GA13455@nic.fr> On Tue, Jul 23, 2013 at 04:21:08PM +0200, Robert Kisteleki wrote a message of 27 lines which said: > the machine (and the name) is no longer operational. But something still replies: % ping -c3 ns.ripe.net PING ns.ripe.net (193.0.9.6) 56(84) bytes of data. 64 bytes from ns.ripe.net (193.0.9.6): icmp_seq=1 ttl=51 time=45.5 ms 64 bytes from ns.ripe.net (193.0.9.6): icmp_seq=2 ttl=51 time=42.8 ms 64 bytes from ns.ripe.net (193.0.9.6): icmp_seq=3 ttl=51 time=42.1 ms --- ns.ripe.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 42.198/43.541/45.538/1.439 ms % ping6 -c3 ns.ripe.net PING ns.ripe.net(ns.ripe.net) 56 data bytes 64 bytes from ns.ripe.net: icmp_seq=1 ttl=57 time=46.5 ms 64 bytes from ns.ripe.net: icmp_seq=2 ttl=57 time=42.7 ms 64 bytes from ns.ripe.net: icmp_seq=3 ttl=57 time=44.6 ms --- ns.ripe.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 42.793/44.654/46.553/1.535 ms From albyva at empire.org Tue Jul 23 16:36:49 2013 From: albyva at empire.org (AlbyVA) Date: Tue, 23 Jul 2013 10:36:49 -0400 Subject: [atlas] Ping Fails (ns.ripe.net) In-Reply-To: <51EE9154.4000104@ripe.net> References: <51EE9154.4000104@ripe.net> Message-ID: Okay. I do see the discontinued note, thanks. I assume just the reporting of pings is no longer being displayed, since a command line ping appears to still work. -Alby On Tue, Jul 23, 2013 at 10:21 AM, Robert Kisteleki wrote: > Hello, > > This measurement has been discontinued since 2013-07-04, since the machine > (and the name) is no longer operational. This message should also show up > on > the "built-in measurements" section on your probe status page. > > Regards, > Robert > > > On 2013.07.23. 16:11, AlbyVA wrote: > > > > > > > > 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 > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Tue Jul 23 17:26:12 2013 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 23 Jul 2013 17:26:12 +0200 Subject: [atlas] Ping Fails (ns.ripe.net) In-Reply-To: References: <51EE9154.4000104@ripe.net> Message-ID: <51EEA094.9090107@ripe.net> On 2013.07.23. 16:36, AlbyVA wrote: > > > Okay. I do see the discontinued note, thanks. I assume just the reporting > of pings > is no longer being displayed, since a command line ping appears to still work. > > -Alby Yes, I should have been a bit more precise. The name (and the service it provides) still exists, but it changed IPs and deployment model (unicast->anycast), so it was better to stop this "built-in" measurement. Regards, Robert From antony at ripe.net Tue Jul 23 17:26:23 2013 From: antony at ripe.net (Antony Antony) Date: Tue, 23 Jul 2013 17:26:23 +0200 Subject: [atlas] Ping Fails (ns.ripe.net) In-Reply-To: <20130723142642.GA13455@nic.fr> References: <51EE9154.4000104@ripe.net> <20130723142642.GA13455@nic.fr> Message-ID: <20130723152623.GA13943@puppy.ripe.net> the probes were pining it using the old ip address 193.0.0.193 which is stopped now. -antony On Tue, Jul 23, 2013 at 04:26:42PM +0200, Stephane Bortzmeyer wrote: > On Tue, Jul 23, 2013 at 04:21:08PM +0200, > Robert Kisteleki wrote > a message of 27 lines which said: > > > the machine (and the name) is no longer operational. > > But something still replies: > > % ping -c3 ns.ripe.net > PING ns.ripe.net (193.0.9.6) 56(84) bytes of data. > 64 bytes from ns.ripe.net (193.0.9.6): icmp_seq=1 ttl=51 time=45.5 ms > 64 bytes from ns.ripe.net (193.0.9.6): icmp_seq=2 ttl=51 time=42.8 ms > 64 bytes from ns.ripe.net (193.0.9.6): icmp_seq=3 ttl=51 time=42.1 ms > > --- ns.ripe.net ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2003ms > rtt min/avg/max/mdev = 42.198/43.541/45.538/1.439 ms > > % ping6 -c3 ns.ripe.net > PING ns.ripe.net(ns.ripe.net) 56 data bytes > 64 bytes from ns.ripe.net: icmp_seq=1 ttl=57 time=46.5 ms > 64 bytes from ns.ripe.net: icmp_seq=2 ttl=57 time=42.7 ms > 64 bytes from ns.ripe.net: icmp_seq=3 ttl=57 time=44.6 ms > > --- ns.ripe.net ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2003ms > rtt min/avg/max/mdev = 42.793/44.654/46.553/1.535 ms > > From fred_grayson at yahoo.com Sat Jul 27 20:53:41 2013 From: fred_grayson at yahoo.com (Fred Grayson) Date: Sat, 27 Jul 2013 14:53:41 -0400 Subject: [atlas] Outdated for more than one day? Message-ID: <51F41735.7080204@yahoo.com> 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 From fred_grayson at yahoo.com Sun Jul 28 17:19:55 2013 From: fred_grayson at yahoo.com (Fred Grayson) Date: Sun, 28 Jul 2013 11:19:55 -0400 Subject: [atlas] Outdated for more than one day? In-Reply-To: References: <51F41735.7080204@yahoo.com> Message-ID: <51F5369B.2060408@yahoo.com> 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 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 >> > > > From robachevsky at isoc.org Mon Jul 29 17:28:37 2013 From: robachevsky at isoc.org (Andrei Robachevsky) Date: Mon, 29 Jul 2013 17:28:37 +0200 Subject: [atlas] Spoofing the source IP address from a probe? In-Reply-To: <51E790E1.6030507@gmail.com> References: <20130612145331.GA23909@nic.fr> <42BF63F0-6D87-40CC-ADCC-A9E76B227ED8@ripe.net> <20130612154420.GA79562@gweep.net> <942E06E5-C9AE-4752-8902-4D8AF70CC2EA@ripe.net> <51E790E1.6030507@gmail.com> Message-ID: <51F68A25.7000005@isoc.org> Alex Saroyan wrote on 7/18/13 8:53 AM: > Hi, > > I think some hosts would like theirs probes to be used for "source IP > spoofing" check, and only such probes could be used for this particular > type of check. > If RIPE Atlas team implement such features then probably many hosts will > "enable" "Source IP spoofing check ability" on theirs probes and that > can serve for community at the end. 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. I understand that a certain percentage of probes is sitting behind NAT where spoofing won't work in most cases, but there is hopefully a significant number of probes that are connected directly. Regarding the problem itself we are tackling here, we published a follow up to the panel we held at RIPE66: http://www.internetsociety.org/doc/anti-spoofing-continuing-dialogue. Hope this helps raising awareness of the issue further. > Of course overall mechanism should be in a way not make anyone to > suspect that probe can do spoofing by default or probe can do any > harmful thing. > Agree, Andrei > Alex Saroyan > > On 06/12/2013 10:37 PM, Daniel Karrenberg wrote: >> On 12.06.2013, at 17:44 , Joe Provo wrote: >> >>> I would encourage those in the community who wish to be >>> performing individual spoof testing (or instruct others how >>> to do so) to use the easy-peasey pointy-clicky CAIDA/CSAIL >>> tool: http://spoofer.cmand.org/ >>> (also spoofer.csail.mit.edu, spooftest.net, etc etc) >> Seconded. Using this something like this is a conscious decision of >> the user. I have personally run Robert Beverley's probes regularly for >> many years and I am proud to say that both my broadband providers have >> never allowed source address spoofing. This involves a conscious >> decision on my part taking into account local network etiquette, my >> relation to my providers and the local legal situation. It is very >> very different from the RIPE community deciding to use RIPE Atlas to >> do this from my network. >> >> Daniel > > From randy at psg.com Tue Jul 30 05:22:40 2013 From: randy at psg.com (Randy Bush) Date: Tue, 30 Jul 2013 05:22:40 +0200 Subject: [atlas] Spoofing the source IP address from a probe? In-Reply-To: <51F68A25.7000005@isoc.org> References: <20130612145331.GA23909@nic.fr> <42BF63F0-6D87-40CC-ADCC-A9E76B227ED8@ripe.net> <20130612154420.GA79562@gweep.net> <942E06E5-C9AE-4752-8902-4D8AF70CC2EA@ripe.net> <51E790E1.6030507@gmail.com> <51F68A25.7000005@isoc.org> Message-ID: > 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? randy From ghane0 at gmail.com Tue Jul 30 08:11:18 2013 From: ghane0 at gmail.com (Sanjeev Gupta) Date: Tue, 30 Jul 2013 14:11:18 +0800 Subject: [atlas] Spoofing the source IP address from a probe? In-Reply-To: References: <20130612145331.GA23909@nic.fr> <42BF63F0-6D87-40CC-ADCC-A9E76B227ED8@ripe.net> <20130612154420.GA79562@gweep.net> <942E06E5-C9AE-4752-8902-4D8AF70CC2EA@ripe.net> <51E790E1.6030507@gmail.com> <51F68A25.7000005@isoc.org> Message-ID: On Tue, Jul 30, 2013 at 11:22 AM, Randy Bush 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexsaroyan at gmail.com Tue Jul 30 08:34:13 2013 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Tue, 30 Jul 2013 10:34:13 +0400 Subject: [atlas] Spoofing the source IP address from a probe? Message-ID: 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 wrote: >On Tue, Jul 30, 2013 at 11:22 AM, Randy Bush 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robachevsky at isoc.org Tue Jul 30 09:36:01 2013 From: robachevsky at isoc.org (Andrei Robachevsky) Date: Tue, 30 Jul 2013 09:36:01 +0200 Subject: [atlas] Spoofing the source IP address from a probe? In-Reply-To: References: <20130612145331.GA23909@nic.fr> <42BF63F0-6D87-40CC-ADCC-A9E76B227ED8@ripe.net> <20130612154420.GA79562@gweep.net> <942E06E5-C9AE-4752-8902-4D8AF70CC2EA@ripe.net> <51E790E1.6030507@gmail.com> <51F68A25.7000005@isoc.org> Message-ID: <51F76CE1.9070406@isoc.org> Randy Bush wrote on 7/30/13 5:22 AM: >> 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? > I assume it will be also done with the consent of the address holder whose addresses are used for spoofing (e.g. from the RIPE NCC own address block). And spoofing violations will happen extremely rarely, a few packets per week, just to put this into perspective. Andrei From robert at ripe.net Tue Jul 30 12:19:42 2013 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 30 Jul 2013 12:19:42 +0200 Subject: [atlas] RIPE Atlas maintenance on Tuesday, 6 August Message-ID: <51F7933E.3070903@ripe.net> 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 From bortzmeyer at nic.fr Tue Jul 30 15:57:12 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 30 Jul 2013 15:57:12 +0200 Subject: [atlas] Outdated documentation to delete Message-ID: <20130730135712.GA24070@nic.fr> IMHO, the "mechanize" example in is useless now that we have an API and should be deleted. From bortzmeyer at nic.fr Tue Jul 30 23:20:29 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 30 Jul 2013 23:20:29 +0200 Subject: [atlas] HTTP or not HTTP? Message-ID: <20130730212029.GA27334@sources.org> 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? From robert at ripe.net Wed Jul 31 09:16:29 2013 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 31 Jul 2013 09:16:29 +0200 Subject: [atlas] HTTP or not HTTP? In-Reply-To: <20130730212029.GA27334@sources.org> References: <20130730212029.GA27334@sources.org> Message-ID: <51F8B9CD.7040005@ripe.net> On 2013.07.30. 23:20, Stephane Bortzmeyer wrote: > 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? Hello, Technically Atlas can do HTTP measurements. However, we have not publicly enabled this, because HTTP measurements using remote probes can have unintended consequences for the host of those probes. We plan to initiate a policy discussion about this topic, in order to get guidance from the community. Stay tuned! Note that this topic came up before: http://www.ripe.net/ripe/mail/archives/ripe-atlas/2012-August/000552.html Regards, Robert Kisteleki From bortzmeyer at nic.fr Wed Jul 31 09:24:01 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 31 Jul 2013 09:24:01 +0200 Subject: [atlas] HTTP or not HTTP? In-Reply-To: <51F8B9CD.7040005@ripe.net> References: <20130730212029.GA27334@sources.org> <51F8B9CD.7040005@ripe.net> Message-ID: <20130731072401.GA16267@nic.fr> On Wed, Jul 31, 2013 at 09:16:29AM +0200, Robert Kisteleki wrote a message of 31 lines which said: > Technically Atlas can do HTTP measurements. However, we have not > publicly enabled this, because HTTP measurements using remote probes > can have unintended consequences for the host of those probes. OK, but, IMHO, the documentation should be modified (by deleting the section or by writing IN BOLD that it is not currently enabled) because it is confusing. From robert at ripe.net Wed Jul 31 09:28:43 2013 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 31 Jul 2013 09:28:43 +0200 Subject: [atlas] HTTP or not HTTP? In-Reply-To: <20130731072401.GA16267@nic.fr> References: <20130730212029.GA27334@sources.org> <51F8B9CD.7040005@ripe.net> <20130731072401.GA16267@nic.fr> Message-ID: <51F8BCAB.706@ripe.net> On 2013.07.31. 9:24, Stephane Bortzmeyer wrote: > On Wed, Jul 31, 2013 at 09:16:29AM +0200, > Robert Kisteleki wrote > a message of 31 lines which said: > >> Technically Atlas can do HTTP measurements. However, we have not >> publicly enabled this, because HTTP measurements using remote probes >> can have unintended consequences for the host of those probes. > > OK, but, IMHO, the documentation > should be modified (by > deleting the section or by writing IN BOLD that it is not currently > enabled) because it is confusing. Good point, we'll fix that. Robert From chelliot at pobox.com Wed Jul 31 15:39:39 2013 From: chelliot at pobox.com (Chris Elliott) Date: Wed, 31 Jul 2013 15:39:39 +0200 Subject: [atlas] Registering a new probe... Message-ID: 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 * Map data ?2013 MapLink - Terms of Use 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 * Thanks for looking into this issue. Chris. -- Chris Elliott chelliot at pobox.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dquinn at ripe.net Wed Jul 31 15:52:35 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Wed, 31 Jul 2013 15:52:35 +0200 Subject: [atlas] Registering a new probe... In-Reply-To: References: Message-ID: <51F916A3.6000105@ripe.net> You've selected "My network supports IPv4" and have not supplied a prefix, hence the complaint on the following line in red: "Please enter a valid prefix". If you don't have a prefix to enter, or don't know what it is, it's best to leave the "My network supports IPv4" box un-checked, at which point your application will go through. I'll see what I can do to make this more intuitive, but I thought that having the error message there should be enough. From chelliot at pobox.com Wed Jul 31 15:53:58 2013 From: chelliot at pobox.com (Chris Elliott) Date: Wed, 31 Jul 2013 15:53:58 +0200 Subject: [atlas] Registering a new probe... In-Reply-To: References: Message-ID: Jim pointed out that I was an idiot and couldn't see the red text pointing to the problem... On Wed, Jul 31, 2013 at 3:39 PM, Chris Elliott wrote: > 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 * > > > Map data ?2013 MapLink - Terms of Use > 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 > * > > > > Thanks for looking into this issue. > > Chris. > > > -- > Chris Elliott > chelliot at pobox.com > -- Chris Elliott chelliot at pobox.com -------------- next part -------------- An HTML attachment was scrubbed... URL: