From ml at bartschnet.de Wed Oct 1 08:33:05 2014 From: ml at bartschnet.de (Rene Bartsch) Date: Wed, 01 Oct 2014 08:33:05 +0200 Subject: [atlas] Wrong uptime information in monthly report Message-ID: Hi, I got the following report of a drone: -------------------------------------------------------------------------------------------------------------- This is your monthly availability report for probe 3146 (T-Online Call & Surf Comfort IP Speed 50/10 MBit/s ). Calculation interval : 2014-09-01 00:00:00 - 2014-10-01 00:00:00 Total Connected Time : 15d 16:46 Total Disconnected Time : 14d 07:13 Total Availability : 52.33% +---------------------+---------------------+------------+--------------+ | Connected (UTC) | Disconnected (UTC) | Connected | Disconnected | |---------------------+---------------------+------------+--------------+ | 2014-08-14 11:37:26 | 2014-09-02 02:22:27 | 1d 02:22 | 0d 00:00 | | 2014-09-02 02:36:21 | 2014-09-04 23:40:28 | 2d 21:04 | 0d 00:13 | | 2014-09-05 00:03:58 | 2014-09-16 17:23:55 | 11d 17:19 | 0d 00:23 | +---------------------+---------------------+------------+--------------+ ---------------------------------------------------------------------------------------------------------------- https://atlas.ripe.net/probes/3146/#!tab-network shows an uptime of 99.83%. Please fix this! -- Best regards, Renne From vnaumov at ripe.net Wed Oct 1 09:38:50 2014 From: vnaumov at ripe.net (Viktor Naumov) Date: Wed, 01 Oct 2014 09:38:50 +0200 Subject: [atlas] Wrong uptime information in monthly report In-Reply-To: References: Message-ID: <542BAF8A.6030606@ripe.net> Hi Rene, Indeed it may seem wrong without the last connection event 2014-09-16 17:32:20 14d 8h 0m 2014-10-01 01:32:47 0h 10m See: https://atlas.ripe.net/probes/3146/#!tab-network But your probe was unhappy to disconnect just at the time the report was generated, so it didn't take into account that last event. We working on improving it. Thanks! /vty On 10/1/14, 8:33 AM, Rene Bartsch wrote: > Hi, > > I got the following report of a drone: > > -------------------------------------------------------------------------------------------------------------- > > This is your monthly availability report for probe 3146 (T-Online Call > & Surf Comfort IP Speed 50/10 MBit/s ). > > Calculation interval : 2014-09-01 00:00:00 - 2014-10-01 00:00:00 > Total Connected Time : 15d 16:46 > Total Disconnected Time : 14d 07:13 > Total Availability : 52.33% > > +---------------------+---------------------+------------+--------------+ > | Connected (UTC) | Disconnected (UTC) | Connected | Disconnected | > |---------------------+---------------------+------------+--------------+ > | 2014-08-14 11:37:26 | 2014-09-02 02:22:27 | 1d 02:22 | 0d 00:00 | > | 2014-09-02 02:36:21 | 2014-09-04 23:40:28 | 2d 21:04 | 0d 00:13 | > | 2014-09-05 00:03:58 | 2014-09-16 17:23:55 | 11d 17:19 | 0d 00:23 | > +---------------------+---------------------+------------+--------------+ > > ---------------------------------------------------------------------------------------------------------------- > > > > https://atlas.ripe.net/probes/3146/#!tab-network shows an uptime of > 99.83%. Please fix this! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiri.prochazka at superhosting.cz Wed Oct 1 12:00:40 2014 From: jiri.prochazka at superhosting.cz (jiri.prochazka at superhosting.cz) Date: Wed, 01 Oct 2014 12:00:40 +0200 Subject: [atlas] out of office Message-ID: <8ed4279fc71c83ea4947546cd76f349a-1161912340@mail.superhosting.cz> Dear sender, I am currently out of office returning October 6th. I have limited access to my email, in urgent case you can reach me on my mobile phone + 420 777 87 37 67. Regards, -- Jiri Prochazka network administrator (AS39392) SuperNetwork s.r.o. m: +420 777 87 37 67 w: http://www.superhosting.cz e: jiri.prochazka at superhosting.cz From robert at ripe.net Fri Oct 3 10:08:59 2014 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 03 Oct 2014 10:08:59 +0200 Subject: [atlas] RIPE Atlas vs. bash/shellshock vulnerability Message-ID: <542E599B.5010702@ripe.net> Dear RIPE Atlas users, The RIPE NCC made a public announcement earlier about this issue (see https://www.ripe.net/internet-coordination/news/announcements/ripe-ncc-security-report-on-shellshock-bash-shell-bug). Still, since we have received some questions in email and Twitter about RIPE Atlas vs. this vulnerability so we'd like to respond to these with some more detail. The RIPE Atlas v1-v2-v3 probes are/were not affected by this issue at all since they don't run bash (or even have it installed) and also not providing any accessible services. The anchors have bash installed, but it is not used for any of the services provided. Besides, these servers have been patched right away. The infrastructure components (ie. controllers) were affected and as the RIPE NCC announcement explains, they have been patched as soon as the patch came out; basically within the day. Regards, Robert Kisteleki for the Atlas team From colinj at mx5.org.uk Fri Oct 3 10:17:49 2014 From: colinj at mx5.org.uk (Colin Johnston) Date: Fri, 3 Oct 2014 09:17:49 +0100 Subject: [atlas] RIPE Atlas vs. bash/shellshock vulnerability In-Reply-To: <542E599B.5010702@ripe.net> References: <542E599B.5010702@ripe.net> Message-ID: has bash 4.3 upto patch v29 been applied ? Folks will need to keep ontop of bash bug exploits for a while I guess Colin > On 3 Oct 2014, at 09:08, Robert Kisteleki wrote: > > Dear RIPE Atlas users, > > The RIPE NCC made a public announcement earlier about this issue (see > https://www.ripe.net/internet-coordination/news/announcements/ripe-ncc-security-report-on-shellshock-bash-shell-bug). > > Still, since we have received some questions in email and Twitter about RIPE > Atlas vs. this vulnerability so we'd like to respond to these with some more > detail. > > The RIPE Atlas v1-v2-v3 probes are/were not affected by this issue at all > since they don't run bash (or even have it installed) and also not providing > any accessible services. The anchors have bash installed, but it is not used > for any of the services provided. Besides, these servers have been patched > right away. > > The infrastructure components (ie. controllers) were affected and as the > RIPE NCC announcement explains, they have been patched as soon as the patch > came out; basically within the day. > > Regards, > Robert Kisteleki > for the Atlas team > From randy at psg.com Fri Oct 3 21:26:57 2014 From: randy at psg.com (Randy Bush) Date: Sat, 04 Oct 2014 04:26:57 +0900 Subject: [atlas] RIPE Atlas vs. bash/shellshock vulnerability In-Reply-To: <542E599B.5010702@ripe.net> References: <542E599B.5010702@ripe.net> Message-ID: > The infrastructure components (ie. controllers) were affected and as > the RIPE NCC announcement explains, they have been patched as soon as > the patch came out; basically within the day. patch is not singular. #shellshock is the gift that keeps giving. four times so far, 30+ systems. it's sysadmin sympathy week. please extend mine to brian and the elves. randy From colinj at mx5.org.uk Fri Oct 3 21:33:46 2014 From: colinj at mx5.org.uk (Colin Johnston) Date: Fri, 3 Oct 2014 20:33:46 +0100 Subject: [atlas] RIPE Atlas vs. bash/shellshock vulnerability In-Reply-To: References: <542E599B.5010702@ripe.net> Message-ID: potentially 6 times if not more in coming weeks http://lists.gnu.org/archive/html/bug-bash/2014-10/msg00031.html Colin > On 3 Oct 2014, at 20:26, Randy Bush wrote: > >> The infrastructure components (ie. controllers) were affected and as >> the RIPE NCC announcement explains, they have been patched as soon as >> the patch came out; basically within the day. > > patch is not singular. #shellshock is the gift that keeps giving. four > times so far, 30+ systems. it's sysadmin sympathy week. please extend > mine to brian and the elves. > > randy > From mgalante at ripe.net Tue Oct 7 12:35:46 2014 From: mgalante at ripe.net (Michela Galante) Date: Tue, 7 Oct 2014 12:35:46 +0200 Subject: [atlas] Comcast (US) has joined RIPE Atlas anchors Message-ID: <0CD6075A-10AA-4443-A674-761597DF3C2E@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called us-den-as7922 and it is hosted by Comcast in Denver, United States. Congratulations to Comcast for their second anchor online! Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From mgalante at ripe.net Wed Oct 8 10:26:21 2014 From: mgalante at ripe.net (Michela Galante) Date: Wed, 8 Oct 2014 10:26:21 +0200 Subject: [atlas] teamix (DE) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called de-nue-as33988 and it is hosted by teamix GmbH in Nuremberg, Germany. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From robert at vojcik.net Fri Oct 10 14:01:22 2014 From: robert at vojcik.net (Robert Vojcik) Date: Fri, 10 Oct 2014 14:01:22 +0200 Subject: [atlas] Http Measurements Message-ID: <5437CA92.5030900@vojcik.net> Hi, I'm preparing some measurements for our project because we plan to migrate one big site from CDN. I saw in documentation that Atlas support HTTP measurements but not for all users by default. How can I request this feature ? We will have ping and traceroute measurements but HTTP reponses would be great to compare what impact migration will have. Thank you for help -- Robert From bortzmeyer at nic.fr Fri Oct 10 14:52:54 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 10 Oct 2014 14:52:54 +0200 Subject: [atlas] Http Measurements In-Reply-To: <5437CA92.5030900@vojcik.net> References: <5437CA92.5030900@vojcik.net> Message-ID: <20141010125254.GA6111@nic.fr> On Fri, Oct 10, 2014 at 02:01:22PM +0200, Robert Vojcik wrote a message of 15 lines which said: > I saw in documentation that Atlas support HTTP measurements but not for > all users by default. As far as I know, HTTP measurements are off for users because of the risk of using Atlas for dDoS (a single request can trigger a lot of work on the server, unlike ICMP echo requests) and the legal/political risk for the probe hosters if some user wants to test and the hoster happens to live in Saudi Arabia. > How can I request this feature ? I believe you have to ask directly the RIPE NCC . From james at jump.net.uk Thu Oct 16 19:04:44 2014 From: james at jump.net.uk (James A. T. Rice) Date: Thu, 16 Oct 2014 18:04:44 +0100 Subject: [atlas] RIPE atlas probe network configuration Message-ID: <9BCC0C31-40A4-4C0B-A519-0464570EE125@jump.net.uk> Hi RIPE, We've just obtained our final /22 of IPv4 PA space, and we're looking at doing things a little differently with regards to trying to maximise the efficiency of usage within that block. While 100% utilisation of IP addresses by customers is not difficult in e.g. broadband networks (with a /32 being routed over a point to point link to each user), it is difficult in ethernet networks (with 2^n size subnets, network and broadcast and router addresses). Essentially we're going to try to have each customer device (for this purpose, the RIPE atlas probe is a customer device) consume exactly the number of globally unique IP addresses that it needs. Because for isolation each customer gets their own VLAN, and because "ethernet" traditionally means subnets with 2^n size and network and broadcast addresses and physical router addresses and VRRP addresses needing to be on that subnet, we end up with a subnet of 8 IP addresses used for a customer device that only will have 1 IP address exposed to the outside world: globally unique range: 0 - network 1 - default gateway vrrp 2 - router-a physical 3 - router-b physical 4 - customer device .. .. 7 - broadcast What I'd like to do, in order to only consume 1 globally unique IP address for the whole setup is as follows: private range, e.g. 10.a.b.c/24 0 - network 1 - default gateway vrrp 2 - router-a physical 3 - router-b physical 4 - customer device .. .. 255 - broadcast with a single globally unique IPv4 /32 (let's say) p.q.r.s routed to 10.a.b.4 in the above example. This means that you'd need to configure on your device, something like (assuming linux): network: 10.a.b.0/24 gateway: 10.a.b.1 alias: p.q.r.s/32 with it configured that p.q.r.s is the default source IP address to use for any outbound packets. This is a relatively 'clean' way of doing things, as it doesn't involve proxy-arp or similar trickery. It should be possible to do this for linux based systems. What do you think? Will the atlas probe support it, or would you consider making that a feature? Thanks James Rice Jump Networks Ltd. From rdekema at gmail.com Mon Oct 20 03:49:39 2014 From: rdekema at gmail.com (Rusty Dekema) Date: Sun, 19 Oct 2014 21:49:39 -0400 Subject: [atlas] Fwd: Your RIPE Atlas Probe (ID: 11513) is now connected to our network In-Reply-To: <20141020014004.14946.27585@janus.atlas.ripe.net> References: <20141020014004.14946.27585@janus.atlas.ripe.net> Message-ID: Good evening, In case you track these sorts of things, the ~2 week disconnection of this probe was caused by network trouble on my end (combined with an extended vacation), and not by the probe itself or any other part of the RIPE Atlas system. Cheers, Rusty Dekema ---------- Forwarded message ---------- From: RIPE Atlas Date: Sun, Oct 19, 2014 at 9:40 PM Subject: Your RIPE Atlas Probe (ID: 11513) is now connected to our network To: rdekema at gmail.com Dear RIPE Atlas probe host, Thank you for participating in RIPE Atlas! We're just letting you know that your probe (#11513 with description Comcast Business 50/10 (with IPv6 trial).) has re-established its link to our network and we are again receiving data from it. For your own records, it appears that the reconnection took place at 2014-10-20 01:39 UTC. If you have any questions, please contact us at atlas at ripe.net Best regards, RIPE Atlas Team ********** You are receiving this message because you applied for or were given a RIPE Atlas probe. We will only send messages when your probe becomes disconnected for an extended period of time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Mon Oct 20 15:24:04 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 20 Oct 2014 15:24:04 +0200 Subject: [atlas] RIPE atlas probe network configuration In-Reply-To: <9BCC0C31-40A4-4C0B-A519-0464570EE125@jump.net.uk> References: <9BCC0C31-40A4-4C0B-A519-0464570EE125@jump.net.uk> Message-ID: <54450CF4.8010904@ripe.net> Hi James, On 2014/10/16 19:04 , James A. T. Rice wrote: > This means that you'd need to configure on your device, something like (assuming linux): > network: 10.a.b.0/24 > gateway: 10.a.b.1 > alias: p.q.r.s/32 > > with it configured that p.q.r.s is the default source IP address to use for any outbound packets. > > This is a relatively 'clean' way of doing things, as it doesn't involve proxy-arp or similar trickery. > > It should be possible to do this for linux based systems. What do you think? Will the atlas probe support it, or would you consider making that a feature? I guess not having to do proxy arp is attractive from a network operations point of view, but for a host having to use one specific address is not attractive at all. This would be a lot of work on the Atlas side. Not only adding the alias would require quite a few changes, but then also making sure that all network code would use the right source address. So for Atlas, it would be best if the probe could be configured as p.q.r.0/24 with p.q.r.1 as the gateway. Leaving the whole 10.a.b out of the story. Philip From mgalante at ripe.net Mon Oct 20 16:38:24 2014 From: mgalante at ripe.net (Michela Galante) Date: Mon, 20 Oct 2014 16:38:24 +0200 Subject: [atlas] Afilias (NL) has joined RIPE Atlas anchors Message-ID: <092FEDDE-04D0-4D76-83E1-25F179881799@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called nl-ams-as12041 and it is hosted by Afilias in Amsterdam, Netherlands. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From james at jump.net.uk Mon Oct 20 20:55:09 2014 From: james at jump.net.uk (James A. T. Rice) Date: Mon, 20 Oct 2014 19:55:09 +0100 Subject: [atlas] RIPE atlas probe network configuration In-Reply-To: <54450CF4.8010904@ripe.net> References: <9BCC0C31-40A4-4C0B-A519-0464570EE125@jump.net.uk> <54450CF4.8010904@ripe.net> Message-ID: <30180A8A-F723-4276-843B-81664D38FA8E@jump.net.uk> Hi Philip, On 20 Oct 2014, at 14:24, Philip Homburg wrote: > I guess not having to do proxy arp is attractive from a network > operations point of view, but for a host having to use one specific > address is not attractive at all. > > This would be a lot of work on the Atlas side. Not only adding the alias > would require quite a few changes, but then also making sure that all > network code would use the right source address. I don't think using the right source address should be difficult - http://linux-ip.net/html/routing-saddr-selection.html "the kernel will use the src hint from the chosen route path" http://serverfault.com/questions/248056/set-default-outgoing-ip-on-ubuntu-server-with-multiple-ips suggests the way to bring up the default route and pin eth0:1 to use for outgoing connections is in the form: up route add -net 0.0.0.0/0 gw 11.22.178.1 dev eth0:1 > So for Atlas, it would be best if the probe could be configured as > p.q.r.0/24 with p.q.r.1 as the gateway. Leaving the whole 10.a.b out of > the story. That does bring back memories of moving customers off of a shared VLAN and a /23 onto their own VLAN and /28. Those that didn't renumber in a timely fashion had a VLAN with proxy-arp enabled, and a static arp entry for their mac address to their new (yet configured on their host) IP, and a static route for the old IP address to the new IP address. I guess on my side I could assign a subnet of private space, make a static arp entry to your real mac address for a chosen IP from the private range, and then make a static route /32 for your public IP towards the private IP. The sensible netmask to use would be the /19 or /22 or whatever our allocated block is (otherwise the probe wouldn't be able to reach the IPs it thinks are its network and broadcast addresses. I shall give this a try. Can you think of any problems this might make? What's the limit of the arp table size on the probe for instance? Thanks James From philip.homburg at ripe.net Tue Oct 21 11:32:17 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 21 Oct 2014 11:32:17 +0200 Subject: [atlas] RIPE atlas probe network configuration In-Reply-To: <30180A8A-F723-4276-843B-81664D38FA8E@jump.net.uk> References: <9BCC0C31-40A4-4C0B-A519-0464570EE125@jump.net.uk> <54450CF4.8010904@ripe.net> <30180A8A-F723-4276-843B-81664D38FA8E@jump.net.uk> Message-ID: <54462821.8040809@ripe.net> On 2014/10/20 20:55 , James A. T. Rice wrote: > I don't think using the right source address should be difficult - > http://linux-ip.net/html/routing-saddr-selection.html > "the kernel will use the src hint from the chosen route path" Yes, that might work. I would almost say: just insert a NAT box between the router and the probe. :-) >> So for Atlas, it would be best if the probe could be configured as >> p.q.r.0/24 with p.q.r.1 as the gateway. Leaving the whole 10.a.b out of >> the story. > > That does bring back memories of moving customers off of a shared VLAN and a /23 onto their own VLAN and /28. Those that didn't renumber in a timely fashion had a VLAN with proxy-arp enabled, and a static arp entry for their mac address to their new (yet configured on their host) IP, and a static route for the old IP address to the new IP address. > > I guess on my side I could assign a subnet of private space, make a static arp entry to your real mac address for a chosen IP from the private range, and then make a static route /32 for your public IP towards the private IP. The sensible netmask to use would be the /19 or /22 or whatever our allocated block is (otherwise the probe wouldn't be able to reach the IPs it thinks are its network and broadcast addresses. I shall give this a try. > > Can you think of any problems this might make? What's the limit of the arp table size on the probe for instance? I don't know if there is a BCP for this, but I would suspect that allocating one VLAN per host would be best. The provides complete isolation. Then, if you tell the host it is on a /24 or bigger, the router would have to proxy-arp for the other hosts on the same subnet. But the probe has no business of talking to those hosts. For the ARP cache, if it works for a normal Linux hosts, then I suspect it will work for a v3 probe as well. Philip From mgalante at ripe.net Thu Oct 23 15:55:51 2014 From: mgalante at ripe.net (Michela Galante) Date: Thu, 23 Oct 2014 15:55:51 +0200 Subject: [atlas] 2Day Telecom LLP (KZ) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called kz-ala-as21299 and it is hosted by 2Day Telecom LLP in Almaty, Kazakhstan. With this anchor we reached a total of 80 online. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From BECHA at ripe.net Fri Oct 24 15:29:24 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 24 Oct 2014 15:29:24 +0200 Subject: [atlas] RIPE 69: Learn More About RIPE Atlas and RIPEstat! In-Reply-To: References: Message-ID: <544A5434.9010804@ripe.net> Dear colleagues, Attending RIPE 69 in London? If so, you can learn more about RIPE Atlas and RIPEstat at our sessions: Tutorial: "Basic RIPE NCC Tools for Network Diagnostics and Monitoring" When: Monday, 3 November 2014, 09:00-11:00 Where: Bourg meeting room, mezzanine floor More information about the RIPE 69 tutorials is available online: https://ripe69.ripe.net/programme/meeting-plan/tutorials/ Workshop: "Advanced Topics in RIPE Atlas Usage" When: Tuesday, 4 November, 18:00?19:00 (date might change!) Where: Side Room More information: https://ripe69.ripe.net/programme/meeting-plan/workshops/ This is an opportunity to exchange experiences, ask questions, and learn from each other. I hope to see you in London! Regards, Vesna From BECHA at ripe.net Fri Oct 24 16:54:57 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 24 Oct 2014 16:54:57 +0200 Subject: [atlas] Fwd: [mat-wg] RIPE Atlas Value Proposition Published In-Reply-To: <21D5EADB-B479-4826-884F-EBFDD296BBF9@ripe.net> References: <21D5EADB-B479-4826-884F-EBFDD296BBF9@ripe.net> Message-ID: <544A6841.2010206@ripe.net> Dear colleagues, please take a look at this news about RIPE Atlas, at mat-wg list. Regards, Vesna -------- Original Message -------- Subject: [mat-wg] RIPE Atlas Value Proposition Published Date: Fri, 24 Oct 2014 15:02:14 +0200 From: Kaveh Ranjbar To: mat-wg at ripe.net Dear colleagues, During its meeting in September, the RIPE NCC presented the RIPE NCC Executive Board with a value proposition document detailing the value that RIPE Atlas can bring to network operators, researchers and the Internet community as a whole. The board asked the RIPE NCC to publish this document, which is available on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-value-proposition We also plan to incorporate much of the document's content into the RIPE Atlas website so that RIPE Atlas users can clearly understand the different ways this global Internet measurement network can be used and the many unique benefits it provides. We hope you will find this document useful and that you may even be inspired to make use of RIPE Atlas in new ways. Kind regards, Kaveh Ranjbar Chief Information Officer RIPE NCC From rdekema at gmail.com Sun Oct 26 00:16:26 2014 From: rdekema at gmail.com (Rusty Dekema) Date: Sat, 25 Oct 2014 18:16:26 -0400 Subject: [atlas] Fwd: Your RIPE Atlas Probe (ID: 11513) is now connected to our network In-Reply-To: References: <20141020014004.14946.27585@janus.atlas.ripe.net> Message-ID: Greetings, I do not know anything about probes 14203 or 16058. The only probes I am involved with / responsible for are 10555 and 11513. Cheers, Rusty D On Mon, Oct 20, 2014 at 1:16 AM, Phillip Remaker wrote: > Thanks for the update! > > Can you give me any insight into #14203 and #16058? > > 16058 is particularly troubling, since it never seems to have come up in > the first place. I have it connected and powered up, with no joy. Is > there any way to fully reset it? > > On Sun, Oct 19, 2014 at 6:49 PM, Rusty Dekema wrote: > >> Good evening, >> >> In case you track these sorts of things, the ~2 week disconnection of >> this probe was caused by network trouble on my end (combined with an >> extended vacation), and not by the probe itself or any other part of the >> RIPE Atlas system. >> >> Cheers, >> Rusty Dekema >> >> ---------- Forwarded message ---------- >> From: RIPE Atlas >> Date: Sun, Oct 19, 2014 at 9:40 PM >> Subject: Your RIPE Atlas Probe (ID: 11513) is now connected to our network >> To: rdekema at gmail.com >> >> >> Dear RIPE Atlas probe host, >> >> Thank you for participating in RIPE Atlas! >> >> We're just letting you know that your probe (#11513 with description >> Comcast Business 50/10 (with IPv6 trial).) has re-established its link to >> our network and we are again receiving data from it. For your own records, >> it appears that the reconnection took place at 2014-10-20 01:39 UTC. >> >> If you have any questions, please contact us at atlas at ripe.net >> >> Best regards, >> >> RIPE Atlas Team >> >> ********** >> You are receiving this message because you applied for or were given a >> RIPE Atlas probe. We will only send messages when your probe becomes >> disconnected for an extended period of time. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gilles.pion at gmail.com Wed Oct 29 11:50:55 2014 From: gilles.pion at gmail.com (Gilles Pion) Date: Wed, 29 Oct 2014 11:50:55 +0100 Subject: [atlas] SSL error when connecting to https://atlas.ripe.net/ Message-ID: I'm suddenly unable to connect to https://atlas.ripe.net/ When using Firefox I'm getting the error "ssl_error_no_cypher_overlap" Whith Google Chrome: "ERR_CONNECTION_CLOSED" I'm only able to connect With IE, providing SSLV2 is enabled in advanced options (not a good idea I presume) NB: I'm behind a corporate proxy. -- *Gilles* -------------- next part -------------- An HTML attachment was scrubbed... URL: From schofield at terena.org Wed Oct 29 11:56:34 2014 From: schofield at terena.org (Brook Schofield) Date: Wed, 29 Oct 2014 06:56:34 -0400 Subject: [atlas] SSL error when connecting to https://atlas.ripe.net/ In-Reply-To: References: Message-ID: Works for me (Firefox 34) - but SSL Labs isn't happy: https://www.ssllabs.com/ssltest/analyze.html?d=atlas.ripe.net -Brook On 29 October 2014 06:50, Gilles Pion wrote: > I'm suddenly unable to connect to https://atlas.ripe.net/ > > When using Firefox I'm getting the error "ssl_error_no_cypher_overlap" > Whith Google Chrome: "ERR_CONNECTION_CLOSED" > > I'm only able to connect With IE, providing SSLV2 is enabled in advanced > options (not a good idea I presume) > > NB: I'm behind a corporate proxy. > > -- > *Gilles* > -- =================================================== Brook Schofield, Project Development Officer G?ANT Association, Singel 468 D, 1017 AW Amsterdam, The Netherlands Tel +31 20 530 4488 Fax +31 20 530 4499 Mob +31 65 155 3991 www.g?ant.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Wed Oct 29 12:11:38 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 29 Oct 2014 12:11:38 +0100 Subject: [atlas] SSL error when connecting to https://atlas.ripe.net/ In-Reply-To: References: Message-ID: <5450CB6A.9090000@ripe.net> On 2014-10-29 11:50, Gilles Pion wrote: > I'm suddenly unable to connect to https://atlas.ripe.net/ > > When using Firefox I'm getting the error "ssl_error_no_cypher_overlap" > Whith Google Chrome: "ERR_CONNECTION_CLOSED" > > I'm only able to connect With IE, providing SSLV2 is enabled in advanced > options (not a good idea I presume) > > NB: I'm behind a corporate proxy. > > -- > /Gilles/ Hello, The RIPE NCC has disabled SSLv3 recently -- see https://www.ripe.net/internet-coordination/news/announcements/the-ripe-ncc-disables-sslv3-encryption-for-its-services SSLv2 is also unavailable. Your corporate proxy is probably playing tricks on you... Regards, Robert From gilles.pion at gmail.com Wed Oct 29 12:18:18 2014 From: gilles.pion at gmail.com (Gilles Pion) Date: Wed, 29 Oct 2014 12:18:18 +0100 Subject: [atlas] SSL error when connecting to https://atlas.ripe.net/ In-Reply-To: <5450CB6A.9090000@ripe.net> References: <5450CB6A.9090000@ripe.net> Message-ID: 2014-10-29 12:11 GMT+01:00 Robert Kisteleki : > Your corporate proxy is probably playing tricks You're certainly right, I'm going to check this with the network admin team. Thanks, -- Gilles From nick at inex.ie Wed Oct 29 12:20:16 2014 From: nick at inex.ie (Nick Hilliard) Date: Wed, 29 Oct 2014 11:20:16 +0000 Subject: [atlas] SSL error when connecting to https://atlas.ripe.net/ In-Reply-To: <5450CB6A.9090000@ripe.net> References: <5450CB6A.9090000@ripe.net> Message-ID: <5450CD70.6030406@inex.ie> On 29/10/2014 11:11, Robert Kisteleki wrote: > On 2014-10-29 11:50, Gilles Pion wrote: >> NB: I'm behind a corporate proxy. > > SSLv2 is also unavailable. Your corporate proxy is probably playing tricks > on you... interesting. If your corporate proxy is causing the problem, then it sounds like it might be decrypting / re-encrypting your SSL sessions. Do other SSL connections break if you remove your company's root certificate? Nick From Piotr.Strzyzewski at polsl.pl Wed Oct 29 12:06:39 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 29 Oct 2014 12:06:39 +0100 Subject: [atlas] SSL error when connecting to https://atlas.ripe.net/ In-Reply-To: References: Message-ID: <20141029110639.GF1853@hydra.ck.polsl.pl> On Wed, Oct 29, 2014 at 11:50:55AM +0100, Gilles Pion wrote: > I'm suddenly unable to connect to https://atlas.ripe.net/ > > When using Firefox I'm getting the error "ssl_error_no_cypher_overlap" Have you checked security.tls.version.max and security.tls.version.min in your about:config? Right now, I would recommend min=1 and max=3. All the best, Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From s.eravuchira at jacobs-university.de Wed Oct 29 14:02:41 2014 From: s.eravuchira at jacobs-university.de (Steffie Jacob Eravuchira) Date: Wed, 29 Oct 2014 14:02:41 +0100 Subject: [atlas] [mat-wg] New on RIPE Labs: New RIPE Atlas Measurements User Interface In-Reply-To: <544FB563.5030908@ripe.net> References: <544FB563.5030908@ripe.net> Message-ID: <5450E571.1010906@jacobs-university.de> Hello, On 10/28/2014 04:25 PM, Mirjam Kuehne wrote: > Dear colleagues, > > We're very excited to announce an all-new user interface for RIPE Atlas > measurements. Users can now schedule, monitor and manage their own > customised measurements more efficiently than ever before, and can now > make use of the tagging feature when selecting probes for use in those > measurements. Learn more about the new features on RIPE Labs and let us > know what you think: > > https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-new-measurements-ui-and-tagging The new user interface for RIPE Atlas measurements looks well-designed. In the old interface, the "Target" field allows us to choose from a drop-down list of anchors/ringnodes. But in the new interface, the "Target" field is just a text field. Given, as a user, I do not know the hostnames of all anchors, would it be possible to bring the drop-down anchor list feature back? Thanks. -- Regards, Steffie _______________________________________________ Steffie Jacob Eravuchira Research I, Room 91 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany From robert at ripe.net Wed Oct 29 14:08:17 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 29 Oct 2014 14:08:17 +0100 Subject: [atlas] [mat-wg] New on RIPE Labs: New RIPE Atlas Measurements User Interface In-Reply-To: <5450E571.1010906@jacobs-university.de> References: <544FB563.5030908@ripe.net> <5450E571.1010906@jacobs-university.de> Message-ID: <5450E6C1.9030403@ripe.net> Hi, >> https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-new-measurements-ui-and-tagging >> > > The new user interface for RIPE Atlas measurements looks well-designed. Thank you! > In the old interface, the "Target" field allows us to choose from a > drop-down list of anchors/ringnodes. But in the new interface, the > "Target" field is just a text field. Given, as a user, I do not know the > hostnames of all anchors, would it be possible to bring the drop-down > anchor list feature back? Yes, it's on our list, will be done in the next release (after RIPE69). Regards, Robert From BECHA at ripe.net Wed Oct 29 14:37:52 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 29 Oct 2014 14:37:52 +0100 Subject: [atlas] [mat-wg] New on RIPE Labs: New RIPE Atlas Measurements User Interface In-Reply-To: <5450E571.1010906@jacobs-university.de> References: <544FB563.5030908@ripe.net> <5450E571.1010906@jacobs-university.de> Message-ID: <5450EDB0.1030705@ripe.net> Hi Steffie, all, On 29-okt.-14 14:02, Steffie Jacob Eravuchira wrote: > Hello, > > On 10/28/2014 04:25 PM, Mirjam Kuehne wrote: >> Dear colleagues, >> >> We're very excited to announce an all-new user interface for RIPE Atlas >> measurements. Users can now schedule, monitor and manage their own >> customised measurements more efficiently than ever before, and can now >> make use of the tagging feature when selecting probes for use in those >> measurements. Learn more about the new features on RIPE Labs and let us >> know what you think: >> >> https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-new-measurements-ui-and-tagging >> > > The new user interface for RIPE Atlas measurements looks well-designed. Glad you like it :) In addition to good looks, the latest RIPE Atlas release delivers several requested features from the roadmap: - Improved measurements pages and creation - Using tagging for probe selection when creating measurements - More control over probe selection (using tagging) - Improved IPv6 probe selection (using tagging) Updated roadmap can be found here: http://roadmap.ripe.net/ripe-atlas/ Please take a look, and let me (or the list) know of any other new features you want us to add in the future. Regards, Vesna From gboonie at gmail.com Thu Oct 30 21:20:15 2014 From: gboonie at gmail.com (gboonie) Date: Thu, 30 Oct 2014 21:20:15 +0100 Subject: [atlas] [mat-wg] New on RIPE Labs: New RIPE Atlas Measurements User Interface In-Reply-To: <5450EDB0.1030705@ripe.net> References: <544FB563.5030908@ripe.net> <5450E571.1010906@jacobs-university.de> <5450EDB0.1030705@ripe.net> Message-ID: <54529D7F.1010604@gmail.com> In the past we had a real result on DNS queries. The result would show the IP of a A record query and the remaining TTL. This info has been removed a few versions back. Is it intended to get this back? It was very useful for me. Thanks, Dave From graham at apolix.co.za Fri Oct 31 06:44:47 2014 From: graham at apolix.co.za (Graham Beneke) Date: Fri, 31 Oct 2014 07:44:47 +0200 Subject: [atlas] [mat-wg] New on RIPE Labs: New RIPE Atlas Measurements User Interface In-Reply-To: <5450EDB0.1030705@ripe.net> References: <544FB563.5030908@ripe.net> <5450E571.1010906@jacobs-university.de> <5450EDB0.1030705@ripe.net> Message-ID: <545321CF.5030507@apolix.co.za> On 29/10/2014 15:37, Vesna Manojlovic wrote: > In addition to good looks, the latest RIPE Atlas release delivers > several requested features from the roadmap: > - Improved measurements pages and creation I was using the new measurements UI to review the status of one of my measurements and I noticed a bug on the "Probes" tab: In the table the headers allow you to sort the various columns. When selecting the "RTT" column it seems that the sorting is based on the raw string and not the numeric value. This means that the results are being sorted as: 1 10 100 2 20 200 Rather than the more expected: 1 2 10 20 100 200 -- Graham Beneke From thomasholterbach at gmail.com Fri Oct 31 08:34:38 2014 From: thomasholterbach at gmail.com (Thomas Holterbach) Date: Fri, 31 Oct 2014 16:34:38 +0900 Subject: [atlas] Be careful with probe 4981 Message-ID: Hi, I am going to perform some tests on our atlas probe (id 4981, ASN 3130) during the next two or three weeks. Please note that during this period, measurements from or toward this probe might be inaccurate. Thank you for your attention, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From zacharias.tzermias at gmail.com Fri Oct 31 12:34:36 2014 From: zacharias.tzermias at gmail.com (Aris Tzermias) Date: Fri, 31 Oct 2014 13:34:36 +0200 Subject: [atlas] MTR measurement support Message-ID: Dear all, I was wondering whether you plan to provide an MTR ( https://en.wikipedia.org/wiki/MTR_%28software%29) support as a User-defined measurement. Best regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Fri Oct 31 14:06:58 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 31 Oct 2014 14:06:58 +0100 Subject: [atlas] MTR measurement support In-Reply-To: References: Message-ID: <54538972.1090203@ripe.net> On 2014/10/31 12:34 , Aris Tzermias wrote: > I was wondering whether you plan to provide an MTR > (https://en.wikipedia.org/wiki/MTR_%28software%29) support as a > User-defined measurement. Hi Aris, >From the point of view of Atlas, MTR consists of two parts, a measurement part and a user interface part. What part you most interested in? To completely simulate MTR, we would have to increase the frequency of traceroute measurements to one every second, which is a bit much, and write some code that generates the same output as MTR. Philip From BECHA at ripe.net Fri Oct 31 15:01:09 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 31 Oct 2014 15:01:09 +0100 Subject: [atlas] Data Streaming in RIPE Atlas In-Reply-To: <54538AF5.9020101@ripe.net> References: <54538AF5.9020101@ripe.net> Message-ID: <54539625.9070001@ripe.net> Dear colleagues, RIPE Atlas data is now available as a live data stream, opening the door to a host of new applications and use cases. You can read more about this new functionality (and watch the video!) on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/data-streaming-in-ripe-atlas Please let us know if you make a cool use of this new feature! Kind regards, Vesna From furry13 at gmail.com Fri Oct 31 15:15:04 2014 From: furry13 at gmail.com (Jen Linkova) Date: Fri, 31 Oct 2014 15:15:04 +0100 Subject: [atlas] Atlas Sagan library and UDP tarceroute results: bug or feature? Message-ID: Hello, I've just found that using Sagan library for analyzing UDP traceroute measurement results may produce incorrect results: 'target_responded' variable is not be set to 'True' if the source address of the traceroute reply is not the target address of the traceroute, but any other address that belongs to the node. (From the traceroute.py code: def target_responded(self): if self._target_responded is not None: return self._target_responded self._target_responded = False if self.hops and self.hops[-1].packets: destination_address = IP(self.destination_address) for packet in self.hops[-1].packets: if packet.origin and destination_address == IP(packet.origin): self._target_responded = True return self.target_responded ) I don't think that's a valid assumption that a target node is *always* choosing the probe packet's destination address as a reply source. In particular, in case of UDP packets addressed to anycast, it might fail because the node can reply from another address. In particular, rfc4443 (ICMP for IPv6) says: 2.2. Message Source Address Determination A node that originates an ICMPv6 message has to determine both the Source and Destination IPv6 Addresses in the IPv6 header before calculating the checksum. If the node has more than one unicast address, it MUST choose the Source Address of the message as follows: (a) If the message is a response to a message sent to one of the node's unicast addresses, the Source Address of the reply MUST be that same address. (b) If the message is a response to a message sent to any other address, such as - a multicast group address, - an anycast address implemented by the node, or - a unicast address that does not belong to the node the Source Address of the ICMPv6 packet MUST be a unicast address belonging to the node. == and in the same RFC source address selection for ICMP echo reply messages is defined: The source address of an Echo Reply sent in response to a unicast Echo Request message MUST be the same as the destination address of that Echo Request message. An Echo Reply SHOULD be sent in response to an Echo Request message sent to an IPv6 multicast or anycast address. In this case, the source address of the reply MUST be a unicast address belonging to the interface on which the Echo Request message was received. ==== So, I'm sending this email, first, to warn those of you who is using Sagan to analyze UDP traceroute results, and, secondly, to discuss, if Sagan behavior is a bug (I believe it is) or a feature ;) -- SY, Jen Linkova aka Furry