From BECHA at ripe.net Thu Nov 1 16:54:38 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 01 Nov 2012 16:54:38 +0100 Subject: [atlas] New RIPE Atlas features from October, and roadmap for November and beyond Message-ID: <50929B3E.4090209@ripe.net> Dear RIPE Atlas users, I am pleased to announce the whole lot of new things you can do with RIPE Atlas in/since October: - one new map (comparing TCP & UDM DNS measurements) - easier credits administration - and for some of you, we worked together further on Atlas Anchors There's more, with pictures, in the RIPE Labs article: https://labs.ripe.net/Members/becha/ripe-atlas-roadmap-october-2012-update We are also announcing many new features till the end of the year, and plans for few months in the future, for example: - more notifications - more APIs - promoting active users etc Please let us know if you want us to increase the priority of some of the ones listed in the article. Regards, and enjoy the measurements, Vesna From x12ozmouse at ya.ru Fri Nov 2 13:25:54 2012 From: x12ozmouse at ya.ru (Roman A. aka BasicXP) Date: Fri, 02 Nov 2012 16:25:54 +0400 Subject: [atlas] Question on UDMs Message-ID: <5093BBD2.5070308@ya.ru> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello! First of all, I'd like to thank RIPE for such an interesting project, allowing to study the availability of various resources online. I have a question. If I'd like to set up a UDM, that will only be designated for my probe only, will it require credits or using my own probe is "free"? Thank you in advance. _____ Best regards, Roman A. aka BasicXP x12ozmouse at ya.ru -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJQk7vQAAoJEBjQX5UpOG9YquQP/RptIW1NbaPdOPczWUTYvjxB ZMRNHWO/VX2RWeYMIRWcoUpqVJSV2f7Sy+55hG6kkkcnWvXb+Do9ro4/MsyXocsD y+AXzgt9zgEaQMtJsgr7gjOttRp4vl9Y9RiQ/NfAV/QMZj6YH0QuoqjhpSLDYs6H bA8rmCAx2RGOTlhEvQTBnwI/K6zO8Cp9psLyQ1hzkQeUqlZbOGtD4AGpBuLOcrGR cHyckfN3Lww83oaecBEU1wjgOgUuHzTQzoJKhU7CLr0h0EeBC60Qd9CD75CW7yUD pAZA3JUHhAsYh4Bw5NDihuRhRqDYfo+Ch63JZvdNxznWgRXPgNjm8dm9BqC3rOM2 /aYo4MnglRke7VqCw9vPkw1IW/aXCfx7OoOt4Vp17dKal5iOS/FT2u58qFkzeLRT Mn90I5EdcEbB+Nuv3GsjYBI94JrrSK2KtcoV235mSTAGYyAM665c3fVR+HkOc9Eu s/msjchT3MBlEini6HVqAqdTFDaCro+mOw53lKzCch8VQSJRTrbHz1S7RgRVK9dB 89E1ij3HhUv6Tz9y3fGvWmNwFCWxgkY0qnB8erlFDcTxBtg/ou+a5oU2Yd6Pa14n HaZfXgzSjpasDSTDzxfLzpG/w7qhAluQgo2Q+fViG8yweVWvCDT9DrvbTEuUrPFq TuxIjj0uFFzfPUZrSTrW =GYfh -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3738 bytes Desc: ?????????????????????????????????? ?????????????? S/MIME URL: From robert at ripe.net Mon Nov 5 09:06:10 2012 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 05 Nov 2012 09:06:10 +0100 Subject: [atlas] Question on UDMs In-Reply-To: <5093BBD2.5070308@ya.ru> References: <5093BBD2.5070308@ya.ru> Message-ID: <50977372.1090209@ripe.net> On 2012.11.02. 13:25, Roman A. aka BasicXP wrote: > Hello! > > First of all, I'd like to thank RIPE for such an interesting project, > allowing to study the availability of various resources online. I have > a question. If I'd like to set up a UDM, that will only be designated > for my probe only, will it require credits or using my own probe is > "free"? Thank you in advance. > > _____ Best regards, Roman A. aka BasicXP x12ozmouse at ya.ru Dear Roman, All UDMs require credits. If you already have a probe then you should already have an "income" which you can use do schedule your UDM. When doing so, you can pick a particular probe to use -- which can be your own. Regards, Robert Kisteleki From Artur.Russu at orange.md Mon Nov 5 14:09:10 2012 From: Artur.Russu at orange.md (Artur Russu) Date: Mon, 5 Nov 2012 13:09:10 +0000 Subject: [atlas] "down" probe resurrection In-Reply-To: <50977372.1090209@ripe.net> References: <5093BBD2.5070308@ya.ru> <50977372.1090209@ripe.net> Message-ID: Hello dear ripe community, I am trying to resurrect a "down" status ripe v1 probe. Probe is connected to a router and is auto configured for both ipv4 and ipv6. For test purposes, ipv6 has been disabled. Facts: 1 - Probe ID: 98 2 - probe was down for ~ 1 year (sorry) 3 - from router I have both ipv4 and ipv6 connectivity. 4 - sniffing shows traffic: pings, dns queries, ssl. For 22 minutes 58 seconds dumped 3.7 megabytes. 5 - probe has old firmware - 4.030 (force upgrade?) 6 - probe is rebooting every 5 minutes ! 7 - ssl sessions (usually last less than 5 minutes) are finished by probe (sends FIN packet) 8 - probe is still down 9 - probe is natted, in the atlas interface the ipv4 is not updated 10 - last 25 connections show nothing for ipv4 (for test purposes we are ipv4 only now, earlier we had enabled ipv6, connections were logged but no data was updated) 11 - nothing in charts Please help me resurrect this baby. ;) Best Regards, Artur Russu PS Engineer TD / MCN / Mobile Packet Core Orange Moldova S. A. Tel.: +373 22 975381 Tel.: +373 691 98381 E-mail: artur.russu at orange.md This message and attached information may be confidential. It is intended only for the use of the individual or entity named above. If you have received this message in error you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited, and please immediately notify us by telephone or reply by e-mail and then promptly delete the message. Thank you for your cooperation. From philip.homburg at ripe.net Mon Nov 5 16:01:37 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 05 Nov 2012 16:01:37 +0100 Subject: [atlas] "down" probe resurrection In-Reply-To: References: <5093BBD2.5070308@ya.ru> <50977372.1090209@ripe.net> Message-ID: <5097D4D1.8040205@ripe.net> On 11/5/12 14:09 , Artur Russu wrote: > Hello dear ripe community, > > I am trying to resurrect a "down" status ripe v1 probe. > > Probe is connected to a router and is auto configured for both ipv4 and ipv6. > For test purposes, ipv6 has been disabled. > > Facts: > 1 - Probe ID: 98 > 2 - probe was down for ~ 1 year (sorry) > 3 - from router I have both ipv4 and ipv6 connectivity. > 4 - sniffing shows traffic: pings, dns queries, ssl. For 22 minutes 58 seconds dumped 3.7 megabytes. > 5 - probe has old firmware - 4.030 (force upgrade?) > 6 - probe is rebooting every 5 minutes ! > 7 - ssl sessions (usually last less than 5 minutes) are finished by probe (sends FIN packet) > 8 - probe is still down > 9 - probe is natted, in the atlas interface the ipv4 is not updated > 10 - last 25 connections show nothing for ipv4 (for test purposes we are ipv4 only now, earlier we had enabled ipv6, connections were logged but no data was updated) > 11 - nothing in charts > > Please help me resurrect this baby. ;) > > The probe is continuously trying to upgrade itself. I have no idea why it doesn't succeed. After failing to upgrade, the probe continues with its normal initialization. It gets part way through and then it restarts. I now disabled the firmware upgrade, but it takes a couple of days before the probe finds out. In the mean time, the only reason we know at why the probe would reboot is if traceroute is somehow blocked. Maybe you can check where UDP based traceroute works from the network the probe is on. From Artur.Russu at orange.md Mon Nov 5 17:14:21 2012 From: Artur.Russu at orange.md (Artur Russu) Date: Mon, 5 Nov 2012 16:14:21 +0000 Subject: [atlas] "down" probe resurrection In-Reply-To: <5097D4D1.8040205@ripe.net> References: <5093BBD2.5070308@ya.ru> <50977372.1090209@ripe.net> <5097D4D1.8040205@ripe.net> Message-ID: Hi Philip, I will monitor it till tomorrow. Just connected my laptop instead of probe, and ran udp test ping with different ttl. Test were successful, traffic passes the firewall. Probe still rebooting. C:\Program Files\Nmap>nping.exe --udp --ttl 3 -g 54767 8.8.8.8 Starting Nping 0.5.51 ( http://nmap.org/nping ) at 2012-11-05 17:54 E. Europe Standard Time SENT (0.6090s) UDP 10.20.30.6:54767 > 8.8.8.8:40125 ttl=3 id=19712 iplen=28 RCVD (0.7960s) ICMP 10.251.0.113 > 10.20.30.6 TTL=0 during transit (type=11/code=0) ttl=253 id=30800 iplen=56 SENT (1.7810s) UDP 10.20.30.6:54767 > 8.8.8.8:40125 ttl=3 id=19712 iplen=28 RCVD (1.7810s) ICMP 10.251.0.113 > 10.20.30.6 TTL=0 during transit (type=11/code=0) ttl=253 id=30801 iplen=56 SENT (2.7810s) UDP 10.20.30.6:54767 > 8.8.8.8:40125 ttl=3 id=19712 iplen=28 RCVD (2.7810s) ICMP 10.251.0.113 > 10.20.30.6 TTL=0 during transit (type=11/code=0) ttl=253 id=30802 iplen=56 SENT (3.7810s) UDP 10.20.30.6:54767 > 8.8.8.8:40125 ttl=3 id=19712 iplen=28 RCVD (3.7810s) ICMP 10.251.0.113 > 10.20.30.6 TTL=0 during transit (type=11/code=0) ttl=253 id=30803 iplen=56 SENT (4.7810s) UDP 10.20.30.6:54767 > 8.8.8.8:40125 ttl=3 id=19712 iplen=28 RCVD (4.7810s) ICMP 10.251.0.113 > 10.20.30.6 TTL=0 during transit (type=11/code=0) ttl=253 id=30804 iplen=56 Max rtt: 15.000ms | Min rtt: 0.000ms | Avg rtt: 3.000ms Raw packets sent: 5 (210B) | Rcvd: 5 (280B) | Lost: 0 (0.00%) Tx time: 4.17200s | Tx bytes/s: 50.34 | Tx pkts/s: 1.20 Rx time: 5.17200s | Rx bytes/s: 54.14 | Rx pkts/s: 0.97 Nping done: 1 IP address pinged in 5.78 seconds From Artur.Russu at orange.md Tue Nov 6 10:51:03 2012 From: Artur.Russu at orange.md (Artur Russu) Date: Tue, 6 Nov 2012 09:51:03 +0000 Subject: [atlas] "down" probe resurrection References: <5093BBD2.5070308@ya.ru> <50977372.1090209@ripe.net> <5097D4D1.8040205@ripe.net> Message-ID: Just enabled Ipv6 back again. Now the probe has both Ipv4 and ipv6 connectivity. Behavior is the same, the tests are done in ipv4 but data is dumped using ipv6. Probe still reboots constantly every 5 minutes. UDP traceroute by probe is done for first and second hops, but till the gateway there are more hops... Any thoughts? From philip.homburg at ripe.net Tue Nov 6 10:55:43 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 06 Nov 2012 10:55:43 +0100 Subject: [atlas] "down" probe resurrection In-Reply-To: References: <5093BBD2.5070308@ya.ru> <50977372.1090209@ripe.net> <5097D4D1.8040205@ripe.net> Message-ID: <5098DE9F.7030503@ripe.net> On 11/6/12 10:51 , Artur Russu wrote: > Just enabled Ipv6 back again. > > Now the probe has both Ipv4 and ipv6 connectivity. > Behavior is the same, the tests are done in ipv4 but data is dumped using ipv6. > Probe still reboots constantly every 5 minutes. > > UDP traceroute by probe is done for first and second hops, but till the gateway there are more hops... > > The best thing is to wait until tomorrow morning when the probe should stop trying to upgrade itself. From mj at mjturner.net Tue Nov 6 21:59:01 2012 From: mj at mjturner.net (Michael-John Turner) Date: Tue, 6 Nov 2012 20:59:01 +0000 Subject: [atlas] Probe sending DHCP request, not accepting? Message-ID: <20121106205901.GA86766@tesla.majic12.net> Hi My probe arrived late last week and I finally hooked it up late yesterday afternoon. All was working fine until around 3:30am today when I received an automated email to say that my probe was down. I restarted it at around 7:00am when I got up but that didn't help - ever since it's been requesting a new IP every 3-5 seconds but not accepting the offered lease. From my dhcpd logs: Nov 6 07:12:02 dreamland dhcpd: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via br0 Nov 6 07:12:02 dreamland dhcpd: DHCPOFFER on 192.168.1.248 to aa:bb:cc:dd:ee:ff via br0 Nov 6 07:12:05 dreamland dhcpd: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via br0 Nov 6 07:12:05 dreamland dhcpd: DHCPOFFER on 192.168.1.248 to aa:bb:cc:dd:ee:ff via br0 (where aa:bb:cc:dd:ee:ff is the correct MAC, I've just redacted it). I've allocated the device a static IP based upon its MAC. Help! :) My probe ID is 3508. -mj -- Michael-John Turner mj at mjturner.net <> http://mjturner.net/ From philip.homburg at ripe.net Wed Nov 7 10:36:14 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 07 Nov 2012 10:36:14 +0100 Subject: [atlas] Probe sending DHCP request, not accepting? In-Reply-To: <20121106205901.GA86766@tesla.majic12.net> References: <20121106205901.GA86766@tesla.majic12.net> Message-ID: <509A2B8E.8000903@ripe.net> On 11/6/12 21:59 , Michael-John Turner wrote: > I've > allocated the device a static IP based upon its MAC. > > When a probe knows it probe ID, it changes its DHCP client-id. See https://atlas.ripe.net/faq#how-does-the-probe-connect Maybe you can capture the dhcp traffic with tcpdump to see if the server sends something the probe doesn't like? From mj at mjturner.net Wed Nov 7 11:14:22 2012 From: mj at mjturner.net (Michael-John Turner) Date: Wed, 7 Nov 2012 10:14:22 +0000 Subject: [atlas] Probe sending DHCP request, not accepting? In-Reply-To: <509A2B8E.8000903@ripe.net> References: <20121106205901.GA86766@tesla.majic12.net> <509A2B8E.8000903@ripe.net> Message-ID: <20121107101422.GA27800@majestic.pimp.org.za> On Wed, Nov 07, 2012 at 10:36:14AM +0100, Philip Homburg wrote: > When a probe knows it probe ID, it changes its DHCP client-id. See > https://atlas.ripe.net/faq#how-does-the-probe-connect Thanks for the suggestion - I had seen that but didn't have the stanza matching by client ID as I didn't think it was necessary (MAC address alone should be sufficient, I would've thought?). I have added it now, but it hasn't helped. > Maybe you can capture the dhcp traffic with tcpdump to see if the server > sends something the probe doesn't like? Sure. I've placed a copy of the the request/reply at http://dl.rsx11.net/misc/atlas_probe_dhcp.txt. I've redacted the MAC addresses (aa:bb:cc... is the MAC of the probe) but everything else is unchanged. I don't see anything unusual - please let me know if you'd like a copy of the raw tcpdump output. I also received an off-list suggestion regarding a possible duplicate IP so I've changed the IP assigned to the probe without it making any difference. Not sure if it makes a difference, but I do also have rtavd and DHCPv6 servers running on the same network (IPv6 connectivity to/from the probe was working fine until this problem started). -mj -- Michael-John Turner mj at mjturner.net <> http://mjturner.net/ From philip.homburg at ripe.net Wed Nov 7 11:22:06 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 07 Nov 2012 11:22:06 +0100 Subject: [atlas] Probe sending DHCP request, not accepting? In-Reply-To: <20121107101422.GA27800@majestic.pimp.org.za> References: <20121106205901.GA86766@tesla.majic12.net> <509A2B8E.8000903@ripe.net> <20121107101422.GA27800@majestic.pimp.org.za> Message-ID: <509A364E.5080405@ripe.net> On 11/7/12 11:14 , Michael-John Turner wrote: > Sure. I've placed a copy of the the request/reply at > http://dl.rsx11.net/misc/atlas_probe_dhcp.txt. I've redacted the MAC > addresses (aa:bb:cc... is the MAC of the probe) but everything else is > unchanged. I don't see anything unusual - please let me know if you'd like > a copy of the raw tcpdump output. > > According to your log the dhcp server sends the offer to 192.168.1.247, but the probe doesn't listen to that IP address because it is still trying to get one. The proper response would be to broadcast the offer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Artur.Russu at orange.md Wed Nov 7 12:18:50 2012 From: Artur.Russu at orange.md (Artur Russu) Date: Wed, 7 Nov 2012 11:18:50 +0000 Subject: [atlas] "down" probe resurrection In-Reply-To: <5098DE9F.7030503@ripe.net> References: <5093BBD2.5070308@ya.ru> <50977372.1090209@ripe.net> <5097D4D1.8040205@ripe.net> <5098DE9F.7030503@ripe.net> Message-ID: Hi Philip, Starting with approx. 11:10 the probe stopped flapping, so no more reboots. But, I see no traffic.. the probe doesn't do any tests in ipv4 and only router advertisements in ipv6. Still down in atlas page. What are our next steps? From mj at mjturner.net Wed Nov 7 12:34:21 2012 From: mj at mjturner.net (Michael-John Turner) Date: Wed, 7 Nov 2012 11:34:21 +0000 Subject: [atlas] Probe sending DHCP request, not accepting? In-Reply-To: <509A364E.5080405@ripe.net> References: <20121106205901.GA86766@tesla.majic12.net> <509A2B8E.8000903@ripe.net> <20121107101422.GA27800@majestic.pimp.org.za> <509A364E.5080405@ripe.net> Message-ID: <20121107113421.GA7975@majestic.pimp.org.za> On Wed, Nov 07, 2012 at 11:22:06AM +0100, Philip Homburg wrote: > According to your log the dhcp server sends the offer to 192.168.1.247, > but the probe doesn't listen to that IP address because it is still trying > to get one. The proper response would be to broadcast the offer. Ah, well spotted! I've enabled the 'always-broadcast' option (ISC dhcpd 4.2.2) to force a broadcast to be sent even when the client doesn't request it. ... TIME: 2012-11-07 11:13:48.277 IP: 192.168.1.10 (ff:ee:dd:cc:bb:aa) > 255.255.255.255 (ff:ff:ff:ff:ff:ff) OP: 2 (BOOTPREPLY) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: 2cce0f0a SECS: 0 FLAGS: 7f80 CIADDR: 0.0.0.0 YIADDR: 192.168.1.247 ... Still no request from the client after the offer :( Nov 7 11:25:41 dreamland dhcpd: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via br0 Nov 7 11:25:41 dreamland dhcpd: DHCPOFFER on 192.168.1.247 to aa:bb:cc:dd:ee:ff via br0 Nov 7 11:25:44 dreamland dhcpd: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via br0 Nov 7 11:25:44 dreamland dhcpd: DHCPOFFER on 192.168.1.247 to aa:bb:cc:dd:ee:ff via br0 11:29:51.569439 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from aa:bb:cc:dd:ee:ff, length 548 11:29:51.569927 IP 192.168.1.10.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 320 11:29:54.579613 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from aa:bb:cc:dd:ee:ff, length 548 11:29:54.579994 IP 192.168.1.10.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 320 (MAC redacted). This is most strange as this setup was working for several hours and I've not had any problems with my DHCP setup before. -mj -- Michael-John Turner mj at mjturner.net <> http://mjturner.net/ From Artur.Russu at orange.md Thu Nov 8 10:28:50 2012 From: Artur.Russu at orange.md (Artur Russu) Date: Thu, 8 Nov 2012 09:28:50 +0000 Subject: [atlas] "down" probe resurrection In-Reply-To: <509A76A9.3000005@ripe.net> References: <5093BBD2.5070308@ya.ru> <50977372.1090209@ripe.net> <5097D4D1.8040205@ripe.net> <5098DE9F.7030503@ripe.net> <509A76A9.3000005@ripe.net> Message-ID: Hi Philip, Connected it to my home network, directly to my provider, it has now a public IP address assigned by ISP's dhcp. Powered it from an USB power outlet (it has now 5 V/500 mA). Still reboots... :( What do your logs say? I will leave it like this for 24 hours. I guess that if this setup will still fail we'll have to return the probe to RIPE. Where can I find the procedure of returning a probe? Best Regards,? Artur Russu PS Engineer TD / MCN / Mobile Packet Core Orange Moldova S. A. Tel.: +373 22 975381 Tel.: +373 691 98381 E-mail:?artur.russu at orange.md ???????????????? From BECHA at ripe.net Thu Nov 8 16:57:45 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 08 Nov 2012 16:57:45 +0100 Subject: [atlas] RIPE Atlas nominated for an ISOC Award Message-ID: <509BD679.20205@ripe.net> Hi guys, a bit of good news and publicity: RIPE Atlas has been nominated for an award by the Netherlands chapter of the Internet Society (ISOC). Please find a short announcement on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-nominated-for-an-award Makes me feel proud for being part of it :) Since RIPE Atlas if build with your help - congratulations, well done! Cheers, Vesna From carsten at schiefner.de Thu Nov 8 17:49:05 2012 From: carsten at schiefner.de (Carsten Schiefner) Date: Thu, 08 Nov 2012 17:49:05 +0100 Subject: [atlas] RIPE Atlas nominated for an ISOC Award In-Reply-To: <509BD679.20205@ripe.net> References: <509BD679.20205@ripe.net> Message-ID: <509BE281.50202@schiefner.de> Hi Vesna, On 08.11.2012 16:57, Vesna Manojlovic wrote: > a bit of good news and publicity: RIPE Atlas has been nominated for an > award by the Netherlands chapter of the Internet Society (ISOC). > > Please find a short announcement on RIPE Labs: > https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-nominated-for-an-award > > > Makes me feel proud for being part of it :) > > Since RIPE Atlas if build with your help - congratulations, well done! so all probe holders are invited to the ceremony, I assume? ;-) Cheers, -C. From BECHA at ripe.net Tue Nov 13 10:24:39 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 13 Nov 2012 10:24:39 +0100 Subject: [atlas] New page: RIPE Atlas Community Message-ID: <50A211D7.6020704@ripe.net> Good morning :) Since yesterday, we have a new page that shows the activity of the RIPE Atlas users community: https://atlas.ripe.net/atlas/community We are publishing top-ten hosts of the "Always Up" probes, top-ten UDM users: "Big Spenders" -- people who spend most credits, by doing the most measurements, and the flowing list of new arrivals, with flags of their countries. (Now you can see that there was IETF last week -- Bert gave away 55 probes!) Enjoy your additional few minutes of fame, if you name appears on one of these lists :) We are looking forward to your compliments, and to the further wishes on what else would you like to see here... We will be featuring these top-users in our communication, so expect some more attention from us... Ciao, Vesna From bwijnen at ripe.net Tue Nov 13 10:35:47 2012 From: bwijnen at ripe.net (Bert Wijnen) Date: Tue, 13 Nov 2012 10:35:47 +0100 Subject: [atlas] New page: RIPE Atlas Community In-Reply-To: <50A211D7.6020704@ripe.net> References: <50A211D7.6020704@ripe.net> Message-ID: <50A21473.5010701@ripe.net> so under newcomers you also list those that do not have their probe UP yet? Bert On 11/13/12 10:24 AM, Vesna Manojlovic wrote: > Good morning :) > > Since yesterday, we have a new page that shows the activity of the > RIPE Atlas users community: > https://atlas.ripe.net/atlas/community > > We are publishing top-ten hosts of the "Always Up" probes, > top-ten UDM users: "Big Spenders" -- people who spend most credits, > by doing the most measurements, > and > the flowing list of new arrivals, with flags of their countries. > > (Now you can see that there was IETF last week -- Bert gave away > 55 probes!) > > Enjoy your additional few minutes of fame, > if you name appears on one of these lists :) > > We are looking forward to your compliments, > and to the further wishes on what else would you like to see here... > > We will be featuring these top-users in our communication, > so expect some more attention from us... > > Ciao, > Vesna > > > From grinapo+ripeatlas at gmail.com Tue Nov 13 12:57:22 2012 From: grinapo+ripeatlas at gmail.com (Peter Gervai) Date: Tue, 13 Nov 2012 12:57:22 +0100 Subject: [atlas] Atlas F.ROOT ping Message-ID: Hello, Atlas helped me today first to see a hard-to-detect bug: F-root anycast algo works fine for v4 but fails miserably for v6, as instead of AMSterdam it sends all traffic to some remote island in the pacific. ;-) Seems to be the reverse true for M-root: ipv4 sends me off to nowhere land while v6 is great. A-root follows the F-suit. (C-root is not a good avertisement valie for Cogent, with v4 only address and considerable ongoing pkt loss.) Thanks! Peter From grinapo+ripeatlas at gmail.com Tue Nov 13 13:15:58 2012 From: grinapo+ripeatlas at gmail.com (Peter Gervai) Date: Tue, 13 Nov 2012 13:15:58 +0100 Subject: [atlas] Atlas F.ROOT ping In-Reply-To: References: Message-ID: On Tue, Nov 13, 2012 at 12:57 PM, Peter Gervai wrote: > Atlas helped me today first to see a hard-to-detect bug: F-root > anycast algo works fine for v4 but fails miserably for v6, as instead > of AMSterdam it sends all traffic to some remote island in the > pacific. ;-) Just to follow myself up, most of the private email was about questions easily answered by my humble probe No. 3338. :-) It's all public, as far as my setup skills shine. :-] Peter ps: reminds me to always attach the probe# to my email to back up my claims. From bicknell at ufp.org Tue Nov 13 16:34:11 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 13 Nov 2012 07:34:11 -0800 Subject: [atlas] Atlas F.ROOT ping In-Reply-To: References: Message-ID: <20121113153411.GA22380@ussenterprise.ufp.org> In a message written on Tue, Nov 13, 2012 at 12:57:22PM +0100, Peter Gervai wrote: > Atlas helped me today first to see a hard-to-detect bug: F-root > anycast algo works fine for v4 but fails miserably for v6, as instead > of AMSterdam it sends all traffic to some remote island in the > pacific. ;-) The good folks at ISC would be quite happy if you opened a ticket with them on this issue. Drop an e-mail to noc at isc.org to do so, including traceroutes and such would help a lot. As you noticed with both F and M, there's always a routing misconfiguration somewhere for someone. IPv6 is still a little less mature than IPv4 in that sense. Lots of good people are working on the problem. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From grinapo+ripeatlas at gmail.com Tue Nov 13 18:09:37 2012 From: grinapo+ripeatlas at gmail.com (Peter Gervai) Date: Tue, 13 Nov 2012 18:09:37 +0100 Subject: [atlas] Atlas F.ROOT ping In-Reply-To: <20121113153411.GA22380@ussenterprise.ufp.org> References: <20121113153411.GA22380@ussenterprise.ufp.org> Message-ID: On Tue, Nov 13, 2012 at 4:34 PM, Leo Bicknell wrote: > In a message written on Tue, Nov 13, 2012 at 12:57:22PM +0100, Peter Gervai wrote: >> Atlas helped me today first to see a hard-to-detect bug: F-root >> anycast algo works fine for v4 but fails miserably for v6, as instead >> of AMSterdam it sends all traffic to some remote island in the >> pacific. ;-) > > The good folks at ISC would be quite happy if you opened a ticket > with them on this issue. Drop an e-mail to noc at isc.org to do so, > including traceroutes and such would help a lot. I did. > As you noticed with both F and M, there's always a routing > misconfiguration somewhere for someone. IPv6 is still a little > less mature than IPv4 in that sense. Lots of good people are working > on the problem. We have to watch ipv6 with much more attention since we really have to prevent people saying that it's "worse" than ipv4, especially now that ripe handled our last v4 block ever and no more. Later or possibly sooner the endusers get it, and I mean the END endusers, those gravediggers, spoon-binders and dishwashers. :-) And DNS is the first entry, so I'd prefer working and reachable roots. And Atlas is a great way to assure that. Peter From jim at daedelus.com Tue Nov 13 18:59:45 2012 From: jim at daedelus.com (Jim Martin) Date: Tue, 13 Nov 2012 09:59:45 -0800 Subject: [atlas] Atlas F.ROOT ping In-Reply-To: References: <20121113153411.GA22380@ussenterprise.ufp.org> Message-ID: On Nov 13, 2012, at 9:09 AM, Peter Gervai wrote: > On Tue, Nov 13, 2012 at 4:34 PM, Leo Bicknell wrote: >> In a message written on Tue, Nov 13, 2012 at 12:57:22PM +0100, Peter Gervai wrote: >>> Atlas helped me today first to see a hard-to-detect bug: F-root >>> anycast algo works fine for v4 but fails miserably for v6, as instead >>> of AMSterdam it sends all traffic to some remote island in the >>> pacific. ;-) >> >> The good folks at ISC would be quite happy if you opened a ticket >> with them on this issue. Drop an e-mail to noc at isc.org to do so, >> including traceroutes and such would help a lot. > > I did. And we appreciate it :-) We'll look into the issue for F. - Jim (who's Ops at ISC, but is subscribed to this list from a personal account) From matthaeus.wander at uni-due.de Wed Nov 28 18:41:40 2012 From: matthaeus.wander at uni-due.de (=?ISO-8859-15?Q?Matth=E4us_Wander?=) Date: Wed, 28 Nov 2012 18:41:40 +0100 Subject: [atlas] Two users managing one probe Message-ID: <50B64CD4.3070607@uni-due.de> Hi, is it possible to register the same probe by two different users? I would like to give my co-worker full access to a probe in our group LAN. Kind regards, Matt -- Universit?t Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5156 bytes Desc: S/MIME Kryptografische Unterschrift URL: From jim at daedelus.com Wed Nov 28 19:07:44 2012 From: jim at daedelus.com (Jim Martin) Date: Wed, 28 Nov 2012 10:07:44 -0800 Subject: [atlas] Two users managing one probe In-Reply-To: <50B64CD4.3070607@uni-due.de> References: <50B64CD4.3070607@uni-due.de> Message-ID: <0B0CF7D0-6329-4F97-A5E5-A2932B14B05D@daedelus.com> If it is possible, I'd be very interested in understanding how to do it, as I have the exact same use case. If it's not possible, might it be added to the road map? Thanks! - Jim On Nov 28, 2012, at 9:41 AM, Matth?us Wander wrote: > Hi, > > is it possible to register the same probe by two different users? I > would like to give my co-worker full access to a probe in our group LAN. > > Kind regards, > Matt > > -- > Universit?t Duisburg-Essen > Verteilte Systeme > Bismarckstr. 90 / BC 316 > 47057 Duisburg > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4365 bytes Desc: not available URL: From to at hosteurope.de Wed Nov 28 19:18:15 2012 From: to at hosteurope.de (Tobias Offermann) Date: Wed, 28 Nov 2012 19:18:15 +0100 Subject: [atlas] Two users managing one probe In-Reply-To: <50B64CD4.3070607@uni-due.de> References: <50B64CD4.3070607@uni-due.de> Message-ID: <50B65567.2020809@hosteurope.de> On 11/28/2012 06:41 PM, Matth?us Wander wrote: > is it possible to register the same probe by two different users? I > would like to give my co-worker full access to a probe in our group LAN. I had exactly the same issue - RIPE told me to register a separate ("shared") group account and let them change the probe association to that account. Regards, Tobi -- Network Security & Infrastructure ----------------------------------------------------------------------- Host Europe GmbH - http://www.hosteurope.de Welserstra?e 14 - 51149 K?ln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht K?ln - USt-IdNr.: DE187370678 Gesch?ftsf?hrer: Patrick Pulverm?ller, Thomas Vollrath (*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt. Mobilfunknetzen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From Woeber at CC.UniVie.ac.at Fri Nov 30 14:32:54 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Fri, 30 Nov 2012 14:32:54 +0100 Subject: [atlas] Two users managing one probe In-Reply-To: <50B65567.2020809@hosteurope.de> References: <50B64CD4.3070607@uni-due.de> <50B65567.2020809@hosteurope.de> Message-ID: <50B8B586.5060307@CC.UniVie.ac.at> Tobias Offermann wrote: > On 11/28/2012 06:41 PM, Matth?us Wander wrote: > >>is it possible to register the same probe by two different users? I >>would like to give my co-worker full access to a probe in our group LAN. > > > I had exactly the same issue - :-) I was talking to Arlas folks at the NCC about this thing in the past... In particular I/we would need a (rather simple) split of functionality into a full-control+configure-access and a read-only access type. > RIPE told me to register a separate ("shared") > group account Is there any guidance available somewhere how to do that? TIA! > and let them change the probe association to that account. > > Regards, > Tobi Wilfried