From rdekema at gmail.com Sat Aug 3 05:09:03 2013 From: rdekema at gmail.com (Rusty Dekema) Date: Fri, 2 Aug 2013 23:09:03 -0400 Subject: [atlas] Probe no longer on an IPv6 network? Message-ID: Good evening, When I first installed it, probe 10555 was on a network which supports IPv6. Since then, I have moved it to a different network which does not have IPv6 access at all. Is there something I should do to let the RIPE Atlas system know that it no longer has IPv6 access? It seems like there should be, but I haven't found it. I would not like for it to be one of those probes which "thinks" it has IPv6 but actually does not... Thanks, Rusty D -------------- next part -------------- An HTML attachment was scrubbed... URL: From folkert at vanheusden.com Sun Aug 4 01:29:03 2013 From: folkert at vanheusden.com (folkert) Date: Sun, 4 Aug 2013 01:29:03 +0200 Subject: [atlas] adding a device Message-ID: <20130803232903.GI8801@belle.intranet.vanheusden.com> Hi, Yesterday I received a probe-device at a conference. I entered the details in the website (which was a lot of fun: finding out the ipv4 prefix(?!) - I ended up trying a couple of entries found in the whois info of my ipv4 address, also in what format should I enter the mac-address?) but the device does not appear in the "My probes" list. Even after a couple of hours. I verified that it got an ip4-address from the dhcp server and also radvd is happily announcing the ipv6-prefix in that segment. Furthermore: I see that the probe is doing all kinds of network traffic to the internet. So the device at itself seems to work. What can be wrong? Folkert van Heusden -- Always wondered what the latency of your webserver is? Or how much more latency you get when you go through a proxy server/tor? The numbers tell the tale and with HTTPing you know them! http://www.vanheusden.com/httping/ ----------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com From rejo at zenger.nl Sun Aug 4 22:45:57 2013 From: rejo at zenger.nl (Rejo Zenger) Date: Sun, 4 Aug 2013 22:45:57 +0200 Subject: [atlas] adding a device In-Reply-To: <20130803232903.GI8801@belle.intranet.vanheusden.com> References: <20130803232903.GI8801@belle.intranet.vanheusden.com> Message-ID: <20130804204557.GA12920@broop-kidron.home> ++ 04/08/13 01:29 +0200 - folkert: >Yesterday I received a probe-device at a conference. I entered the >details in the website (which was a lot of fun: finding out the ipv4 >prefix(?!) - I ended up trying a couple of entries found in the whois [...] Probably: have some more patience. Those probes get added manually and it takes some time before someone has added your probe. -- Rejo Zenger . . 0x21DBEFD4 . GPG encrypted e-mail preferred . +31.6.39642738 . @rejozenger -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From folkert at vanheusden.com Sun Aug 4 23:20:37 2013 From: folkert at vanheusden.com (folkert) Date: Sun, 4 Aug 2013 23:20:37 +0200 Subject: [atlas] adding a device In-Reply-To: <20130804204557.GA12920@broop-kidron.home> References: <20130803232903.GI8801@belle.intranet.vanheusden.com> <20130804204557.GA12920@broop-kidron.home> Message-ID: <20130804212037.GK8801@belle.intranet.vanheusden.com> > >Yesterday I received a probe-device at a conference. I entered the > >details in the website (which was a lot of fun: finding out the ipv4 > >prefix(?!) - I ended up trying a couple of entries found in the whois > [...] > > Probably: have some more patience. Those probes get added manually and > it takes some time before someone has added your probe. Oh sorry I thought it was all automatic. Sorry Folkert van Heusden -- ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com From robert at ripe.net Mon Aug 5 09:34:14 2013 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 05 Aug 2013 09:34:14 +0200 Subject: [atlas] adding a device In-Reply-To: <20130804212037.GK8801@belle.intranet.vanheusden.com> References: <20130803232903.GI8801@belle.intranet.vanheusden.com> <20130804204557.GA12920@broop-kidron.home> <20130804212037.GK8801@belle.intranet.vanheusden.com> Message-ID: <51FF5576.70701@ripe.net> On 2013.08.04. 23:20, folkert wrote: >>> Yesterday I received a probe-device at a conference. I entered the >>> details in the website (which was a lot of fun: finding out the ipv4 >>> prefix(?!) - I ended up trying a couple of entries found in the whois >> [...] >> >> Probably: have some more patience. Those probes get added manually and >> it takes some time before someone has added your probe. > > Oh sorry I thought it was all automatic. > Sorry > > > Folkert van Heusden Hello, When you get a probe from an ambassador and you register that probe, our system tries to verify the data given by you (i.e. your logged in user and the probe data) against the data provided by your ambassador. If the two match, the probe is automatically registered to you. This usually takes up to an hour or so. If your data doesn't match with what we know (for example, you're using a different email address / account than what the ambassador registered) then we need to fall back to manual verification, which is obviously slower. In your case I think the ambassador just didn't have time yet to record his/her part yet. I'm sure it will happen soon -- and then one of the the above two will apply. Hope this explains, Robert PS: this comes up every now and then; we'll make a FAQ entry for it From philip.homburg at ripe.net Mon Aug 5 23:42:15 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 05 Aug 2013 23:42:15 +0200 Subject: [atlas] Probe no longer on an IPv6 network? In-Reply-To: References: Message-ID: <52001C37.6090802@ripe.net> Hi Rusty, On 2013/08/03 5:09 , Rusty Dekema wrote: > > > When I first installed it, probe 10555 was on a network which supports > IPv6. Since then, I have moved it to a different network which does > not have IPv6 access at all. > > Is there something I should do to let the RIPE Atlas system know that > it no longer has IPv6 access? It seems like there should be, but I > haven't found it. I would not like for it to be one of those probes > which "thinks" it has IPv6 but actually does not... > When they connect to a controller, probes report their IPv4 and IPv6 addresses. If a probe doesn't report any IPv6 address (other than link local) it will not get any new IPv6 measurements. If you look at the graphs for your probe, you will see that they stopped getting updated shortly after you moved the probe. Your probe still takes part in some IPv6 UDMs. But that is mostly because at the moment there is no mechanism to remove a probe from a UDM. Philip From robert at ripe.net Tue Aug 6 15:21:12 2013 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 06 Aug 2013 15:21:12 +0200 Subject: [atlas] RIPE Atlas maintenance on Tuesday, 6 August In-Reply-To: <51F7933E.3070903@ripe.net> References: <51F7933E.3070903@ripe.net> Message-ID: <5200F848.8060209@ripe.net> Dear All, This work is now done and we believe everything is back to normal (*). Please let us know (preferably via atlas-bugs at ripe.net) if you find something not working. Regards, Robert Kisteleki (*) independently of this maintenance, one of the data servers (zpm01) is having some hardware issues, which causes data downloads and RRDs for probes 1-499 to be flaky. We're working on this. On 2013.07.30. 12:19, Robert Kisteleki wrote: > > 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 tore at fud.no Wed Aug 7 13:19:08 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 07 Aug 2013 13:19:08 +0200 Subject: [atlas] 1000Base-T not supported? Message-ID: <52022D2C.6010605@fud.no> Today I was struggling to get a v3 probe (TP-Link) connected to my network, the link just wouldn't come up. On a whim I tried connecting it to a tri-rate 10/100/100Base-T device, and lo and behold - it came alive! Only 100Mb, though. Is it really the case that the probes don't support 1GbE? The probe has ?150Mb? printed on it, which strikes me as rather odd if it's limited upwards to 100Mb. Tore From philip.homburg at ripe.net Wed Aug 7 13:48:01 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 07 Aug 2013 13:48:01 +0200 Subject: [atlas] 1000Base-T not supported? In-Reply-To: <52022D2C.6010605@fud.no> References: <52022D2C.6010605@fud.no> Message-ID: <520233F1.3010903@ripe.net> Hi Tore, On 2013/08/07 13:19 , Tore Anderson wrote: > Today I was struggling to get a v3 probe (TP-Link) connected to my > network, the link just wouldn't come up. On a whim I tried connecting it > to a tri-rate 10/100/100Base-T device, and lo and behold - it came > alive! Only 100Mb, though. Yes, probes are 10/100 only. These days it is even mentioned in the FAQ :-) (wonders what the advantage is of 1Gbps-only ports) > Is it really the case that the probes don't support 1GbE? The probe has > ?150Mb? printed on it, which strikes me as rather odd if it's limited > upwards to 100Mb. > > Maybe the Wifi is technically 150 Mbps? There is also a 3G/4G switch on the probe. Chinese marketing? Philip From tore at fud.no Wed Aug 7 14:02:48 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 07 Aug 2013 14:02:48 +0200 Subject: [atlas] 1000Base-T not supported? In-Reply-To: <520233F1.3010903@ripe.net> References: <52022D2C.6010605@fud.no> <520233F1.3010903@ripe.net> Message-ID: <52023768.2050304@fud.no> * Philip Homburg > Yes, probes are 10/100 only. These days it is even mentioned in the FAQ :-) *blush* - sorry for the noise! > (wonders what the advantage is of 1Gbps-only ports) FWIW, all the SFPs I stock are single-rate, and the switch I tried to connect the probe to can only accept single-rate 1/10G SFPs anyway. Tore From chelliot at pobox.com Wed Aug 7 23:08:56 2013 From: chelliot at pobox.com (Chris Elliott) Date: Wed, 7 Aug 2013 17:08:56 -0400 Subject: [atlas] 1000Base-T not supported? In-Reply-To: <520233F1.3010903@ripe.net> References: <52022D2C.6010605@fud.no> <520233F1.3010903@ripe.net> Message-ID: On Wednesday, August 7, 2013, Philip Homburg wrote: > Hi Tore, > > On 2013/08/07 13:19 , Tore Anderson wrote: > > Today I was struggling to get a v3 probe (TP-Link) connected to my > > network, the link just wouldn't come up. On a whim I tried connecting it > > to a tri-rate 10/100/100Base-T device, and lo and behold - it came > > alive! Only 100Mb, though. > Yes, probes are 10/100 only. These days it is even mentioned in the FAQ :-) > > (wonders what the advantage is of 1Gbps-only ports) > > Is it really the case that the probes don't support 1GbE? The probe has > > ?150Mb? printed on it, which strikes me as rather odd if it's limited > > upwards to 100Mb. 100M full-duplex, thus 200M throughput! :-) Maybe the Wifi is technically 150 Mbps? There is also a 3G/4G switch on > the probe. Chinese marketing? Indeed, 802.11n with a 40M wide channel maxes out at 150M. I'll guarantee you'll get higher throughput via wired and lower latency and jitter, plus far fewer hassles. Plug it in and walk away. I'm hoping/expecting that RIPE never supports wireless in these probes. Chris. > Philip > > -- Chris Elliott chelliot at pobox.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Thu Aug 8 01:28:07 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 08 Aug 2013 01:28:07 +0200 Subject: [atlas] 1000Base-T not supported? In-Reply-To: References: <52022D2C.6010605@fud.no> <520233F1.3010903@ripe.net> Message-ID: <5202D807.2050604@ripe.net> On 2013/08/07 23:08 , Chris Elliott wrote: > > Indeed, 802.11n with a 40M wide channel maxes out at 150M. > I'll guarantee you'll get higher throughput via wired and lower > latency and jitter, plus far fewer hassles. Plug it in and walk away. > I'm hoping/expecting that RIPE never supports wireless in these probes. > > There are some specific cases where measuring wifi makes sense. But that will be in addition to wired ethernet and not instead of. Philip From ms at uakom.sk Thu Aug 8 11:54:01 2013 From: ms at uakom.sk (Martin Stanislav) Date: Thu, 8 Aug 2013 11:54:01 +0200 Subject: [atlas] Probe sharing Message-ID: <20130808095401.GA10342@moon.uakom.sk> Hi, This spring RIPE Atlas update [1] introduced a new feature called probe sharing. Probe sharing should work for colleagues within the same LIR and is to be set via: "My Probes" -> "Probe's Settings" -> "General Configuration" -> Select your LIR in the "Share with" field. I've set the "Share with" field to our LIR ID for all three local probes. But a colleague of mine, in spite of being able to login to the Lirportal, sees an error message below every time he tries to access the probe list at https://atlas.ripe.net/atlas/myprobes.html The error message: "You are not logged in as a RIPE NCC member". Is there anything I've missed? Possible delay in privilege propagation from the Lirportal to Atlas section? Thanks. Martin [1] https://labs.ripe.net/Members/kistel/new-ripe-atlas-features-april-2013 From robert at ripe.net Thu Aug 8 12:13:03 2013 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 08 Aug 2013 12:13:03 +0200 Subject: [atlas] Probe sharing In-Reply-To: <20130808095401.GA10342@moon.uakom.sk> References: <20130808095401.GA10342@moon.uakom.sk> Message-ID: <52036F2F.7000008@ripe.net> Hi, This function should work in general; in order for us to look into the specifics please drop us a mail with details (probe id, your and your colleague's account/email) to atlas at ripe.net Thank you, Robert On 2013.08.08. 11:54, Martin Stanislav wrote: > Hi, > > This spring RIPE Atlas update [1] introduced a new feature > called probe sharing. Probe sharing should work for colleagues > within the same LIR and is to be set via: > "My Probes" -> "Probe's Settings" -> "General Configuration" -> > Select your LIR in the "Share with" field. > > I've set the "Share with" field to our LIR ID for all three > local probes. But a colleague of mine, in spite of being able > to login to the Lirportal, sees an error message below every > time he tries to access the probe list at > https://atlas.ripe.net/atlas/myprobes.html > > The error message: "You are not logged in as a RIPE NCC member". > > Is there anything I've missed? Possible delay in privilege > propagation from the Lirportal to Atlas section? > > Thanks. > > Martin > > [1] https://labs.ripe.net/Members/kistel/new-ripe-atlas-features-april-2013 > > > From d_churchill at comcast.net Thu Aug 8 14:19:37 2013 From: d_churchill at comcast.net (David Churchill) Date: Thu, 8 Aug 2013 08:19:37 -0400 Subject: [atlas] Multiple Probe v3 Disconnects Message-ID: <001501ce9431$8d03fc00$a70bf400$@net> I just received my v3 probe 3 days ago and I've noticed on the status page that that there are quite a few disconnects: Disconnect at: Connected time: Disconnected time: (still connected) 0d, 0h, 30m (still connected) 2013-08-08 11:37:44 UTC 0d, 0h, 38m 0d, 0h, 2m 2013-08-08 10:49:09 UTC 0d, 1h, 14m 0d, 0h, 10m 2013-08-08 09:31:38 UTC 0d, 2h, 2m 0d, 0h, 3m 2013-08-08 07:25:41 UTC 0d, 1h, 22m 0d, 0h, 3m 2013-08-08 05:53:24 UTC 0d, 1h, 26m 0d, 0h, 9m 2013-08-08 04:24:56 UTC 0d, 2h, 23m 0d, 0h, 2m 2013-08-08 01:57:23 UTC 0d, 1h, 18m 0d, 0h, 4m 2013-08-08 00:35:09 UTC 0d, 0h, 26m 0d, 0h, 3m 2013-08-08 00:05:53 UTC 0d, 1h, 25m 0d, 0h, 2m 2013-08-07 22:37:14 UTC 0d, 1h, 12m 0d, 0h, 3m 2013-08-07 21:20:56 UTC 0d, 0h, 4m 0d, 0h, 4m 2013-08-07 21:11:44 UTC 0d, 2h, 9m 0d, 0h, 4m 2013-08-07 18:59:32 UTC 0d, 0h, 39m 0d, 0h, 2m 2013-08-07 18:18:40 UTC 0d, 6h, 12m 0d, 0h, 1m 2013-08-07 12:03:56 UTC 0d, 12h, 42m 0d, 0h, 1m 2013-08-06 23:19:16 UTC 0d, 0h, 4m 0d, 0h, 2m 2013-08-06 23:15:08 UTC 0d, 0h, 2m 0d, 0h, 0m 2013-08-06 23:05:16 UTC 0d, 4h, 45m 0d, 0h, 7m 2013-08-06 18:17:13 UTC 0d, 1h, 54m 0d, 0h, 2m 2013-08-06 16:18:39 UTC 0d, 0h, 45m 0d, 0h, 3m 2013-08-06 15:32:39 UTC 0d, 0h, 41m 0d, 0h, 0m 2013-08-06 14:50:33 UTC 0d, 2h, 32m 0d, 0h, 0m 2013-08-06 05:51:43 UTC 0d, 6h, 47m 0d, 6h, 25m Is this something I should be concerned about? If so, could it have to do with the fact that my probe is plugged into a 10/100/1000 MBit switch (I saw an earlier thread that suggested this might be an issue)? If the Gigabit switch is a problem, would it help if I cascade a 10/100 switch off one of the Gigabit switch's ports, or off one of my router's ports (which are all Gigabit) and then plug the probe into that 10/100 switch? Finally, I'm using a cell phone charger for power, it's 5V, mini-usb, I don't think that should cause an issue should it? Thanks for any help, David C. Churchill 5285 Vinings Springs Trl Mableton, GA 30126 770.819.5935 d_churchill at comcast.net From philip.homburg at ripe.net Thu Aug 8 15:04:44 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 08 Aug 2013 15:04:44 +0200 Subject: [atlas] Multiple Probe v3 Disconnects In-Reply-To: <001501ce9431$8d03fc00$a70bf400$@net> References: <001501ce9431$8d03fc00$a70bf400$@net> Message-ID: <5203976C.1080604@ripe.net> Hi David, On 2013/08/08 14:19 , David Churchill wrote: > I just received my v3 probe 3 days ago and I've noticed on the status page > that that there are quite a few disconnects: > > Disconnect at: Connected time: Disconnected time: > (still connected) 0d, 0h, 30m (still connected) > 2013-08-08 11:37:44 UTC 0d, 0h, 38m 0d, 0h, 2m > 2013-08-08 10:49:09 UTC 0d, 1h, 14m 0d, 0h, 10m > 2013-08-08 09:31:38 UTC 0d, 2h, 2m 0d, 0h, 3m [...] > Is this something I should be concerned about? If so, could it have to do > with the fact that my probe is plugged into a 10/100/1000 MBit switch (I saw > an earlier thread that suggested this might be an issue)? If the Gigabit > switch is a problem, would it help if I cascade a 10/100 switch off one of > the Gigabit switch's ports, or off one of my router's ports (which are all > Gigabit) and then plug the probe into that 10/100 switch? Finally, I'm > using a cell phone charger for power, it's 5V, mini-usb, I don't think that > should cause an issue should it? > > The probe seems to have a problem staying connected to it controller. It could be an IPv6 problem between Comcast and Hetzner. I don't think it is a local problem. I'm not aware of any ethernet related issues, or than that if you have a switch that only does 1Gbps, then a probe can't connect. Philip From folkert at vanheusden.com Thu Aug 8 16:01:34 2013 From: folkert at vanheusden.com (folkert) Date: Thu, 8 Aug 2013 16:01:34 +0200 Subject: [atlas] Multiple Probe v3 Disconnects In-Reply-To: <5203976C.1080604@ripe.net> References: <001501ce9431$8d03fc00$a70bf400$@net> <5203976C.1080604@ripe.net> Message-ID: <20130808140129.GB29890@belle.intranet.vanheusden.com> > The probe seems to have a problem staying connected to it controller. It > could be an IPv6 problem between Comcast and Hetzner. > I don't think it is a local problem. This morning I also got an e-mail from the probe that it had lost connectivity for over a day. Yesterdayevening I saw only 2 leds blinking so I rebooted it. My internet connection has not been down for the last 1.5 days (I monitor that). It has number: 12263 Folkert van Heusden -- Always wondered what the latency of your webserver is? Or how much more latency you get when you go through a proxy server/tor? The numbers tell the tale and with HTTPing you know them! http://www.vanheusden.com/httping/ ----------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com From fearghas at gmail.com Thu Aug 8 16:39:34 2013 From: fearghas at gmail.com (Fearghas McKay) Date: Thu, 8 Aug 2013 15:39:34 +0100 Subject: [atlas] Probe sharing In-Reply-To: <52036F2F.7000008@ripe.net> References: <20130808095401.GA10342@moon.uakom.sk> <52036F2F.7000008@ripe.net> Message-ID: <55052F15-DB14-4AF0-BDDB-2AD13386BFF6@gmail.com> On 8 Aug 2013, at 11:13, Robert Kisteleki wrote: > This function should work in general; in order for us to look into the > specifics please drop us a mail with details (probe id, your and your > colleague's account/email) to atlas at ripe.net Is this feature going to be spread wider than just LIRs ? ie to the non-RIPE regions and non-NCC networks in the RIPE region ? f From philip.homburg at ripe.net Thu Aug 8 17:02:25 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 08 Aug 2013 17:02:25 +0200 Subject: [atlas] Multiple Probe v3 Disconnects In-Reply-To: <20130808140129.GB29890@belle.intranet.vanheusden.com> References: <001501ce9431$8d03fc00$a70bf400$@net> <5203976C.1080604@ripe.net> <20130808140129.GB29890@belle.intranet.vanheusden.com> Message-ID: <5203B301.4000007@ripe.net> Hi Folkert, On 2013/08/08 16:01 , folkert wrote: >> The probe seems to have a problem staying connected to it controller. It >> could be an IPv6 problem between Comcast and Hetzner. >> I don't think it is a local problem. > This morning I also got an e-mail from the probe that it had lost > connectivity for over a day. Yesterdayevening I saw only 2 leds blinking > so I rebooted it. > My internet connection has not been down for the last 1.5 days (I > monitor that). > > It has number: 12263 > > Can you try pinging the probe? Does it still have two LEDs blinking? That usually indicates a local network problem. Philip From robert at ripe.net Thu Aug 8 17:04:06 2013 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 08 Aug 2013 17:04:06 +0200 Subject: [atlas] Probe sharing In-Reply-To: <55052F15-DB14-4AF0-BDDB-2AD13386BFF6@gmail.com> References: <20130808095401.GA10342@moon.uakom.sk> <52036F2F.7000008@ripe.net> <55052F15-DB14-4AF0-BDDB-2AD13386BFF6@gmail.com> Message-ID: <5203B366.1070302@ripe.net> On 2013.08.08. 16:39, Fearghas McKay wrote: > > On 8 Aug 2013, at 11:13, Robert Kisteleki wrote: > >> This function should work in general; in order for us to look into the >> specifics please drop us a mail with details (probe id, your and your >> colleague's account/email) to atlas at ripe.net > > Is this feature going to be spread wider than just LIRs ? ie to the non-RIPE regions and non-NCC networks in the RIPE region ? > > f Hi, There's a feature on the "requested" list (see roadmap.ripe.net) about sharing the probe with ad-hoc groups. Its priority, of course, depends on how many people ask for this and how loudly, in relation to other requests :-) Cheers, Robert From folkert at vanheusden.com Thu Aug 8 17:07:58 2013 From: folkert at vanheusden.com (folkert) Date: Thu, 8 Aug 2013 17:07:58 +0200 Subject: [atlas] Multiple Probe v3 Disconnects In-Reply-To: <5203B301.4000007@ripe.net> References: <001501ce9431$8d03fc00$a70bf400$@net> <5203976C.1080604@ripe.net> <20130808140129.GB29890@belle.intranet.vanheusden.com> <5203B301.4000007@ripe.net> Message-ID: <20130808150758.GC29890@belle.intranet.vanheusden.com> > >> The probe seems to have a problem staying connected to it controller. It > >> could be an IPv6 problem between Comcast and Hetzner. > >> I don't think it is a local problem. > > This morning I also got an e-mail from the probe that it had lost > > connectivity for over a day. Yesterdayevening I saw only 2 leds blinking > > so I rebooted it. > > My internet connection has not been down for the last 1.5 days (I > > monitor that). > > > > It has number: 12263 > Can you try pinging the probe? Does it still have two LEDs blinking? > That usually indicates a local network problem. I can't ping it. All other hosts on that switch can be pinged though. I also tried unplugging and replugging it. Did not help. Folkert van Heusden -- www.vanheusden.com/multitail - win een vlaai van multivlaai! zorg ervoor dat multitail opgenomen wordt in Fedora Core, AIX, Solaris of HP/UX en win een vlaai naar keuze ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com From tapio.sokura at iki.fi Thu Aug 8 19:41:29 2013 From: tapio.sokura at iki.fi (Tapio Sokura) Date: Thu, 08 Aug 2013 20:41:29 +0300 Subject: [atlas] Probe sharing In-Reply-To: <5203B366.1070302@ripe.net> References: <20130808095401.GA10342@moon.uakom.sk> <52036F2F.7000008@ripe.net> <55052F15-DB14-4AF0-BDDB-2AD13386BFF6@gmail.com> <5203B366.1070302@ripe.net> Message-ID: <5203D849.2000004@iki.fi> Hi, On 8.8.2013 18:04, Robert Kisteleki wrote: > There's a feature on the "requested" list (see roadmap.ripe.net) about > sharing the probe with ad-hoc groups. Its priority, of course, depends on > how many people ask for this and how loudly, in relation to other requests :-) Ok, here's one more request to add to that queue :-) A few days ago I installed a probe at a server facility, and would like to share all the data that is visible to me for that probe with other people present on the same network/facility. Relate to the above, is there an http link I can share that would directly lead to a certain (public) probe's measurement results/graph page? Without requiring logging in? I see there's the API system that can be used to fetch at least raw data, but can it supply rendered graphs? Also I'm having a bit of trouble getting the probe to use a statically configured IP address, when there is DHCP also available in the same network. Is this by design, by chance or is something wrong? The statically configured data should be ok, but "my probe" page says the probe is not using it. For IPv6 I'd like to be able to manually specify the address to use, but use the RAs to determine gateways. Tapio From axel.fischer at 1und1.de Wed Aug 14 14:27:56 2013 From: axel.fischer at 1und1.de (Axel Fischer) Date: Wed, 14 Aug 2013 14:27:56 +0200 Subject: [atlas] v3 Probe got disconnected and won't reconnect Message-ID: <520B77CC.40800@1und1.de> Hi, on 2013-08-11 at 05:15:30 UTC one of our probes (ID: 11707) got disconnected. It is connected via a switch to a router within our network. I can see the link up (it remained up all the time) but see the 3rd LED (Network Test) and 4th LED (Connecting) blinking. The MAC was visible on the switch port and router. I powercycled the probe but no change except that the MAC is no longer visible on the router. With a laptop instead of the probe it works fine. Is the probe broken? How can this state be fixed? Regards, Axel -- Axel Fischer Network Engineer 1&1 Internet AG Brauerstrasse 48 D-76135 Karlsruhe http://www.1und1.de (AS8560) Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 6484 Vorstand: Ralph Dommermuth, Frank Einhellinger, Robert Hoffmann, Andreas Hofmann, Markus Huhn, Hans-Henning Kettler, Uwe Lamnek, Jan Oetjen, Christian W?rst Aufsichtsratsvorsitzender: Michael Scheeren Member of United Internet Diese E-Mail kann vertrauliche und/oder gesetzlich gesch?tzte Informationen enthalten. Wenn Sie nicht der bestimmungsgem??e Adressat sind oder diese E-Mail irrt?mlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese Email. Anderen als dem bestimmungsgem??en Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This E-Mail may contain confidential and/or privileged information. If you are not the intended recipient of this E-Mail, you are hereby notified that saving, distribution or use of the content of this E-Mail in any way is prohibited. If you have received this E-Mail in error, please notify the sender and delete the E-Mail. From anonym.tsk at gmail.com Wed Aug 14 14:39:23 2013 From: anonym.tsk at gmail.com (=?KOI8-R?B?7snLz8zByiD3wdPJzNje1cs=?=) Date: Wed, 14 Aug 2013 16:39:23 +0400 Subject: [atlas] v3 Probe got disconnected and won't reconnect In-Reply-To: <520B77CC.40800@1und1.de> References: <520B77CC.40800@1und1.de> Message-ID: My probe (10234) too is not reconnected after disconnect. 2013/8/14 Axel Fischer > Hi, > on 2013-08-11 at 05:15:30 UTC one of our probes (ID: 11707) got > disconnected. > It is connected via a switch to a router within our network. I can see the > link > up (it remained up all the time) but see the 3rd LED (Network Test) and > 4th LED > (Connecting) blinking. The MAC was visible on the switch port and router. > I powercycled the probe but no change except that the MAC is no longer > visible > on the router. With a laptop instead of the probe it works fine. > > Is the probe broken? How can this state be fixed? > > > Regards, > Axel > > -- > Axel Fischer > Network Engineer > > 1&1 Internet AG > Brauerstrasse 48 > D-76135 Karlsruhe > > http://www.1und1.de (AS8560) > > Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 6484 > > Vorstand: Ralph Dommermuth, Frank Einhellinger, Robert Hoffmann, > Andreas Hofmann, Markus Huhn, Hans-Henning Kettler, Uwe Lamnek, > Jan Oetjen, Christian W?rst > Aufsichtsratsvorsitzender: Michael Scheeren > > Member of United Internet > > Diese E-Mail kann vertrauliche und/oder gesetzlich gesch?tzte Informationen > enthalten. Wenn Sie nicht der bestimmungsgem??e Adressat sind oder diese > E-Mail > irrt?mlich erhalten haben, unterrichten Sie bitte den Absender und > vernichten > Sie diese Email. Anderen als dem bestimmungsgem??en Adressaten ist > untersagt, > diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche > Weise > auch immer zu verwenden. > > This E-Mail may contain confidential and/or privileged information. If you > are > not the intended recipient of this E-Mail, you are hereby notified that > saving, > distribution or use of the content of this E-Mail in any way is > prohibited. If > you have received this E-Mail in error, please notify the sender and > delete the > E-Mail. > > -- ? ?????????, ????????? ???????. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Wed Aug 14 16:24:49 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 14 Aug 2013 16:24:49 +0200 Subject: [atlas] v3 Probe got disconnected and won't reconnect In-Reply-To: <520B77CC.40800@1und1.de> References: <520B77CC.40800@1und1.de> Message-ID: <520B9331.8000608@ripe.net> Hi, On 2013/08/14 14:27 , Axel Fischer wrote: > on 2013-08-11 at 05:15:30 UTC one of our probes (ID: 11707) got disconnected. > It is connected via a switch to a router within our network. I can see the link > up (it remained up all the time) but see the 3rd LED (Network Test) and 4th LED > (Connecting) blinking. The MAC was visible on the switch port and router. > I powercycled the probe but no change except that the MAC is no longer visible > on the router. With a laptop instead of the probe it works fine. > > Is the probe broken? How can this state be fixed? > In general it is better to create a ticket by sending mail to atlas at ripe.net. Can you try pinging the probe? Moving the probe to a network that has DHCP would allow you to see if the probe does anything at all (send DHCP discovers and request) Philip From marco.davids at sidn.nl Tue Aug 20 13:18:55 2013 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Tue, 20 Aug 2013 13:18:55 +0200 Subject: [atlas] Geo locations confirmed Message-ID: <5213509F.7000608@sidn.nl> Hi, Are any of the geo-locations of Atlas probes confirmed, double-checked, or verified by RIPE? Or do we just have to take for granted, whatever the owner of the probe enters in the probe's settings ? Thanks, -- Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4225 bytes Desc: S/MIME Cryptographic Signature URL: From robert at ripe.net Tue Aug 20 13:43:35 2013 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 20 Aug 2013 13:43:35 +0200 Subject: [atlas] Geo locations confirmed In-Reply-To: <5213509F.7000608@sidn.nl> References: <5213509F.7000608@sidn.nl> Message-ID: <52135667.9030501@ripe.net> On 2013.08.20. 13:18, Marco Davids (SIDN) wrote: > Hi, > > Are any of the geo-locations of Atlas probes confirmed, double-checked, > or verified by RIPE? Or do we just have to take for granted, whatever > the owner of the probe enters in the probe's settings ? > > Thanks, > Hi, Generally speaking, we believe what the users claim as the probe's geolocation. However, we also have an internal process to check this against a geoip database (Maxmind). In the vast majority of the cases the results match; the biggest discrepancy is usually because the hosts give relatively precise information and Maxmind is, in many cases, "country only". We do see some odd cases though, which may be because the hosts... khm, "misrepresent the facts", or the probe has been moved from its initial location, or the geoip database is wrong. We also plan to use actual ("anchoring") measurements to help us decide what the reason is. Bottom line: for practical purposes we take the hosts' input for granted and we could disclose more findings if the community wants us to. Regards, Robert From tom.kac at gmail.com Thu Aug 22 17:26:46 2013 From: tom.kac at gmail.com (Tom Kacprzynski) Date: Thu, 22 Aug 2013 10:26:46 -0500 Subject: [atlas] IPv6 Report - Blank Message-ID: Hello, Is anyone else having the issue of downloading IPv6 measurement reports? I ran few of them and the file is empty. I tried downloading both formats JSON and Fragment. I also tried downloading the public measurement without any luck either. Thanks -- *Tom Kacprzynski* -------------- next part -------------- An HTML attachment was scrubbed... URL: From dquinn at ripe.net Thu Aug 22 18:47:03 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Thu, 22 Aug 2013 18:47:03 +0200 Subject: [atlas] IPv6 Report - Blank In-Reply-To: References: Message-ID: <52164087.5040107@ripe.net> Tom and I have been talking about this off-list, and it appears that some of the measurements in question were just taking longer than expected to populate. However there were a few measurements that did in fact appear empty and we're looking into it. It should be noted though that the data is being logged, just not coming out through the API. Unfortunately, as it's 1845h here in Amsterdam, the earliest we can visit this is tomorrow. I'll keep the list updated with what we find. From tom.kac at gmail.com Thu Aug 22 18:49:20 2013 From: tom.kac at gmail.com (Tom Kacprzynski) Date: Thu, 22 Aug 2013 11:49:20 -0500 Subject: [atlas] IPv6 Report - Blank In-Reply-To: <52164087.5040107@ripe.net> References: <52164087.5040107@ripe.net> Message-ID: Daniel Thank you for looking into this. Tom On Thursday, August 22, 2013, Daniel Quinn wrote: > Tom and I have been talking about this off-list, and it appears that some > of the measurements in question were just taking longer than expected to > populate. However there were a few measurements that did in fact appear > empty and we're looking into it. It should be noted though that the data > is being logged, just not coming out through the API. > > Unfortunately, as it's 1845h here in Amsterdam, the earliest we can visit > this is tomorrow. I'll keep the list updated with what we find. > > -- *Tom Kacprzynski* *CCIE#36159* http://kemot-net.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From BECHA at ripe.net Fri Aug 23 11:14:23 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 23 Aug 2013 11:14:23 +0200 Subject: [atlas] On RIPE Labs: Future of the RIPE NCC technical services Message-ID: <521727EF.1070405@ripe.net> Dear colleagues, please take a look at the Labs article by Kaveh Ranjbar, which touches upon the future of the RIPE Atlas services: https://labs.ripe.net/Members/kranjbar/future-of-ripe-ncc-technical-services Regards, Vesna From robert at ripe.net Fri Aug 23 12:35:19 2013 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 23 Aug 2013 12:35:19 +0200 Subject: [atlas] Crediting for probe uptime Message-ID: <52173AE7.2050606@ripe.net> Dear All, In the last two days we noticed a hickup in the crediting procedure (the one that gives credits to probe hosts and sponsors). We believe the proper fix is in place now. We just finished crediting everyone for the time period in question, which means all of the probes generated more than usual credits -- compensating for the missing ones lately, and some interest :-) We apologise for the inconvenience this may have caused. Regards, Robert Kisteleki From micha at fakenet.eu.org Mon Aug 26 01:28:03 2013 From: micha at fakenet.eu.org (Michael Stevens) Date: Mon, 26 Aug 2013 01:28:03 +0200 Subject: [atlas] Garbage Measurements Message-ID: Hello, at the moment I'm seeing a lot of measurements on my both probes, that doesn't have any live target and, sometimes, have even invalid targets like 2001:db8:0:dead:beef::1 which is part of the IPv6 for documentation purposes. I've made a screenshot here: http://i.imgur.com/PRXHsOZ.png Can someone from RIPE check this out? Not sure if there is someone abusing RIPE Atlas in a nasty way. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Mon Aug 26 02:37:34 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 26 Aug 2013 02:37:34 +0200 Subject: [atlas] Garbage Measurements In-Reply-To: References: Message-ID: <521AA34E.4050501@ripe.net> Hi Michael, On 2013/08/26 1:28 , Michael Stevens wrote: > > at the moment I'm seeing a lot of measurements on my both probes, that > doesn't have any live target and, sometimes, have even invalid targets > like 2001:db8:0:dead:beef::1 which is part of the IPv6 for > documentation purposes. I've made a screenshot here: > http://i.imgur.com/PRXHsOZ.png > > Can someone from RIPE check this out? Not sure if there is someone > abusing RIPE Atlas in a nasty way. > I have no idea what the purpose is of those measurements. But user that created them does get charged for the results. And probes return results. So from that point of view nothing is wrong. Philip From pk at DENIC.DE Mon Aug 26 08:52:07 2013 From: pk at DENIC.DE (Peter Koch) Date: Mon, 26 Aug 2013 08:52:07 +0200 Subject: [atlas] Garbage Measurements In-Reply-To: <521AA34E.4050501@ripe.net> References: <521AA34E.4050501@ripe.net> Message-ID: <20130826065207.GB31167@x28.adm.denic.de> On Mon, Aug 26, 2013 at 02:37:34AM +0200, Philip Homburg wrote: > I have no idea what the purpose is of those measurements. But user that > created them does get charged for the results. And probes return > results. So from that point of view nothing is wrong. maybe it's time to compile a filter list to counter reconnaissance of thge probes' network vicinity, which I don't think was the stated purpose of the Atlas project. -Peter From andra.lutu at imdea.org Mon Aug 26 10:23:33 2013 From: andra.lutu at imdea.org (Andra Lutu) Date: Mon, 26 Aug 2013 10:23:33 +0200 Subject: [atlas] Garbage Measurements In-Reply-To: <20130826065207.GB31167@x28.adm.denic.de> References: <521AA34E.4050501@ripe.net> <20130826065207.GB31167@x28.adm.denic.de> Message-ID: <521B1085.4070907@imdea.org> Dear all, The culprit for the high number of tests running on the RIPE Atlas platform would be me. I do apologize for not sending a notification prior to deploying the tests, we do understand that we are looking at quite a massive number of measurements. We are currently trying to slow down the rhythm of the traceroutes, in an effort to not be so aggressive. The purpose of the measurements is to establish the reachability of the limited-visibility IPv6 prefixes we were able to identify using the BGP Visibility Scanner. The measurements are a part of our efforts of enhancing our understanding on the results of the visibility tool for IPv6 prefixes. The RIPE Atlas team was kind enough to help us with our research and allowed us to use the Atlas platform. For more information about the BGP Visibility project, I kindly refer you to http://visibility.it.uc3m.es/ We've previously focused on the visibility of the IPv4 prefixes, please find a more detailed view on our results in the following RIPE Labs article: https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner For any further inquiries, do not hesitate to contact us! I do apologize for any distress this might have caused! For the future, we will try to notify before deploying another large number of tests! Thank you, best regards, Andra -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Mon Aug 26 13:32:19 2013 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 26 Aug 2013 13:32:19 +0200 Subject: [atlas] Garbage Measurements In-Reply-To: <20130826065207.GB31167@x28.adm.denic.de> References: <521AA34E.4050501@ripe.net> <20130826065207.GB31167@x28.adm.denic.de> Message-ID: <521B3CC3.5060207@ripe.net> Hello, On 2013.08.26. 8:52, Peter Koch wrote: > On Mon, Aug 26, 2013 at 02:37:34AM +0200, Philip Homburg wrote: > >> I have no idea what the purpose is of those measurements. But user that >> created them does get charged for the results. And probes return >> results. So from that point of view nothing is wrong. > > maybe it's time to compile a filter list to counter reconnaissance of > thge probes' network vicinity, which I don't think was the stated purpose > of the Atlas project. > > -Peter Indeed, we do exclude the "probes' network vicinity", as you called it. At the moment, this is the exclusion list: exclude4 = ('PRIVATE', 'RESERVED') exclude6 = ('LINKLOCAL', 'UNSPECIFIED', 'LOOPBACK', 'MULTICAST') (The above acronyms are defined in the IPy Python module, see https://github.com/haypo/python-ipy/blob/master/IPy.py for details.) Please speak up if you have justification for other networks to be excluded. Note that it's very difficult to apply the above filters to perfection; a sophisticated enough user may be able to find ways around it. Retards, Robert From andra.lutu at imdea.org Mon Aug 26 15:39:58 2013 From: andra.lutu at imdea.org (Andra Lutu) Date: Mon, 26 Aug 2013 15:39:58 +0200 Subject: [atlas] Garbage Measurements In-Reply-To: <521B1085.4070907@imdea.org> References: <521AA34E.4050501@ripe.net> <20130826065207.GB31167@x28.adm.denic.de> <521B1085.4070907@imdea.org> Message-ID: <521B5AAE.9010306@imdea.org> Hi, We will soon be resuming our measurements using the RIPE Atlas platform. We've scheduled the traceroutes to one every 18 seconds (a more uniform distribution than the previous approach of batches of 100 tests every 30 minutes), to address the concerns regarding the load we put on the system. We still have about 1,300 target addresses to test, so the total duration of the measurements is estimated to approx. 7 hours (i.e., scheduled to start at 16h00 CET -- with expected finishing time at around 23h00 CET). We do apologize for any inconvenience! For any further comments, inquiries, suggestions etc., do not hesitate to contact us! Thank you, best regards, Andra On 08/26/2013 10:23 AM, Andra Lutu wrote: > Dear all, > > The culprit for the high number of tests running on the RIPE Atlas > platform would be me. > I do apologize for not sending a notification prior to deploying the > tests, we do understand that we are looking at quite a massive number > of measurements. > We are currently trying to slow down the rhythm of the traceroutes, in > an effort to not be so aggressive. > > The purpose of the measurements is to establish the reachability of > the limited-visibility IPv6 prefixes we were able to identify using > the BGP Visibility Scanner. > The measurements are a part of our efforts of enhancing our > understanding on the results of the visibility tool for IPv6 prefixes. > The RIPE Atlas team was kind enough to help us with our research and > allowed us to use the Atlas platform. > For more information about the BGP Visibility project, I kindly refer > you to http://visibility.it.uc3m.es/ > We've previously focused on the visibility of the IPv4 prefixes, > please find a more detailed view on our results in the following RIPE > Labs article: > https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner > > For any further inquiries, do not hesitate to contact us! > I do apologize for any distress this might have caused! > For the future, we will try to notify before deploying another large > number of tests! > > Thank you, best regards, > Andra > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dquinn at ripe.net Tue Aug 27 10:49:16 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Tue, 27 Aug 2013 10:49:16 +0200 Subject: [atlas] Reddit? Message-ID: <521C680C.9040608@ripe.net> Hello everyone, I'm one of the developers on the RIPE Atlas project and I'm hoping some of you can help me figure out if we should have a presence on [Reddit](http://www.reddit.com/) and if so, where. I'm a pretty active member of that community, so I was appointed to ask the lot of you if we should bother setting up a subreddit, or if we should just frequent any particular subreddit to answer questions and/or promote RIPE Atlas. So, does anyone reading this fancy the idea of better outreach on Reddit? And if so, in what way would you recommend? Feel free to post your responses to the list, or just respond to me directly. We'll let you know if we decide to branch out in this way. From BECHA at ripe.net Tue Aug 27 16:59:50 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 27 Aug 2013 16:59:50 +0200 Subject: [atlas] Success stories to share at RIPE67? In-Reply-To: <521B45D3.1090108@NLnetLabs.nl> References: <521B45D3.1090108@NLnetLabs.nl> Message-ID: <521CBEE6.4050308@ripe.net> Hi RIPE Atlas active hosts & users, I know of two RIPE Atlas related talks that are still being considered for RIPE67 -- and there might be more! Do you have a success story to share? Plenary-talks CallForPapers is extended, and then there are working-group sessions too, MAT-wg being the most typical, but in the past there were presentations on using RIPE Atlas in IPv6-WG and DNS, and Routing-WG... If you need help with preparing slides, or doing extra measurements to prove your tests - do let us know! Good luck if you decide to present, and see you at RIPE67! Regards, Vesna -------- Original Message -------- Dear Colleagues, A list of currently accepted RIPE 67 Plenary talks, BoFs, Tutorials and Workshops is now published at: https://ripe67.ripe.net/programme/meeting-plan/draft-programme/ There are still few slots remaining for a final RIPE 67 programme and RIPE Programme Committee will accept new proposals until *9 September 2013*. This is our last call for you to submit your proposals. See https://ripe67.ripe.net/programme/cfp/ or find the original CFP below. Kind regards Filiz Yilmaz for RIPE Programme Committee ------------------ Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 67 will take place from 14-18 October 2013 in Athens, Greece. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 67. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: * IPv6 deployment * Managing IPv4 scarcity in operations * Commercial transactions of IPv4 addresses * Data centre technologies * Network and DNS operations * Internet governance and regulatory practices * Network and routing security * Content delivery * Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at https://ripe67.ripe.net/programme/i-want-to-present/presentation-formats/ Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the plenary, the RIPE PC also offers several time slots for "lightning talks", which are selected immediately before or during the conference. The following general requirements apply: * Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 4 August 2013, using the meeting submission system (https://ripe67.ripe.net/submit-topic/). Proposals submitted after this date will be considered on a space-available basis. * Lightning talks should also be submitted using the meeting submission system (https://ripe67.ripe.net/submit-topic/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice - in some cases on the same day but often one day prior to the relevant session. * Presenters should indicate how much time they will require. See more information on time slot allocations per presentation format (https://ripe67.ripe.net/programme/i-want-to-present/presentation-formats/) * Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panelists, presenters and moderators. * Due to potential technical issues, it is expected that most, if not all, presenters/panelists will be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. From warren at kumari.net Tue Aug 27 23:49:00 2013 From: warren at kumari.net (Warren Kumari) Date: Tue, 27 Aug 2013 17:49:00 -0400 Subject: [atlas] Disabling one measurement on my probe... Message-ID: Hi all, Due to much stupidity my probe lives behind 2 NATs (don't ask). Anyway, one of the NATs / firewalls is suddenly throwing hissyfits and logging a bunch of messages like: [00005] 2013-08-27 17:33:29 [Root]system-critical-00435: ICMP fragment! From 78.46.37.134 to 192.168.15.207, proto 1 (zone Untrust, int ethernet3). Occurred 2 times. I can see the Measurement IDs that are causing this (1019675, 1019728), but I have two questions: 1: is there a way to disable specific measurements from a specific probe and 2: did anything change recently with the "Ping" measurement, like the packet size for example? I *did* spend some time reading the list archives and documentation, but was not able to find an answer. W P.S: And yes, I will sometime remove the NATs, but cannot until there is another ISP available -- I live in a 3rd world country where any broadened is a luxury, and multiple providers is more than one can reasonably expect? -- "When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie." -- Terry Pratchett From andrewbosch at comcast.net Wed Aug 28 02:10:57 2013 From: andrewbosch at comcast.net (Andrew Bosch) Date: Tue, 27 Aug 2013 19:10:57 -0500 Subject: [atlas] Reddit? In-Reply-To: <521C680C.9040608@ripe.net> References: <521C680C.9040608@ripe.net> Message-ID: <521D4011.2040707@comcast.net> On 8/27/2013 3:49 AM, Daniel Quinn wrote: > Hello everyone, I'm one of the developers on the RIPE Atlas project and > I'm hoping some of you can help me figure out if we should have a > presence on [Reddit](http://www.reddit.com/) and if so, where. I'm a > pretty active member of that community, so I was appointed to ask the > lot of you if we should bother setting up a subreddit, or if we should > just frequent any particular subreddit to answer questions and/or > promote RIPE Atlas. > > So, does anyone reading this fancy the idea of better outreach on > Reddit? And if so, in what way would you recommend? Feel free to post > your responses to the list, or just respond to me directly. We'll let > you know if we decide to branch out in this way. > > Does the Atlas project have a presence on Google+? From listclient at sokolov.eu.org Wed Aug 28 04:01:13 2013 From: listclient at sokolov.eu.org (Daniel AJ Sokolov (lists)) Date: Tue, 27 Aug 2013 23:01:13 -0300 Subject: [atlas] Reddit? In-Reply-To: <521C680C.9040608@ripe.net> References: <521C680C.9040608@ripe.net> Message-ID: <521D59E9.3040402@sokolov.eu.org> I don't see the point of a Reddit presence. >From my point of view, I'd rather see resources allocated to attract users in areas where very few or no probes are installed. For example, is there an African equivalent to Reddit? What about South America? Not that I'm involved in the project in any further way than hosting a probe. So these are just my 2 cents. BR Daniel AJ On 2013-08-27 05:49 wrote Daniel Quinn: > Hello everyone, I'm one of the developers on the RIPE Atlas project and > I'm hoping some of you can help me figure out if we should have a > presence on [Reddit](http://www.reddit.com/) and if so, where. I'm a > pretty active member of that community, so I was appointed to ask the > lot of you if we should bother setting up a subreddit, or if we should > just frequent any particular subreddit to answer questions and/or > promote RIPE Atlas. > > So, does anyone reading this fancy the idea of better outreach on > Reddit? And if so, in what way would you recommend? Feel free to post > your responses to the list, or just respond to me directly. We'll let > you know if we decide to branch out in this way. > > From astrikos at ripe.net Wed Aug 28 07:51:17 2013 From: astrikos at ripe.net (Andreas Strikos) Date: Wed, 28 Aug 2013 07:51:17 +0200 Subject: [atlas] Disabling one measurement on my probe... In-Reply-To: References: Message-ID: <521D8FD5.4000905@ripe.net> Hi Warren, On 8/27/13 11:49 PM, Warren Kumari wrote: > Hi all, > > Due to much stupidity my probe lives behind 2 NATs (don't ask). > Anyway, one of the NATs / firewalls is suddenly throwing hissyfits and logging a bunch of messages like: > [00005] 2013-08-27 17:33:29 [Root]system-critical-00435: ICMP fragment! From 78.46.37.134 to 192.168.15.207, proto 1 (zone Untrust, int ethernet3). Occurred 2 times. > > I can see the Measurement IDs that are causing this (1019675, 1019728), but I have two questions: > 1: is there a way to disable specific measurements from a specific probe and No there is not an easy way yet, although we are working on it and users will be able to add/remove probes. Anyhow, from what I see these two UDMs are already stopped so you shouldn't have any more cases with these two. > 2: did anything change recently with the "Ping" measurement, like the packet size for example? Among other options[1] user can change the packet size and from what I see it's 48bytes for the first one 1485 for the second. > > I *did* spend some time reading the list archives and documentation, but was not able to find an answer. > > W > P.S: And yes, I will sometime remove the NATs, but cannot until there is another ISP available -- I live in a 3rd world country where any broadened is a luxury, and multiple providers is more than one can reasonably expect? > > > > -- > "When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie." > -- Terry Pratchett > > > > > Regards, Andreas [*] You can see the different options users can set for the ping UDMs if you scroll a bit down on this page https://atlas.ripe.net/doc/udm#creating-a-new-measurement From emile.aben at ripe.net Wed Aug 28 09:00:44 2013 From: emile.aben at ripe.net (Emile Aben) Date: Wed, 28 Aug 2013 09:00:44 +0200 Subject: [atlas] Disabling one measurement on my probe... In-Reply-To: <521D8FD5.4000905@ripe.net> References: <521D8FD5.4000905@ripe.net> Message-ID: <521DA01C.8040505@ripe.net> Hi Warren, >> Due to much stupidity my probe lives behind 2 NATs (don't ask). >> Anyway, one of the NATs / firewalls is suddenly throwing hissyfits and >> logging a bunch of messages like: >> [00005] 2013-08-27 17:33:29 [Root]system-critical-00435: ICMP >> fragment! From 78.46.37.134 to 192.168.15.207, proto 1 (zone Untrust, >> int ethernet3). Occurred 2 times. >> >> I can see the Measurement IDs that are causing this (1019675, >> 1019728), but I have two questions: >> 1: is there a way to disable specific measurements from a specific >> probe and > No there is not an easy way yet, although we are working on it and users > will be able to add/remove probes. > Anyhow, from what I see these two UDMs are already stopped so you > shouldn't have any more cases with these two. >> 2: did anything change recently with the "Ping" measurement, like the >> packet size for example? > Among other options[1] user can change the packet size and from what I > see it's 48bytes for the first one 1485 for the second. I'm the culprit here. I did start a couple of UDM measurements with large packet-sizes to try and provide some data from what RIPE Atlas sees when sending fragmented packets (this is a discussion on the NANOG-list currently), and apparently your probe is one of the cases it caught (though the log message doesn't specify if it blocked the fragments or not). Emile Aben RIPE NCC >> >> I *did* spend some time reading the list archives and documentation, >> but was not able to find an answer. >> >> W >> P.S: And yes, I will sometime remove the NATs, but cannot until there >> is another ISP available -- I live in a 3rd world country where any >> broadened is a luxury, and multiple providers is more than one can >> reasonably expect? >> >> >> >> -- >> "When it comes to glittering objects, wizards have all the taste and >> self-control of a deranged magpie." >> -- Terry Pratchett >> >> >> >> >> > Regards, > Andreas > > [*] You can see the different options users can set for the ping UDMs if > you scroll a bit down on this page > https://atlas.ripe.net/doc/udm#creating-a-new-measurement > From dquinn at ripe.net Thu Aug 29 11:31:30 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Thu, 29 Aug 2013 11:31:30 +0200 Subject: [atlas] Reddit? In-Reply-To: <521D4011.2040707@comcast.net> References: <521C680C.9040608@ripe.net> <521D4011.2040707@comcast.net> Message-ID: <521F14F2.5000701@ripe.net> On 08/28/2013 02:10 AM, Andrew Bosch wrote: > Does the Atlas project have a presence on Google+? Not yet, but our people in Communications tell me that there are plans to go in that direction at some point. From dquinn at ripe.net Thu Aug 29 11:34:39 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Thu, 29 Aug 2013 11:34:39 +0200 Subject: [atlas] Reddit? In-Reply-To: <521D59E9.3040402@sokolov.eu.org> References: <521C680C.9040608@ripe.net> <521D59E9.3040402@sokolov.eu.org> Message-ID: <521F15AF.2000902@ripe.net> On 08/28/2013 04:01 AM, Daniel AJ Sokolov (lists) wrote: > I don't see the point of a Reddit presence. > > >From my point of view, I'd rather see resources allocated to attract > users in areas where very few or no probes are installed. For example, > is there an African equivalent to Reddit? What about South America? > > Not that I'm involved in the project in any further way than hosting a > probe. So these are just my 2 cents. Honestly, I was just curious if there were parts of Reddit that might be discussing network infrastructure that might benefit from some of us talking about Atlas, but from the lack of response so far, it sounds like there's little interest in a RIPE presence there. No worries, I just thought it worth putting to the list :-) From max+ratlml at grobecker.info Thu Aug 29 13:40:28 2013 From: max+ratlml at grobecker.info (Max Grobecker) Date: Thu, 29 Aug 2013 13:40:28 +0200 Subject: [atlas] Data visualization not working? Message-ID: <521F332C.9030009@grobecker.info> Hi, is there any known reason/issue why new created measurements don't visualize the data? I'm pretty sure I ticked the "Visualize Data" box when creating a new measurement, but when I open my new measurement, the "RRD" tab is missing and in the settings the "Visualize" box is unchecked :-( Is it just me or do other people have the same issue? Greetings, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From dquinn at ripe.net Thu Aug 29 13:59:32 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Thu, 29 Aug 2013 13:59:32 +0200 Subject: [atlas] Data visualization not working? In-Reply-To: <521F332C.9030009@grobecker.info> References: <521F332C.9030009@grobecker.info> Message-ID: <521F37A4.3070000@ripe.net> It may be that your measurement exceeds the maximum number of participating probes , but without a measurement id it?s hard to tell. Please drop me a message off-list and I?ll see what I can do for you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at kumari.net Thu Aug 29 21:24:57 2013 From: warren at kumari.net (Warren Kumari) Date: Thu, 29 Aug 2013 15:24:57 -0400 Subject: [atlas] Disabling one measurement on my probe... In-Reply-To: <521DA01C.8040505@ripe.net> References: <521D8FD5.4000905@ripe.net> <521DA01C.8040505@ripe.net> Message-ID: <19D8CA38-DB30-4566-B3A2-13E410530E31@kumari.net> On Aug 28, 2013, at 3:00 AM, Emile Aben wrote: > Hi Warren, > >>> Due to much stupidity my probe lives behind 2 NATs (don't ask). >>> Anyway, one of the NATs / firewalls is suddenly throwing hissyfits and >>> logging a bunch of messages like: >>> [00005] 2013-08-27 17:33:29 [Root]system-critical-00435: ICMP >>> fragment! From 78.46.37.134 to 192.168.15.207, proto 1 (zone Untrust, >>> int ethernet3). Occurred 2 times. >>> >>> I can see the Measurement IDs that are causing this (1019675, >>> 1019728), but I have two questions: >>> 1: is there a way to disable specific measurements from a specific >>> probe and >> No there is not an easy way yet, although we are working on it and users >> will be able to add/remove probes. >> Anyhow, from what I see these two UDMs are already stopped so you >> shouldn't have any more cases with these two. >>> 2: did anything change recently with the "Ping" measurement, like the >>> packet size for example? >> Among other options[1] user can change the packet size and from what I >> see it's 48bytes for the first one 1485 for the second. > > I'm the culprit here. No worries. > I did start a couple of UDM measurements with > large packet-sizes to try and provide some data from what RIPE Atlas > sees when sending fragmented packets (this is a discussion on the > NANOG-list currently), and apparently your probe is one of the cases it > caught (though the log message doesn't specify if it blocked the > fragments or not). I guess I make a good test case then :-) I get a log email for each of the failures, I can easily tell procmail to just send those mails to /dev/null (I'm not at that house, so I cannot tell the firewall to not log) This is interesting / useful research, please don't let my bizarre home network deter you from running tests, etc. I was just interested? W > > Emile Aben > RIPE NCC > >>> >>> I *did* spend some time reading the list archives and documentation, >>> but was not able to find an answer. >>> >>> W >>> P.S: And yes, I will sometime remove the NATs, but cannot until there >>> is another ISP available -- I live in a 3rd world country where any >>> broadened is a luxury, and multiple providers is more than one can >>> reasonably expect? >>> >>> >>> >>> -- >>> "When it comes to glittering objects, wizards have all the taste and >>> self-control of a deranged magpie." >>> -- Terry Pratchett >>> >>> >>> >>> >>> >> Regards, >> Andreas >> >> [*] You can see the different options users can set for the ping UDMs if >> you scroll a bit down on this page >> https://atlas.ripe.net/doc/udm#creating-a-new-measurement >> > -- "Working the ICANN process is like being nibbled to death by ducks, it takes forever, it doesn't make sense, and in the end we're still dead in the water." -- Tom Galvin, VeriSign's vice president for government relations. From max+ratlml at grobecker.info Thu Aug 29 21:42:40 2013 From: max+ratlml at grobecker.info (Max Grobecker) Date: Thu, 29 Aug 2013 21:42:40 +0200 Subject: [atlas] Data visualization not working? In-Reply-To: <521F37A4.3070000@ripe.net> References: <521F332C.9030009@grobecker.info> <521F37A4.3070000@ripe.net> Message-ID: <521FA430.5070506@grobecker.info> Hi, Thank you, It's a private measurement with about 34 Probes, so that is very likely causing the problem ;-) So nevermind... Greetings from Wuppertal, Germany Max Grobecker Am 29.08.2013 13:59, schrieb Daniel Quinn: > It may be that your measurement exceeds the maximum number of > participating probes , but without a > measurement id it?s hard to tell. Please drop me a message off-list and > I?ll see what I can do for you. >