From philip.homburg at ripe.net Tue Aug 2 13:42:52 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 2 Aug 2016 13:42:52 +0200 Subject: [atlas] New analysis of version 3 probes on RIPE Labs Message-ID: <30f3997d-de44-e53a-4c02-ddd06df6a2fe@ripe.net> Hi, As promised, we?ve continued to look into the issue that some people are having with the version 3 probes and have found that actual hardware failures for version 3 probes are in fact relatively rare compared to filesystem corruption. We?ve published a new article on RIPE Labs with the complete analysis: https://labs.ripe.net/Members/philip_homburg/further-analysis-of-ripe-atlas-version-3-probe?pk_campaign=atlas&pk_kwd=list-atlas We?ll continue looking into these issues, so stay tuned for future articles. Philip Homburg RIPE NCC From robert at ripe.net Wed Aug 3 16:12:01 2016 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 3 Aug 2016 16:12:01 +0200 Subject: [atlas] Awarding credits for measurement results Message-ID: Dear probe and anchor hosts, When you create measurement results in RIPE Atlas, you?ll now get a little something extra back in the form of credits. From now on, we?re giving all RIPE Atlas probe and anchor hosts one credit back for every measurement result they generate. This means that most probe hosts will earn up to an additional 10,000 credits (50%) per day on top of the credits they get for keeping their probes online, anchor hosts will earn an additional roughly 200,000 credits (100%) daily, and DNSMON anchor hosts will receive roughly 1,000,000 additional credits. This is our way of rewarding the probe and anchor hosts who contribute the most to RIPE Atlas - enjoy! Regards, Robert Kisteleki RIPE NCC From mcandela at ripe.net Wed Aug 3 17:46:34 2016 From: mcandela at ripe.net (Massimo Candela) Date: Wed, 3 Aug 2016 17:46:34 +0200 Subject: [atlas] atlas-stream SSL problem Message-ID: Hi all, We are currently experiencing an issue with the load balancer of the streaming service over SSL. We are working on it. The service on http on port 80 is not affected. The Atlas CLI and Cousteau are not affected too. Sorry for the inconvenience. It will be fixed soon. Best regards, Massimo Candela -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From mcandela at ripe.net Wed Aug 3 18:21:40 2016 From: mcandela at ripe.net (Massimo Candela) Date: Wed, 3 Aug 2016 18:21:40 +0200 Subject: [atlas] atlas-stream SSL problem In-Reply-To: References: Message-ID: <92553253-0E7B-4B1D-9295-6088C7DA030E@ripe.net> The issue has been fixed. Best regards, Massimo Candela > On 03 Aug 2016, at 17:46, Massimo Candela wrote: > > Hi all, > > We are currently experiencing an issue with the load balancer of the streaming service over SSL. > We are working on it. > > The service on http on port 80 is not affected. > The Atlas CLI and Cousteau are not affected too. > > Sorry for the inconvenience. It will be fixed soon. > > Best regards, > Massimo Candela > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From ripe at fersing.eu Thu Aug 4 00:17:03 2016 From: ripe at fersing.eu (Boris Fersing) Date: Wed, 03 Aug 2016 22:17:03 +0000 Subject: [atlas] Probe reported as disconnected but is actually online Message-ID: <4ef3e6a63e353e86be45e55f5fd957c3@rainloop.fersing.net> Hi there, Today I had a power failure at home and since then, my probe's state is "disconnected", but I checked the network traffic and it looks like the probe is actually able to reach the internet and is doing some DNS requests I don't know about: U431.M.sos.atlas.ripe.net U980.M.sos.atlas.ripe.net U116.M.sos.atlas.ripe.net Do you know what those SOS requests mean? The SOS history on the atlas.ripe.net page doesn't show any useful message. The Status (beta) tab shows the following message: ===== Firewall Problems Suspected What does this mean? Probes connect to the controlling infrastructure using SSH (via port 443). If our system detects that the probe is successfully engaged in other kinds of activities, but these SSH connections fail, then it's highly likely that these connections are somehow blocked or disturbed. This could be because there's a firewall blocking these connections. Another reason could be that there is a (transparent) proxy in the way that affects port 443 (usually HTTPS) connections, which means the probe and its controller cannot mutually authenticate each other (because the proxy is interfering). How can I fix this? Check whether you have a firewall or an aggressive NAT appliance preventing such connections. Also check whether there's a transparent proxy on the path. Alternatively, you can try plugging in the probe on a different network to confirm whether a firewall / proxy is really causing the problem. ===== But since I don't know which host the probe is trying to connect to, I can't really test it and tcpdump doesn't show any attempt to a port 443. Thanks Boris From vnaumov at ripe.net Thu Aug 4 08:47:36 2016 From: vnaumov at ripe.net (Viktor Naumov) Date: Thu, 4 Aug 2016 08:47:36 +0200 Subject: [atlas] Probe reported as disconnected but is actually online In-Reply-To: <4ef3e6a63e353e86be45e55f5fd957c3@rainloop.fersing.net> References: <4ef3e6a63e353e86be45e55f5fd957c3@rainloop.fersing.net> Message-ID: Hi Boris, The troubleshooting system sees that you have a number disconnects, sees connection to a registration server, but probe cannot make it to controller, therefore it thinks that there are possible firewall problems. But if you say that you had a power outage it most probably looks like a file system corruption on the flash drive. Please try this https://labs.ripe.net/Members/philip_homburg/troubleshooting-ripe-atlas-probes-usb-sticks wbr /vty On 8/4/16 12:17 AM, Boris Fersing wrote: > Hi there, > > Today I had a power failure at home and since then, my probe's state is "disconnected", but I > checked the network traffic and it looks like the probe is actually able to reach the internet and > is doing some DNS requests I don't know about: > > U431.M.sos.atlas.ripe.net > U980.M.sos.atlas.ripe.net > U116.M.sos.atlas.ripe.net > > Do you know what those SOS requests mean? The SOS history on the atlas.ripe.net page doesn't show > any useful message. > > The Status (beta) tab shows the following message: > > ===== > > Firewall Problems Suspected > What does this mean? > Probes connect to the controlling infrastructure using SSH (via port 443). If our system detects > that the probe is successfully engaged in other kinds of activities, but these SSH connections > fail, then it's highly likely that these connections are somehow blocked or disturbed. > > This could be because there's a firewall blocking these connections. Another reason could be that > there is a (transparent) proxy in the way that affects port 443 (usually HTTPS) connections, which > means the probe and its controller cannot mutually authenticate each other (because the proxy is > interfering). > > How can I fix this? > Check whether you have a firewall or an aggressive NAT appliance preventing such connections. Also > check whether there's a transparent proxy on the path. Alternatively, you can try plugging in the > probe on a different network to confirm whether a firewall / proxy is really causing the problem. > > ===== > > But since I don't know which host the probe is trying to connect to, I can't really test it and tcpdump doesn't show any attempt to a port 443. > > > Thanks > Boris > From ripe at fersing.eu Thu Aug 4 14:08:35 2016 From: ripe at fersing.eu (Boris Fersing) Date: Thu, 04 Aug 2016 12:08:35 +0000 Subject: [atlas] Probe reported as disconnected but is actually online In-Reply-To: References: <4ef3e6a63e353e86be45e55f5fd957c3@rainloop.fersing.net> Message-ID: Hi Viktor, I tried the flash drive reset procedure and now the probe is back online. Thank you, Boris August 4 2016 2:47 AM, "Viktor Naumov" wrote: > Hi Boris, > > The troubleshooting system sees that you have a number disconnects, sees connection to a > registration server, but probe cannot make it to controller, therefore it thinks that there are > possible firewall problems. > > But if you say that you had a power outage it most probably looks like a file system corruption on > the flash drive. > Please try this > https://labs.ripe.net/Members/philip_homburg/troubleshooting-ripe-atlas-probes-usb-sticks > > wbr > > /vty > > On 8/4/16 12:17 AM, Boris Fersing wrote: > >> Hi there, >> >> Today I had a power failure at home and since then, my probe's state is "disconnected", but I >> checked the network traffic and it looks like the probe is actually able to reach the internet and >> is doing some DNS requests I don't know about: >> >> U431.M.sos.atlas.ripe.net >> U980.M.sos.atlas.ripe.net >> U116.M.sos.atlas.ripe.net >> >> Do you know what those SOS requests mean? The SOS history on the atlas.ripe.net page doesn't show >> any useful message. >> >> The Status (beta) tab shows the following message: >> >> ===== >> >> Firewall Problems Suspected >> What does this mean? >> Probes connect to the controlling infrastructure using SSH (via port 443). If our system detects >> that the probe is successfully engaged in other kinds of activities, but these SSH connections >> fail, then it's highly likely that these connections are somehow blocked or disturbed. >> >> This could be because there's a firewall blocking these connections. Another reason could be that >> there is a (transparent) proxy in the way that affects port 443 (usually HTTPS) connections, which >> means the probe and its controller cannot mutually authenticate each other (because the proxy is >> interfering). >> >> How can I fix this? >> Check whether you have a firewall or an aggressive NAT appliance preventing such connections. Also >> check whether there's a transparent proxy on the path. Alternatively, you can try plugging in the >> probe on a different network to confirm whether a firewall / proxy is really causing the problem. >> >> ===== >> >> But since I don't know which host the probe is trying to connect to, I can't really test it and >> tcpdump doesn't show any attempt to a port 443. >> >> Thanks >> Boris From colinj at mx5.org.uk Thu Aug 4 14:18:43 2016 From: colinj at mx5.org.uk (Colin Johnston) Date: Thu, 4 Aug 2016 13:18:43 +0100 Subject: [atlas] Probe reported as disconnected but is actually online In-Reply-To: References: <4ef3e6a63e353e86be45e55f5fd957c3@rainloop.fersing.net> Message-ID: <33E64D10-55BF-45D6-BBB8-82584D13902D@mx5.org.uk> surely a fsck via the mini operating system, of the affected flash drive file system should able to be attempted remotely before reinstall of new image ? Colin > On 4 Aug 2016, at 13:08, Boris Fersing wrote: > > Hi Viktor, > > I tried the flash drive reset procedure and now the probe is back online. > > Thank you, > Boris > > > August 4 2016 2:47 AM, "Viktor Naumov" wrote: >> Hi Boris, >> >> The troubleshooting system sees that you have a number disconnects, sees connection to a >> registration server, but probe cannot make it to controller, therefore it thinks that there are >> possible firewall problems. >> >> But if you say that you had a power outage it most probably looks like a file system corruption on >> the flash drive. >> Please try this >> https://labs.ripe.net/Members/philip_homburg/troubleshooting-ripe-atlas-probes-usb-sticks >> >> wbr >> >> /vty >> >> On 8/4/16 12:17 AM, Boris Fersing wrote: >> >>> Hi there, >>> >>> Today I had a power failure at home and since then, my probe's state is "disconnected", but I >>> checked the network traffic and it looks like the probe is actually able to reach the internet and >>> is doing some DNS requests I don't know about: >>> >>> U431.M.sos.atlas.ripe.net >>> U980.M.sos.atlas.ripe.net >>> U116.M.sos.atlas.ripe.net >>> >>> Do you know what those SOS requests mean? The SOS history on the atlas.ripe.net page doesn't show >>> any useful message. >>> >>> The Status (beta) tab shows the following message: >>> >>> ===== >>> >>> Firewall Problems Suspected >>> What does this mean? >>> Probes connect to the controlling infrastructure using SSH (via port 443). If our system detects >>> that the probe is successfully engaged in other kinds of activities, but these SSH connections >>> fail, then it's highly likely that these connections are somehow blocked or disturbed. >>> >>> This could be because there's a firewall blocking these connections. Another reason could be that >>> there is a (transparent) proxy in the way that affects port 443 (usually HTTPS) connections, which >>> means the probe and its controller cannot mutually authenticate each other (because the proxy is >>> interfering). >>> >>> How can I fix this? >>> Check whether you have a firewall or an aggressive NAT appliance preventing such connections. Also >>> check whether there's a transparent proxy on the path. Alternatively, you can try plugging in the >>> probe on a different network to confirm whether a firewall / proxy is really causing the problem. >>> >>> ===== >>> >>> But since I don't know which host the probe is trying to connect to, I can't really test it and >>> tcpdump doesn't show any attempt to a port 443. >>> >>> Thanks >>> Boris > From franc.molitierno at gmail.com Thu Aug 4 14:23:12 2016 From: franc.molitierno at gmail.com (Francesco Molitierno) Date: Thu, 4 Aug 2016 14:23:12 +0200 Subject: [atlas] Verbatim stick falled in read only In-Reply-To: References: Message-ID: The verbatim stick of my probe seems falled in a read-only state, there is something that i can try to fix? -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Thu Aug 4 14:41:09 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 4 Aug 2016 14:41:09 +0200 Subject: [atlas] Probe reported as disconnected but is actually online In-Reply-To: <33E64D10-55BF-45D6-BBB8-82584D13902D@mx5.org.uk> References: <4ef3e6a63e353e86be45e55f5fd957c3@rainloop.fersing.net> <33E64D10-55BF-45D6-BBB8-82584D13902D@mx5.org.uk> Message-ID: <8f0aa5de-57c3-fec2-568f-302161365122@ripe.net> Hi, On 2016/08/04 14:18 , Colin Johnston wrote: > surely a fsck via the mini operating system, of the affected flash drive file system should able to be attempted remotely before reinstall of new image ? The problem is that the mini operating system on the built-in flash doesn't notice that the filesystem on the USB stick is corrupt and then tries to boot from it. It is not clear what the most fool-proof way would be to detect corruption. We are working on changing the filesystem from ext2 to ext4. Hopefully that helps. If it doesn't, then we have to look into detecting corrupt filesystems. Philip From philip.homburg at ripe.net Thu Aug 4 14:43:00 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 4 Aug 2016 14:43:00 +0200 Subject: [atlas] Verbatim stick falled in read only In-Reply-To: References: Message-ID: <7232f95d-d566-24dd-fc5e-7f41083c2463@ripe.net> Hi Francesco, On 2016/08/04 14:23 , Francesco Molitierno wrote: > The verbatim stick of my probe seems falled in a read-only state, there > is something that i can try to fix? Unfortunately, when the USB stick is read-only it should be considered broken an has to be replaced. Any USB stick of 4 GB or bigger will do. Note that all existing data on the stick will be lost. Philip From gboonie at gmail.com Thu Aug 4 19:16:47 2016 From: gboonie at gmail.com (gboonie) Date: Thu, 4 Aug 2016 19:16:47 +0200 Subject: [atlas] Awarding credits for measurement results In-Reply-To: References: Message-ID: <6e9449fc-466c-44c6-7c32-2c9f6eb49587@gmail.com> Are there any projects in need of a few million credits? I have more than I'll ever be using. Dave Op 3-8-2016 om 16:12 schreef Robert Kisteleki: > Dear probe and anchor hosts, > > When you create measurement results in RIPE Atlas, you?ll now get a little > something extra back in the form of credits. From now on, we?re giving all > RIPE Atlas probe and anchor hosts one credit back for every measurement > result they generate. This means that most probe hosts will earn up to an > additional 10,000 credits (50%) per day on top of the credits they get for > keeping their probes online, anchor hosts will earn an additional roughly > 200,000 credits (100%) daily, and DNSMON anchor hosts will receive roughly > 1,000,000 additional credits. > > This is our way of rewarding the probe and anchor hosts who contribute the > most to RIPE Atlas - enjoy! > > Regards, > Robert Kisteleki > RIPE NCC > From Clinton.Work at telus.com Tue Aug 9 17:21:25 2016 From: Clinton.Work at telus.com (Clinton Work) Date: Tue, 9 Aug 2016 09:21:25 -0600 Subject: [atlas] Incrementing LTS For probe 6106 Message-ID: Probe 6106 has an LTS value of at least 187450 and it continues to grow. ================================= Clinton Work Senior Design Specialist IP Core Network Integrity TELUS | Network and System Operations Phone: (403) 384-4027 -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Tue Aug 9 17:31:53 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 9 Aug 2016 17:31:53 +0200 Subject: [atlas] Incrementing LTS For probe 6106 In-Reply-To: References: Message-ID: On 2016/08/09 17:21 , Clinton Work wrote: > Probe 6106 has an LTS value of at least 187450 and it continues to grow. The code that manages the lts value does a consistency check with the time on the controller. The problem with the anchor is that the connection to the controller (in Amsterdam) is slow enough that the consistency check fails. I don't know why. The latency to Amsterdam doesn't seem exceptionally high. See https://stat.ripe.net/m/widget/atlas-ping-measurements#w.mode=condensed&w.measurement_id=2030&w.probe_id=6106 Philip From robert at ripe.net Fri Aug 12 10:44:39 2016 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 12 Aug 2016 10:44:39 +0200 Subject: [atlas] IPv4-only Anchors Now Supported Message-ID: <8a7a22a8-5319-df06-ea74-59e8537d0df9@ripe.net> Dear colleagues, We've decided to support "IPv4-only" anchors in ASNs where IPv6 is not available. You can learn more in this RIPE Labs article: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ipv4-only-ripe-atlas-anchors-now-supported?pk_campaign=labs&pk_kwd=list-atlas Regards, Robert Kisteleki RIPE NCC From gert at space.net Fri Aug 12 10:51:28 2016 From: gert at space.net (Gert Doering) Date: Fri, 12 Aug 2016 10:51:28 +0200 Subject: [atlas] IPv4-only Anchors Now Supported In-Reply-To: <8a7a22a8-5319-df06-ea74-59e8537d0df9@ripe.net> References: <8a7a22a8-5319-df06-ea74-59e8537d0df9@ripe.net> Message-ID: <20160812085128.GV79185@Space.Net> Hi, On Fri, Aug 12, 2016 at 10:44:39AM +0200, Robert Kisteleki wrote: > We've decided to support "IPv4-only" anchors in ASNs where IPv6 is not > available. You can learn more in this RIPE Labs article: Uh, what? It is not April first. 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: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lorenzo at google.com Fri Aug 12 10:52:38 2016 From: lorenzo at google.com (Lorenzo Colitti) Date: Fri, 12 Aug 2016 17:52:38 +0900 Subject: [atlas] IPv4-only Anchors Now Supported In-Reply-To: <8a7a22a8-5319-df06-ea74-59e8537d0df9@ripe.net> References: <8a7a22a8-5319-df06-ea74-59e8537d0df9@ripe.net> Message-ID: On Fri, Aug 12, 2016 at 5:44 PM, Robert Kisteleki wrote: > We've decided to support "IPv4-only" anchors in ASNs where IPv6 is not > available. You can learn more in this RIPE Labs article: > > https://labs.ripe.net/Members/suzanne_taylor_muzzin/ipv4- > only-ripe-atlas-anchors-now-supported?pk_campaign=labs&pk_kwd=list-atlas I think it would be useful if the Atlas UI automatically displayed Legacy IP Only logos next to all such anchors, such that users can easily be aware of such limitations. As a long-time Atlas user, where do I file a feature request? :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Fri Aug 12 11:50:54 2016 From: randy at psg.com (Randy Bush) Date: Fri, 12 Aug 2016 18:50:54 +0900 Subject: [atlas] IPv4-only Anchors Now Supported In-Reply-To: <8a7a22a8-5319-df06-ea74-59e8537d0df9@ripe.net> References: <8a7a22a8-5319-df06-ea74-59e8537d0df9@ripe.net> Message-ID: where do i file a feature requenst for anchors with ipv6 to display "connectivity may suck?" randy From pk at DENIC.DE Fri Aug 12 12:00:38 2016 From: pk at DENIC.DE (Peter Koch) Date: Fri, 12 Aug 2016 12:00:38 +0200 Subject: [atlas] IPv4-only Anchors Now Supported In-Reply-To: <8a7a22a8-5319-df06-ea74-59e8537d0df9@ripe.net> References: <8a7a22a8-5319-df06-ea74-59e8537d0df9@ripe.net> Message-ID: <20160812100038.GA31204@x28.adm.denic.de> On Fri, Aug 12, 2016 at 10:44:39AM +0200, Robert Kisteleki wrote: > We've decided to support "IPv4-only" anchors in ASNs where IPv6 is not > available. You can learn more in this RIPE Labs article: the article says "However, we will only support IPv4-only anchors hosted in ASNs that cannot announce IPv6 for technical reasons.". Could the NCC share examples (respectfully anonymized) of such _technical_ (as opposed to "technical") reasons? -Peter From nick at inex.ie Fri Aug 12 13:01:32 2016 From: nick at inex.ie (Nick Hilliard) Date: Fri, 12 Aug 2016 12:01:32 +0100 Subject: [atlas] IPv4-only Anchors Now Supported In-Reply-To: <20160812100038.GA31204@x28.adm.denic.de> References: <8a7a22a8-5319-df06-ea74-59e8537d0df9@ripe.net> <20160812100038.GA31204@x28.adm.denic.de> Message-ID: <57ADAC8C.4080304@inex.ie> Peter Koch wrote: > the article says "However, we will only support IPv4-only anchors hosted > in ASNs that cannot announce IPv6 for technical reasons.". > Could the NCC share examples (respectfully anonymized) of such > _technical_ (as opposed to "technical") reasons? anything in Iran probably falls into this category. There are no real technical reasons left for not supporting ipv6, only policy reasons. Nick From ihsan at dogan.ch Sat Aug 13 09:11:21 2016 From: ihsan at dogan.ch (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Sat, 13 Aug 2016 09:11:21 +0200 Subject: [atlas] Probe down - USB? Message-ID: <2d095685-946b-d964-09b1-6bedf218fd0f@dogan.ch> Hi, My probe went down this morning. Probably I'm running into the issue with the USB stick. I was thinking to replace the USB stick. Are there any special requirements (size, speed, etc.) for the USB stick? -Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From c.estelmann at gmx.net Sat Aug 13 11:00:58 2016 From: c.estelmann at gmx.net (Estelmann, Christian) Date: Sat, 13 Aug 2016 11:00:58 +0200 Subject: [atlas] Probe down - USB? In-Reply-To: <2d095685-946b-d964-09b1-6bedf218fd0f@dogan.ch> References: <2d095685-946b-d964-09b1-6bedf218fd0f@dogan.ch> Message-ID: <39a12eb2-e021-84af-2031-47ae092dc557@gmx.net> Hi, every USB flash drive with 4 GB (or more) will do. See https://labs.ripe.net/Members/philip_homburg/troubleshooting-ripe-atlas-probes-usb-sticks Don't forget that all data on the flash drive will be destroyed. Greetings, Christian Am 13.08.2016 um 09:11 schrieb ?hsan Do?an: > Hi, > > My probe went down this morning. Probably I'm running into the issue > with the USB stick. > > I was thinking to replace the USB stick. Are there any special > requirements (size, speed, etc.) for the USB stick? > > > > -Ihsan > From ihsan at dogan.ch Sat Aug 13 13:24:59 2016 From: ihsan at dogan.ch (=?utf-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Sat, 13 Aug 2016 13:24:59 +0200 Subject: [atlas] Probe down - USB? In-Reply-To: <39a12eb2-e021-84af-2031-47ae092dc557@gmx.net> References: <2d095685-946b-d964-09b1-6bedf218fd0f@dogan.ch> <39a12eb2-e021-84af-2031-47ae092dc557@gmx.net> Message-ID: <20160813112459.GA49004@dogan.ch> Hi, On Saturday, 13 Aug 2016 11:00 +0200, Estelmann, Christian wrote: > every USB flash drive with 4 GB (or more) will do. > See > https://labs.ripe.net/Members/philip_homburg/troubleshooting-ripe-atlas-probes-usb-sticks Thanks. I have now ordered a 8 GB flash drive. > Don't forget that all data on the flash drive will be destroyed. But it's not affecting me, as it's pulling the configuration again, right? -Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From budiwijaya at ipv6.or.id Sat Aug 13 14:44:10 2016 From: budiwijaya at ipv6.or.id (Budiwijaya) Date: Sat, 13 Aug 2016 19:44:10 +0700 Subject: [atlas] Probe down - USB? In-Reply-To: <20160813112459.GA49004@dogan.ch> References: <2d095685-946b-d964-09b1-6bedf218fd0f@dogan.ch> <39a12eb2-e021-84af-2031-47ae092dc557@gmx.net> <20160813112459.GA49004@dogan.ch> Message-ID: Ihsan, You don't need to change the USB stick, just unplug from the probe, format the disk with fat32 using PC, plug back again to the probe, and you're done. Thank you Budiwijaya On Sat, Aug 13, 2016 at 6:24 PM, ?hsan?Do?an wrote: > Hi, > > On Saturday, 13 Aug 2016 11:00 +0200, Estelmann, Christian wrote: > >> every USB flash drive with 4 GB (or more) will do. >> See >> https://labs.ripe.net/Members/philip_homburg/troubleshooting-ripe-atlas-probes-usb-sticks > > Thanks. I have now ordered a 8 GB flash drive. > >> Don't forget that all data on the flash drive will be destroyed. > > But it's not affecting me, as it's pulling the configuration > again, right? > > > > -Ihsan > > -- > ihsan at dogan.ch http://blog.dogan.ch/ > From colinj at mx5.org.uk Sat Aug 13 14:46:30 2016 From: colinj at mx5.org.uk (Colin Johnston) Date: Sat, 13 Aug 2016 13:46:30 +0100 Subject: [atlas] Probe down - USB? Message-ID: <11C40759-7347-449D-9B4B-6AFEB2D3EAD8@mx5.org.uk> or mount the usb flash with linux ext3 and fsck check it :) Sent from my iPhone > On 13 Aug 2016, at 13:44, Budiwijaya wrote: > > You don't need to change the USB stick, just unplug from the probe, > format the disk with fat32 using PC, plug back again to the probe, > and you're done. > > Thank you > Budiwijaya > > > On Sat, Aug 13, 2016 at 6:24 PM, =C4=B0hsan=C2=A0Do=C4=9Fan > wrote: >> Hi, >> >>> On Saturday, 13 Aug 2016 11:00 +0200, Estelmann, Christian wrote: >>> >>> every USB flash drive with 4 GB (or more) will do. >>> See >>> https://labs.ripe.net/Members/philip_homburg/troubleshooting-ripe-atlas-= > probes-usb-sticks >> >> Thanks. I have now ordered a 8 GB flash drive. >> >>> Don't forget that all data on the flash drive will be destroyed. >> >> But it's not affecting me, as it's pulling the configuration >> again, right? >> >> >> >> -Ihsan >> >> -- >> ihsan at dogan.ch http://blog.dogan.ch/ > From ihsan at dogan.ch Sat Aug 13 14:57:11 2016 From: ihsan at dogan.ch (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Sat, 13 Aug 2016 14:57:11 +0200 Subject: [atlas] Probe down - USB? In-Reply-To: References: <2d095685-946b-d964-09b1-6bedf218fd0f@dogan.ch> <39a12eb2-e021-84af-2031-47ae092dc557@gmx.net> <20160813112459.GA49004@dogan.ch> Message-ID: Hi Budiwijaya, Am 13.08.2016 um 14:44 schrieb Budiwijaya: > You don't need to change the USB stick, just unplug from the probe, > format the disk with fat32 using PC, plug back again to the probe, > and you're done. Thanks for the hint. I'll try that first. -Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From BECHA at ripe.net Mon Aug 15 14:58:51 2016 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 15 Aug 2016 14:58:51 +0200 Subject: [atlas] Join RIPE NCC IXP Tools Hackathon, 22-23 October, Madrid In-Reply-To: <56CF163D.5040104@ripe.net> References: <56CF163D.5040104@ripe.net> Message-ID: <8d18265a-9c58-850c-cf85-1e03853ea93d@ripe.net> Dear colleagues, together with Euro-IX, Comcast and ISOC, the RIPE NCC is hosting a hackathon in the weekend before RIPE73, in Madrid. For a change, the event will *not* be focused on RIPE Atlas _only_, but on IXP-related-tools. In addition to RIPE Atlas data, we will use RIS data, PeeringDB data, existing software tools that deal with IXP-data-integration (such as IXP manager, IXP-Countri-Jedi...) in order to solve some of the challenges that operators have when making peering decisions, and to illustrate the impact of IXPs on the Internet routing and connectivity. We are looking for designers and developers, students and network operators, and of course colleagues from IXPs, to work together on hacking the new & old toolsets and visualizations! All source code developed during the hackathon will be publicly licensed and available on GitHub, and will be free for the entire community to use. -------------------- How to Apply -------------------- Interested? Learn more and apply online today! https://atlas.ripe.net/hackathon/ixp-tools/#!application-form *The application deadline is 15 September* Thanks to our generous sponsors, there is a limited travel funding available for certain categories of applicants. Please find more in this RIPE Labs article: https://labs.ripe.net/Members/suzanne_taylor_muzzin/announcing-the-ixp-tools-hackathon We look forward to seeing you there! Regards, Vesna From bortzmeyer at nic.fr Tue Aug 16 19:02:23 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 16 Aug 2016 19:02:23 +0200 Subject: [atlas] Alternative to jq: gron Message-ID: <20160816170223.GA26305@laperouse.bortzmeyer.org> It seems many people here use jq to browse JSON files. I've been referred recently to gron which is quite different: less features but probably simpler to use for beginners. Unlike jq, gron does not have a filtering language: it just formats the JSON in a way that makes simple to use traditional grep. Here is an example with measurement #4477822, a DNS one: % gron 4477822.json|more json = []; json[0] = {}; json[0].from = "178.248.214.8"; json[0].fw = 4730; json[0].group_id = 4477822; json[0].lts = 18; ... Selecting the values of the serial number is as simple as: % gron 4477822.json | grep SERIAL json[0].resultset[0].result.answers[0].SERIAL = 2223898795; json[0].resultset[1].result.answers[0].SERIAL = 2223898793; json[1].resultset[0].result.answers[0].SERIAL = 2223898790; json[1].resultset[1].result.answers[0].SERIAL = 2223898792; json[1].resultset[2].result.answers[0].SERIAL = 2223898795; json[2].resultset[0].result.answers[0].SERIAL = 2223898791; ... And you can turn back the result of the filtering into JSON. From randy at psg.com Tue Aug 16 20:37:07 2016 From: randy at psg.com (Randy Bush) Date: Tue, 16 Aug 2016 20:37:07 +0200 Subject: [atlas] Alternative to jq: gron In-Reply-To: <20160816170223.GA26305@laperouse.bortzmeyer.org> References: <20160816170223.GA26305@laperouse.bortzmeyer.org> Message-ID: have you looked at python's json lib, json.dump? randy From v.solovei at triacom.ua Wed Aug 17 14:41:24 2016 From: v.solovei at triacom.ua (Vladislav Solovei) Date: Wed, 17 Aug 2016 14:41:24 +0200 Subject: [atlas] Probe 10973 problem Message-ID: Hi. I have connected probe 10973 (which was offline several years) to the network. Firmware updated from 3.3.8 to 4010. "Status" said that "Your probe is currently connected." But on probe page i see the message: "Note: this probe is most likely not operational, and as such it has been written off as of 2013-12-03 15:44 UTC. The most likely reason for this is that the host could not be contacted." It is ok? :) Do i need to upgrade FW to latest version (tried to reboot probe several times, but fw version still 4010)? Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From robert at ripe.net Wed Aug 17 14:55:50 2016 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 17 Aug 2016 14:55:50 +0200 Subject: [atlas] RIPE Atlas "Commercial use" policy Message-ID: <8f1a8442-0de4-beb2-2eee-561c0984816a@ripe.net> Dear colleagues, A few different organisations have approached us about using RIPE Atlas data for commercial products, services, reports, etc. We?ve now published conditions for the commercial use of RIPE Atlas data: https://atlas.ripe.net/get-involved/commercial-use/ Please read these conditions carefully if you plan on using RIPE Atlas data for any commercial purpose, and don?t hesitate to contact us if you have any questions. Regards, Robert Kisteleki RIPE NCC From jterbeest at ripe.net Wed Aug 17 15:29:03 2016 From: jterbeest at ripe.net (Johan ter Beest) Date: Wed, 17 Aug 2016 15:29:03 +0200 Subject: [atlas] Probe 10973 problem In-Reply-To: References: Message-ID: <1c64720c-c67c-b060-0c82-940d9190afaf@ripe.net> Hi Vladislav, On 17/08/16 14:41, Vladislav Solovei wrote: > Hi. > > I have connected probe 10973 (which was offline several years) to the network. > Firmware updated from 3.3.8 to 4010. > "Status" said that "Your probe is currently connected." > But on probe page i see the message: > "Note: this probe is most likely not operational, and as such it has been written off as of 2013-12-03 15:44 UTC. The most likely reason for this is that the host could not be contacted." > It is ok? :) The message should disappear overnight when we check if written-off probes have re-connected to the network. So please leave the probe connected and I'll check it first thing tomorrow morning to see if everything is ok. If not, I'll contact you off-list to troubleshoot further. > > Do i need to upgrade FW to latest version (tried to reboot probe several times, but fw version still 4010)? The probe should update by itself but it does take time so just leave it connected. And thank you for plugging in the probe, it's always nice to see old probes come back ;) Kind regards, Johan ter Beest RIPE Atlas Team > > > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > From mj at mjturner.net Sun Aug 21 19:43:25 2016 From: mj at mjturner.net (Michael-John Turner) Date: Sun, 21 Aug 2016 18:43:25 +0100 Subject: [atlas] Reconnecting probe 3508 - troubleshooting Message-ID: <20160821174324.drnu2vbe3yjs3zgx@tesla.turnde.net> Hi I've just reconnected probe 3508 to the network after a number of years offline (I think it was last online in November 2012?). Under the SOS history, I can see that it's making DNS queries successfully (using the DNS servers it receives by DHCP), but it's not connecting correctly to the RIPE network. The following is also displayed under SOS history: "This probe cannot connect on port 443 (HTTPS)". Any thoughts on where I can start troubleshooting? For test purposes I've connected the probe to my LAN, with full internet access. Cheers, MJ -- Michael-John Turner * mj at mjturner.net * http://mjturner.net/ From vnaumov at ripe.net Mon Aug 22 08:09:51 2016 From: vnaumov at ripe.net (Viktor Naumov) Date: Mon, 22 Aug 2016 08:09:51 +0200 Subject: [atlas] Reconnecting probe 3508 - troubleshooting In-Reply-To: <20160821174324.drnu2vbe3yjs3zgx@tesla.turnde.net> References: <20160821174324.drnu2vbe3yjs3zgx@tesla.turnde.net> Message-ID: <4c6e484c-a895-3bb3-3186-be9b29888973@ripe.net> Hi Michael-John, Check if you can connect from you network to woolsey.atlas.ripe.net and/or oneill.atlas.ripe.net using port 443 wbr /vty On 8/21/16 7:43 PM, Michael-John Turner wrote: > Hi > > I've just reconnected probe 3508 to the network after a number of years > offline (I think it was last online in November 2012?). > > Under the SOS history, I can see that it's making DNS queries successfully > (using the DNS servers it receives by DHCP), but it's not connecting > correctly to the RIPE network. The following is also displayed under SOS > history: "This probe cannot connect on port 443 (HTTPS)". > > Any thoughts on where I can start troubleshooting? For test purposes I've > connected the probe to my LAN, with full internet access. > > Cheers, MJ From mj at mjturner.net Mon Aug 22 22:14:56 2016 From: mj at mjturner.net (Michael-John Turner) Date: Mon, 22 Aug 2016 21:14:56 +0100 Subject: [atlas] Reconnecting probe 3508 - troubleshooting In-Reply-To: <4c6e484c-a895-3bb3-3186-be9b29888973@ripe.net> References: <20160821174324.drnu2vbe3yjs3zgx@tesla.turnde.net> <4c6e484c-a895-3bb3-3186-be9b29888973@ripe.net> Message-ID: <20160822201456.kiee2gmv44fwycuy@tesla.turnde.net> Hi Viktor, On Mon, Aug 22, 2016 at 08:09:51AM +0200, Viktor Naumov wrote: > Check if you can connect from you network to > woolsey.atlas.ripe.net and/or oneill.atlas.ripe.net using port 443 Yes, I can connect to both, using both IPv4 and IPv6 (I tested using the OpenSSH client from a machine on the same network). The reason why the probe was offline originally was that it stopped accepting DHCPOFFERs for some reason, with the result that it would continually send DHCPDISCOVERs every few seconds but never ACK an OFFER and never connect properly to the network. That seemed to be fixed when I powered it on again yesterday but now I see the problem is occurring again (it started again as soon as the initial lease it received yesterday expired): ... Aug 22 21:10:18 dreamland dhcpd: DHCPOFFER on 192.168.1.247 to 00:80:a3:91:38:ac via br0 Aug 22 21:10:21 dreamland dhcpd: DHCPDISCOVER from 00:80:a3:91:38:ac via br0 Aug 22 21:10:21 dreamland dhcpd: DHCPOFFER on 192.168.1.247 to 00:80:a3:91:38:ac via br0 Aug 22 21:10:24 dreamland dhcpd: DHCPDISCOVER from 00:80:a3:91:38:ac via br0 Aug 22 21:10:24 dreamland dhcpd: DHCPOFFER on 192.168.1.247 to 00:80:a3:91:38:ac via br0 Aug 22 21:10:27 dreamland dhcpd: DHCPDISCOVER from 00:80:a3:91:38:ac via br0 Aug 22 21:10:27 dreamland dhcpd: DHCPOFFER on 192.168.1.247 to 00:80:a3:91:38:ac via br0 Aug 22 21:10:30 dreamland dhcpd: DHCPDISCOVER from 00:80:a3:91:38:ac via br0 Aug 22 21:10:30 dreamland dhcpd: DHCPOFFER on 192.168.1.247 to 00:80:a3:91:38:ac via br0 Aug 22 21:10:33 dreamland dhcpd: DHCPDISCOVER from 00:80:a3:91:38:ac via br0 Aug 22 21:10:33 dreamland dhcpd: DHCPOFFER on 192.168.1.247 to 00:80:a3:91:38:ac via br0 Aug 22 21:10:36 dreamland dhcpd: DHCPDISCOVER from 00:80:a3:91:38:ac via br0 ... This poor probe seems cursed :( Is there any way to reset it (it's a v1 probe, according to the Atlas website on firmware 4480)? Cheers, MJ -- Michael-John Turner * mj at mjturner.net * http://mjturner.net/ From philip.homburg at ripe.net Tue Aug 23 10:52:58 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 23 Aug 2016 10:52:58 +0200 Subject: [atlas] Reconnecting probe 3508 - troubleshooting In-Reply-To: <20160822201456.kiee2gmv44fwycuy@tesla.turnde.net> References: <20160821174324.drnu2vbe3yjs3zgx@tesla.turnde.net> <4c6e484c-a895-3bb3-3186-be9b29888973@ripe.net> <20160822201456.kiee2gmv44fwycuy@tesla.turnde.net> Message-ID: <78c23f6f-fdc6-1f1a-d1fd-ed085115840e@ripe.net> On 2016/08/22 22:14 , Michael-John Turner wrote: > The reason why the probe was offline originally was that it stopped > accepting DHCPOFFERs for some reason, with the result that it would > continually send DHCPDISCOVERs every few seconds but never ACK an OFFER and > never connect properly to the network. That seemed to be fixed when I > powered it on again yesterday but now I see the problem is occurring again > (it started again as soon as the initial lease it received yesterday > expired): > > ... > Aug 22 21:10:18 dreamland dhcpd: DHCPOFFER on 192.168.1.247 to 00:80:a3:91:38:ac via br0 > Aug 22 21:10:21 dreamland dhcpd: DHCPDISCOVER from 00:80:a3:91:38:ac via br0 > Aug 22 21:10:21 dreamland dhcpd: DHCPOFFER on 192.168.1.247 to 00:80:a3:91:38:ac via br0 > ... > > This poor probe seems cursed :( Is there any way to reset it (it's a v1 > probe, according to the Atlas website on firmware 4480)? One possible explanation is that the probe doesn't actually receive any packets (i.e. the receive circuitry at the ethernet level is broken). The only way to know for sure is to open up the probe and attach a serial console. But I'm not aware of any software failure mode that leads to this behavior. Philip From daniel.karrenberg at ripe.net Tue Aug 23 12:02:46 2016 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 23 Aug 2016 12:02:46 +0200 Subject: [atlas] Reconnecting probe 3508 - troubleshooting In-Reply-To: <78c23f6f-fdc6-1f1a-d1fd-ed085115840e@ripe.net> References: <20160821174324.drnu2vbe3yjs3zgx@tesla.turnde.net> <4c6e484c-a895-3bb3-3186-be9b29888973@ripe.net> <20160822201456.kiee2gmv44fwycuy@tesla.turnde.net> <78c23f6f-fdc6-1f1a-d1fd-ed085115840e@ripe.net> Message-ID: <62cf8f3e-d04f-8393-44ee-2b25ed5d5255@ripe.net> On 23.08.16 10:52 , Philip Homburg wrote: > On 2016/08/22 22:14 , Michael-John Turner wrote: >> The reason why the probe was offline originally was that it stopped >> accepting DHCPOFFERs for some reason, with the result that it would >> continually send DHCPDISCOVERs every few seconds but never ACK an OFFER and >> never connect properly to the network. That seemed to be fixed when I >> powered it on again yesterday but now I see the problem is occurring again >> (it started again as soon as the initial lease it received yesterday >> expired): >> >> ... >> Aug 22 21:10:18 dreamland dhcpd: DHCPOFFER on 192.168.1.247 to 00:80:a3:91:38:ac via br0 >> Aug 22 21:10:21 dreamland dhcpd: DHCPDISCOVER from 00:80:a3:91:38:ac via br0 >> Aug 22 21:10:21 dreamland dhcpd: DHCPOFFER on 192.168.1.247 to 00:80:a3:91:38:ac via br0 >> ... >> >> This poor probe seems cursed :( Is there any way to reset it (it's a v1 >> probe, according to the Atlas website on firmware 4480)? > > One possible explanation is that the probe doesn't actually receive any > packets (i.e. the receive circuitry at the ethernet level is broken). > The only way to know for sure is to open up the probe and attach a > serial console. But I'm not aware of any software failure mode that > leads to this behavior. Try a different ethernet cable and/or switch port. Daniel From mj at mjturner.net Tue Aug 23 21:20:58 2016 From: mj at mjturner.net (Michael-John Turner) Date: Tue, 23 Aug 2016 20:20:58 +0100 Subject: [atlas] Reconnecting probe 3508 - troubleshooting In-Reply-To: <62cf8f3e-d04f-8393-44ee-2b25ed5d5255@ripe.net> References: <20160821174324.drnu2vbe3yjs3zgx@tesla.turnde.net> <4c6e484c-a895-3bb3-3186-be9b29888973@ripe.net> <20160822201456.kiee2gmv44fwycuy@tesla.turnde.net> <78c23f6f-fdc6-1f1a-d1fd-ed085115840e@ripe.net> <62cf8f3e-d04f-8393-44ee-2b25ed5d5255@ripe.net> Message-ID: <20160823192058.a3p3j3ebit6dfpap@tesla.turnde.net> On Tue, Aug 23, 2016 at 12:02:46PM +0200, Daniel Karrenberg wrote: > Try a different ethernet cable and/or switch port. I have done both of those (a completely different switch, in fact), but to no avail. Cheers, MJ -- Michael-John Turner * mj at mjturner.net * http://mjturner.net/ From mj at mjturner.net Tue Aug 23 21:24:17 2016 From: mj at mjturner.net (Michael-John Turner) Date: Tue, 23 Aug 2016 20:24:17 +0100 Subject: [atlas] Reconnecting probe 3508 - troubleshooting In-Reply-To: <78c23f6f-fdc6-1f1a-d1fd-ed085115840e@ripe.net> References: <20160821174324.drnu2vbe3yjs3zgx@tesla.turnde.net> <4c6e484c-a895-3bb3-3186-be9b29888973@ripe.net> <20160822201456.kiee2gmv44fwycuy@tesla.turnde.net> <78c23f6f-fdc6-1f1a-d1fd-ed085115840e@ripe.net> Message-ID: <20160823192417.3ukx33kqfjadhs3r@tesla.turnde.net> On Tue, Aug 23, 2016 at 10:52:58AM +0200, Philip Homburg wrote: > One possible explanation is that the probe doesn't actually receive any > packets (i.e. the receive circuitry at the ethernet level is broken). > The only way to know for sure is to open up the probe and attach a > serial console. But I'm not aware of any software failure mode that > leads to this behavior. Hmm. The odd thing is that the first time I powered it on (after it had been powered off for a long time), it received the lease correctly. When that expired and it needed to renew, the problems started gain (and exactly the same DHCP problem I had that caused me to disconnect it some years back). Oddly, even after receiving an IP the first time, it was able to do DNS requests (they showed up in the SOS log on the Atlas site), but it wasn't able to report via ssh on 443 (which works fine from other hosts on the same network). Argh, this is so frustrating :( Is it possible to open a V1 probe and connect a serial console without damaging it? Cheers, MJ -- Michael-John Turner * mj at mjturner.net * http://mjturner.net/ From gert at space.net Tue Aug 23 21:51:18 2016 From: gert at space.net (Gert Doering) Date: Tue, 23 Aug 2016 21:51:18 +0200 Subject: [atlas] Reconnecting probe 3508 - troubleshooting In-Reply-To: <20160823192417.3ukx33kqfjadhs3r@tesla.turnde.net> References: <20160821174324.drnu2vbe3yjs3zgx@tesla.turnde.net> <4c6e484c-a895-3bb3-3186-be9b29888973@ripe.net> <20160822201456.kiee2gmv44fwycuy@tesla.turnde.net> <78c23f6f-fdc6-1f1a-d1fd-ed085115840e@ripe.net> <20160823192417.3ukx33kqfjadhs3r@tesla.turnde.net> Message-ID: <20160823195118.GK79185@Space.Net> Hi, On Tue, Aug 23, 2016 at 08:24:17PM +0100, Michael-John Turner wrote: > Oddly, even after receiving an IP the first time, it was able to do DNS > requests (they showed up in the SOS log on the Atlas site), but it wasn't > able to report via ssh on 443 (which works fine from other hosts on the > same network). Well, it can *send*. It might not be able to *hear* the answer to the DNS requests, so the fact that the SOS messages are seen at Atlas Central doesn't really say anything about receiving of packets after the initial DHCP packet... So, it could just be borderline broken... if cold enough, it works, if the room is warming up, it no longer receives packets... 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: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From budiwijaya at ipv6.or.id Wed Aug 24 03:43:32 2016 From: budiwijaya at ipv6.or.id (Budiwijaya) Date: Wed, 24 Aug 2016 08:43:32 +0700 Subject: [atlas] Reconnecting probe 3508 - troubleshooting In-Reply-To: <20160823195118.GK79185@Space.Net> References: <20160821174324.drnu2vbe3yjs3zgx@tesla.turnde.net> <4c6e484c-a895-3bb3-3186-be9b29888973@ripe.net> <20160822201456.kiee2gmv44fwycuy@tesla.turnde.net> <78c23f6f-fdc6-1f1a-d1fd-ed085115840e@ripe.net> <20160823192417.3ukx33kqfjadhs3r@tesla.turnde.net> <20160823195118.GK79185@Space.Net> Message-ID: The best way I think is to request newer probe. Thank you budiwijaya On Wed, Aug 24, 2016 at 2:51 AM, Gert Doering wrote: > Hi, > > On Tue, Aug 23, 2016 at 08:24:17PM +0100, Michael-John Turner wrote: >> Oddly, even after receiving an IP the first time, it was able to do DNS >> requests (they showed up in the SOS log on the Atlas site), but it wasn't >> able to report via ssh on 443 (which works fine from other hosts on the >> same network). > > Well, it can *send*. It might not be able to *hear* the answer to the > DNS requests, so the fact that the SOS messages are seen at Atlas Central > doesn't really say anything about receiving of packets after the initial > DHCP packet... > > So, it could just be borderline broken... if cold enough, it works, if > the room is warming up, it no longer receives packets... > > 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 From robert at ripe.net Wed Aug 24 10:17:14 2016 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 24 Aug 2016 10:17:14 +0200 Subject: [atlas] Reconnecting probe 3508 - troubleshooting In-Reply-To: <20160823192058.a3p3j3ebit6dfpap@tesla.turnde.net> References: <20160821174324.drnu2vbe3yjs3zgx@tesla.turnde.net> <4c6e484c-a895-3bb3-3186-be9b29888973@ripe.net> <20160822201456.kiee2gmv44fwycuy@tesla.turnde.net> <78c23f6f-fdc6-1f1a-d1fd-ed085115840e@ripe.net> <62cf8f3e-d04f-8393-44ee-2b25ed5d5255@ripe.net> <20160823192058.a3p3j3ebit6dfpap@tesla.turnde.net> Message-ID: On 2016-08-23 21:20, Michael-John Turner wrote: > On Tue, Aug 23, 2016 at 12:02:46PM +0200, Daniel Karrenberg wrote: >> Try a different ethernet cable and/or switch port. > > I have done both of those (a completely different switch, in fact), but to > no avail. > > Cheers, MJ Hi, It is possible that the probe is in some irrecoverable state. However, before requesting a new one, please try plugging it in into a different network (friend's home, work or such) and leave it for a bit. If this works then you can rule out the probe being faulty. (We had many cases where the probe was sent back to us, and simply plugging it in on our network "just worked".) Regards, Robert From wenqin.shao at telecom-paristech.fr Wed Aug 24 19:19:57 2016 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Wed, 24 Aug 2016 19:19:57 +0200 Subject: [atlas] Atlas Sagan error_message Message-ID: <948F3296-5F8D-4432-9BE3-A42E0696D5D0@telecom-paristech.fr> Dear list, I was using ripe.atlas.sagan to parse some ping measurements, one of them looks like the following in JSON format: rec = {u'af': 4, u'prb_id': 15843, u'result': [{u'error': u'connect failed: Network is unreachable'}], u'avg': -1, u'size': 20, u'from': u'88.174.18.20', u'proto': u'ICMP', u'timestamp': 1470009620, u'dup': 0, u'type': u'ping', u'sent': 0, u'msm_id': 1010, u'fw': 4730, u'max': -1, u'step': 240, u'src_addr': u'192.168.0.22', u'rcvd': 0, u'msm_name': u'Ping', u'lts': 641089, u'dst_name': u'192.228.79.201', u'min': -1, u'dst_addr': u'192.228.79.201'} Suppose that the above measurement is stored in a variable called rec as a dict, and I parse it using PingResult: from ripe.atlas.sagan import PingResult parsed_rec = PingResult(rec) I was expecting a no-empty string for parsed_rec.error_message, as we can see the measurement result contains an error string, however the parsed_rec.error_message is None. type(parsed_rec.error_message) Probably I misunderstood some part of the doc: error_message str If the result is an error, the message string is in here Could someone please clarify the exact functionality of this error_message? Many thanks in advance. Best, wenqin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mj at mjturner.net Wed Aug 24 21:31:08 2016 From: mj at mjturner.net (Michael-John Turner) Date: Wed, 24 Aug 2016 20:31:08 +0100 Subject: [atlas] Reconnecting probe 3508 - troubleshooting In-Reply-To: References: <20160821174324.drnu2vbe3yjs3zgx@tesla.turnde.net> <4c6e484c-a895-3bb3-3186-be9b29888973@ripe.net> <20160822201456.kiee2gmv44fwycuy@tesla.turnde.net> <78c23f6f-fdc6-1f1a-d1fd-ed085115840e@ripe.net> <62cf8f3e-d04f-8393-44ee-2b25ed5d5255@ripe.net> <20160823192058.a3p3j3ebit6dfpap@tesla.turnde.net> Message-ID: <20160824193108.ijevtkxjehvxtvk2@tesla.turnde.net> On Wed, Aug 24, 2016 at 10:17:14AM +0200, Robert Kisteleki wrote: > It is possible that the probe is in some irrecoverable state. However, > before requesting a new one, please try plugging it in into a different > network (friend's home, work or such) and leave it for a bit. If this works > then you can rule out the probe being faulty. Good thinking. I'll do that in the next few days and report back my findings. > (We had many cases where the probe was sent back to us, and simply plugging > it in on our network "just worked".) If I don't get the probe working, what is the process to request a replacement? Cheers, MJ -- Michael-John Turner * mj at mjturner.net * http://mjturner.net/ From mir at ripe.net Thu Aug 25 16:30:32 2016 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 25 Aug 2016 16:30:32 +0200 Subject: [atlas] New on RIPE Labs: Another Look at RIPE Atlas Probe Lifetimes In-Reply-To: <8ab41faa-f435-276d-e076-19cb50cb5ad3@ripe.net> References: <8ab41faa-f435-276d-e076-19cb50cb5ad3@ripe.net> Message-ID: <32c7b40a-3a2e-ac98-dac8-f9fdd0e3ef0f@ripe.net> Dear colleagues, We took another, more detailed look at probe lifetimes and the dynamics of probes connecting and disconnecting from the RIPE Atlas infrastructure to try to understand how to keep the network growing in the long term. https://labs.ripe.net/Members/wilhelm/another-look-at-ripe-atlas-probe-lifetimes?pk_campaign=labs&pk_kwd=list-mat Kind regards, Mirjam Kuehne RIPE NCC From colinj at mx5.org.uk Thu Aug 25 16:37:06 2016 From: colinj at mx5.org.uk (Colin Johnston) Date: Thu, 25 Aug 2016 15:37:06 +0100 Subject: [atlas] New on RIPE Labs: Another Look at RIPE Atlas Probe Lifetimes In-Reply-To: <32c7b40a-3a2e-ac98-dac8-f9fdd0e3ef0f@ripe.net> References: <8ab41faa-f435-276d-e076-19cb50cb5ad3@ripe.net> <32c7b40a-3a2e-ac98-dac8-f9fdd0e3ef0f@ripe.net> Message-ID: <98E8919C-0D95-4AAC-BE4F-DE543CD715D0@mx5.org.uk> maybe virtual vm probes might be useful to investigate and also a split file system for v3 probs with /var/log on a different file system ? Colin > On 25 Aug 2016, at 15:30, Mirjam Kuehne wrote: > > > Dear colleagues, > > We took another, more detailed look at probe lifetimes and the dynamics > of probes connecting and disconnecting from the RIPE Atlas > infrastructure to try to understand how to keep the network growing in > the long term. > > https://labs.ripe.net/Members/wilhelm/another-look-at-ripe-atlas-probe-lifetimes?pk_campaign=labs&pk_kwd=list-mat > > Kind regards, > Mirjam Kuehne > RIPE NCC > From mm at 42com.com Thu Aug 25 16:51:28 2016 From: mm at 42com.com (=?UTF-8?Q?Max_M=c3=bchlbronner?=) Date: Thu, 25 Aug 2016 16:51:28 +0200 Subject: [atlas] New on RIPE Labs: Another Look at RIPE Atlas Probe Lifetimes In-Reply-To: <98E8919C-0D95-4AAC-BE4F-DE543CD715D0@mx5.org.uk> References: <8ab41faa-f435-276d-e076-19cb50cb5ad3@ripe.net> <32c7b40a-3a2e-ac98-dac8-f9fdd0e3ef0f@ripe.net> <98E8919C-0D95-4AAC-BE4F-DE543CD715D0@mx5.org.uk> Message-ID: <0d880f7c-5cb9-6b99-5892-24c16dbec825@42com.com> Hi, i noticed another problem besides the hardware, the "controllers" are not really highly-available? (E.g. ctr-ams07, NL) Sometimes the probes are disconnected from a RIPE controller for some time even though there is no absolutely no network issue at the probes site. I suppose this could happen from time to time but it's too often. (Maybe it's just me, maybe everyone should check the connection history at RIPE atlas). Also if a controller is not working sometimes it seems to take forever until the probe will use a failover controller and in the meanwhile its "disconnected"... Any chance to improve the availability? Best Regards Max M. On 25.08.2016 16:37, Colin Johnston wrote: > maybe virtual vm probes might be useful to investigate and also a split file system for v3 probs with /var/log on a different file system ? > > Colin > >> On 25 Aug 2016, at 15:30, Mirjam Kuehne wrote: >> >> >> Dear colleagues, >> >> We took another, more detailed look at probe lifetimes and the dynamics >> of probes connecting and disconnecting from the RIPE Atlas >> infrastructure to try to understand how to keep the network growing in >> the long term. >> >> https://labs.ripe.net/Members/wilhelm/another-look-at-ripe-atlas-probe-lifetimes?pk_campaign=labs&pk_kwd=list-mat >> >> Kind regards, >> Mirjam Kuehne >> RIPE NCC >> > From robert at ripe.net Thu Aug 25 19:44:24 2016 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 25 Aug 2016 19:44:24 +0200 Subject: [atlas] New on RIPE Labs: Another Look at RIPE Atlas Probe Lifetimes In-Reply-To: <0d880f7c-5cb9-6b99-5892-24c16dbec825@42com.com> References: <8ab41faa-f435-276d-e076-19cb50cb5ad3@ripe.net> <32c7b40a-3a2e-ac98-dac8-f9fdd0e3ef0f@ripe.net> <98E8919C-0D95-4AAC-BE4F-DE543CD715D0@mx5.org.uk> <0d880f7c-5cb9-6b99-5892-24c16dbec825@42com.com> Message-ID: <8d8f6552-467e-0db3-247c-921f56f4a458@ripe.net> Hello, Some clarifications below. On 2016-08-25 16:51, Max M?hlbronner wrote: > Hi, > > i noticed another problem besides the hardware, the "controllers" are not > really highly-available? (E.g. ctr-ams07, NL) They are not individually highly-available, but we have many of them for redundancy. So if some of them go down, only a portion of the network is affected. > Sometimes the probes are disconnected from a RIPE controller for some time > even though there is no absolutely no network issue at the probes site. I > suppose this could happen from time to time but it's too often. (Maybe it's > just me, maybe everyone should check the connection history at RIPE atlas). Every now and then, the NCC network has a hickup, or scheduled network maintenance. This can break the connections of the probes currently connected to us. We have controllers in other networks too (in Germany, US east/west and Singapore) which of course can have similar issues. As you probably know, probes keep an open TCP (SSH) connection to the controller. If any part of the network between the probe and the controller fails hard enough, there is a disconnection. In other words, probe disconnection can be caused by issues in the probe's network, in ours, or in anything in between :) > Also if a controller is not working sometimes it seems to take forever until > the probe will use a failover controller and in the meanwhile its > "disconnected"... Any chance to improve the availability? Generally speaking, probes try hard to get back to the same controller they were connected to before disconnection. If this does not succeed for two hours, then they connect to the reg.servers ("trust anchors" if you will) to ask for a new controller. In the meantime they continue to measure and buffer results -- though they indeed show up as disconnected and therefore can't participate in the newest measurements. We have this mechanism in place to avoid probes jumping around from controller to controller in case there's a glitch somewhere. Hope this clarifies, Robert > Best Regards > > > Max M. > > > On 25.08.2016 16:37, Colin Johnston wrote: >> maybe virtual vm probes might be useful to investigate and also a split >> file system for v3 probs with /var/log on a different file system ? >> >> Colin >> >>> On 25 Aug 2016, at 15:30, Mirjam Kuehne wrote: >>> >>> >>> Dear colleagues, >>> >>> We took another, more detailed look at probe lifetimes and the dynamics >>> of probes connecting and disconnecting from the RIPE Atlas >>> infrastructure to try to understand how to keep the network growing in >>> the long term. >>> >>> https://labs.ripe.net/Members/wilhelm/another-look-at-ripe-atlas-probe-lifetimes?pk_campaign=labs&pk_kwd=list-mat >>> >>> >>> Kind regards, >>> Mirjam Kuehne >>> RIPE NCC >>> >> > > > > From gert at space.net Thu Aug 25 22:46:15 2016 From: gert at space.net (Gert Doering) Date: Thu, 25 Aug 2016 22:46:15 +0200 Subject: [atlas] New on RIPE Labs: Another Look at RIPE Atlas Probe Lifetimes In-Reply-To: <98E8919C-0D95-4AAC-BE4F-DE543CD715D0@mx5.org.uk> References: <8ab41faa-f435-276d-e076-19cb50cb5ad3@ripe.net> <32c7b40a-3a2e-ac98-dac8-f9fdd0e3ef0f@ripe.net> <98E8919C-0D95-4AAC-BE4F-DE543CD715D0@mx5.org.uk> Message-ID: <20160825204615.GX79185@Space.Net> Hi, On Thu, Aug 25, 2016 at 03:37:06PM +0100, Colin Johnston wrote: > maybe virtual vm probes might be useful You're not giving up on this, are you? 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: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jared at puck.nether.net Fri Aug 26 00:18:51 2016 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 25 Aug 2016 18:18:51 -0400 Subject: [atlas] New on RIPE Labs: Another Look at RIPE Atlas Probe Lifetimes In-Reply-To: <20160825204615.GX79185@Space.Net> References: <8ab41faa-f435-276d-e076-19cb50cb5ad3@ripe.net> <32c7b40a-3a2e-ac98-dac8-f9fdd0e3ef0f@ripe.net> <98E8919C-0D95-4AAC-BE4F-DE543CD715D0@mx5.org.uk> <20160825204615.GX79185@Space.Net> Message-ID: > On Aug 25, 2016, at 4:46 PM, Gert Doering wrote: > > On Thu, Aug 25, 2016 at 03:37:06PM +0100, Colin Johnston wrote: >> maybe virtual vm probes might be useful > > You're not giving up on this, are you? It?s way easier for me to spin up 25 virtual probes than 25 physical ones :) Hoping that virtual probe is making progress :) - Jared From randy at psg.com Fri Aug 26 09:57:25 2016 From: randy at psg.com (Randy Bush) Date: Fri, 26 Aug 2016 16:57:25 +0900 Subject: [atlas] New on RIPE Labs: Another Look at RIPE Atlas Probe Lifetimes In-Reply-To: References: <8ab41faa-f435-276d-e076-19cb50cb5ad3@ripe.net> <32c7b40a-3a2e-ac98-dac8-f9fdd0e3ef0f@ripe.net> <98E8919C-0D95-4AAC-BE4F-DE543CD715D0@mx5.org.uk> <20160825204615.GX79185@Space.Net> Message-ID: > It?s way easier for me to spin up 25 virtual probes than 25 physical > ones :) it is even easier to spin up 1,000 prngs From hank at efes.iucc.ac.il Mon Aug 29 13:10:09 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 29 Aug 2016 14:10:09 +0300 Subject: [atlas] API probe search Message-ID: When searching for specific ASN probes via: https://atlas.ripe.net/probes/ and entering a search like "ASxxxx", why does the API ignore the letters AS and respond with probes that have an id of yxxxx or xxxxy or ASN yxxxy? Shouldn't it be if I specify a specific string of ASxxx the response should be *only *those probes in ASxxx or at the worst also ASxxxy? Thanks, Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenqin.shao at telecom-paristech.fr Mon Aug 29 14:20:18 2016 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Mon, 29 Aug 2016 14:20:18 +0200 Subject: [atlas] API probe search In-Reply-To: References: Message-ID: Hi, Here is an example from the official doc https://atlas.ripe.net/docs/rest/#probe https://atlas.ripe.net/api/v1/probe/?asn=3333 It queries the probes hosted in AS 3333. It works for me. My two cents, wenqin > On 29 Aug 2016, at 13:10, Hank Nussbacher wrote: > > When searching for specific ASN probes via: > https://atlas.ripe.net/probes/ > and entering a search like "ASxxxx", why does the API ignore the letters AS and respond with probes that have an id of yxxxx or xxxxy or ASN yxxxy? Shouldn't it be if I specify a specific string of ASxxx the response should be only those probes in ASxxx or at the worst also ASxxxy? > > Thanks, > Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdenhertog at ripe.net Mon Aug 29 14:23:55 2016 From: jdenhertog at ripe.net (Jasper den Hertog) Date: Mon, 29 Aug 2016 14:23:55 +0200 Subject: [atlas] API probe search In-Reply-To: References: Message-ID: Hi All, Please note that the v1 API is deprecated. The latest and greatest query would be: https://atlas.ripe.net/api/v2/probes/?asn=3333 and the docs for this live at: https://atlas.ripe.net/docs/api/v2/manual/probes/queryparameters.html and https://atlas.ripe.net/docs/api/v2/reference/#!/probes/Probe_List_GET Greetings, Jasper den Hertog > On 29 Aug 2016, at 14:20, Wenqin SHAO wrote: > > Hi, > > Here is an example from the official doc https://atlas.ripe.net/docs/rest/#probe > > https://atlas.ripe.net/api/v1/probe/?asn=3333 > > It queries the probes hosted in AS 3333. > It works for me. > > My two cents, > wenqin > >> On 29 Aug 2016, at 13:10, Hank Nussbacher > wrote: >> >> When searching for specific ASN probes via: >> https://atlas.ripe.net/probes/ >> and entering a search like "ASxxxx", why does the API ignore the letters AS and respond with probes that have an id of yxxxx or xxxxy or ASN yxxxy? Shouldn't it be if I specify a specific string of ASxxx the response should be only those probes in ASxxx or at the worst also ASxxxy? >> >> Thanks, >> Hank > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2619 bytes Desc: not available URL: From hank at efes.iucc.ac.il Mon Aug 29 18:11:57 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 29 Aug 2016 19:11:57 +0300 Subject: [atlas] API probe search In-Reply-To: References: Message-ID: <5245d9dd-3339-a45e-ef20-51c0f2990ad9@efes.iucc.ac.il> On 8/29/2016 3:23 PM, Jasper den Hertog wrote: Sorry I wasn't more clear. I am referring to the GUI API located at: https://atlas.ripe.net/probes/ There is a search box on that page. It even says "filter by id/asn/country/description" Put in there AS222 and see what pops up. Regards, Hank > Hi All, > > Please note that the v1 API is deprecated. > > The latest and greatest query would be: > > https://atlas.ripe.net/api/v2/probes/?asn=3333 > > and the docs for this live at: > > https://atlas.ripe.net/docs/api/v2/manual/probes/queryparameters.html > > and > > https://atlas.ripe.net/docs/api/v2/reference/#!/probes/Probe_List_GET > > > Greetings, > > Jasper den Hertog > > >> On 29 Aug 2016, at 14:20, Wenqin SHAO >> > > wrote: >> >> Hi, >> >> Here is an example from the official >> doc https://atlas.ripe.net/docs/rest/#probe >> >> https://atlas.ripe.net/api/v1/probe/?asn=3333 >> >> It queries the probes hosted in AS 3333. >> It works for me. >> >> My two cents, >> wenqin >> >>> On 29 Aug 2016, at 13:10, Hank Nussbacher >> > wrote: >>> >>> When searching for specific ASN probes via: >>> https://atlas.ripe.net/probes/ >>> and entering a search like "ASxxxx", why does the API ignore the >>> letters AS and respond with probes that have an id of yxxxx or xxxxy >>> or ASN yxxxy? Shouldn't it be if I specify a specific string of >>> ASxxx the response should be *only *those probes in ASxxx or at the >>> worst also ASxxxy? >>> >>> Thanks, >>> Hank >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: