From lorenzo at google.com Sat Jan 2 18:27:57 2016 From: lorenzo at google.com (Lorenzo Colitti) Date: Sun, 3 Jan 2016 02:27:57 +0900 Subject: [atlas] Availability report accuracy Message-ID: Hi, mostly out of curiosity: what sort of accuracy are the numbers in the monthly availability report? For example: the report says that my probe was "connected" 99.95% of the time (down for 20 seconds) in December. What does that mean? That the SSH control connection was not up? That the probe didn't have link? That it couldn't reach any targets? Something else? Cheers, Lorenzo -------------- next part -------------- An HTML attachment was scrubbed... URL: From elektronik at normalzeit.org Sat Jan 2 18:57:15 2016 From: elektronik at normalzeit.org (Gerhard Joch) Date: Sat, 2 Jan 2016 18:57:15 +0100 Subject: [atlas] Availability report accuracy In-Reply-To: References: Message-ID: Hi all, I want to jump into this topic too, but before a Happy New Year to everybody. Was wondering too, for December my probe got an total availability of only 98.17% - and which is in fact not true. I'm on a VDSL line 50 mbit from German Telekom, and every night my router has to re-establish the connection to get a new public IP. According to the log files from my router this whole process takes only a couple of seconds, but in the Monthly probe report from atlas the time between Disconnected and new Connected is around 20 to 30 minutes, see examples below: +---------------------+---------------------+------------+--------------+ | Connected (UTC) | Disconnected (UTC) | Connected | Disconnected | |---------------------+---------------------+------------+--------------+ | 2015-12-26 02:35:51 | 2015-12-27 02:06:06 | 0d 23:30 | 0d 00:27 | | 2015-12-27 02:31:20 | 2015-12-28 02:04:36 | 0d 23:33 | 0d 00:25 | | 2015-12-28 02:39:09 | 2015-12-29 02:04:29 | 0d 23:25 | 0d 00:34 | | 2015-12-29 02:31:40 | 2015-12-30 02:03:09 | 0d 23:31 | 0d 00:27 | And this reports my router (times in CET) 27.12.15 03:07:12 Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen. 27.12.15 03:07:15 Internetverbindung wurde getrennt. 27.12.15 03:07:16 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 87.158.136.176, ... 28.12.15 03:06:02 Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen. 28.12.15 03:06:06 Internetverbindung wurde getrennt. 28.12.15 03:06:08 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 87.158.141.126, ... 29.12.15 03:04:46 Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen. 29.12.15 03:04:49 Internetverbindung wurde getrennt. 29.12.15 03:04:50 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 87.158.145.147, ... How comes this huge difference? Cheers, Gerhard > Am 02.01.2016 um 18:27 schrieb Lorenzo Colitti : > > Hi, > > mostly out of curiosity: what sort of accuracy are the numbers in the monthly availability report? For example: the report says that my probe was "connected" 99.95% of the time (down for 20 seconds) in December. > > What does that mean? That the SSH control connection was not up? That the probe didn't have link? That it couldn't reach any targets? Something else? > > Cheers, > Lorenzo -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinj at mx5.org.uk Sat Jan 2 20:43:21 2016 From: colinj at mx5.org.uk (Colin Johnston) Date: Sat, 2 Jan 2016 19:43:21 +0000 Subject: [atlas] Availability report accuracy In-Reply-To: References: Message-ID: <6EE077CA-A2C5-49A5-A667-E47BE2021551@mx5.org.uk> it would be great to have a virtual probe so i could give it two fttc ethernet connections to overcome ip dhcp forced renew colin Sent from my iPhone > On 2 Jan 2016, at 17:57, Gerhard Joch wrote: > > Hi all, > > I want to jump into this topic too, but before a Happy New Year to everybody. > > Was wondering too, for December my probe got an total availability of only 98.17% - and which is in fact not true. I'm on a VDSL line 50 mbit from German Telekom, and every night my router has to re-establish the connection to get a new public IP. According to the log files from my router this whole process takes only a couple of seconds, but in the Monthly probe report from atlas the time between Disconnected and new Connected is around 20 to 30 minutes, see examples below: > > +---------------------+---------------------+------------+--------------+ > | Connected (UTC) | Disconnected (UTC) | Connected | Disconnected | > |---------------------+---------------------+------------+--------------+ > | 2015-12-26 02:35:51 | 2015-12-27 02:06:06 | 0d 23:30 | 0d 00:27 | > | 2015-12-27 02:31:20 | 2015-12-28 02:04:36 | 0d 23:33 | 0d 00:25 | > | 2015-12-28 02:39:09 | 2015-12-29 02:04:29 | 0d 23:25 | 0d 00:34 | > | 2015-12-29 02:31:40 | 2015-12-30 02:03:09 | 0d 23:31 | 0d 00:27 | > > And this reports my router (times in CET) > > 27.12.15 03:07:12 Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen. > 27.12.15 03:07:15 Internetverbindung wurde getrennt. > 27.12.15 03:07:16 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 87.158.136.176, ... > 28.12.15 03:06:02 Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen. > 28.12.15 03:06:06 Internetverbindung wurde getrennt. > 28.12.15 03:06:08 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 87.158.141.126, ... > 29.12.15 03:04:46 Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen. > 29.12.15 03:04:49 Internetverbindung wurde getrennt. > 29.12.15 03:04:50 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 87.158.145.147, ... > > How comes this huge difference? > > Cheers, > > Gerhard > > > > >> Am 02.01.2016 um 18:27 schrieb Lorenzo Colitti : >> >> Hi, >> >> mostly out of curiosity: what sort of accuracy are the numbers in the monthly availability report? For example: the report says that my probe was "connected" 99.95% of the time (down for 20 seconds) in December. >> >> What does that mean? That the SSH control connection was not up? That the probe didn't have link? That it couldn't reach any targets? Something else? >> >> Cheers, >> Lorenzo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Sun Jan 3 12:56:33 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Sun, 3 Jan 2016 12:56:33 +0100 Subject: [atlas] Availability report accuracy In-Reply-To: References: Message-ID: <56890C71.5070001@ripe.net> On 2016/01/02 18:27 , Lorenzo Colitti wrote: > mostly out of curiosity: what sort of accuracy are the numbers in the > monthly availability report? For example: the report says that my probe > was "connected" 99.95% of the time (down for 20 seconds) in December. > > What does that mean? That the SSH control connection was not up? That > the probe didn't have link? That it couldn't reach any targets? > Something else? The measurement is about the ssh connection. From philip.homburg at ripe.net Sun Jan 3 13:12:51 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Sun, 3 Jan 2016 13:12:51 +0100 Subject: [atlas] Availability report accuracy In-Reply-To: References: Message-ID: <56891043.5040109@ripe.net> On 2016/01/02 18:57 , Gerhard Joch wrote: > I want to jump into this topic too, but before a Happy New Year to > everybody. > > Was wondering too, for December my probe got an total availability of > only 98.17% - and which is in fact not true. I'm on a VDSL line 50 mbit > from German Telekom, and every night my router has to re-establish the > connection to get a new public IP. According to the log files from my > router this whole process takes only a couple of seconds, but in the > Monthly probe report from atlas the time between Disconnected and new > Connected is around 20 to 30 minutes, see examples below: > > +---------------------+---------------------+------------+--------------+ > | Connected (UTC) | Disconnected (UTC) | Connected | Disconnected | > |---------------------+---------------------+------------+--------------+ > | 2015-12-26 02:35:51 | 2015-12-27 02:06:06 | 0d 23:30 | 0d 00:27 | > | 2015-12-27 02:31:20 | 2015-12-28 02:04:36 | 0d 23:33 | 0d 00:25 | > | 2015-12-28 02:39:09 | 2015-12-29 02:04:29 | 0d 23:25 | 0d 00:34 | > | 2015-12-29 02:31:40 | 2015-12-30 02:03:09 | 0d 23:31 | 0d 00:27 | Hi, I'm not completely sure, but I think the problem is that the probe is waiting for a TCP connection timeout. I guess that for some reason the probe doesn't get a TCP RST. Might be a firewall problem somewhere. Philip From steve-ripe.net at nexusuk.org Wed Jan 6 13:23:25 2016 From: steve-ripe.net at nexusuk.org (Steve Hill) Date: Wed, 6 Jan 2016 12:23:25 +0000 Subject: [atlas] Atlas probe offline Message-ID: <568D073D.5080507@nexusuk.org> My Atlas probe (ID 14587) has been showing as offline since December 16th. I can see DHCP requests/replies, it ARPs for the gateway and I can see DNS requests and pings from the probe, and successful replies to all of this traffic being sent back to the probe. e.g.: 12:13:38.790096 IP 192.168.0.115.35404 > 217.146.115.154.53: 2+ AAAA? ctr-nue15.atlas.ripe.net. (42) 12:13:38.797337 IP 217.146.115.154.53 > 192.168.0.115.35404: 2 1/6/12 AAAA 2a01:4f8:120:14ee::2 (482) 12:13:38.798179 IP 192.168.0.115.57785 > 217.146.115.154.53: 3+ A? ctr-nue15.atlas.ripe.net. (42) 12:13:38.799649 IP 217.146.115.154.53 > 192.168.0.115.57785: 3 1/6/12 A 78.46.87.51 (470) 12:14:58.990977 IP 192.168.0.115.37934 > 217.146.115.154.53: 2+ AAAA? IUSB-READONLY.U36.M6466B3B0EC98.sos.atlas.ripe.net. (68) 12:14:59.060132 IP 217.146.115.154.53 > 192.168.0.115.37934: 2 1/1/2 AAAA 2001:67c:2e8:11::c100:1337 (164) 12:14:59.060983 IP 192.168.0.115.57523 > 217.146.115.154.53: 3+ A? IUSB-READONLY.U36.M6466B3B0EC98.sos.atlas.ripe.net. (68) 12:14:59.114915 IP 217.146.115.154.53 > 192.168.0.115.57523: 3 1/1/2 A 193.0.19.55 (152) 12:14:59.115925 IP 192.168.0.115 > 193.0.19.55: ICMP echo request, id 954, seq 0, length 64 12:14:59.142586 IP 193.0.19.55 > 192.168.0.115: ICMP echo reply, id 954, seq 0, length 64 12:15:00.116800 IP 192.168.0.115 > 193.0.19.55: ICMP echo request, id 954, seq 1, length 64 12:15:00.143773 IP 193.0.19.55 > 192.168.0.115: ICMP echo reply, id 954, seq 1, length 64 I can't see any other IPv4 traffic, but I do see IPv6 HTTPS traffic. I'm not sure where to go next with figuring out why the probe seems to have vanished. Any ideas would be greatly appreciated. Many thanks. -- - Steve From vnaumov at ripe.net Wed Jan 6 14:14:38 2016 From: vnaumov at ripe.net (Viktor Naumov) Date: Wed, 6 Jan 2016 14:14:38 +0100 Subject: [atlas] Atlas probe offline In-Reply-To: <568D073D.5080507@nexusuk.org> References: <568D073D.5080507@nexusuk.org> Message-ID: <568D133E.5090603@ripe.net> Hi Steve, You could notice "USB-READONLY". This is the SOS message indicating that probe has a failed flash drive. If you replace it with new flash drive the probe will be back in business. /vty On 1/6/16 1:23 PM, Steve Hill wrote: > > My Atlas probe (ID 14587) has been showing as offline since December > 16th. I can see DHCP requests/replies, it ARPs for the gateway and I > can see DNS requests and pings from the probe, and successful replies > to all of this traffic being sent back to the probe. e.g.: > > 12:13:38.790096 IP 192.168.0.115.35404 > 217.146.115.154.53: 2+ AAAA? > ctr-nue15.atlas.ripe.net. (42) > 12:13:38.797337 IP 217.146.115.154.53 > 192.168.0.115.35404: 2 1/6/12 > AAAA 2a01:4f8:120:14ee::2 (482) > 12:13:38.798179 IP 192.168.0.115.57785 > 217.146.115.154.53: 3+ A? > ctr-nue15.atlas.ripe.net. (42) > 12:13:38.799649 IP 217.146.115.154.53 > 192.168.0.115.57785: 3 1/6/12 > A 78.46.87.51 (470) > 12:14:58.990977 IP 192.168.0.115.37934 > 217.146.115.154.53: 2+ AAAA? > IUSB-READONLY.U36.M6466B3B0EC98.sos.atlas.ripe.net. (68) > 12:14:59.060132 IP 217.146.115.154.53 > 192.168.0.115.37934: 2 1/1/2 > AAAA 2001:67c:2e8:11::c100:1337 (164) > 12:14:59.060983 IP 192.168.0.115.57523 > 217.146.115.154.53: 3+ A? > IUSB-READONLY.U36.M6466B3B0EC98.sos.atlas.ripe.net. (68) > 12:14:59.114915 IP 217.146.115.154.53 > 192.168.0.115.57523: 3 1/1/2 A > 193.0.19.55 (152) > 12:14:59.115925 IP 192.168.0.115 > 193.0.19.55: ICMP echo request, id > 954, seq 0, length 64 > 12:14:59.142586 IP 193.0.19.55 > 192.168.0.115: ICMP echo reply, id > 954, seq 0, length 64 > 12:15:00.116800 IP 192.168.0.115 > 193.0.19.55: ICMP echo request, id > 954, seq 1, length 64 > 12:15:00.143773 IP 193.0.19.55 > 192.168.0.115: ICMP echo reply, id > 954, seq 1, length 64 > > > I can't see any other IPv4 traffic, but I do see IPv6 HTTPS traffic. > I'm not sure where to go next with figuring out why the probe seems to > have vanished. Any ideas would be greatly appreciated. > > Many thanks. > From c.estelmann at gmx.net Wed Jan 6 14:17:29 2016 From: c.estelmann at gmx.net (Estelmann, Christian) Date: Wed, 6 Jan 2016 14:17:29 +0100 Subject: [atlas] Atlas probe offline In-Reply-To: <568D073D.5080507@nexusuk.org> References: <568D073D.5080507@nexusuk.org> Message-ID: <568D13E9.1050302@gmx.net> Hi, your probe is tagged as "readonly flash drive". Disconnect the probe, connect the usb stick to your computer and test it (e.g. delete all partitions, create own partitions and write some data to it). If data can not be written to the usb stick a) disable the write lock, b) replace it by a new one one (4 GB capacity at minimum). Then reconnect the probe (power and ethernet, but without the usb stick), wait 5 minutes and then plug in the usb stick. I hope that helps. Greetings, Christian Am 06.01.2016 um 13:23 schrieb Steve Hill: > > My Atlas probe (ID 14587) has been showing as offline since December > 16th. I can see DHCP requests/replies, it ARPs for the gateway and I > can see DNS requests and pings from the probe, and successful replies to > all of this traffic being sent back to the probe. e.g.: > > 12:13:38.790096 IP 192.168.0.115.35404 > 217.146.115.154.53: 2+ AAAA? > ctr-nue15.atlas.ripe.net. (42) > 12:13:38.797337 IP 217.146.115.154.53 > 192.168.0.115.35404: 2 1/6/12 > AAAA 2a01:4f8:120:14ee::2 (482) > 12:13:38.798179 IP 192.168.0.115.57785 > 217.146.115.154.53: 3+ A? > ctr-nue15.atlas.ripe.net. (42) > 12:13:38.799649 IP 217.146.115.154.53 > 192.168.0.115.57785: 3 1/6/12 A > 78.46.87.51 (470) > 12:14:58.990977 IP 192.168.0.115.37934 > 217.146.115.154.53: 2+ AAAA? > IUSB-READONLY.U36.M6466B3B0EC98.sos.atlas.ripe.net. (68) > 12:14:59.060132 IP 217.146.115.154.53 > 192.168.0.115.37934: 2 1/1/2 > AAAA 2001:67c:2e8:11::c100:1337 (164) > 12:14:59.060983 IP 192.168.0.115.57523 > 217.146.115.154.53: 3+ A? > IUSB-READONLY.U36.M6466B3B0EC98.sos.atlas.ripe.net. (68) > 12:14:59.114915 IP 217.146.115.154.53 > 192.168.0.115.57523: 3 1/1/2 A > 193.0.19.55 (152) > 12:14:59.115925 IP 192.168.0.115 > 193.0.19.55: ICMP echo request, id > 954, seq 0, length 64 > 12:14:59.142586 IP 193.0.19.55 > 192.168.0.115: ICMP echo reply, id 954, > seq 0, length 64 > 12:15:00.116800 IP 192.168.0.115 > 193.0.19.55: ICMP echo request, id > 954, seq 1, length 64 > 12:15:00.143773 IP 193.0.19.55 > 192.168.0.115: ICMP echo reply, id 954, > seq 1, length 64 > > > I can't see any other IPv4 traffic, but I do see IPv6 HTTPS traffic. I'm > not sure where to go next with figuring out why the probe seems to have > vanished. Any ideas would be greatly appreciated. > > Many thanks. > From steve-ripe.net at nexusuk.org Wed Jan 6 15:58:33 2016 From: steve-ripe.net at nexusuk.org (Steve Hill) Date: Wed, 6 Jan 2016 14:58:33 +0000 Subject: [atlas] Atlas probe offline In-Reply-To: <568D13E9.1050302@gmx.net> References: <568D073D.5080507@nexusuk.org> <568D13E9.1050302@gmx.net> Message-ID: <568D2B99.5070201@nexusuk.org> On 06/01/16 13:17, Estelmann, Christian wrote: > your probe is tagged as "readonly flash drive". > > Disconnect the probe, connect the usb stick to your computer and test it > (e.g. delete all partitions, create own partitions and write some data > to it). If data can not be written to the usb stick a) disable the write > lock, b) replace it by a new one one (4 GB capacity at minimum). > Then reconnect the probe (power and ethernet, but without the usb > stick), wait 5 minutes and then plug in the usb stick. Thanks - looks like that was it. The original drive has gone read-only, swapping it for another USB stick has fixed the issue. -- - Steve From GeertJan.deGroot at xs4all.nl Sat Jan 9 15:15:12 2016 From: GeertJan.deGroot at xs4all.nl (Geert Jan de Groot) Date: Sat, 09 Jan 2016 15:15:12 +0100 Subject: [atlas] What is 'iwantbcp38compliancetesting' user tag? Message-ID: When revisiting the settings of my probe, I found this 'iwantbcp38compliancetesting' user tag. I know what BCP38 is, but what is the meaning of the tag? Is it a poll? Geert Jan From bortzmeyer at nic.fr Sat Jan 9 15:25:01 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 9 Jan 2016 15:25:01 +0100 Subject: [atlas] What is 'iwantbcp38compliancetesting' user tag? In-Reply-To: References: Message-ID: <20160109142501.GA22631@nic.fr> On Sat, Jan 09, 2016 at 03:15:12PM +0100, Geert Jan de Groot wrote a message of 8 lines which said: > I know what BCP38 is, but what is the meaning of the tag? > Is it a poll? I don't know but I see that there are only 22 probes with this tag. From jeroen at dckd.nl Sat Jan 9 16:00:35 2016 From: jeroen at dckd.nl (Jeroen van der Ham) Date: Sat, 9 Jan 2016 16:00:35 +0100 Subject: [atlas] What is 'iwantbcp38compliancetesting' user tag? In-Reply-To: References: Message-ID: Hi, > On 09 Jan 2016, at 15:15, Geert Jan de Groot wrote: > > When revisiting the settings of my probe, I found this > 'iwantbcp38compliancetesting' user tag. > > I know what BCP38 is, but what is the meaning of the tag? > Is it a poll? BCP 38 is a standard to prevent spoofed packets coming from networks. These spoofed packets are a popular means of performing DDoS attacks. This would go away when all networks implement BCP 38, thus filtering out all packets with spoofed source addresses. The problem is that it is very very hard to measure compliance of BCP 38. A simple way would be to send out spoofed packets. There has been discussion on this list to allow this measurement to be performed on RIPE Atlas probes. The community currently is against it, as sending spoofed packets can raise red flags for network operators, or is possibly against the user policy. Users are often not aware of these consequences or rules surrounding spoofed packets. Using these tags is probably a silent protest against this decision ;) Jeroen. From bortzmeyer at nic.fr Sat Jan 9 16:06:26 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 9 Jan 2016 16:06:26 +0100 Subject: [atlas] What is 'iwantbcp38compliancetesting' user tag? In-Reply-To: References: Message-ID: <20160109150626.GA26508@nic.fr> On Sat, Jan 09, 2016 at 04:00:35PM +0100, Jeroen van der Ham wrote a message of 27 lines which said: > Using these tags is probably a silent protest against this > decision?;) Geert said it was *his* probe so I assume he did not set the tag. From gil at magisto.com Sat Jan 9 16:24:48 2016 From: gil at magisto.com (Gil Bahat) Date: Sat, 9 Jan 2016 17:24:48 +0200 Subject: [atlas] What is 'iwantbcp38compliancetesting' user tag? In-Reply-To: <20160109150626.GA26508@nic.fr> References: <20160109150626.GA26508@nic.fr> Message-ID: I am setting this tag on all my probes, which probably accounts for at least half that number... Imho Non compliance with BCP38 invites trouble and I'd like this eradicated from here, personally. On Jan 9, 2016 5:07 PM, "Stephane Bortzmeyer" wrote: > On Sat, Jan 09, 2016 at 04:00:35PM +0100, > Jeroen van der Ham wrote > a message of 27 lines which said: > > > Using these tags is probably a silent protest against this > > decision ;) > > Geert said it was *his* probe so I assume he did not set the tag. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From GeertJan.deGroot at xs4all.nl Sat Jan 9 16:30:41 2016 From: GeertJan.deGroot at xs4all.nl (Geert Jan de Groot) Date: Sat, 09 Jan 2016 16:30:41 +0100 Subject: [atlas] What is 'iwantbcp38compliancetesting' user tag? In-Reply-To: Your message of "Sat, 09 Jan 2016 16:06:26 +0100." <20160109150626.GA26508@nic.fr> Message-ID: On Sat, 9 Jan 2016 16:06:26 +0100 Stephane Bortzmeyer wrote: > Geert said it was *his* probe so I assume he did not set the tag. I set the tag because it was listed as user tag; it was not a field whose name I created myself. It wasn't there when I checked the values before ,I therefore wonder the creation of the tag value, hence the question. I *did* get formal approval, from my ISP, to do bcp38 tests as long as it's low-volume, testing only, and I share the results with them. Since then I have reported to them that tests using spoofer.caida.org were OK, i.e. spoofing was properly filtered. Geert Jan From philip.homburg at ripe.net Sat Jan 9 17:08:56 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Sat, 9 Jan 2016 17:08:56 +0100 Subject: [atlas] What is 'iwantbcp38compliancetesting' user tag? In-Reply-To: References: Message-ID: <56913098.8030902@ripe.net> On 2016/01/09 16:30 , Geert Jan de Groot wrote: > On Sat, 9 Jan 2016 16:06:26 +0100 Stephane Bortzmeyer wrote: >> Geert said it was *his* probe so I assume he did not set the tag. > > I set the tag because it was listed as user tag; it was not a field > whose name I created myself. It wasn't there when I checked the values > before ,I therefore wonder the creation of the tag value, hence the question. As far as I know, there is some sort of public/private thing for probe tags. You can tag your probe with anything you like but it isn't visible except for yourself. Then tags that are popular enough and are not offensive (or that otherwise seem to make sense) and are make public. Which means that you can see which probes have those tags and the UI will also suggest them. From emile.aben at ripe.net Sun Jan 10 06:17:25 2016 From: emile.aben at ripe.net (Emile Aben) Date: Sun, 10 Jan 2016 06:17:25 +0100 Subject: [atlas] What is 'iwantbcp38compliancetesting' user tag? In-Reply-To: <56913098.8030902@ripe.net> References: <56913098.8030902@ripe.net> Message-ID: <5691E965.1060105@ripe.net> Hi, As for the origin of the tag: I set this on my probe as an experiment to see if one could do a poll among probe hosts. Apparently the hosts of 21 other probes already found the tag without it every being advertised. Now that it is more widely known it would probably be interesting for proponents of BCP38 compliance-testing to set that probe-tag, and for opponents to set the 'idontwantbcp38compliancetesting' probe-tag. cheers, Emile From michael at schloh.com Sat Jan 9 16:11:16 2016 From: michael at schloh.com (Michael Schloh von Bennewitz) Date: Sat, 9 Jan 2016 16:11:16 +0100 Subject: [atlas] Examination of ARM based Atlas telemetry nodes Message-ID: <20160109151116.GO11855@elotro.europalab.com> Hello developers, I'm scheduled to talk at the forthcoming MINIX conference, and was hoping to have the chance to examine your ARM based Atlas telemetry system. I only know of the Raspberry Pi devices loaned to the Tor project, and this could be relevant to my IoT work (leveraging IPv6 and ARM.) Andrew Tanenbaum recommended I write to Philip, is he here? Cheers, Michael -- Michael Schloh von Bennewitz Software Development Engineer Europalab Networks R&D, Munich Office: +49(89)44239885 UTC+2 Mobile: Same as 'Office' VoIP: sips:michael at schloh.com Web: http://michael.schloh.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3527 bytes Desc: not available URL: From robert at ripe.net Sun Jan 10 12:42:23 2016 From: robert at ripe.net (Robert Kisteleki) Date: Sun, 10 Jan 2016 12:42:23 +0100 Subject: [atlas] Atlas probe offline In-Reply-To: <568D2B99.5070201@nexusuk.org> References: <568D073D.5080507@nexusuk.org> <568D13E9.1050302@gmx.net> <568D2B99.5070201@nexusuk.org> Message-ID: <5692439F.4010300@ripe.net> On 2016-01-06 15:58, Steve Hill wrote: > On 06/01/16 13:17, Estelmann, Christian wrote: > >> your probe is tagged as "readonly flash drive". >> >> Disconnect the probe, connect the usb stick to your computer and test it >> (e.g. delete all partitions, create own partitions and write some data >> to it). If data can not be written to the usb stick a) disable the write >> lock, b) replace it by a new one one (4 GB capacity at minimum). >> Then reconnect the probe (power and ethernet, but without the usb >> stick), wait 5 minutes and then plug in the usb stick. > > Thanks - looks like that was it. The original drive has gone read-only, > swapping it for another USB stick has fixed the issue. A little bit of background information that could help: The probes use USB storage to buffer results. This comes handy when the probe is off-line, and especially handy if the error is outside the host's network. The unpredictable nature of power losses and other unfriendly events regarding filesystems of course affect these sticks too. This is not unexpected, so the probes do file system checks and repairs as needed to overcome fs corruption resulting from this (and, as some people know this by experience, they can even format and use a new USB stick if it's inserted while the probe is powered up). We learned the hard way that the particular type of USB stick (Sandisk nano) has a particular "feature", namely that it switches to permanent read-only mode if it detects possible corruption. This is most likely there to prevent further escalation of the problem, while allowing recovery of the remaining data from the stick. This is probably ok for generic use, as they are cheap and replaceable. However, in the RIPE Atlas context, this is bad, as there's nothing we can do to fix -- besides reporting to the host. We're unsure what exactly triggers the behaviour. Because of this behaviour we started using a different brand for storage a while ago. We see no need to pro-actively swap out the sticks (and it's also very difficult to do in practice) as the problem only occurs with a small amount of probes. Cheers, Robert From bortzmeyer at nic.fr Sun Jan 10 12:56:36 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 10 Jan 2016 12:56:36 +0100 Subject: [atlas] Examination of ARM based Atlas telemetry nodes In-Reply-To: <20160109151116.GO11855@elotro.europalab.com> References: <20160109151116.GO11855@elotro.europalab.com> Message-ID: <20160110115636.GA18183@sources.org> On Sat, Jan 09, 2016 at 04:11:16PM +0100, Michael Schloh von Bennewitz wrote a message of 103 lines which said: > Andrew Tanenbaum recommended I write to Philip, is he here? This mailing list is the public and open mailing list of RIPE Atlas users. For instance, I'm just an ordinary user. But it does not mean it is a bad place to learn. I suggest that you start with the official Web site or, if you have time, by the very comprehensive article in vol 18.3 of Internet Protocol journal You can have all the papers on RIPE Labs mentioning Atlas and IPv6 with From woeber at cc.univie.ac.at Sun Jan 10 15:50:19 2016 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Sun, 10 Jan 2016 15:50:19 +0100 Subject: [atlas] Examination of ARM based Atlas telemetry nodes In-Reply-To: <20160109151116.GO11855@elotro.europalab.com> References: <20160109151116.GO11855@elotro.europalab.com> Message-ID: <56926FAB.8080707@cc.univie.ac.at> This, too, may be useful information: https://github.com/RIPE-NCC/ripe-atlas-tools https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib and https://labs.ripe.net/Members/philip_homburg/ripe-atlas-measurements-source-code Hth, -ww144 On 2016-01-09 16:11, Michael Schloh von Bennewitz wrote: > > Hello developers, > > I'm scheduled to talk at the forthcoming MINIX conference, and was > hoping to have the chance to examine your ARM based Atlas telemetry > system. > > I only know of the Raspberry Pi devices loaned to the Tor project, > and this could be relevant to my IoT work (leveraging IPv6 and ARM.) > > Andrew Tanenbaum recommended I write to Philip, is he here? > > Cheers, > Michael > From daniel.karrenberg at ripe.net Mon Jan 11 10:39:45 2016 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 11 Jan 2016 10:39:45 +0100 Subject: [atlas] What is 'iwantbcp38compliancetesting' user tag? In-Reply-To: <5691E965.1060105@ripe.net> References: <56913098.8030902@ripe.net> <5691E965.1060105@ripe.net> Message-ID: <56937861.3080308@ripe.net> On 10.01.16 6:17 , Emile Aben wrote: > Hi, > > As for the origin of the tag: I set this on my probe as an experiment to > see if one could do a poll among probe hosts. Apparently the hosts of 21 > other probes already found the tag without it every being advertised. > > Now that it is more widely known it would probably be interesting for > proponents of BCP38 compliance-testing to set that probe-tag, and for > opponents to set the 'idontwantbcp38compliancetesting' probe-tag. In general I like creative use of the RIPE Atlas system. I could see the use of a "SourceAddressSpoofOK" tag that says it would be OK to spoof source addresses when sending traffic from this probe. This kind of opt-in statement has meaning. It would also be a constructive way to get around the risks associated with source address spoofing from probes of unsuspecting hosts. However doing a poll by setting probe tags which are meant to convey attributes of the probe and not opinions of the host is not really useful. This is aggravated by the lack of a clear definition for the meaning of this tag. Daniel From steve-ripe.net at nexusuk.org Mon Jan 11 10:44:57 2016 From: steve-ripe.net at nexusuk.org (Steve Hill) Date: Mon, 11 Jan 2016 09:44:57 +0000 Subject: [atlas] Atlas probe offline In-Reply-To: <5692439F.4010300@ripe.net> References: <568D073D.5080507@nexusuk.org> <568D13E9.1050302@gmx.net> <568D2B99.5070201@nexusuk.org> <5692439F.4010300@ripe.net> Message-ID: <56937999.80003@nexusuk.org> On 10/01/16 11:42, Robert Kisteleki wrote: > A little bit of background information that could help: Thanks for the detailed explanation. I had seen the "USB drive readonly" notification, but didn't know whether it was a warning or if the drive was supposed to be readonly anyway. Once I'd been told that this was a problem I popped the drive out of the probe and put it in another machine and found that yes it was indeed readonly. Some Googling confirmed that this is a permanent state for those USB disks after they detect corruption. Bit of a pain that these sticks don't have a "just wipe the thing and start over" option in that case. -- - Steve From annikaw at penguinfriends.org Mon Jan 11 10:52:47 2016 From: annikaw at penguinfriends.org (Annika Wickert) Date: Mon, 11 Jan 2016 10:52:47 +0100 Subject: [atlas] Atlas probe offline In-Reply-To: <56937999.80003@nexusuk.org> References: <568D073D.5080507@nexusuk.org> <568D13E9.1050302@gmx.net> <568D2B99.5070201@nexusuk.org> <5692439F.4010300@ripe.net> <56937999.80003@nexusuk.org> Message-ID: <56937B6F.8020800@penguinfriends.org> Hi, as one of my probes also had problems with the USB drive it would be nice to have the procedure on how to recover from this failure described in the FAQ. Because I just tried my luck and booted without the drive and inserted it when the probe was booted. And this worked but it could have avoided a ticket to the RIPE team if this would have been described in the FAQ. On 11/01/16 10:44, Steve Hill wrote: > On 10/01/16 11:42, Robert Kisteleki wrote: > >> A little bit of background information that could help: > > Thanks for the detailed explanation. I had seen the "USB drive > readonly" notification, but didn't know whether it was a warning or if > the drive was supposed to be readonly anyway. Once I'd been told that > this was a problem I popped the drive out of the probe and put it in > another machine and found that yes it was indeed readonly. Some > Googling confirmed that this is a permanent state for those USB disks > after they detect corruption. > > Bit of a pain that these sticks don't have a "just wipe the thing and > start over" option in that case. > > From robert at ripe.net Mon Jan 11 11:53:29 2016 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 11 Jan 2016 11:53:29 +0100 Subject: [atlas] Atlas probe offline In-Reply-To: <56937B6F.8020800@penguinfriends.org> References: <568D073D.5080507@nexusuk.org> <568D13E9.1050302@gmx.net> <568D2B99.5070201@nexusuk.org> <5692439F.4010300@ripe.net> <56937999.80003@nexusuk.org> <56937B6F.8020800@penguinfriends.org> Message-ID: <569389A9.1030806@ripe.net> On 2016-01-11 10:52, Annika Wickert wrote: > Hi, > > as one of my probes also had problems with the USB drive it would be nice to > have the procedure on how to recover from this failure described in the FAQ. > > Because I just tried my luck and booted without the drive and inserted it > when the probe was booted. And this worked but it could have avoided a > ticket to the RIPE team if this would have been described in the FAQ. Hello, We've been reluctant to publish the procedure in the FAQ, as the outcome is most likely that it'll be exercised even if there's no reason to. However, we're working on a feature to give probe hosts more guidance about what's going on (and especially what's going wrong) with their probe (*), and here we will make it clear if the USB replacement is in order. Regards, Robert (*) anything we can detect remotely, such as DNS configuration errors, firewalls, readonly USBs, flakey power sources, ... From gert at space.net Mon Jan 11 12:01:45 2016 From: gert at space.net (Gert Doering) Date: Mon, 11 Jan 2016 12:01:45 +0100 Subject: [atlas] Atlas probe offline In-Reply-To: <569389A9.1030806@ripe.net> References: <568D073D.5080507@nexusuk.org> <568D13E9.1050302@gmx.net> <568D2B99.5070201@nexusuk.org> <5692439F.4010300@ripe.net> <56937999.80003@nexusuk.org> <56937B6F.8020800@penguinfriends.org> <569389A9.1030806@ripe.net> Message-ID: <20160111110145.GW58491@Space.Net> Hi, On Mon, Jan 11, 2016 at 11:53:29AM +0100, Robert Kisteleki wrote: > However, we're working on a feature to give probe hosts more guidance about > what's going on (and especially what's going wrong) with their probe (*), > and here we will make it clear if the USB replacement is in order. This is much appreciated... I've bitten by USB outages a few times, and it wasn't always obvious why the probe was acting up. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From emile.aben at ripe.net Tue Jan 12 05:36:05 2016 From: emile.aben at ripe.net (Emile Aben) Date: Tue, 12 Jan 2016 05:36:05 +0100 Subject: [atlas] What is 'iwantbcp38compliancetesting' user tag? In-Reply-To: <56937861.3080308@ripe.net> References: <56913098.8030902@ripe.net> <5691E965.1060105@ripe.net> <56937861.3080308@ripe.net> Message-ID: <569482B5.8090907@ripe.net> On 11/01/16 10:39, Daniel Karrenberg wrote: > > > On 10.01.16 6:17 , Emile Aben wrote: >> Hi, >> >> As for the origin of the tag: I set this on my probe as an experiment to >> see if one could do a poll among probe hosts. Apparently the hosts of 21 >> other probes already found the tag without it every being advertised. >> >> Now that it is more widely known it would probably be interesting for >> proponents of BCP38 compliance-testing to set that probe-tag, and for >> opponents to set the 'idontwantbcp38compliancetesting' probe-tag. > > In general I like creative use of the RIPE Atlas system. I could see the > use of a "SourceAddressSpoofOK" tag that says it would be OK to spoof > source addresses when sending traffic from this probe. This kind of > opt-in statement has meaning. It would also be a constructive way to get > around the risks associated with source address spoofing from probes of > unsuspecting hosts. > > However doing a poll by setting probe tags which are meant to convey > attributes of the probe and not opinions of the host is not really > useful. This is aggravated by the lack of a clear definition for the > meaning of this tag. dismissing this as useless is a bit premature i think. this is an experiment about how to get community feedback, tied to specific resources (ripe atlas probes) this community has (ie. one vote per probe). if the number of people that 'vote' is insignificant the conclusion is that my attempt of collecting feedback didn't work. as to meaning of the tag: as you said yourself the tag conveys the opinion of the probe host. what may be unclear is if the probe host would be ok with bcp38 tests from their own probes. my assumption is they are (i probably should have made the tag 'iwantbcp38compliancetestingonthisprobe', but thought that rather long). currently there are 37 probes with 'iwantbcp38compliancetesting' set, so in case ripe atlas would have 'bcp38-compliance testing' as an opt-in measurement, this would likely be the lower bound of the probes that would be opted-in. emile ps: i think the definition problem is more with spoofing vs. bcp38-compliance testing. spoofing doesn't necessarily involve all involved parties' agreement, while i think a bcp38-compliance test could (should?). personally, as a probe host, i would *not* want all spoofing being made possible from my ripe atlas probe, but i would be ok with bcp38-compliance testing, especially if all involved parties are ok with sending bcp38 test packets. involved parties: - probe host - holder/user of src address for a bcp38 test packet - holder/user of dst address for a bcp38 test packet and i think we can create circumstances where we can actually make all these parties agree. having a probe host opt-in (like my tag implies, but could be more explicit like you suggest) and by having fixed src/dst address space being used for these tests (or have probe public ip addresses of hosts that agree being used in tests?). From woeber at cc.univie.ac.at Tue Jan 12 12:48:13 2016 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Tue, 12 Jan 2016 12:48:13 +0100 Subject: [atlas] integrity checks for the Atlas software? Message-ID: <5694E7FD.30705@cc.univie.ac.at> While thinking about options or mechanisms to make virtual probes "tamper-proof" I had this question coming up: Is the probe software capable to "verify" (check-sum or digital sig) the bootstrap kit and then, during run-time, verify that the code in memory is still genuine? Thanks, Wilfried From canadatechguy at gmail.com Tue Jan 12 12:54:09 2016 From: canadatechguy at gmail.com (Tanner Ryan) Date: Tue, 12 Jan 2016 06:54:09 -0500 Subject: [atlas] integrity checks for the Atlas software? In-Reply-To: <5694E7FD.30705@cc.univie.ac.at> References: <5694E7FD.30705@cc.univie.ac.at> Message-ID: I think that is completely possible. The only issue is that it will take up far more resources validating the integrity of the code (which could be used for measurements). On Tuesday, 12 January 2016, Wilfried Woeber wrote: > > While thinking about options or mechanisms to make virtual probes > "tamper-proof" > I had this question coming up: > > Is the probe software capable to "verify" (check-sum or digital sig) the > bootstrap > kit and then, during run-time, verify that the code in memory is still > genuine? > > Thanks, > Wilfried > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Tue Jan 12 13:02:50 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 12 Jan 2016 13:02:50 +0100 Subject: [atlas] integrity checks for the Atlas software? In-Reply-To: <5694E7FD.30705@cc.univie.ac.at> References: <5694E7FD.30705@cc.univie.ac.at> Message-ID: <5694EB6A.7000106@ripe.net> On 2016/01/12 12:48 , Wilfried Woeber wrote: > While thinking about options or mechanisms to make virtual probes "tamper-proof" > I had this question coming up: > > Is the probe software capable to "verify" (check-sum or digital sig) the bootstrap > kit and then, during run-time, verify that the code in memory is still genuine? Hi Wilfried, If you do that naively, .i.e. by calling a function called verify_digital_sig or something and with binaries that have symbol tables, then that call is very easy to patch out. Beyond that, it becomes and arms race. You can try to scramble binaries and some people see it as a challenge to break that. The only way to do secure boot is to lock the owner of a computer out of the booting process. And then we are back to locked hardware. Philip From the.lists at mgm51.com Tue Jan 12 18:55:07 2016 From: the.lists at mgm51.com (Mike) Date: Tue, 12 Jan 2016 12:55:07 -0500 Subject: [atlas] What is 'iwantbcp38compliancetesting' user tag? In-Reply-To: <569482B5.8090907@ripe.net> References: <56913098.8030902@ripe.net> <5691E965.1060105@ripe.net> <56937861.3080308@ripe.net> <569482B5.8090907@ripe.net> Message-ID: <56953DFB.9080209@mgm51.com> On 1/11/2016 11:36 PM, Emile Aben wrote: > [snip] > dismissing this as useless is a bit premature i think. this is an > experiment about how to get community feedback, tied to specific > resources (ripe atlas probes) this community has (ie. one vote per > probe). if the number of people that 'vote' is insignificant the > conclusion is that my attempt of collecting feedback didn't work. > > [snip] If I want to affect the feature set of the probe, I would do so by using communication channels that are already in place, e.g., that we are using now with this mailing list. I view the probes' tags as a way to announce what the capability of the probe is, and not what I want the capability of the probe to be. I feel that the reduction of the usefulness of the probes' tags to something akin to facebook's "likes" is a diversion of purpose. If you want to have some manner of voting, then do so via your account on the RIPE website. I have to log in to the account to change the tags on my probe, why not just put a voting option on the website? I see no need, and I have no desire, to display my vote among the public data on my probe. From michabailey at gmail.com Tue Jan 12 19:16:54 2016 From: michabailey at gmail.com (Micha Bailey) Date: Tue, 12 Jan 2016 20:16:54 +0200 Subject: [atlas] integrity checks for the Atlas software? In-Reply-To: References: <5694E7FD.30705@cc.univie.ac.at> Message-ID: No, this isn't possible. Or rather, it's not feasible with currently-existing software. The *only* way to have any kind of remote assurance of specific software running is through remote attestation, meaning that you have trusted hardware (e.g. a TPM) that can sign a statement that the machine m is running a certain trusted BIOS/EFI/whatever, that signs a statement that the computer is running a certain trusted bootloader, and so on, creating a chain of trusted signatures all the way through the OS and hypervisor certifying that a specific VM is running and can't be interfered with. As far as I know that full software stack doesn't exist at this point, and it arguably shouldn't exist/be used in most cases (see Google results for ?remote attestation?). Short of that, there's no way to guarantee that certain code is running unmodified. As soon as the user/owner/hacker/rogue datacenter employee is able to modify anything below the VM in the stack without being detected, they can falsify whatever they want (for example, the hypervisor could be programmed such that certain instructions are stored correctly in memory correctly, but when executing the code it's silently swapped out). It may be possible to make this hard, and even hard enough to be considered acceptable for Atlas (though said protection may not even be considered necessary -- what's our threat model here?), but it can't be made impossible for a determined-enough attacker. On Tuesday, January 12, 2016, Tanner Ryan wrote: > I think that is completely possible. > > The only issue is that it will take up far more resources validating the > integrity of the code (which could be used for measurements). > > On Tuesday, 12 January 2016, Wilfried Woeber > wrote: > >> >> While thinking about options or mechanisms to make virtual probes >> "tamper-proof" >> I had this question coming up: >> >> Is the probe software capable to "verify" (check-sum or digital sig) the >> bootstrap >> kit and then, during run-time, verify that the code in memory is still >> genuine? >> >> Thanks, >> Wilfried >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dario.ciccarone at gmail.com Tue Jan 12 19:46:41 2016 From: dario.ciccarone at gmail.com (Dario Ciccarone) Date: Tue, 12 Jan 2016 13:46:41 -0500 Subject: [atlas] integrity checks for the Atlas software? In-Reply-To: References: <5694E7FD.30705@cc.univie.ac.at> Message-ID: What Micha said :) DISCLAIMER: I work for a vendor, but the following aren?t in any way, shape or form my current employer views. It?s my personal opinion, based, however, on many years of doing IRT. Micha is absolutely right ? unless you start w/ a TPM-kind of hardware support, there?s no way to have 100% confidence in that ?what I?m running is what I?m supposed to be running?. Regrettably, getting trusted boot and execution right is expensive in money and time, and hard to get it absolutely right. I honestly don?t think the Atlas project would be able to continue w/ the existing business model of using cheap, off-the-shelf hardware, and give it away for free ? and provide a secure boot/trusted execution kind of probe. RIPE just doesn?t have that kind of money lying around, AFAIK. Of course, it all depends on who your adversary is, and the kind of resources it has available. While a trusted anchor in hardware, hardware TPM, digital signatures and strong crypto/hardware entropy source and RNG would be needed for a full blown solution (plus all the associated build environment, developers, testers, etc) you can achieve a ?not-too-shabby? middle ground ? a two-step boot process, a first stage loader checking the signature on the main image before loading & launching it. Of course ? an attacker could come up w/ a modified binary that doesn?t even perform this check, and just launches whatever . . . Move the first stage loader to a ROM ? more expensive, better. But again, it?s about who you?re up against ? based on risk/benefit, RIPE ATLAS may (a) do it all, (b) middle ground, (c) nothing at all From: ripe-atlas on behalf of Micha Bailey Date: Tuesday, January 12, 2016 at 1:16 PM To: Tanner Ryan Cc: Wilfried Woeber , "ripe-atlas at ripe.net" Subject: Re: [atlas] integrity checks for the Atlas software? > No, this isn't possible. Or rather, it's not feasible with currently-existing > software. The *only* way to have any kind of remote assurance of specific > software running is through remote attestation, meaning that you have trusted > hardware (e.g. a TPM) that can sign a statement that the machine m is running > a certain trusted BIOS/EFI/whatever, that signs a statement that the computer > is running a certain trusted bootloader, and so on, creating a chain of > trusted signatures all the way through the OS and hypervisor certifying that a > specific VM is running and can't be interfered with. As far as I know that > full software stack doesn't exist at this point, and it arguably shouldn't > exist/be used in most cases (see Google results for ?remote attestation?). > Short of that, there's no way to guarantee that certain code is running > unmodified. As soon as the user/owner/hacker/rogue datacenter employee is able > to modify anything below the VM in the stack without being detected, they can > falsify whatever they want (for example, the hypervisor could be programmed > such that certain instructions are stored correctly in memory correctly, but > when executing the code it's silently swapped out). It may be possible to make > this hard, and even hard enough to be considered acceptable for Atlas (though > said protection may not even be considered necessary -- what's our threat > model here?), but it can't be made impossible for a determined-enough > attacker. > > On Tuesday, January 12, 2016, Tanner Ryan wrote: >> I think that is completely possible. >> >> The only issue is that it will take up far more resources validating the >> integrity of the code (which could be used for measurements). >> >> On Tuesday, 12 January 2016, Wilfried Woeber > > wrote: >>> >>> While thinking about options or mechanisms to make virtual probes >>> "tamper-proof" >>> I had this question coming up: >>> >>> Is the probe software capable to "verify" (check-sum or digital sig) the >>> bootstrap >>> kit and then, during run-time, verify that the code in memory is still >>> genuine? >>> >>> Thanks, >>> Wilfried >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Tue Jan 12 21:04:13 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 12 Jan 2016 21:04:13 +0100 Subject: [atlas] integrity checks for the Atlas software? In-Reply-To: References: <5694E7FD.30705@cc.univie.ac.at> Message-ID: <20160112200413.GA28686@nic.fr> On Tue, Jan 12, 2016 at 06:54:09AM -0500, Tanner Ryan wrote a message of 52 lines which said: > I think that is completely possible. No, for the reasons explained by Micha and Dario. For a detailed survey (using the PC as an example), see this excellent review From calderm at usc.edu Wed Jan 13 07:34:28 2016 From: calderm at usc.edu (Matt Calder) Date: Tue, 12 Jan 2016 22:34:28 -0800 Subject: [atlas] Error on multi-probe measurement creation Message-ID: Starting on Jan 6th, I started getting this error when creating new measurements. "Your selection of probes contains at least one probe that is unavailable. Error 104." These measurements had been running with no issues for the last year. I tried checking through the API that all probe's status' are Connected and are Public but it doesn't seem to make a difference. I am specifying a list of specific probes to be used which is needed for the specific experiment. Small number of probes like 1, 2, or 3 usually work. Larger numbers like 10 - 75, work occasionally. 300 - 400 probes per measurement never seem to work. Appreciate any help. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From emile.aben at ripe.net Wed Jan 13 10:40:19 2016 From: emile.aben at ripe.net (Emile Aben) Date: Wed, 13 Jan 2016 10:40:19 +0100 Subject: [atlas] What is 'iwantbcp38compliancetesting' user tag? In-Reply-To: <56953DFB.9080209@mgm51.com> References: <56913098.8030902@ripe.net> <5691E965.1060105@ripe.net> <56937861.3080308@ripe.net> <569482B5.8090907@ripe.net> <56953DFB.9080209@mgm51.com> Message-ID: <56961B83.2090706@ripe.net> On 12/01/16 18:55, Mike wrote: > On 1/11/2016 11:36 PM, Emile Aben wrote: >> [snip] >> dismissing this as useless is a bit premature i think. this is an >> experiment about how to get community feedback, tied to specific >> resources (ripe atlas probes) this community has (ie. one vote per >> probe). if the number of people that 'vote' is insignificant the >> conclusion is that my attempt of collecting feedback didn't work. >> >> [snip] > > If I want to affect the feature set of the probe, I would do so by using > communication channels that are already in place, e.g., that we are > using now with this mailing list. > > I view the probes' tags as a way to announce what the capability of the > probe is, and not what I want the capability of the probe to be. I feel > that the reduction of the usefulness of the probes' tags to something > akin to facebook's "likes" is a diversion of purpose. agree that this shouldn't become a facebook-"like" type of thing, but it's a fine line. i see this particular tag as showing the potential for a capability of the probe, a tag like 'iwantaffordablebroadband' would not be. > If you want to have some manner of voting, then do so via your account > on the RIPE website. I have to log in to the account to change the tags > on my probe, why not just put a voting option on the website? I see no > need, and I have no desire, to display my vote among the public data on > my probe. agree, this is a hack. a web poll could be a better means of collecting feedback, if we'd also tie the analysis to probe hosting, to show if there is potential for an opt-in bcp38 compliance testing. current status of the tags: $ egrep -i 'bcp38|spoof' tags.txt iwantbcp38compliancetesting (45) sourceaddressspoofok (3) bcp38 (1) i'd characterise that as a bit low turn-out, but informative in the light of previous discussions on this mailing list. as a comparison, for the ripe labs poll on wifi measurements in ripe atlas we got 159 voters. cheers, emile From calderm at usc.edu Fri Jan 15 19:07:55 2016 From: calderm at usc.edu (Matt Calder) Date: Fri, 15 Jan 2016 10:07:55 -0800 Subject: [atlas] Error on multi-probe measurement creation In-Reply-To: References: Message-ID: Just to follow up, this issue was patched on 2016-01-13. Thanks guys! On Tue, Jan 12, 2016 at 10:34 PM, Matt Calder wrote: > Starting on Jan 6th, I started getting this error when creating new > measurements. > > "Your selection of probes contains at least one probe that is unavailable. > Error 104." > > These measurements had been running with no issues for the last year. I > tried checking through the API that all probe's status' are Connected and > are Public but it doesn't seem to make a difference. I am specifying a > list of specific probes to be used which is needed for the specific > experiment. Small number of probes like 1, 2, or 3 usually work. Larger > numbers like 10 - 75, work occasionally. 300 - 400 probes per measurement > never seem to work. > > Appreciate any help. > > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From remaker at gmail.com Sun Jan 17 19:37:07 2016 From: remaker at gmail.com (Phillip Remaker) Date: Sun, 17 Jan 2016 10:37:07 -0800 Subject: [atlas] Failing 4GB USB on v3 probes? Message-ID: So far, I have had two of the SanDisk Cruzer 4GB drives (SDCZ33) fail, and I think I have two other ML-3020 (v3) devices with the same fate. Case #1, the drive fell into read only one. Case #2, the drive identifies to the USB, but read of block 0 (capacity) fails. The first time I called SanDisk and jumped through their hundred hoops to replace it.They were reluctant since I couldn't produce a receipt. This time, I just grabbed an old 8GB USB and dropped it in. Looks like it only uses 3GB. Does Atlas plan to pursue warranty claim, or is this an acceptable failure level for the probes? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhestina at ripe.net Mon Jan 18 18:07:13 2016 From: lhestina at ripe.net (Lia Hestina) Date: Mon, 18 Jan 2016 18:07:13 +0100 Subject: [atlas] RIPE Atlas webinar recording and new dates Message-ID: Dear colleagues, We are happy to let you know that a recording of the Advance RIPE Atlas Usage webinar is now available on YouTube: https://www.youtube.com/watch?v=oJMFGuM0kMo > If you would like to participate in a live webinar, we have two sessions available on the following dates: February 9 2016 March 17 2016 The Advanced RIPE Atlas Usage webinar teaches network operators how to use RIPE Atlas to monitor and troubleshoot their own networks. Learn more about the webinar and the necessary prerequisites: https://www.ripe.net/support/training/learn-online/webinars/advanced-ripe-atlas-usage-webinar > RIPE NCC members can register online at: https://lirportal.ripe.net/training/register/courseCode/WEB20150046 > Non-members can email training at ripe.net > and be manually registered. Kind regards, RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2608 bytes Desc: not available URL: From camin at ripe.net Wed Jan 20 14:57:19 2016 From: camin at ripe.net (Chris Amin) Date: Wed, 20 Jan 2016 14:57:19 +0100 Subject: [atlas] Display issues on the RIPE Atlas measurements listing Message-ID: <569F923F.3010405@ripe.net> Dear RIPE Atlas users, Some of you may be noticing issues displaying measurements on the RIPE Atlas UI if you look at Public measurements or have lots of measurements of your own. We're currently working on this issue and apologise for any inconvenience caused. Kind regards, Chris Amin RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From camin at ripe.net Wed Jan 20 16:52:23 2016 From: camin at ripe.net (Chris Amin) Date: Wed, 20 Jan 2016 16:52:23 +0100 Subject: [atlas] Display issues on the RIPE Atlas measurements listing In-Reply-To: <569F923F.3010405@ripe.net> References: <569F923F.3010405@ripe.net> Message-ID: <569FAD37.3050602@ripe.net> On 20/01/2016 14:57, Chris Amin wrote: > Some of you may be noticing issues displaying measurements on the RIPE > Atlas UI if you look at Public measurements or have lots of measurements > of your own. We're currently working on this issue and apologise for any > inconvenience caused. Any issues with the measurement listing should now be resolved. Thanks, Chris Amin RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From camin at ripe.net Fri Jan 22 12:07:27 2016 From: camin at ripe.net (Chris Amin) Date: Fri, 22 Jan 2016 12:07:27 +0100 Subject: [atlas] Possible changes to the V1 REST API Message-ID: <56A20D6F.4090605@ripe.net> Dear RIPE Atlas users, Over the past few days we have been making some changes behind the scenes in preparation for an upcoming version of the RIPE Atlas REST API. We identified and resolved several problems that these changes caused to the existing version of the API. The problems have now been fixed and you should not notice anything different with the existing API. If you continue to see anything strange, do please let us know. Kind regards, Chris Amin RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From sarah.wassermann at student.ulg.ac.be Sun Jan 24 14:37:49 2016 From: sarah.wassermann at student.ulg.ac.be (sarah.wassermann at student.ulg.ac.be) Date: Sun, 24 Jan 2016 14:37:49 +0100 (CET) Subject: [atlas] probe tagged as "Hardware problem suspected" Message-ID: <74078299.439678.1453642668972.JavaMail.root@student.ulg.ac.be> Hi, My probe (probeID: 24102) got tagged as "Hardware problem suspected" 2 weeks ago (and has also been disconnected since 2 weeks) and I am unable to bring it back to life again... (I am not an expert regarding hardware problems, so I will not be able to address the issue; restarting the router and plugging it out/back in didn't help). This probe behaved a bit strangely since the beginning: it disconnected itself for a few minutes per day without any reason, but I didn't pay much attention to that. Unfortunately, I need credits to conduct my research. Is it possible to order a new probe and to send this probe to RIPE? Maybe they can fix the problem and send the probe to someone who is interested in hosting a one? Thanks! Sarah Wassermann From c.estelmann at gmx.net Sun Jan 24 16:04:02 2016 From: c.estelmann at gmx.net (Estelmann, Christian) Date: Sun, 24 Jan 2016 16:04:02 +0100 Subject: [atlas] probe tagged as "Hardware problem suspected" In-Reply-To: <74078299.439678.1453642668972.JavaMail.root@student.ulg.ac.be> References: <74078299.439678.1453642668972.JavaMail.root@student.ulg.ac.be> Message-ID: <56A4E7E2.6020808@gmx.net> Hi, 1) Is the probe dead or are some LEDs on when it is powered? Maybe https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean will help. 2) What type of internet connection is used? For example in germany it is common that your private connections are disconnected every 24 hours. Cause of this disconnect the connection of the probes times out and this is counted as offline. 4 to 7 minutes offline time per day (counted by Atlas) is normal on a common german internet connection. (the ISPs don't want that you run your own server at home, so they force you to get every 24 hours a new IP-address) Greetings, Christian Estelmann Am 24.01.2016 um 14:37 schrieb sarah.wassermann at student.ulg.ac.be: > Hi, > > My probe (probeID: 24102) got tagged as "Hardware problem suspected" 2 weeks ago (and has also been disconnected since 2 weeks) and I am unable to bring it back to life again... (I am not an expert regarding hardware problems, so I will not be able to address the issue; restarting the router and plugging it out/back in didn't help). This probe behaved a bit strangely since the beginning: it disconnected itself for a few minutes per day without any reason, but I didn't pay much attention to that. > > Unfortunately, I need credits to conduct my research. Is it possible to order a new probe and to send this probe to RIPE? Maybe they can fix the problem and send the probe to someone who is interested in hosting a one? > > Thanks! > > Sarah Wassermann > From sarah.wassermann at student.ulg.ac.be Sun Jan 24 17:35:43 2016 From: sarah.wassermann at student.ulg.ac.be (sarah.wassermann at student.ulg.ac.be) Date: Sun, 24 Jan 2016 17:35:43 +0100 (CET) Subject: [atlas] probe tagged as "Hardware problem suspected" In-Reply-To: <56A4E7E2.6020808@gmx.net> Message-ID: <1331434192.540974.1453653343390.JavaMail.root@student.ulg.ac.be> Hi Christian, Thanks for the reply. Indeed, only the first 2 lights are turned on, so according to the table on the FAQ, it would be running from built-in flash, but I don't get what this really means... Regarding my internet-connection, it is possible that the connection gets disconnected for several minutes a day; I have to check with my ISP! Best regards, Sarah ----- Mail original ----- De: "Christian Estelmann" ?: "sarah wassermann" Cc: ripe-atlas at ripe.net Envoy?: Dimanche 24 Janvier 2016 16:04:02 Objet: Re: [atlas] probe tagged as "Hardware problem suspected" Hi, 1) Is the probe dead or are some LEDs on when it is powered? Maybe https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean will help. 2) What type of internet connection is used? For example in germany it is common that your private connections are disconnected every 24 hours. Cause of this disconnect the connection of the probes times out and this is counted as offline. 4 to 7 minutes offline time per day (counted by Atlas) is normal on a common german internet connection. (the ISPs don't want that you run your own server at home, so they force you to get every 24 hours a new IP-address) Greetings, Christian Estelmann Am 24.01.2016 um 14:37 schrieb sarah.wassermann at student.ulg.ac.be: > Hi, > > My probe (probeID: 24102) got tagged as "Hardware problem suspected" 2 weeks ago (and has also been disconnected since 2 weeks) and I am unable to bring it back to life again... (I am not an expert regarding hardware problems, so I will not be able to address the issue; restarting the router and plugging it out/back in didn't help). This probe behaved a bit strangely since the beginning: it disconnected itself for a few minutes per day without any reason, but I didn't pay much attention to that. > > Unfortunately, I need credits to conduct my research. Is it possible to order a new probe and to send this probe to RIPE? Maybe they can fix the problem and send the probe to someone who is interested in hosting a one? > > Thanks! > > Sarah Wassermann > From c.estelmann at gmx.net Sun Jan 24 17:52:53 2016 From: c.estelmann at gmx.net (Estelmann, Christian) Date: Sun, 24 Jan 2016 17:52:53 +0100 Subject: [atlas] probe tagged as "Hardware problem suspected" In-Reply-To: <1331434192.540974.1453653343390.JavaMail.root@student.ulg.ac.be> References: <1331434192.540974.1453653343390.JavaMail.root@student.ulg.ac.be> Message-ID: <56A50165.2070007@gmx.net> Hi Sarah, perhaps it is the typical problem and the USB stick is broken (SanDisk nano, see [1]). You can replace the usb stick with another one. In [2] I have written how to to so in a previous mail. The stick needs a capacity of >3 GB (see [3]). Greetings, Christian [1] https://www.ripe.net/ripe/mail/archives/ripe-atlas/2016-January/002573.html [2] https://www.ripe.net/ripe/mail/archives/ripe-atlas/2016-January/002562.html [3] https://www.ripe.net/ripe/mail/archives/ripe-atlas/2015-December/002450.html Am 24.01.2016 um 17:35 schrieb sarah.wassermann at student.ulg.ac.be: > Hi Christian, > > Thanks for the reply. > > Indeed, only the first 2 lights are turned on, so according to the table on the FAQ, it would be running from built-in flash, but I don't get what this really means... > > Regarding my internet-connection, it is possible that the connection gets disconnected for several minutes a day; I have to check with my ISP! > > Best regards, > > Sarah > > ----- Mail original ----- > De: "Christian Estelmann" > ?: "sarah wassermann" > Cc: ripe-atlas at ripe.net > Envoy?: Dimanche 24 Janvier 2016 16:04:02 > Objet: Re: [atlas] probe tagged as "Hardware problem suspected" > > Hi, > > 1) Is the probe dead or are some LEDs on when it is powered? > Maybe > https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean > will help. > > 2) What type of internet connection is used? For example in germany it > is common that your private connections are disconnected every 24 hours. > Cause of this disconnect the connection of the probes times out and this > is counted as offline. 4 to 7 minutes offline time per day (counted by > Atlas) is normal on a common german internet connection. > (the ISPs don't want that you run your own server at home, so they force > you to get every 24 hours a new IP-address) > > Greetings, > Christian Estelmann > > Am 24.01.2016 um 14:37 schrieb sarah.wassermann at student.ulg.ac.be: >> Hi, >> >> My probe (probeID: 24102) got tagged as "Hardware problem suspected" 2 weeks ago (and has also been disconnected since 2 weeks) and I am unable to bring it back to life again... (I am not an expert regarding hardware problems, so I will not be able to address the issue; restarting the router and plugging it out/back in didn't help). This probe behaved a bit strangely since the beginning: it disconnected itself for a few minutes per day without any reason, but I didn't pay much attention to that. >> >> Unfortunately, I need credits to conduct my research. Is it possible to order a new probe and to send this probe to RIPE? Maybe they can fix the problem and send the probe to someone who is interested in hosting a one? >> >> Thanks! >> >> Sarah Wassermann >> From sarah.wassermann at student.ulg.ac.be Sun Jan 24 17:57:09 2016 From: sarah.wassermann at student.ulg.ac.be (sarah.wassermann at student.ulg.ac.be) Date: Sun, 24 Jan 2016 17:57:09 +0100 (CET) Subject: [atlas] probe tagged as "Hardware problem suspected" In-Reply-To: <56A50165.2070007@gmx.net> Message-ID: <1124391696.553333.1453654629733.JavaMail.root@student.ulg.ac.be> Hi Christian, Thanks for the info. I will have a look at this and try to fix the problem :) Best regards, Sarah ----- Mail original ----- De: "Christian Estelmann" ?: "sarah wassermann" Cc: ripe-atlas at ripe.net Envoy?: Dimanche 24 Janvier 2016 17:52:53 Objet: Re: [atlas] probe tagged as "Hardware problem suspected" Hi Sarah, perhaps it is the typical problem and the USB stick is broken (SanDisk nano, see [1]). You can replace the usb stick with another one. In [2] I have written how to to so in a previous mail. The stick needs a capacity of >3 GB (see [3]). Greetings, Christian [1] https://www.ripe.net/ripe/mail/archives/ripe-atlas/2016-January/002573.html [2] https://www.ripe.net/ripe/mail/archives/ripe-atlas/2016-January/002562.html [3] https://www.ripe.net/ripe/mail/archives/ripe-atlas/2015-December/002450.html Am 24.01.2016 um 17:35 schrieb sarah.wassermann at student.ulg.ac.be: > Hi Christian, > > Thanks for the reply. > > Indeed, only the first 2 lights are turned on, so according to the table on the FAQ, it would be running from built-in flash, but I don't get what this really means... > > Regarding my internet-connection, it is possible that the connection gets disconnected for several minutes a day; I have to check with my ISP! > > Best regards, > > Sarah > > ----- Mail original ----- > De: "Christian Estelmann" > ?: "sarah wassermann" > Cc: ripe-atlas at ripe.net > Envoy?: Dimanche 24 Janvier 2016 16:04:02 > Objet: Re: [atlas] probe tagged as "Hardware problem suspected" > > Hi, > > 1) Is the probe dead or are some LEDs on when it is powered? > Maybe > https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean > will help. > > 2) What type of internet connection is used? For example in germany it > is common that your private connections are disconnected every 24 hours. > Cause of this disconnect the connection of the probes times out and this > is counted as offline. 4 to 7 minutes offline time per day (counted by > Atlas) is normal on a common german internet connection. > (the ISPs don't want that you run your own server at home, so they force > you to get every 24 hours a new IP-address) > > Greetings, > Christian Estelmann > > Am 24.01.2016 um 14:37 schrieb sarah.wassermann at student.ulg.ac.be: >> Hi, >> >> My probe (probeID: 24102) got tagged as "Hardware problem suspected" 2 weeks ago (and has also been disconnected since 2 weeks) and I am unable to bring it back to life again... (I am not an expert regarding hardware problems, so I will not be able to address the issue; restarting the router and plugging it out/back in didn't help). This probe behaved a bit strangely since the beginning: it disconnected itself for a few minutes per day without any reason, but I didn't pay much attention to that. >> >> Unfortunately, I need credits to conduct my research. Is it possible to order a new probe and to send this probe to RIPE? Maybe they can fix the problem and send the probe to someone who is interested in hosting a one? >> >> Thanks! >> >> Sarah Wassermann >> From sarah.wassermann at student.ulg.ac.be Sun Jan 24 23:48:01 2016 From: sarah.wassermann at student.ulg.ac.be (sarah.wassermann at student.ulg.ac.be) Date: Sun, 24 Jan 2016 23:48:01 +0100 (CET) Subject: [atlas] probe tagged as "Hardware problem suspected" In-Reply-To: <56A50165.2070007@gmx.net> Message-ID: <1047393309.756724.1453675680986.JavaMail.root@student.ulg.ac.be> Hi Christian, I followed the steps your described in your "tutorials" and my probe now seems to work again. Thanks a lot! Sarah ----- Mail original ----- De: "Christian Estelmann" ?: "sarah wassermann" Cc: ripe-atlas at ripe.net Envoy?: Dimanche 24 Janvier 2016 17:52:53 Objet: Re: [atlas] probe tagged as "Hardware problem suspected" Hi Sarah, perhaps it is the typical problem and the USB stick is broken (SanDisk nano, see [1]). You can replace the usb stick with another one. In [2] I have written how to to so in a previous mail. The stick needs a capacity of >3 GB (see [3]). Greetings, Christian [1] https://www.ripe.net/ripe/mail/archives/ripe-atlas/2016-January/002573.html [2] https://www.ripe.net/ripe/mail/archives/ripe-atlas/2016-January/002562.html [3] https://www.ripe.net/ripe/mail/archives/ripe-atlas/2015-December/002450.html Am 24.01.2016 um 17:35 schrieb sarah.wassermann at student.ulg.ac.be: > Hi Christian, > > Thanks for the reply. > > Indeed, only the first 2 lights are turned on, so according to the table on the FAQ, it would be running from built-in flash, but I don't get what this really means... > > Regarding my internet-connection, it is possible that the connection gets disconnected for several minutes a day; I have to check with my ISP! > > Best regards, > > Sarah > > ----- Mail original ----- > De: "Christian Estelmann" > ?: "sarah wassermann" > Cc: ripe-atlas at ripe.net > Envoy?: Dimanche 24 Janvier 2016 16:04:02 > Objet: Re: [atlas] probe tagged as "Hardware problem suspected" > > Hi, > > 1) Is the probe dead or are some LEDs on when it is powered? > Maybe > https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean > will help. > > 2) What type of internet connection is used? For example in germany it > is common that your private connections are disconnected every 24 hours. > Cause of this disconnect the connection of the probes times out and this > is counted as offline. 4 to 7 minutes offline time per day (counted by > Atlas) is normal on a common german internet connection. > (the ISPs don't want that you run your own server at home, so they force > you to get every 24 hours a new IP-address) > > Greetings, > Christian Estelmann > > Am 24.01.2016 um 14:37 schrieb sarah.wassermann at student.ulg.ac.be: >> Hi, >> >> My probe (probeID: 24102) got tagged as "Hardware problem suspected" 2 weeks ago (and has also been disconnected since 2 weeks) and I am unable to bring it back to life again... (I am not an expert regarding hardware problems, so I will not be able to address the issue; restarting the router and plugging it out/back in didn't help). This probe behaved a bit strangely since the beginning: it disconnected itself for a few minutes per day without any reason, but I didn't pay much attention to that. >> >> Unfortunately, I need credits to conduct my research. Is it possible to order a new probe and to send this probe to RIPE? Maybe they can fix the problem and send the probe to someone who is interested in hosting a one? >> >> Thanks! >> >> Sarah Wassermann >> From daniel.karrenberg at ripe.net Mon Jan 25 10:54:43 2016 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 25 Jan 2016 10:54:43 +0100 Subject: [atlas] probe tagged as "Hardware problem suspected" In-Reply-To: <1047393309.756724.1453675680986.JavaMail.root@student.ulg.ac.be> References: <1047393309.756724.1453675680986.JavaMail.root@student.ulg.ac.be> Message-ID: <56A5F0E3.5080905@ripe.net> Excellent to see that members of the RIPE Atlas community support each other! Daniel On 24.01.16 23:48 , sarah.wassermann at student.ulg.ac.be wrote: > Hi Christian, > > I followed the steps your described in your "tutorials" and my probe now seems to work again. Thanks a lot! > > Sarah From michabailey at gmail.com Mon Jan 25 15:52:15 2016 From: michabailey at gmail.com (Micha Bailey) Date: Mon, 25 Jan 2016 16:52:15 +0200 Subject: [atlas] Probe downtime notification Message-ID: I got an email 20 minutes ago telling me that my probe (#25346) is down, and apparently it's been down since 2016-01-24 15:11:10 UTC -- almost 24 hours. My settings are such that I should be getting an email within 15 minutes. Does anyone know why it's not emailing me right away? Has this happened to anyone else? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ondrej.Caletka at cesnet.cz Mon Jan 25 16:20:50 2016 From: Ondrej.Caletka at cesnet.cz (=?UTF-8?Q?Ond=c5=99ej_Caletka?=) Date: Mon, 25 Jan 2016 16:20:50 +0100 Subject: [atlas] An article/FAQ entry about probe troubleshooting Message-ID: <56A63D52.4030902@cesnet.cz> Hi all, it seems that failing probes are getting more and more to be an issue, possibly due to USB flash drive failure. I think it would be nice if there was an article / FAQ entry with some official troubleshooting procedures, so we could just send a link to anybody complaining about non functional probe. Is there something like this on the roadmap? Perhaps we as the community could make something up: - how to check whether the port probe is connected to has proper IP and DNS parameters and is allowed to establish a SSH session to TCP port 443 in the Internet (beware of DPI firewalls that allow HTTPS but not SSH over 443) - how to check the LED status and the SOS list at the probe page (the current LED explanation in the FAQ is too techy and even power users like me still don't understand all presented states :) ) - how to diagnose USB flash drive failure, how to force reformatting the flash drive and how to replace it with a new one What do you think? Cheers, Ond?ej Caletka CESNET -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3718 bytes Desc: Elektronicky podpis S/MIME URL: From sarah.wassermann at student.ulg.ac.be Mon Jan 25 16:24:22 2016 From: sarah.wassermann at student.ulg.ac.be (sarah.wassermann at student.ulg.ac.be) Date: Mon, 25 Jan 2016 16:24:22 +0100 (CET) Subject: [atlas] An article/FAQ entry about probe troubleshooting In-Reply-To: <56A63D52.4030902@cesnet.cz> Message-ID: <504717477.630001.1453735462410.JavaMail.root@student.ulg.ac.be> +1 ! Sarah ----- Mail original ----- De: "Ond?ej Caletka" ?: ripe-atlas at ripe.net Envoy?: Lundi 25 Janvier 2016 16:20:50 Objet: [atlas] An article/FAQ entry about probe troubleshooting Hi all, it seems that failing probes are getting more and more to be an issue, possibly due to USB flash drive failure. I think it would be nice if there was an article / FAQ entry with some official troubleshooting procedures, so we could just send a link to anybody complaining about non functional probe. Is there something like this on the roadmap? Perhaps we as the community could make something up: - how to check whether the port probe is connected to has proper IP and DNS parameters and is allowed to establish a SSH session to TCP port 443 in the Internet (beware of DPI firewalls that allow HTTPS but not SSH over 443) - how to check the LED status and the SOS list at the probe page (the current LED explanation in the FAQ is too techy and even power users like me still don't understand all presented states :) ) - how to diagnose USB flash drive failure, how to force reformatting the flash drive and how to replace it with a new one What do you think? Cheers, Ond?ej Caletka CESNET From canadatechguy at gmail.com Mon Jan 25 16:28:37 2016 From: canadatechguy at gmail.com (Tanner Ryan) Date: Mon, 25 Jan 2016 10:28:37 -0500 Subject: [atlas] An article/FAQ entry about probe troubleshooting In-Reply-To: <504717477.630001.1453735462410.JavaMail.root@student.ulg.ac.be> References: <56A63D52.4030902@cesnet.cz> <504717477.630001.1453735462410.JavaMail.root@student.ulg.ac.be> Message-ID: An issue with having a FAQ for the failing USBs is that people will perform the procedure when it is not necessary. I think though that there should still be more debugging info for connections. On Monday, January 25, 2016, wrote: > +1 ! > > Sarah > > ----- Mail original ----- > De: "Ond?ej Caletka" > > ?: ripe-atlas at ripe.net > Envoy?: Lundi 25 Janvier 2016 16:20:50 > Objet: [atlas] An article/FAQ entry about probe troubleshooting > > Hi all, > > it seems that failing probes are getting more and more to be an issue, > possibly due to USB flash drive failure. I think it would be nice if > there was an article / FAQ entry with some official troubleshooting > procedures, so we could just send a link to anybody complaining about > non functional probe. > > Is there something like this on the roadmap? Perhaps we as the community > could make something up: > > - how to check whether the port probe is connected to has proper IP and > DNS parameters and is allowed to establish a SSH session to TCP port 443 > in the Internet (beware of DPI firewalls that allow HTTPS but not SSH > over 443) > > - how to check the LED status and the SOS list at the probe page (the > current LED explanation in the FAQ is too techy and even power users > like me still don't understand all presented states :) ) > > - how to diagnose USB flash drive failure, how to force reformatting > the flash drive and how to replace it with a new one > > > What do you think? > > Cheers, > Ond?ej Caletka > CESNET > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From c.estelmann at gmx.net Mon Jan 25 16:34:57 2016 From: c.estelmann at gmx.net (Estelmann, Christian) Date: Mon, 25 Jan 2016 16:34:57 +0100 Subject: [atlas] An article/FAQ entry about probe troubleshooting In-Reply-To: References: <56A63D52.4030902@cesnet.cz> <504717477.630001.1453735462410.JavaMail.root@student.ulg.ac.be> Message-ID: <56A640A1.4010102@gmx.net> Hi, first, yes, a FAQ article would be nice. The USB stick of my probe broke in November and I wrote to atlas at ripe.net because I was not able to find anything about this problem. After a little ping pong mailing and a to small USB stick I was finally able to get the probe back online. [1] helped to find out that the USB stick needs a capacity of about 3 GB at minimum. But I also suggest that the error tag has to be more specific. In my case it was simple "Hardware problem supspected" (yes, with typo, I think this is corrected now). If the system is able to detect that the USB stick is read only it surely can report this. And then it will be only a little step to automatically send a mail to the owner. That would be great. Greetings, Christian Estelmann [1] https://www.mdsec.co.uk/2015/09/an-introduction-to-hardware-hacking-the-ripe-atlas-probe/ Am 25.01.2016 um 16:28 schrieb Tanner Ryan: > An issue with having a FAQ for the failing USBs is that people will > perform the procedure when it is not necessary. > > I think though that there should still be more debugging info for > connections. > > On Monday, January 25, 2016, > wrote: > > +1 ! > > Sarah > > ----- Mail original ----- > De: "Ond?ej Caletka" > > ?: ripe-atlas at ripe.net > Envoy?: Lundi 25 Janvier 2016 16:20:50 > Objet: [atlas] An article/FAQ entry about probe troubleshooting > > Hi all, > > it seems that failing probes are getting more and more to be an issue, > possibly due to USB flash drive failure. I think it would be nice if > there was an article / FAQ entry with some official troubleshooting > procedures, so we could just send a link to anybody complaining about > non functional probe. > > Is there something like this on the roadmap? Perhaps we as the community > could make something up: > > - how to check whether the port probe is connected to has proper > IP and > DNS parameters and is allowed to establish a SSH session to TCP port 443 > in the Internet (beware of DPI firewalls that allow HTTPS but not SSH > over 443) > > - how to check the LED status and the SOS list at the probe page (the > current LED explanation in the FAQ is too techy and even power users > like me still don't understand all presented states :) ) > > - how to diagnose USB flash drive failure, how to force reformatting > the flash drive and how to replace it with a new one > > > What do you think? > > Cheers, > Ond?ej Caletka > CESNET > > From gert at space.net Mon Jan 25 16:41:39 2016 From: gert at space.net (Gert Doering) Date: Mon, 25 Jan 2016 16:41:39 +0100 Subject: [atlas] An article/FAQ entry about probe troubleshooting In-Reply-To: <56A640A1.4010102@gmx.net> References: <56A63D52.4030902@cesnet.cz> <504717477.630001.1453735462410.JavaMail.root@student.ulg.ac.be> <56A640A1.4010102@gmx.net> Message-ID: <20160125154139.GU58491@Space.Net> Hi, On Mon, Jan 25, 2016 at 04:34:57PM +0100, Estelmann, Christian wrote: > If the system is able to detect that the USB stick is read only it > surely can report this. +1 - well, it actually *does* report it as part of the SOS DNS queries, but the whole process "there is a SOS that looks very typical for FAQ item 37 -> send note to user pointing to that FAQ item" is, uh, somewhat underdeveloped right now. (Two of my probes have been through the USB dance, and it took something like two weeks of e-mailing back and forth to resolve the issue, which is a tad long for a FAQ issue...) gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From c.estelmann at gmx.net Mon Jan 25 16:49:54 2016 From: c.estelmann at gmx.net (Estelmann, Christian) Date: Mon, 25 Jan 2016 16:49:54 +0100 Subject: [atlas] An article/FAQ entry about probe troubleshooting In-Reply-To: <20160125154139.GU58491@Space.Net> References: <56A63D52.4030902@cesnet.cz> <504717477.630001.1453735462410.JavaMail.root@student.ulg.ac.be> <56A640A1.4010102@gmx.net> <20160125154139.GU58491@Space.Net> Message-ID: <56A64422.3000900@gmx.net> Hi, Am 25.01.2016 um 16:41 schrieb Gert Doering: > Hi, > > On Mon, Jan 25, 2016 at 04:34:57PM +0100, Estelmann, Christian wrote: >> If the system is able to detect that the USB stick is read only it >> surely can report this. > > +1 - well, it actually *does* report it as part of the SOS DNS queries, > but the whole process "there is a SOS that looks very typical for FAQ > item 37 -> send note to user pointing to that FAQ item" is, uh, somewhat > underdeveloped right now. I have not the technical equipment at home to sniff the traffic*. So I am not able to see which DNS queries are performed. But simple tagging the probe with something like "USB stick read-only" will surely help to find the problem. The current "something is wrong" tag is not very helpful (imho). *OK, I could boot Knoppix on my laptop (probe connected to Ethernet port, traffic forwarded via WLAN to the internet) to sniff the traffic. Or something like this... Greetings, Christian Estelmann From gert at space.net Mon Jan 25 16:55:41 2016 From: gert at space.net (Gert Doering) Date: Mon, 25 Jan 2016 16:55:41 +0100 Subject: [atlas] An article/FAQ entry about probe troubleshooting In-Reply-To: <56A64422.3000900@gmx.net> References: <56A63D52.4030902@cesnet.cz> <504717477.630001.1453735462410.JavaMail.root@student.ulg.ac.be> <56A640A1.4010102@gmx.net> <20160125154139.GU58491@Space.Net> <56A64422.3000900@gmx.net> Message-ID: <20160125155541.GV58491@Space.Net> Hi, On Mon, Jan 25, 2016 at 04:49:54PM +0100, Estelmann, Christian wrote: > > On Mon, Jan 25, 2016 at 04:34:57PM +0100, Estelmann, Christian wrote: > >> If the system is able to detect that the USB stick is read only it > >> surely can report this. > > > > +1 - well, it actually *does* report it as part of the SOS DNS queries, > > but the whole process "there is a SOS that looks very typical for FAQ > > item 37 -> send note to user pointing to that FAQ item" is, uh, somewhat > > underdeveloped right now. > > I have not the technical equipment at home to sniff the traffic*. So I > am not able to see which DNS queries are performed. But simple tagging > the probe with something like "USB stick read-only" will surely help to > find the problem. The current "something is wrong" tag is not very > helpful (imho). This is what I'm saying. The probe is clearly communicating the problem back - these DNS requests hit the RIPE DNS resolvers, and they know what is wrong. The SOS messages are listed on the atlas web site, just the "draw automated conclusion and notify user what to do next" bit is missing. > *OK, I could boot Knoppix on my laptop (probe connected to Ethernet > port, traffic forwarded via WLAN to the internet) to sniff the traffic. > Or something like this... "Not being able to sniff the traffic" is a somewhat lame excuse, but missing the point :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From Ondrej.Caletka at cesnet.cz Mon Jan 25 19:48:35 2016 From: Ondrej.Caletka at cesnet.cz (=?UTF-8?Q?Ond=c5=99ej_Caletka?=) Date: Mon, 25 Jan 2016 19:48:35 +0100 Subject: [atlas] An article/FAQ entry about probe troubleshooting In-Reply-To: References: <56A63D52.4030902@cesnet.cz> <504717477.630001.1453735462410.JavaMail.root@student.ulg.ac.be> Message-ID: <56A66E03.8090607@cesnet.cz> Dne 25.1.2016 v 16:28 Tanner Ryan napsal(a): > An issue with having a FAQ for the failing USBs is that people will > perform the procedure when it is not necessary. The question is how much such procedure harms the probe. AFAIK it should not make any harm to the Atlas system as the measurement results are streamed to the Atlas C&C servers in near real time. Plus, when the probe is offline due to USB flash brokenness it brings no value to the Atlas system at all. -- Ond?ej -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3718 bytes Desc: Elektronicky podpis S/MIME URL: From sebastian at nzrs.net.nz Tue Jan 26 00:41:06 2016 From: sebastian at nzrs.net.nz (Sebastian Castro) Date: Tue, 26 Jan 2016 12:41:06 +1300 Subject: [atlas] Querying your own measurements Message-ID: <56A6B292.6080508@nzrs.net.nz> Hi: I'm currently testing the API to get a list of my own measurements. The API here reports ----------- Querying for Your Own Measurements In order to limit the results to your measurements only, just add a mine=true argument. For example: /api/v1/measurement/?mine=true Note that this only works if you're logged in, otherwise the result is the same as for any unauthenticated user. ----------- This seems to imply you need to manage a session within your code to get your own measurements, which I think violates the principle of a REST API. If you have the API key that provides you with access, shouldn't be reasonable to run the call as /api/v1/measurement/?mine=true&key=API_KEY and get a list of your own measurements? Thoughts? Am I reading the documentation in the wrong way? Thanks in advance -- Sebastian Castro Technical Research Manager NZRS Ltd. desk: +64 4 495 2337 mobile: +64 21 400535 From robert at ripe.net Tue Jan 26 11:53:05 2016 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 26 Jan 2016 11:53:05 +0100 Subject: [atlas] An article/FAQ entry about probe troubleshooting In-Reply-To: References: <56A63D52.4030902@cesnet.cz> <504717477.630001.1453735462410.JavaMail.root@student.ulg.ac.be> Message-ID: <56A75011.1030307@ripe.net> Hi, > I think though that there should still be more debugging info for connections. A very similar discussion happened almost exactly two weeks ago on this list, where I responded: > However, we're working on a feature to give probe hosts more guidance about > what's going on (and especially what's going wrong) with their probe (*), > and here we will make it clear if the USB replacement is in order. Besides this, I'm sure we'll happily endorse any kind of community-written troubleshooting guides :) Regards, Robert From robert at ripe.net Tue Jan 26 13:11:35 2016 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 26 Jan 2016 13:11:35 +0100 Subject: [atlas] Querying your own measurements In-Reply-To: <56A6B292.6080508@nzrs.net.nz> References: <56A6B292.6080508@nzrs.net.nz> Message-ID: <56A76277.7050606@ripe.net> On 2016-01-26 0:41, Sebastian Castro wrote: > Hi: > > I'm currently testing the API to get a list of my own measurements. The > API here reports > > ----------- > Querying for Your Own Measurements > > In order to limit the results to your measurements only, just add a > mine=true argument. For example: > > /api/v1/measurement/?mine=true > Note that this only works if you're logged in, otherwise the result is > the same as for any unauthenticated user. > ----------- > > This seems to imply you need to manage a session within your code to get > your own measurements, which I think violates the principle of a REST > API. If you have the API key that provides you with access, shouldn't be > reasonable to run the call as > > /api/v1/measurement/?mine=true&key=API_KEY > > and get a list of your own measurements? > > Thoughts? Am I reading the documentation in the wrong way? > > Thanks in advance Hi, Can you provide your use case here? What's the purpose for getting a list of your on measurements from a script? Shouldn't your scripts already know about the measurements they started? :-) Cheers, Robert From vnaumov at ripe.net Tue Jan 26 14:35:54 2016 From: vnaumov at ripe.net (Viktor Naumov) Date: Tue, 26 Jan 2016 14:35:54 +0100 Subject: [atlas] Probe downtime notification In-Reply-To: References: Message-ID: <56A7763A.6060205@ripe.net> Hi Micha, The connection was in the limbo state and it was kicked out by watchdog after some time and you've got the message withing 15 minutes after that. The probe in such a case is considered down since the time it last reported, which is 2016-01-24 15:11:10UTC. Cheers! /vty On 1/25/16 3:52 PM, Micha Bailey wrote: > I got an email 20 minutes ago telling me that my probe (#25346) is > down, and apparently it's been down since 2016-01-24 15:11:10 UTC -- > almost 24 hours. My settings are such that I should be getting an > email within 15 minutes. Does anyone know why it's not emailing me > right away? Has this happened to anyone else? From sebastian at nzrs.net.nz Tue Jan 26 19:41:02 2016 From: sebastian at nzrs.net.nz (Sebastian Castro) Date: Wed, 27 Jan 2016 07:41:02 +1300 Subject: [atlas] Querying your own measurements In-Reply-To: <56A76277.7050606@ripe.net> References: <56A6B292.6080508@nzrs.net.nz> <56A76277.7050606@ripe.net> Message-ID: <56A7BDBE.6080709@nzrs.net.nz> Hi Robert, On 27/01/16 1:11 AM, Robert Kisteleki wrote: > > On 2016-01-26 0:41, Sebastian Castro wrote: >> Hi: >> >> I'm currently testing the API to get a list of my own measurements. The >> API here reports >> >> ----------- >> Querying for Your Own Measurements >> >> In order to limit the results to your measurements only, just add a >> mine=true argument. For example: >> >> /api/v1/measurement/?mine=true >> Note that this only works if you're logged in, otherwise the result is >> the same as for any unauthenticated user. >> ----------- >> >> This seems to imply you need to manage a session within your code to get >> your own measurements, which I think violates the principle of a REST >> API. If you have the API key that provides you with access, shouldn't be >> reasonable to run the call as >> >> /api/v1/measurement/?mine=true&key=API_KEY >> >> and get a list of your own measurements? >> >> Thoughts? Am I reading the documentation in the wrong way? >> >> Thanks in advance > > Hi, > > Can you provide your use case here? What's the purpose for getting a list of > your on measurements from a script? Shouldn't your scripts already know > about the measurements they started? :-) > That's usually the case, except when a there is a user interruption of the script, a strange failure case or any other that prevents the script to save the list of measurements at the right time :) Cheers, > Cheers, > Robert > -- Sebastian Castro Technical Research Manager NZRS Ltd. desk: +64 4 495 2337 mobile: +64 21 400535 From robert at ripe.net Wed Jan 27 09:37:16 2016 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 27 Jan 2016 09:37:16 +0100 Subject: [atlas] Querying your own measurements In-Reply-To: <56A7BDBE.6080709@nzrs.net.nz> References: <56A6B292.6080508@nzrs.net.nz> <56A76277.7050606@ripe.net> <56A7BDBE.6080709@nzrs.net.nz> Message-ID: <56A881BC.9090905@ripe.net> Hi, >> Can you provide your use case here? What's the purpose for getting a list of >> your on measurements from a script? Shouldn't your scripts already know >> about the measurements they started? :-) >> > > That's usually the case, except when a there is a user interruption of > the script, a strange failure case or any other that prevents the script > to save the list of measurements at the right time :) That can indeed happen -- though one would hope it is really an exception. We have two other kinds of API keys requested earlier and in the pipeline, so adding this third one is probably a minor increment in effort needed :-) However, since we're about to make the v2 API official and eventually remove v1, we'll most likely do this in the new version. Cheers, Robert From mkh at rqc.ru Wed Jan 27 11:10:00 2016 From: mkh at rqc.ru (Marat Khalili) Date: Wed, 27 Jan 2016 13:10:00 +0300 Subject: [atlas] No Ethernet activity on new probe Message-ID: <56A89778.6080106@rqc.ru> Dear All, I have received my probe yesterday morning (V3, like shown on https://atlas.ripe.net/docs/probe-v3/ ), connected and registered it. Unfortunately, not only no measurements or IP address information appeared in my profile after waiting several hours, but there's no Ethernet activity from probe at all, even in the packet trace. Things I tried: * 3 different switches (Fast and Gigabit types); in all cases a notebook running either Windows or Ubuntu when connected into the same socket acquires IP address just fine and can browse the Internet. * 3 different LAN cables; in all cases switches detect 100 Mbps physical wire but nothing more. * 2 different DHCP servers as well as wireshark on direct connection. * 3 different power sources (1A phone charger, notebook 2xUSB, PC USB). * Removing and re-inserting the USB flash key that came with the device, dd'ing its contents to a different USB flash and inserting it instead (dd finished successfully). Every time after the boot sequence ends first light glows steadily and adjacent one blinks slowly, like it is supposed to be according to https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean . Looks like the interface just isn't up in the device OS. Is there anything else I can check? Should I request another probe? (it took more than month to receive first one by post) -- With Best Regards, Marat Khalili -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco at marcoslater.com Wed Jan 27 11:27:53 2016 From: marco at marcoslater.com (Marco Slater) Date: Wed, 27 Jan 2016 10:27:53 +0000 Subject: [atlas] No Ethernet activity on new probe In-Reply-To: <56A89778.6080106@rqc.ru> References: <56A89778.6080106@rqc.ru> Message-ID: <563361A6-B019-4CFC-8D1F-539FE9D08FAA@marcoslater.com> Hi, I?ve had a similar issue where the probe just wouldn?t come online, or detect anything. All I did is leave it there for a few days, it started coming online and going offline constantly every few minutes for the second day, and then it just sorted itself, I noticed I got an alert on the ?Messages? tab saying the probe upgraded its firmware and kernel, it?s been working fine since. Not sure if its related at all, would be nice if you could get some more debugging out of probes. :) I didn?t really question it until now, but it does seem odd. - Marco > On 27 Jan 2016, at 10:10, Marat Khalili wrote: > > Dear All, > > I have received my probe yesterday morning (V3, like shown on https://atlas.ripe.net/docs/probe-v3/ ), connected and registered it. Unfortunately, not only no measurements or IP address information appeared in my profile after waiting several hours, but there's no Ethernet activity from probe at all, even in the packet trace. > > Things I tried: > * 3 different switches (Fast and Gigabit types); in all cases a notebook running either Windows or Ubuntu when connected into the same socket acquires IP address just fine and can browse the Internet. > * 3 different LAN cables; in all cases switches detect 100 Mbps physical wire but nothing more. > * 2 different DHCP servers as well as wireshark on direct connection. > * 3 different power sources (1A phone charger, notebook 2xUSB, PC USB). > * Removing and re-inserting the USB flash key that came with the device, dd'ing its contents to a different USB flash and inserting it instead (dd finished successfully). > > Every time after the boot sequence ends first light glows steadily and adjacent one blinks slowly, like it is supposed to be according to https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean . Looks like the interface just isn't up in the device OS. Is there anything else I can check? Should I request another probe? (it took more than month to receive first one by post) > > -- > > With Best Regards, > Marat Khalili From mkh at rqc.ru Wed Jan 27 11:42:27 2016 From: mkh at rqc.ru (Marat Khalili) Date: Wed, 27 Jan 2016 13:42:27 +0300 Subject: [atlas] No Ethernet activity on new probe In-Reply-To: <563361A6-B019-4CFC-8D1F-539FE9D08FAA@marcoslater.com> References: <56A89778.6080106@rqc.ru> <563361A6-B019-4CFC-8D1F-539FE9D08FAA@marcoslater.com> Message-ID: <56A89F13.1060203@rqc.ru> Hello Marco, Thank you very much for your reply. I'll try to leave it as is until Monday. Do you remember if there was any information about the probe's IP address on the Network tab during that time? -- With Best Regards, Marat Khalili On 27/01/16 13:27, Marco Slater wrote: > Hi, > > I?ve had a similar issue where the probe just wouldn?t come online, or detect anything. > > All I did is leave it there for a few days, it started coming online and going offline constantly every few minutes for the second day, and then it just sorted itself, I noticed I got an alert on the ?Messages? tab saying the probe upgraded its firmware and kernel, it?s been working fine since. > > Not sure if its related at all, would be nice if you could get some more debugging out of probes. :) > > I didn?t really question it until now, but it does seem odd. > > - Marco > > >> On 27 Jan 2016, at 10:10, Marat Khalili wrote: >> >> Dear All, >> >> I have received my probe yesterday morning (V3, like shown on https://atlas.ripe.net/docs/probe-v3/ ), connected and registered it. Unfortunately, not only no measurements or IP address information appeared in my profile after waiting several hours, but there's no Ethernet activity from probe at all, even in the packet trace. >> >> Things I tried: >> * 3 different switches (Fast and Gigabit types); in all cases a notebook running either Windows or Ubuntu when connected into the same socket acquires IP address just fine and can browse the Internet. >> * 3 different LAN cables; in all cases switches detect 100 Mbps physical wire but nothing more. >> * 2 different DHCP servers as well as wireshark on direct connection. >> * 3 different power sources (1A phone charger, notebook 2xUSB, PC USB). >> * Removing and re-inserting the USB flash key that came with the device, dd'ing its contents to a different USB flash and inserting it instead (dd finished successfully). >> >> Every time after the boot sequence ends first light glows steadily and adjacent one blinks slowly, like it is supposed to be according to https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean . Looks like the interface just isn't up in the device OS. Is there anything else I can check? Should I request another probe? (it took more than month to receive first one by post) >> >> -- >> >> With Best Regards, >> Marat Khalili > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Wed Jan 27 12:01:37 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 27 Jan 2016 12:01:37 +0100 Subject: [atlas] No Ethernet activity on new probe In-Reply-To: <56A89778.6080106@rqc.ru> References: <56A89778.6080106@rqc.ru> Message-ID: <56A8A391.1040009@ripe.net> On 2016/01/27 11:10 , Marat Khalili wrote: > Every time after the boot sequence ends first light glows steadily and > adjacent one blinks slowly, like it is supposed to be according to > https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean > . Looks like the interface just isn't up in the device OS. Is there > anything else I can check? Should I request another probe? (it took more > than month to receive first one by post) Hi, After a few minutes, probes as shipped reach the situation where the power LED is on, the next LED is off, the next two LEDs are either blinking or on. The WPS LED seems to have mind of its own, and should ignored. If that is not the case then it is either a power issue or somebody played with the USB stick. To detect network activity when there might be an issue with the USB stick, remove the USB stick and power on the probe. The probe should reach a situation where the power LED is on and the next LED is blinking. In that state the probe will try to a get an address using DHCP, will do IPv6, an on the probe page, new entries in the 'SOS History' history section should show up. This should be enough for basic network connectivity tests. Philip From robert at ripe.net Wed Jan 27 12:18:42 2016 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 27 Jan 2016 12:18:42 +0100 Subject: [atlas] LLDP Support for RIPE Probes In-Reply-To: References: <56794E77.4020504@penguinfriends.org> <5679CFE0.6060506@danysek.cz> <5679D3F6.7020203@inex.ie> Message-ID: <56A8A792.10405@ripe.net> Dear All, Thank you for this suggestion, we put this feature on our agenda as a requested item. We'll do some internal check on what it would take to implement this, and report back to you about ETAs. Regards, Robert On 2015-12-23 0:10, Marco Slater wrote: > Agreed! +1 > > -Marco > >> On 22 Dec 2015, at 23:51, Nick Hilliard wrote: >> >> yes. YES! >> >> Nick >> >> Daniel Suchy wrote: >>> +1 >>> >>>> On 22.12.2015 22:31, Rickard ?stman wrote: >>>> awesome idea. >>>> >>>> another useful feature would be to let the probe share via the atlas >>>> portal what device and port it's connected to. To the owner alone, that is. >>>> >>>> /Rickard >>>> >>>> On Tuesday, 22 December 2015, Max Gebert >>> > wrote: >>>> >>>> Hey! >>>> >>>> I could definitely see the appeal of such a function in our network. >>>> +1 from me! >>>> >>>> Best regards/ H?lsningar >>>> Max Gebert >>>> >>>>> 22 dec 2015 kl. 18:23 skrev Chris Elliott : >>>>> >>>>> +1 >>>>> >>>>> On Tuesday, December 22, 2015, Annika Wickert >>>>> wrote: >>>>> >>>>> Hi everybody, >>>>> >>>>> I would like to see LLDP support in the future on the RIPE probes. >>>>> >>>>> It would be a really helpful feature, to see on what Port the >>>>> RIPE Probe resides at the moment. >>>>> >>>>> Cheers, >>>>> Annika >>>>> >>>>> >>>>> >>>>> -- >>>>> Chris Elliott >>>>> CCIE # 2013 >>>>> >>>>> ?You and I are mirages that perceive themselves? >>>>> --Douglas Hofstadter >> >> > > From robert at ripe.net Wed Jan 27 12:25:19 2016 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 27 Jan 2016 12:25:19 +0100 Subject: [atlas] Scheduling a test for all probes? In-Reply-To: <6DA0773E-8FA8-4269-B170-84591D8B1E36@puck.nether.net> References: <6DA0773E-8FA8-4269-B170-84591D8B1E36@puck.nether.net> Message-ID: <56A8A91F.5050903@ripe.net> (Excuse me for the belated answer -- I'm picking up topics that were not answered by us or the community.) On 2015-12-09 20:00, Jared Mauch wrote: > Is there a way to schedule a one-off test on all the probes to be run ?at a leisurely pace?, eg: looking up a specific DNS QNAME? > > (I?ll call it a lazy query/scheduling). > > - Jared Not at the moment -- one-off really means "it's important, do it now!" One can always schedule a short-running regular measurement and use the (new) spread control mechanism to distribute the probes over a longer period. Cheers, Robert From gil at magisto.com Wed Jan 27 12:27:38 2016 From: gil at magisto.com (Gil Bahat) Date: Wed, 27 Jan 2016 13:27:38 +0200 Subject: [atlas] HTTP measurements at willing targets / protocol suggestion In-Reply-To: <5649B91F.2060408@ripe.net> References: <5649B91F.2060408@ripe.net> Message-ID: Hi, Is there any place where we can have a full list of reasoning as to what's blocking HTTP measurements? The above discussion does not relate to the risks posed to the clients by HTTP measurements (monetary, regulatory/legal), which mandates a mechanism that only willing probe hosts enter it. OTOH I don't understand the abuse scenario from the host side (i.e. if I register evil.whatever and I'm hosting it, who can I damage aside from myself and my own hosting bill? that's unclear to me) as long as the probe's capabilities are Regards, Gil Bahat, Director of Online Operations, Magisto Ltd. On Mon, Nov 16, 2015 at 1:08 PM, Philip Homburg wrote: > On 2015/11/16 12:00 , Emil Stahl Pedersen wrote: > > ?+1 ? > > Sounds like a perfect solution > > ? ?? > > Sounds like it is open for abuse. Someone registers evil.whatever, > passes all validation checks and can then serve any content he likes. > > No way to find out who set it up. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkh at rqc.ru Wed Jan 27 12:53:13 2016 From: mkh at rqc.ru (Marat Khalili) Date: Wed, 27 Jan 2016 14:53:13 +0300 Subject: [atlas] No Ethernet activity on new probe In-Reply-To: <56A8A391.1040009@ripe.net> References: <56A89778.6080106@rqc.ru> <56A8A391.1040009@ripe.net> Message-ID: <56A8AFA9.3020703@rqc.ru> Hello Philip, > power LED is on, the next LED is off, the next two LEDs are either > blinking or on. It is NOT this way here. Regardless of whether USB stick is in or not LEDs 3 and 4 are dark. Is there a place I can download correct image for USB key from? -- With Best Regards, Marat Khalili On 27/01/16 14:01, Philip Homburg wrote: > On 2016/01/27 11:10 , Marat Khalili wrote: >> Every time after the boot sequence ends first light glows steadily and >> adjacent one blinks slowly, like it is supposed to be according to >> https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean >> . Looks like the interface just isn't up in the device OS. Is there >> anything else I can check? Should I request another probe? (it took more >> than month to receive first one by post) > Hi, > > After a few minutes, probes as shipped reach the situation where the > power LED is on, the next LED is off, the next two LEDs are either > blinking or on. The WPS LED seems to have mind of its own, and should > ignored. > > If that is not the case then it is either a power issue or somebody > played with the USB stick. > > To detect network activity when there might be an issue with the USB > stick, remove the USB stick and power on the probe. The probe should > reach a situation where the power LED is on and the next LED is blinking. > > In that state the probe will try to a get an address using DHCP, will do > IPv6, an on the probe page, new entries in the 'SOS History' history > section should show up. This should be enough for basic network > connectivity tests. > > Philip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco at marcoslater.com Wed Jan 27 12:54:01 2016 From: marco at marcoslater.com (Marco Slater) Date: Wed, 27 Jan 2016 11:54:01 +0000 Subject: [atlas] No Ethernet activity on new probe In-Reply-To: <56A89F13.1060203@rqc.ru> References: <56A89778.6080106@rqc.ru> <563361A6-B019-4CFC-8D1F-539FE9D08FAA@marcoslater.com> <56A89F13.1060203@rqc.ru> Message-ID: Hi Marat, I noticed information started to show up on the panel when it started its few reboot loops. After that it kept loosing network connectivity, even though it was there, which showed up on the panel, it would connect/disconnect to the atlas control servers constantly for at least a day, after which it just stopped and stabilised. If someone can let me know if theres any way to restore logs or any hint as to what exactly happened on my probe, I have no problem taking a look and sharing my findings, even though it seems to work fine now, so far. If it helps, the probe ID for the one of mine which had said issues is 19100 . Hope this helps in some way. :) - Marco > On 27 Jan 2016, at 10:42, Marat Khalili wrote: > > Hello Marco, > > Thank you very much for your reply. I'll try to leave it as is until Monday. > > Do you remember if there was any information about the probe's IP address on the Network tab during that time? > > -- > > With Best Regards, > Marat Khalili > > > On 27/01/16 13:27, Marco Slater wrote: >> Hi, >> >> I?ve had a similar issue where the probe just wouldn?t come online, or detect anything. >> >> All I did is leave it there for a few days, it started coming online and going offline constantly every few minutes for the second day, and then it just sorted itself, I noticed I got an alert on the ?Messages? tab saying the probe upgraded its firmware and kernel, it?s been working fine since. >> >> Not sure if its related at all, would be nice if you could get some more debugging out of probes. :) >> >> I didn?t really question it until now, but it does seem odd. >> >> - Marco >> >> >> >>> On 27 Jan 2016, at 10:10, Marat Khalili >>> wrote: >>> >>> Dear All, >>> >>> I have received my probe yesterday morning (V3, like shown on >>> https://atlas.ripe.net/docs/probe-v3/ >>> ), connected and registered it. Unfortunately, not only no measurements or IP address information appeared in my profile after waiting several hours, but there's no Ethernet activity from probe at all, even in the packet trace. >>> >>> Things I tried: >>> * 3 different switches (Fast and Gigabit types); in all cases a notebook running either Windows or Ubuntu when connected into the same socket acquires IP address just fine and can browse the Internet. >>> * 3 different LAN cables; in all cases switches detect 100 Mbps physical wire but nothing more. >>> * 2 different DHCP servers as well as wireshark on direct connection. >>> * 3 different power sources (1A phone charger, notebook 2xUSB, PC USB). >>> * Removing and re-inserting the USB flash key that came with the device, dd'ing its contents to a different USB flash and inserting it instead (dd finished successfully). >>> >>> Every time after the boot sequence ends first light glows steadily and adjacent one blinks slowly, like it is supposed to be according to >>> https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean >>> . Looks like the interface just isn't up in the device OS. Is there anything else I can check? Should I request another probe? (it took more than month to receive first one by post) >>> >>> -- >>> >>> With Best Regards, >>> Marat Khalili >>> >> > From marco at marcoslater.com Wed Jan 27 12:56:08 2016 From: marco at marcoslater.com (Marco Slater) Date: Wed, 27 Jan 2016 11:56:08 +0000 Subject: [atlas] 500 Probe limit Message-ID: Hello, I?ve been doing some tests on anycasted networks, and I?ve been hitting an error which doesn?t allow me to assign more then 500 probes to a measurement, is there a way to have this unlocked? I presume it is a default protection to not cause issues to hosts being probed? Thank you. :) - Marco From robert at ripe.net Wed Jan 27 13:11:33 2016 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 27 Jan 2016 13:11:33 +0100 Subject: [atlas] 500 Probe limit In-Reply-To: References: Message-ID: <56A8B3F5.8040603@ripe.net> On 2016-01-27 12:56, Marco Slater wrote: > Hello, > > I?ve been doing some tests on anycasted networks, and I?ve been hitting an error which doesn?t allow me to assign more then 500 probes to a measurement, is there a way to have this unlocked? > > I presume it is a default protection to not cause issues to hosts being probed? > > Thank you. :) > > - Marco Correct, it's one of the safety measures to keep resource use fair. As a related note: ultimately we want to change to a "max results asked per day" metric instead of max probes and measurements. We're almost ready -- let us know (atlas at ripe.net) if you want to volunteer as a tester for this! Cheers, Robert From sebastian at nzrs.net.nz Wed Jan 27 20:01:16 2016 From: sebastian at nzrs.net.nz (Sebastian Castro) Date: Thu, 28 Jan 2016 08:01:16 +1300 Subject: [atlas] Querying your own measurements In-Reply-To: <56A881BC.9090905@ripe.net> References: <56A6B292.6080508@nzrs.net.nz> <56A76277.7050606@ripe.net> <56A7BDBE.6080709@nzrs.net.nz> <56A881BC.9090905@ripe.net> Message-ID: <56A913FC.7010804@nzrs.net.nz> On 27/01/16 9:37 PM, Robert Kisteleki wrote: > Hi, > >>> Can you provide your use case here? What's the purpose for getting a list of >>> your on measurements from a script? Shouldn't your scripts already know >>> about the measurements they started? :-) >>> >> >> That's usually the case, except when a there is a user interruption of >> the script, a strange failure case or any other that prevents the script >> to save the list of measurements at the right time :) > > That can indeed happen -- though one would hope it is really an exception. > > We have two other kinds of API keys requested earlier and in the pipeline, > so adding this third one is probably a minor increment in effort needed :-) > However, since we're about to make the v2 API official and eventually remove > v1, we'll most likely do this in the new version. Thanks, that's sensible. Will wait for v2 API then :) Cheers, > > Cheers, > Robert > > -- Sebastian Castro Technical Research Manager NZRS Ltd. desk: +64 4 495 2337 mobile: +64 21 400535 From alexander at neilson.net.nz Wed Jan 27 20:04:16 2016 From: alexander at neilson.net.nz (Alexander Neilson) Date: Thu, 28 Jan 2016 08:04:16 +1300 Subject: [atlas] 500 Probe limit In-Reply-To: References: Message-ID: Hi Marco If you look at the bottom of https://atlas.ripe.net/docs/udm/#rate-limits you can see the email link to contact the RIPE Atlas team to propose your test and they can (and will) unlock to allow for testing like you seem to be talking about. I was approved to use this for a full network test of Google DNS Anycasting (I was specifically looking to find the prevalence of ISP's imposing their own DNS servers as the Google 8.8.8.8 and 8.8.4.4). I am fairly sure I have those test results public so if that is useful to you then feel free to collect and use the data. If you can't find it let me know and I will check the references for you of the tests. Regards Alexander Alexander Neilson Neilson Productions Limited alexander at neilson.net.nz 021 329 681 On 28 January 2016 at 00:56, Marco Slater wrote: > Hello, > > I?ve been doing some tests on anycasted networks, and I?ve been hitting an > error which doesn?t allow me to assign more then 500 probes to a > measurement, is there a way to have this unlocked? > > I presume it is a default protection to not cause issues to hosts being > probed? > > Thank you. :) > > - Marco > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkh at rqc.ru Thu Jan 28 08:16:12 2016 From: mkh at rqc.ru (Marat Khalili) Date: Thu, 28 Jan 2016 10:16:12 +0300 Subject: [atlas] No Ethernet activity on new probe In-Reply-To: References: <56A89778.6080106@rqc.ru> <563361A6-B019-4CFC-8D1F-539FE9D08FAA@marcoslater.com> <56A89F13.1060203@rqc.ru> Message-ID: <56A9C03C.7090302@rqc.ru> Following some advices received by email, I booted it without USB then inserted USB stick 10 minutes later, and it worked. Probably stock firmware has some problem detecting USB devices during boot cycle. In any case, problem is solved for now. -- With Best Regards, Marat Khalili On 27/01/16 14:54, Marco Slater wrote: > Hi Marat, > > I noticed information started to show up on the panel when it started its few reboot loops. After that it kept loosing network connectivity, even though it was there, which showed up on the panel, it would connect/disconnect to the atlas control servers constantly for at least a day, after which it just stopped and stabilised. > > If someone can let me know if theres any way to restore logs or any hint as to what exactly happened on my probe, I have no problem taking a look and sharing my findings, even though it seems to work fine now, so far. If it helps, the probe ID for the one of mine which had said issues is 19100 . > > Hope this helps in some way. :) > > - Marco > >> On 27 Jan 2016, at 10:42, Marat Khalili wrote: >> >> Hello Marco, >> >> Thank you very much for your reply. I'll try to leave it as is until Monday. >> >> Do you remember if there was any information about the probe's IP address on the Network tab during that time? >> >> -- >> >> With Best Regards, >> Marat Khalili >> >> >> On 27/01/16 13:27, Marco Slater wrote: >>> Hi, >>> >>> I?ve had a similar issue where the probe just wouldn?t come online, or detect anything. >>> >>> All I did is leave it there for a few days, it started coming online and going offline constantly every few minutes for the second day, and then it just sorted itself, I noticed I got an alert on the ?Messages? tab saying the probe upgraded its firmware and kernel, it?s been working fine since. >>> >>> Not sure if its related at all, would be nice if you could get some more debugging out of probes. :) >>> >>> I didn?t really question it until now, but it does seem odd. >>> >>> - Marco >>> >>> >>> >>>> On 27 Jan 2016, at 10:10, Marat Khalili >>>> wrote: >>>> >>>> Dear All, >>>> >>>> I have received my probe yesterday morning (V3, like shown on >>>> https://atlas.ripe.net/docs/probe-v3/ >>>> ), connected and registered it. Unfortunately, not only no measurements or IP address information appeared in my profile after waiting several hours, but there's no Ethernet activity from probe at all, even in the packet trace. >>>> >>>> Things I tried: >>>> * 3 different switches (Fast and Gigabit types); in all cases a notebook running either Windows or Ubuntu when connected into the same socket acquires IP address just fine and can browse the Internet. >>>> * 3 different LAN cables; in all cases switches detect 100 Mbps physical wire but nothing more. >>>> * 2 different DHCP servers as well as wireshark on direct connection. >>>> * 3 different power sources (1A phone charger, notebook 2xUSB, PC USB). >>>> * Removing and re-inserting the USB flash key that came with the device, dd'ing its contents to a different USB flash and inserting it instead (dd finished successfully). >>>> >>>> Every time after the boot sequence ends first light glows steadily and adjacent one blinks slowly, like it is supposed to be according to >>>> https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean >>>> . Looks like the interface just isn't up in the device OS. Is there anything else I can check? Should I request another probe? (it took more than month to receive first one by post) >>>> >>>> -- >>>> >>>> With Best Regards, >>>> Marat Khalili >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luke at cloudflare.com Thu Jan 28 10:47:40 2016 From: luke at cloudflare.com (Luke Overend) Date: Thu, 28 Jan 2016 09:47:40 +0000 Subject: [atlas] List of my measurements via API Message-ID: Hi all, I have searched the docs and tried everything I can think of but I cannot get a list of my measurements via the API. Can anyone provide me details on how to do this? If it is not currently possible how do I go about requesting the feature? Thanks Luke Overend -------------------------------------- CloudFlare - AS13335 Network Engineer luke at cloudflare.com +442038136383 +447795328022 http://www.peeringdb.com/view.php?asn=13335 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenqin.shao at telecom-paristech.fr Thu Jan 28 11:13:59 2016 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Thu, 28 Jan 2016 11:13:59 +0100 Subject: [atlas] API (v1) querying probes--does stats_name field count and possibility of negative selection Message-ID: <1ABC9119-8743-4FCF-8F6A-DC9F8A6585E3@telecom-paristech.fr> Dear list, I encountered some unexpected results when selecting probes with status_name filed. An example is given below: https://atlas.ripe.net/api/v1/probe/?country_code=BG&tags=system-v3,datacentre&is_public=true&status_name=Abandoned 8 results were returned containing probes that are abandoned, as well disconnected and connected. To nail down the problematic field, I tried following queries: https://atlas.ripe.net/api/v1/probe/?status_name=Connected https://atlas.ripe.net/api/v1/probe/?status_name=Abandoned https://atlas.ripe.net/api/v1/probe/?status_name=Disconnected https://atlas.ripe.net/api/v1/probe/?status_name=Haha Exactly same number of probes, 16889, are return with each of these quests, which makes me wonder whether the status_name filed is actually taken into consideration? One other issue, is to negatively select probes according to some fields, especially tags filed, for example, probes do not contain home tag. I?d like to know if such selection logic is supported by v1 API? If yes, how to compose the query? If not, would it be considered in v2 API? A bunch of thanks in advance. Regards, Wenqin Telecom ParisTech -------------- next part -------------- An HTML attachment was scrubbed... URL: