From robert at ripe.net Wed Mar 2 10:01:58 2016 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 2 Mar 2016 10:01:58 +0100 Subject: [atlas] Small downtime expected Message-ID: <56D6AC06.8090500@ripe.net> Dear All, Due to operational reasons we will have a short downtime of the main RIPE Atlas website at 11:00 (CET). We expect this to last less than 15 minutes. The system will continue to collect results in the meantime, so no data loss is expected. Regards, Robert Kisteleki From cs at fnx.li Thu Mar 3 12:51:06 2016 From: cs at fnx.li (=?UTF-8?Q?Christian_Schr=C3=B6tter?=) Date: Thu, 03 Mar 2016 12:51:06 +0100 Subject: [atlas] Probe marked as offline, but it's online... Message-ID: Hello Atlas users! I've connected my probe to a new network environment, to test everything before the big migration starts. It came up again immediately and displayed it's new network details at the WebUI. For the first time there was an IPv6-ULA prefix visible. The router (OpenWrt 15.05) supports full IPv6 via tunnel, but it's not advertised to the probe's VLAN and blocked by firewall rules. Everything seems to work, good! I've switched it off/on for several times, went back to the old router/modem and powered it on again. After some hours I've checked the WebUI again: My probe is offline! :-( I've tested it again on the new router: Offline! Once again on the old setup: Offline! Untouched default router/modem from my ISP: Offline! Current LED status: (from 1-5; power to button) > on > off > slow blink > on > on SOS-DNS-history from Wireshark: (switch port mirrored to my analysis interface) > Standard query 0x0002 AAAA U.*************.sos.atlas.ripe.net > Standard query response 0x0002 AAAA 2001:67c:2e8:11::c100:1337 > Standard query 0x0003 A U.*************.sos.atlas.ripe.net > Standard query response 0x0003 A 193.0.19.55 The probe is online and communicates with many servers. Looks like the built-in tests are running fine. There is NTP, DNS, ICMP, UDP and HTTP traffic. But it's still offline at the WebUI. I've double and triple checked everything on my side. Any ideas what's going wrong? -- With kind regards, Christian Schr?tter From cs at fnx.li Thu Mar 3 17:04:19 2016 From: cs at fnx.li (=?UTF-8?Q?Christian_Schr=C3=B6tter?=) Date: Thu, 03 Mar 2016 17:04:19 +0100 Subject: [atlas] Probe marked as offline, but it's online... In-Reply-To: References: Message-ID: <4af68c817553ff233b4362bfe433b46f@fnx.li> Issue fixed! :-) I've stopped the probe, removed the USB drive, started the probe, waited 5 minutes and inserted the USB stick again. After 5-10 minutes the probe rebooted and now it's visible again in the WebUI. Looks like the USB drive didn't like multiple power losses in a short timeframe... -- With kind regards, Christian Schr?tter From sarah.wassermann at student.ulg.ac.be Sun Mar 6 12:25:09 2016 From: sarah.wassermann at student.ulg.ac.be (sarah.wassermann at student.ulg.ac.be) Date: Sun, 6 Mar 2016 12:25:09 +0100 (CET) Subject: [atlas] probe tagged as "system: Firewall problem suspected" In-Reply-To: <56C442FE.3090304@ripe.net> Message-ID: <2036516140.522590.1457263509140.JavaMail.root@student.ulg.ac.be> Hi Viktor, I tried all your pieces of advice, but my probe is still disconnected (with 3rd light slowly blinking). I also attempted to connect it to my router in Li?ge, on which another probe is also connected and working fine, but even there the probe didn't come back to life. Thanks to several generous credit-donations, I don't need credits anymore, but can I send the probe somewhere so that it can be fixed? There are not that many probes here in Luxembourg and I would be happy to host a working probe to help extend the network! Best regards, Sarah ----- Mail original ----- De: "Viktor Naumov" ?: "sarah wassermann" Cc: ripe-atlas at ripe.net Envoy?: Mercredi 17 F?vrier 2016 10:53:02 Objet: Re: [atlas] probe tagged as "system: Firewall problem suspected" Hi Sarah, The tagging is done by heuristic that analyzes the probe connection attempts, SOS, timing between them and some other attributes like messages about flash drive. It has to have a quite large window for looking into data and it can take up to a few days for addressing a probe to a special controller if needed and resetting tags. In your case I see that it was disconnected at 2016-02-12 12:26:09. Up till this time your probe had no problem connecting regservers and controllers (tcp/443). After that time I see only SOS (DNS (tcp|udp)/53). That suggests the network problem with the highest probability - DNS is open but tcp/443 is closed. The lowest probability has the hardware problem (flash drive) in this case. Please use the tag as a suggestion where to begin your local diagnostics. If the network is good you can try to reinit the flash drive. wbr /vty On 2/16/16 7:29 PM, sarah.wassermann at student.ulg.ac.be wrote: > Hi, > > I have (once again) problems with my probe (probeID: 24102). This time, it got tagged as "system: Firewall problem suspected". The strange thing is that I did not touch anything on my router when this happened and did not change any other configuration... > This probe is located in Luxembourg. I now brought it to Belgium and plugged it into the router I have here. Nothing changed. Furthermore, here in Belgium, its 3rd light is slowly blinking, which let's suppose that it gets tuck in the network-testing phase. > > Anybody knows how to fix this? > > (I already had some problems with that probe ("system: Hardware problem suspected") but I could solve them thanks to a hint given by a user.) > > My worst problem is that, due to this issue, we have difficulties earning enough credits for our research... So I would be really happy if this problem could be solved easily :( > > Thanks! > > Sarah > From hank at efes.iucc.ac.il Mon Mar 7 08:36:46 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 7 Mar 2016 09:36:46 +0200 Subject: [atlas] Probe offline In-Reply-To: References: <56A6B292.6080508@nzrs.net.nz> <56A76277.7050606@ripe.net> Message-ID: <56DD2F8E.6070104@efes.iucc.ac.il> I too have a probe that won't come online after being online for months: https://atlas.ripe.net/probes/17879/#!tab-general I did the reset trick: I've stopped the probe, removed the USB drive, started the probe, waited 5 minutes and inserted the USB stick again. The probe comes up but via the WebGUI it shows offline. The IP is pingable so I am at a loss of what I should now do to get it back into the on-line mode. Any help appreciated. Thanks, Hank From magicsata at gmail.com Mon Mar 7 08:45:51 2016 From: magicsata at gmail.com (Alistair Mackenzie) Date: Mon, 7 Mar 2016 07:45:51 +0000 Subject: [atlas] Probe offline In-Reply-To: <56DD2F8E.6070104@efes.iucc.ac.il> References: <56A6B292.6080508@nzrs.net.nz> <56A76277.7050606@ripe.net> <56DD2F8E.6070104@efes.iucc.ac.il> Message-ID: Can you send the SOS DNS packets? On 7 Mar 2016 07:37, "Hank Nussbacher" wrote: > I too have a probe that won't come online after being online for months: > https://atlas.ripe.net/probes/17879/#!tab-general > > I did the reset trick: > I've stopped the probe, removed the USB drive, started the probe, waited > 5 minutes and inserted the USB stick again. The probe comes up but via > the WebGUI it shows offline. > The IP is pingable so I am at a loss of what I should now do to get it > back into the on-line mode. > > Any help appreciated. > > Thanks, > Hank > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vnaumov at ripe.net Mon Mar 7 08:46:26 2016 From: vnaumov at ripe.net (Viktor Naumov) Date: Mon, 7 Mar 2016 08:46:26 +0100 Subject: [atlas] probe tagged as "system: Firewall problem suspected" In-Reply-To: <2036516140.522590.1457263509140.JavaMail.root@student.ulg.ac.be> References: <2036516140.522590.1457263509140.JavaMail.root@student.ulg.ac.be> Message-ID: <56DD31D2.4070808@ripe.net> Hi Sarah, Did you try to boot the probe without USB drive plugged in and replugging it back in 10 minutes while being powered? Did you try to replace the USB drive with a new one with capacity >= 4G? If you tried everything please write to atlas at ripe.net it will create a ticket and we will look further what we can do together about it. Cheers! /vty On 3/6/16 12:25 PM, sarah.wassermann at student.ulg.ac.be wrote: > Hi Viktor, > > I tried all your pieces of advice, but my probe is still disconnected (with 3rd light slowly blinking). > I also attempted to connect it to my router in Li?ge, on which another probe is also connected and working fine, but even there the probe didn't come back to life. > > Thanks to several generous credit-donations, I don't need credits anymore, but can I send the probe somewhere so that it can be fixed? There are not that many probes here in Luxembourg and I would be happy to host a working probe to help extend the network! > > Best regards, > > Sarah > > ----- Mail original ----- > De: "Viktor Naumov" > ?: "sarah wassermann" > Cc: ripe-atlas at ripe.net > Envoy?: Mercredi 17 F?vrier 2016 10:53:02 > Objet: Re: [atlas] probe tagged as "system: Firewall problem suspected" > > Hi Sarah, > > The tagging is done by heuristic that analyzes the probe connection > attempts, SOS, timing between them and some other attributes like > messages about flash drive. It has to have a quite large window for > looking into data and it can take up to a few days for addressing a > probe to a special controller if needed and resetting tags. > > In your case I see that it was disconnected at 2016-02-12 12:26:09. Up > till this time your probe had no problem connecting regservers and > controllers (tcp/443). After that time I see only SOS (DNS > (tcp|udp)/53). That suggests the network problem with the highest > probability - DNS is open but tcp/443 is closed. The lowest probability > has the hardware problem (flash drive) in this case. > > Please use the tag as a suggestion where to begin your local > diagnostics. If the network is good you can try to reinit the flash drive. > > wbr > > /vty > > On 2/16/16 7:29 PM, sarah.wassermann at student.ulg.ac.be wrote: >> Hi, >> >> I have (once again) problems with my probe (probeID: 24102). This time, it got tagged as "system: Firewall problem suspected". The strange thing is that I did not touch anything on my router when this happened and did not change any other configuration... >> This probe is located in Luxembourg. I now brought it to Belgium and plugged it into the router I have here. Nothing changed. Furthermore, here in Belgium, its 3rd light is slowly blinking, which let's suppose that it gets tuck in the network-testing phase. >> >> Anybody knows how to fix this? >> >> (I already had some problems with that probe ("system: Hardware problem suspected") but I could solve them thanks to a hint given by a user.) >> >> My worst problem is that, due to this issue, we have difficulties earning enough credits for our research... So I would be really happy if this problem could be solved easily :( >> >> Thanks! >> >> Sarah >> From hank at efes.iucc.ac.il Mon Mar 7 09:39:47 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 7 Mar 2016 10:39:47 +0200 Subject: [atlas] Probe offline In-Reply-To: References: <56A6B292.6080508@nzrs.net.nz> <56A76277.7050606@ripe.net> <56DD2F8E.6070104@efes.iucc.ac.il> Message-ID: <56DD3E53.1040106@efes.iucc.ac.il> On 07/03/2016 09:45, Alistair Mackenzie wrote: Resolver Time (UTC) Query Type Power-up Time Info 2001:bf8:900:5:20c:29ff:fe79:3b51 2016-03-07 08:37:54 A 1h 50m NO-USB 128.139.227.250 2016-03-07 08:37:54 AAAA 1h 50m NO-USB What does that mean? I can try reseating the USB again, but if that doesn't work, it could be the USB is fried? -Hank > Can you send the SOS DNS packets? > > On 7 Mar 2016 07:37, "Hank Nussbacher" > wrote: > > I too have a probe that won't come online after being online for > months: > https://atlas.ripe.net/probes/17879/#!tab-general > > > I did the reset trick: > I've stopped the probe, removed the USB drive, started the probe, > waited > 5 minutes and inserted the USB stick again. The probe comes up but via > the WebGUI it shows offline. > The IP is pingable so I am at a loss of what I should now do to get it > back into the on-line mode. > > Any help appreciated. > > Thanks, > Hank > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Mon Mar 7 09:49:48 2016 From: gert at space.net (Gert Doering) Date: Mon, 7 Mar 2016 09:49:48 +0100 Subject: [atlas] Probe offline In-Reply-To: <56DD3E53.1040106@efes.iucc.ac.il> References: <56A6B292.6080508@nzrs.net.nz> <56A76277.7050606@ripe.net> <56DD2F8E.6070104@efes.iucc.ac.il> <56DD3E53.1040106@efes.iucc.ac.il> Message-ID: <20160307084948.GY93321@Space.Net> Hi, On Mon, Mar 07, 2016 at 10:39:47AM +0200, Hank Nussbacher wrote: > What does that mean? I can try reseating the USB again, but if that > doesn't work, it could be the USB is fried? Try the USB stick in a "normal" PC and see whether it can be formatted there. I recently had one of mine completely break - the stick could be seen, but it was empty and all write access failed. I'm not sure what the Atlas v3 does with its USB stick, but this is the number one problem issue... maybe a new firmware version could be designed that has more advanced flash handling (like, ubifs instead of "normal" filesystems) and falls back to "not use flash if the flash is broken". What I see with my probes is that the aim of the flash buffer ("we can store measurement results if we can't upload them to the control server due to network outages etc." -> less probability of result loss) is actually backfiring into "extended downtimes of probes due to USB breakage of probes in locations where you can't just-so swap the USB flash"... (two of my 3 v3 probes have had virtually no network outages since they are operating, and the central servers also had few outages - but both have been down for weeks because I just had no time to go out, buy a new flash drive, and *drive over* to replace it - once again) 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 vnaumov at ripe.net Mon Mar 7 09:54:54 2016 From: vnaumov at ripe.net (Viktor Naumov) Date: Mon, 7 Mar 2016 09:54:54 +0100 Subject: [atlas] Probe offline In-Reply-To: <56DD3E53.1040106@efes.iucc.ac.il> References: <56A6B292.6080508@nzrs.net.nz> <56A76277.7050606@ripe.net> <56DD2F8E.6070104@efes.iucc.ac.il> <56DD3E53.1040106@efes.iucc.ac.il> Message-ID: <56DD41DE.7000402@ripe.net> Hi, I've never encountered the USB being fried but the USB flash drive failures are quite often nowadays. Try to replace it with a new one with capacity >= 4Gb. Just plug it in and your probe will reinitialize it. Do not expect your probe online immediately after it. Please give it some time because it requires a full reinitializing of the probe firmware. /vty On 3/7/16 9:39 AM, Hank Nussbacher wrote: > On 07/03/2016 09:45, Alistair Mackenzie wrote: > Resolver Time (UTC) Query Type Power-up Time Info > 2001:bf8:900:5:20c:29ff:fe79:3b51 2016-03-07 08:37:54 A 1h 50m NO-USB > 128.139.227.250 2016-03-07 08:37:54 AAAA 1h 50m NO-USB > > > What does that mean? I can try reseating the USB again, but if that > doesn't work, it could be the USB is fried? > > -Hank > > >> Can you send the SOS DNS packets? >> >> On 7 Mar 2016 07:37, "Hank Nussbacher" > > wrote: >> >> I too have a probe that won't come online after being online for >> months: >> https://atlas.ripe.net/probes/17879/#!tab-general >> >> >> I did the reset trick: >> I've stopped the probe, removed the USB drive, started the probe, >> waited >> 5 minutes and inserted the USB stick again. The probe comes up >> but via >> the WebGUI it shows offline. >> The IP is pingable so I am at a loss of what I should now do to >> get it >> back into the on-line mode. >> >> Any help appreciated. >> >> Thanks, >> Hank >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hank at efes.iucc.ac.il Mon Mar 7 14:09:36 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 7 Mar 2016 15:09:36 +0200 Subject: [atlas] Probe offline In-Reply-To: <20160307084948.GY93321@Space.Net> References: <56A6B292.6080508@nzrs.net.nz> <56A76277.7050606@ripe.net> <56DD2F8E.6070104@efes.iucc.ac.il> <56DD3E53.1040106@efes.iucc.ac.il> <20160307084948.GY93321@Space.Net> Message-ID: <56DD7D90.3020805@efes.iucc.ac.il> On 07/03/2016 10:49, Gert Doering wrote: > Hi, > > On Mon, Mar 07, 2016 at 10:39:47AM +0200, Hank Nussbacher wrote: >> What does that mean? I can try reseating the USB again, but if that >> doesn't work, it could be the USB is fried? > Try the USB stick in a "normal" PC and see whether it can be formatted > there. I recently had one of mine completely break - the stick could be > seen, but it was empty and all write access failed. I pulled the USB stick and tried formatting it. Even though it says 4GB Sandisk, I could only get it to 1GB. So I opened a new probe, extracted its USB stick and stuck it into the probe as well (unformatted). Still off-line. I went to our "lights out" facility 3x today - a 15 minute brisk walk across campus and don't have time to go there again. At home it is far easier to play with these things then it is when the probe is installed as close to your network core as possible (which is usually at a LO facility). I know exactly how you feel! -Hank > > I'm not sure what the Atlas v3 does with its USB stick, but this is the > number one problem issue... maybe a new firmware version could be designed > that has more advanced flash handling (like, ubifs instead of "normal" > filesystems) and falls back to "not use flash if the flash is broken". > > What I see with my probes is that the aim of the flash buffer ("we can > store measurement results if we can't upload them to the control server > due to network outages etc." -> less probability of result loss) is > actually backfiring into "extended downtimes of probes due to USB breakage > of probes in locations where you can't just-so swap the USB flash"... > (two of my 3 v3 probes have had virtually no network outages since they > are operating, and the central servers also had few outages - but both > have been down for weeks because I just had no time to go out, buy a > new flash drive, and *drive over* to replace it - once again) > > Gert Doering > -- NetMaster From m.piscaer at edutel.nl Mon Mar 7 14:24:19 2016 From: m.piscaer at edutel.nl (M. Piscaer) Date: Mon, 7 Mar 2016 14:24:19 +0100 Subject: [atlas] Probe offline In-Reply-To: <56DD7D90.3020805@efes.iucc.ac.il> References: <56A6B292.6080508@nzrs.net.nz> <56A76277.7050606@ripe.net> <56DD2F8E.6070104@efes.iucc.ac.il> <56DD3E53.1040106@efes.iucc.ac.il> <20160307084948.GY93321@Space.Net> <56DD7D90.3020805@efes.iucc.ac.il> Message-ID: <56DD8103.3060804@edutel.nl> Hi Hank, On https://www.youtube.com/watch?v=Y8oF0MaoUlQ I saw that you can use an new clean USB disk. When the usb disk is FAT formated, the probe will use that new usb stick. Kind regards, Michiel Piscaer On 07-03-16 14:09, Hank Nussbacher wrote: > On 07/03/2016 10:49, Gert Doering wrote: >> Hi, >> >> On Mon, Mar 07, 2016 at 10:39:47AM +0200, Hank Nussbacher wrote: >>> What does that mean? I can try reseating the USB again, but if that >>> doesn't work, it could be the USB is fried? >> Try the USB stick in a "normal" PC and see whether it can be formatted >> there. I recently had one of mine completely break - the stick could be >> seen, but it was empty and all write access failed. > > I pulled the USB stick and tried formatting it. Even though it says 4GB > Sandisk, I could only get it to 1GB. > So I opened a new probe, extracted its USB stick and stuck it into the > probe as well (unformatted). Still off-line. > > I went to our "lights out" facility 3x today - a 15 minute brisk walk > across campus and don't have time to > go there again. > > At home it is far easier to play with these things then it is when the > probe is installed as close to your network core as possible (which is > usually at a LO facility). I know exactly how you feel! > > -Hank > >> >> I'm not sure what the Atlas v3 does with its USB stick, but this is the >> number one problem issue... maybe a new firmware version could be designed >> that has more advanced flash handling (like, ubifs instead of "normal" >> filesystems) and falls back to "not use flash if the flash is broken". >> >> What I see with my probes is that the aim of the flash buffer ("we can >> store measurement results if we can't upload them to the control server >> due to network outages etc." -> less probability of result loss) is >> actually backfiring into "extended downtimes of probes due to USB breakage >> of probes in locations where you can't just-so swap the USB flash"... >> (two of my 3 v3 probes have had virtually no network outages since they >> are operating, and the central servers also had few outages - but both >> have been down for weeks because I just had no time to go out, buy a >> new flash drive, and *drive over* to replace it - once again) >> >> Gert Doering >> -- NetMaster > > > -- Network / System Engineer Security Officer E-mail: m.piscaer at edutel.nl Telefoon: +31 88 787 0209 Fax: +31 88 787 0502 Mobiel: +31 6 16048782 Threema: PBPCM9X3 PGP: 0x592097DB W3: www.edutel.nl From hank at efes.iucc.ac.il Mon Mar 7 16:04:34 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 7 Mar 2016 17:04:34 +0200 Subject: [atlas] Probe offline In-Reply-To: <56DD8103.3060804@edutel.nl> References: <56A6B292.6080508@nzrs.net.nz> <56A76277.7050606@ripe.net> <56DD2F8E.6070104@efes.iucc.ac.il> <56DD3E53.1040106@efes.iucc.ac.il> <20160307084948.GY93321@Space.Net> <56DD7D90.3020805@efes.iucc.ac.il> <56DD8103.3060804@edutel.nl> Message-ID: <56DD9882.9080000@efes.iucc.ac.il> On 07/03/2016 15:24, M. Piscaer wrote: Thanks. I will try that on Wed when I am back next to our LO site. -Hank > Hi Hank, > > On https://www.youtube.com/watch?v=Y8oF0MaoUlQ I saw that you can use an > new clean USB disk. When the usb disk is FAT formated, the probe will > use that new usb stick. > > Kind regards, > > Michiel Piscaer > > On 07-03-16 14:09, Hank Nussbacher wrote: >> On 07/03/2016 10:49, Gert Doering wrote: >>> Hi, >>> >>> On Mon, Mar 07, 2016 at 10:39:47AM +0200, Hank Nussbacher wrote: >>>> What does that mean? I can try reseating the USB again, but if that >>>> doesn't work, it could be the USB is fried? >>> Try the USB stick in a "normal" PC and see whether it can be formatted >>> there. I recently had one of mine completely break - the stick could be >>> seen, but it was empty and all write access failed. >> I pulled the USB stick and tried formatting it. Even though it says 4GB >> Sandisk, I could only get it to 1GB. >> So I opened a new probe, extracted its USB stick and stuck it into the >> probe as well (unformatted). Still off-line. >> >> I went to our "lights out" facility 3x today - a 15 minute brisk walk >> across campus and don't have time to >> go there again. >> >> At home it is far easier to play with these things then it is when the >> probe is installed as close to your network core as possible (which is >> usually at a LO facility). I know exactly how you feel! >> >> -Hank >> >>> I'm not sure what the Atlas v3 does with its USB stick, but this is the >>> number one problem issue... maybe a new firmware version could be designed >>> that has more advanced flash handling (like, ubifs instead of "normal" >>> filesystems) and falls back to "not use flash if the flash is broken". >>> >>> What I see with my probes is that the aim of the flash buffer ("we can >>> store measurement results if we can't upload them to the control server >>> due to network outages etc." -> less probability of result loss) is >>> actually backfiring into "extended downtimes of probes due to USB breakage >>> of probes in locations where you can't just-so swap the USB flash"... >>> (two of my 3 v3 probes have had virtually no network outages since they >>> are operating, and the central servers also had few outages - but both >>> have been down for weeks because I just had no time to go out, buy a >>> new flash drive, and *drive over* to replace it - once again) >>> >>> Gert Doering >>> -- NetMaster >> >> From hank at efes.iucc.ac.il Wed Mar 9 09:46:03 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 9 Mar 2016 10:46:03 +0200 Subject: [atlas] Probe offline In-Reply-To: <56DD8103.3060804@edutel.nl> References: <56A6B292.6080508@nzrs.net.nz> <56A76277.7050606@ripe.net> <56DD2F8E.6070104@efes.iucc.ac.il> <56DD3E53.1040106@efes.iucc.ac.il> <20160307084948.GY93321@Space.Net> <56DD7D90.3020805@efes.iucc.ac.il> <56DD8103.3060804@edutel.nl> Message-ID: <56DFE2CB.8000301@efes.iucc.ac.il> On 07/03/2016 15:24, M. Piscaer wrote: Finally got it up. USB was fired. Threw it away. Thanks to all, Hank > Hi Hank, > > On https://www.youtube.com/watch?v=Y8oF0MaoUlQ I saw that you can use an > new clean USB disk. When the usb disk is FAT formated, the probe will > use that new usb stick. > > Kind regards, > > Michiel Piscaer > > On 07-03-16 14:09, Hank Nussbacher wrote: >> On 07/03/2016 10:49, Gert Doering wrote: >>> Hi, >>> >>> On Mon, Mar 07, 2016 at 10:39:47AM +0200, Hank Nussbacher wrote: >>>> What does that mean? I can try reseating the USB again, but if that >>>> doesn't work, it could be the USB is fried? >>> Try the USB stick in a "normal" PC and see whether it can be formatted >>> there. I recently had one of mine completely break - the stick could be >>> seen, but it was empty and all write access failed. >> I pulled the USB stick and tried formatting it. Even though it says 4GB >> Sandisk, I could only get it to 1GB. >> So I opened a new probe, extracted its USB stick and stuck it into the >> probe as well (unformatted). Still off-line. >> >> I went to our "lights out" facility 3x today - a 15 minute brisk walk >> across campus and don't have time to >> go there again. >> >> At home it is far easier to play with these things then it is when the >> probe is installed as close to your network core as possible (which is >> usually at a LO facility). I know exactly how you feel! >> >> -Hank >> >>> I'm not sure what the Atlas v3 does with its USB stick, but this is the >>> number one problem issue... maybe a new firmware version could be designed >>> that has more advanced flash handling (like, ubifs instead of "normal" >>> filesystems) and falls back to "not use flash if the flash is broken". >>> >>> What I see with my probes is that the aim of the flash buffer ("we can >>> store measurement results if we can't upload them to the control server >>> due to network outages etc." -> less probability of result loss) is >>> actually backfiring into "extended downtimes of probes due to USB breakage >>> of probes in locations where you can't just-so swap the USB flash"... >>> (two of my 3 v3 probes have had virtually no network outages since they >>> are operating, and the central servers also had few outages - but both >>> have been down for weeks because I just had no time to go out, buy a >>> new flash drive, and *drive over* to replace it - once again) >>> >>> Gert Doering >>> -- NetMaster >> >> From marty at martystrong.co.uk Wed Mar 9 14:31:44 2016 From: marty at martystrong.co.uk (Marty Strong) Date: Wed, 9 Mar 2016 13:31:44 +0000 Subject: [atlas] Probe offline In-Reply-To: <56DFE2CB.8000301@efes.iucc.ac.il> References: <56A6B292.6080508@nzrs.net.nz> <56A76277.7050606@ripe.net> <56DD2F8E.6070104@efes.iucc.ac.il> <56DD3E53.1040106@efes.iucc.ac.il> <20160307084948.GY93321@Space.Net> <56DD7D90.3020805@efes.iucc.ac.il> <56DD8103.3060804@edutel.nl> <56DFE2CB.8000301@efes.iucc.ac.il> Message-ID: I've had 2 probes that died recently, around the same time, USB seems to be dead. I saw a thread a while back about these SanDisk drives being known faulty and going into read-only mode. Replacing the USB seems to have sorted them anyway. On 9 March 2016 at 08:46, Hank Nussbacher wrote: > On 07/03/2016 15:24, M. Piscaer wrote: > > Finally got it up. USB was fired. Threw it away. > > Thanks to all, > Hank > > > Hi Hank, > > > > On https://www.youtube.com/watch?v=Y8oF0MaoUlQ I saw that you can use an > > new clean USB disk. When the usb disk is FAT formated, the probe will > > use that new usb stick. > > > > Kind regards, > > > > Michiel Piscaer > > > > On 07-03-16 14:09, Hank Nussbacher wrote: > >> On 07/03/2016 10:49, Gert Doering wrote: > >>> Hi, > >>> > >>> On Mon, Mar 07, 2016 at 10:39:47AM +0200, Hank Nussbacher wrote: > >>>> What does that mean? I can try reseating the USB again, but if that > >>>> doesn't work, it could be the USB is fried? > >>> Try the USB stick in a "normal" PC and see whether it can be formatted > >>> there. I recently had one of mine completely break - the stick could > be > >>> seen, but it was empty and all write access failed. > >> I pulled the USB stick and tried formatting it. Even though it says 4GB > >> Sandisk, I could only get it to 1GB. > >> So I opened a new probe, extracted its USB stick and stuck it into the > >> probe as well (unformatted). Still off-line. > >> > >> I went to our "lights out" facility 3x today - a 15 minute brisk walk > >> across campus and don't have time to > >> go there again. > >> > >> At home it is far easier to play with these things then it is when the > >> probe is installed as close to your network core as possible (which is > >> usually at a LO facility). I know exactly how you feel! > >> > >> -Hank > >> > >>> I'm not sure what the Atlas v3 does with its USB stick, but this is the > >>> number one problem issue... maybe a new firmware version could be > designed > >>> that has more advanced flash handling (like, ubifs instead of "normal" > >>> filesystems) and falls back to "not use flash if the flash is broken". > >>> > >>> What I see with my probes is that the aim of the flash buffer ("we can > >>> store measurement results if we can't upload them to the control server > >>> due to network outages etc." -> less probability of result loss) is > >>> actually backfiring into "extended downtimes of probes due to USB > breakage > >>> of probes in locations where you can't just-so swap the USB flash"... > >>> (two of my 3 v3 probes have had virtually no network outages since they > >>> are operating, and the central servers also had few outages - but both > >>> have been down for weeks because I just had no time to go out, buy a > >>> new flash drive, and *drive over* to replace it - once again) > >>> > >>> Gert Doering > >>> -- NetMaster > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marty at martystrong.co.uk Wed Mar 9 14:32:42 2016 From: marty at martystrong.co.uk (Marty Strong) Date: Wed, 9 Mar 2016 13:32:42 +0000 Subject: [atlas] Probe offline In-Reply-To: References: <56A6B292.6080508@nzrs.net.nz> <56A76277.7050606@ripe.net> <56DD2F8E.6070104@efes.iucc.ac.il> <56DD3E53.1040106@efes.iucc.ac.il> <20160307084948.GY93321@Space.Net> <56DD7D90.3020805@efes.iucc.ac.il> <56DD8103.3060804@edutel.nl> <56DFE2CB.8000301@efes.iucc.ac.il> Message-ID: In fact looking back at the SOS logs it even managed to detect it: USB-READONLY On 9 March 2016 at 13:31, Marty Strong wrote: > I've had 2 probes that died recently, around the same time, USB seems to > be dead. I saw a thread a while back about these SanDisk drives being known > faulty and going into read-only mode. Replacing the USB seems to have > sorted them anyway. > > On 9 March 2016 at 08:46, Hank Nussbacher wrote: > >> On 07/03/2016 15:24, M. Piscaer wrote: >> >> Finally got it up. USB was fired. Threw it away. >> >> Thanks to all, >> Hank >> >> > Hi Hank, >> > >> > On https://www.youtube.com/watch?v=Y8oF0MaoUlQ I saw that you can use >> an >> > new clean USB disk. When the usb disk is FAT formated, the probe will >> > use that new usb stick. >> > >> > Kind regards, >> > >> > Michiel Piscaer >> > >> > On 07-03-16 14:09, Hank Nussbacher wrote: >> >> On 07/03/2016 10:49, Gert Doering wrote: >> >>> Hi, >> >>> >> >>> On Mon, Mar 07, 2016 at 10:39:47AM +0200, Hank Nussbacher wrote: >> >>>> What does that mean? I can try reseating the USB again, but if that >> >>>> doesn't work, it could be the USB is fried? >> >>> Try the USB stick in a "normal" PC and see whether it can be formatted >> >>> there. I recently had one of mine completely break - the stick could >> be >> >>> seen, but it was empty and all write access failed. >> >> I pulled the USB stick and tried formatting it. Even though it says >> 4GB >> >> Sandisk, I could only get it to 1GB. >> >> So I opened a new probe, extracted its USB stick and stuck it into the >> >> probe as well (unformatted). Still off-line. >> >> >> >> I went to our "lights out" facility 3x today - a 15 minute brisk walk >> >> across campus and don't have time to >> >> go there again. >> >> >> >> At home it is far easier to play with these things then it is when the >> >> probe is installed as close to your network core as possible (which is >> >> usually at a LO facility). I know exactly how you feel! >> >> >> >> -Hank >> >> >> >>> I'm not sure what the Atlas v3 does with its USB stick, but this is >> the >> >>> number one problem issue... maybe a new firmware version could be >> designed >> >>> that has more advanced flash handling (like, ubifs instead of "normal" >> >>> filesystems) and falls back to "not use flash if the flash is broken". >> >>> >> >>> What I see with my probes is that the aim of the flash buffer ("we can >> >>> store measurement results if we can't upload them to the control >> server >> >>> due to network outages etc." -> less probability of result loss) is >> >>> actually backfiring into "extended downtimes of probes due to USB >> breakage >> >>> of probes in locations where you can't just-so swap the USB flash"... >> >>> (two of my 3 v3 probes have had virtually no network outages since >> they >> >>> are operating, and the central servers also had few outages - but both >> >>> have been down for weeks because I just had no time to go out, buy a >> >>> new flash drive, and *drive over* to replace it - once again) >> >>> >> >>> Gert Doering >> >>> -- NetMaster >> >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierky at pierky.com Wed Mar 9 18:58:27 2016 From: pierky at pierky.com (Pier Carlo Chiodi) Date: Wed, 9 Mar 2016 18:58:27 +0100 Subject: [atlas] DNS64 system tag using RFC7050 Message-ID: <20160309175827.GA19342@dave.pierky.com> Hello, I would like to recall this short conversation that appeared in ipv6-wg: https://www.ripe.net/ripe/mail/archives/ipv6-wg/2015-November/002747.html I was wondering if it is worth adding a new system tag to probes: something like system-dns64. >From a quick analysis that I made using RFC7050 [1] I noticed that only a handful of probes are behind a DNS64 box, but I think it would be useful to have them tagged, to avoid spending credits to detect them every time. Or perhaps the game is not worth the candle... In that case, you can find my results as of yesterday there on GitHub. Bests, 1] https://gist.github.com/pierky/e5ec5c8f8f926bff3ef3#file-ripe-atlas-rfc7050-ipv4only-arpa-md -- Pier Carlo Chiodi From mgalante at ripe.net Thu Mar 10 13:47:16 2016 From: mgalante at ripe.net (Michela Galante) Date: Thu, 10 Mar 2016 13:47:16 +0100 Subject: [atlas] Travel funding for RIPE Atlas Interface Hackathon Message-ID: <88EC7A12-CBE5-47F3-979E-BE21BEC9C21A@ripe.net> Dear colleagues, We?re excited to announce that travel funding is now available for the RIPE Atlas Interface Hackathon! As a reminder, the hackathon takes place 21-22 May in Copenhagen, the weekend before the RIPE 72 Meeting. We're looking for creative thinkers to help us develop new interfaces for RIPE Atlas - and we can now help cover the cost of travel and accommodation for a number of successful applicants, thanks to the generous financial support of our sponsor, Comcast. All of the event details and application form are available online: https://atlas.ripe.net/hackathon/Interface/?pk_campaign=hackathon&pk_kwd=list-atlas *The application deadline is 23 March* We hope to see you there! Michela and the RIPE Atlas Team From mgalante at ripe.net Tue Mar 15 16:58:48 2016 From: mgalante at ripe.net (Michela Galante) Date: Tue, 15 Mar 2016 16:58:48 +0100 Subject: [atlas] Webinar "Advanced RIPE Atlas Usage" on Thursday 17 March Message-ID: Dear colleagues, On Thursday 17 March, 12:30 UTC, we are hosting the webinar on "Advanced RIPE Atlas Usage", aiming to teach network operators how to use RIPE Atlas measurements for network monitoring and troubleshooting. Register now at: https://lirportal.ripe.net/training/register/courseCode/WEB20160011 Web-registration is *only* possible for LIRs (RIPE NCC members). Non-members of RIPE NCC (people who do not have "Reg-ID") can email training at ripe.net and be manually registered. More details below. -------------------------- https://www.ripe.net/support/training/learn-online/webinars/advanced-ripe-atlas-usage-webinar This is part of the series of interactive on-line learning sessions, that give you the opportunity to learn and interact with trainers without leaving your desk, as well as for hands-on practice, and to get your questions answered by developers. Learn how to: - Use RIPE Atlas measurements for network monitoring and troubleshooting - Use API calls for measurement creation - Integrate RIPE Atlas with existing monitoring systems Webinars start at 12:30 UTC, and take about one hour. ----------------------------- We look forward to seeing you online. Kind regards, Michela Galante and Vesna Manojlovic RIPE NCC From BECHA at ripe.net Fri Mar 18 15:28:39 2016 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 18 Mar 2016 15:28:39 +0100 Subject: [atlas] Eleven new RIPE Atlas anchors have joined the community In-Reply-To: <56EC1055.4020604@ripe.net> References: <56EC1055.4020604@ripe.net> Message-ID: <56EC1097.8050106@ripe.net> Dear colleagues, 11 new RIPE Atlas anchors have been activated during the last month, bringing the total number to 188: - uk-lba-as33920, hosted by aql in Leeds, United Kingdom - de-ber-as62310, hosted by managedhosting.de GmbH in Berlin, Germany - bt-thi-as38740, hosted by Tashi InfoComm Limited in Thimpbu, Bhutan and sponsored by APNIC - cz-prg-as52130, hosted by Livesport s.r.o. in Prague, Czech Republic - de-dar-as8365, hosted by TU Darmstadt - Secure Mobile Networking Lab/ DFG Collaborative Research Center in Darmstadt, Germany - one more anchor hosted by INX-ZA/Internet Service Providers' Association of South Africa: za-cpt-as37663 in Cape Town, South Africa - ee-tll-as51349, by Estonian Internet Foundation in Tallinn, Estonia - two anchors hosted by Sky UK Limited: uk-lon-as5607 in London and uk-slo-as5607 in Slough, United Kingdom - sixth anchor for Leaseweb Network B.V.: hk-hkg-as133752 in Hong Kong - fi-hel-as3274, hosted by Cygate Oy in Helsinki, Finland. The map of all anchor locations is available at: https://atlas.ripe.net/anchors/map/ You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ And here are the logos and links to hosting companies: https://atlas.ripe.net/get-involved/community/#!tab-anchor-sponsors We are still accepting new applications from organisations interested in hosting a RIPE Atlas anchor. We are particularly interested in deploying anchors in the Middle East, Western Asia, Latin America and Africa, in order to add more geographical diversity to the measurement data. There are more organisations that want to host a RIPE Atlas anchor but don?t have the necessary funding. To learn more about sponsoring an anchor, please contact us at mcb at ripe.net To apply for your own RIPE Atlas anchor: https://atlas.ripe.net/get-involved/become-an-anchor-host/ For any other questions, please contact us at atlas at ripe.net Regards, Vesna Manojlovic Measurements Community Building RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: anchors 177-188.png Type: image/png Size: 44678 bytes Desc: not available URL: From BECHA at ripe.net Mon Mar 21 10:04:37 2016 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 21 Mar 2016 10:04:37 +0100 Subject: [atlas] Reminder: two days left to apply for RIPE Atlas Interface Hackathon In-Reply-To: <56CF163D.5040104@ripe.net> References: <56CF163D.5040104@ripe.net> Message-ID: <56EFB925.8030603@ripe.net> Dear all, if you are interested in the hackathon, hurry to apply: https://atlas.ripe.net/hackathon/Interface/?pk_campaign=hackathon&pk_kwd=list-atlas *The application deadline is 23 March* There is some limited travel funding available, thanks to our sponsor, for academics & contributors to FLOSS projects. Read more here: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-interface-hackathon Regards, Vesna On 25-feb.-16 15:57, Vesna Manojlovic wrote: > Dear colleagues, > > Calling all front-end developers, UI designers, network operators and > other enthusiastic coders! > > The next RIPE Atlas hackathon takes place 21-22 May in Copenhagen, the > weekend before the RIPE 72 Meeting. > > We're looking for creative thinkers to help us develop new interfaces > for RIPE Atlas. 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/Interface/?pk_campaign=hackathon&pk_kwd=list-atlas > > > *The application deadline is 23 March* > > Please note that we are unfortunately unable to provide travel or > accommodation funding. > > We look forward to seeing you there! > > Regards, > Vesna and the RIPE Atlas Team > > From BECHA at ripe.net Mon Mar 21 11:56:05 2016 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 21 Mar 2016 11:56:05 +0100 Subject: [atlas] Fwd: New on RIPE Labs: Support for Elliptic Curve Cryptography (ECC) in DNS Resolvers as Seen by RIPE Atlas In-Reply-To: <56EFCDF5.5060403@ripe.net> References: <56EFCDF5.5060403@ripe.net> Message-ID: <56EFD345.2040204@ripe.net> Dear colleagues, Please find this new article on RIPE Labs contributed by Maciej Andzinski: The Elliptic Curve Cryptography (ECC) is becoming increasingly popular in DNSSEC. While it is sometimes considered to be a remedy for the low DNSSEC adoption rate, there is also a lot of controversy around it. One of the main concerns is that DNSSEC-validating resolvers don't always make use of ECC. We used RIPE Atlas to measure the support for ECC in DNS resolvers. https://labs.ripe.net/Members/maciej_andzinski_2/support-for-elliptic-curve-cryptography-ecc-in-dns-resolvers-as-seen-by-ripe-atlas?pk_campaign=labs&pk_kwd=list-mat Kind regards, Vesna Manojlovic RIPE NCC From gboonie at gmail.com Tue Mar 22 20:37:06 2016 From: gboonie at gmail.com (gboonie) Date: Tue, 22 Mar 2016 20:37:06 +0100 Subject: [atlas] Probe not flagged as "IPv4 works" Message-ID: <56F19EE2.304@gmail.com> Hi, I have 3 probes in different networks. This one probe is not selected for tests when I do a test on multiple probes that I select op probe ID or ASN. This is the troubling probe: https://atlas.ripe.net/probes/24645/ It is connected via a 4G LTE router. The router is up and everything else works. I could just reboot the modem and the probe but I'm wondering why it fails to get flagged with "IPv4 works". The "built in" test seem to work fine. What could be the issue? Is there something I could do to debug? Or just reboot and forget about it? Thanks, Dave From philip.homburg at ripe.net Wed Mar 23 15:13:55 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 23 Mar 2016 15:13:55 +0100 Subject: [atlas] Probe not flagged as "IPv4 works" In-Reply-To: <56F19EE2.304@gmail.com> References: <56F19EE2.304@gmail.com> Message-ID: <56F2A4A3.7070604@ripe.net> On 2016/03/22 20:37 , gboonie wrote: > It is connected via a 4G LTE router. The router is up and everything > else works. I could just reboot the modem and the probe but I'm > wondering why it fails to get flagged with "IPv4 works". The "built in" > test seem to work fine. > > What could be the issue? Is there something I could do to debug? Or just > reboot and forget about it? After a reboot it doesn't seem to come back, so I suspect a USB stick problem. The last results of the pings to the root DNS servers are from 7 March. From gboonie at gmail.com Wed Mar 23 19:25:03 2016 From: gboonie at gmail.com (gboonie) Date: Wed, 23 Mar 2016 19:25:03 +0100 Subject: [atlas] Probe not flagged as "IPv4 works" In-Reply-To: <56F2B66F.40902@ripe.net> References: <56F19EE2.304@gmail.com> <56F2A4A3.7070604@ripe.net> <56F2B66F.40902@ripe.net> Message-ID: <56F2DF7F.1040509@gmail.com> Hi Philip, A powercycle did not help. I did a reboot without USB stick and formated it in my laptop. Then plugged it back and after some minutes it started working again. Some googeling showed that the stick can be replaced by a 4GB stick but the one that it currently has seemed to be only 1GB. What is your view on this? The other strange thing is that the probe did somehow earn credits. That seems to contradict that it was down. On the other hand the "Connection and traffic" graph clearly shows that it is up after been down. Thanks, Dave Op 23-3-2016 om 16:29 schreef Philip Homburg: > On 2016/03/23 16:27 , Dave . wrote: >> Dit you remotely order a reboot?I did get the mail that the probe is >> down now. > Yes, I did. It is now connected again, but doesn't really work. > >> I'll power cycle when I get home and if it does not help, I'll do te >> delayed plug in trick. > That would be nice. > > Philip > From philip.homburg at ripe.net Thu Mar 24 11:31:09 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 24 Mar 2016 11:31:09 +0100 Subject: [atlas] Probe not flagged as "IPv4 works" In-Reply-To: <56F2DF7F.1040509@gmail.com> References: <56F19EE2.304@gmail.com> <56F2A4A3.7070604@ripe.net> <56F2B66F.40902@ripe.net> <56F2DF7F.1040509@gmail.com> Message-ID: <56F3C1ED.6030408@ripe.net> On 2016/03/23 19:25 , gboonie wrote: > A powercycle did not help. I did a reboot without USB stick and formated > it in my laptop. Then plugged it back and after some minutes it started > working again. > > Some googeling showed that the stick can be replaced by a 4GB stick but > the one that it currently has seemed to be only 1GB. What is your view > on this? The stick is 4GB (or bigger). What you see is probably a partition on the stick. > The other strange thing is that the probe did somehow earn credits. That > seems to contradict that it was down. On the other hand the "Connection > and traffic" graph clearly shows that it is up after been down. Credits are given out based if the probe manages to connect to a controller, not based on whether it actually does useful work. Philip From gboonie at gmail.com Sun Mar 27 22:16:58 2016 From: gboonie at gmail.com (gboonie) Date: Sun, 27 Mar 2016 22:16:58 +0200 Subject: [atlas] IPv6 working Message-ID: <56F83FBA.7000708@gmail.com> Hi, This seems to be an anchor that has Ipv6 connectivity but probably connected to a network with a incomplete routing table. https://atlas.ripe.net/probes/6149/#!tab-builtins It cannot reach a lot of the internet so I'm wondering what causes the system to flag it as "ipv6 works". Also, I've done a few hundred pings and found that probes get their "ipv6 works" only taken away after it has been failing for a few hours. Could that please be changed to something short like 10 minutes? And if possible, some stability tests so that if connectivity comes and goes that if does not get back it's "works" status. Thanks, Dave From listclient at sokolov.eu.org Sun Mar 27 22:27:20 2016 From: listclient at sokolov.eu.org (Daniel AJ Sokolov) Date: Sun, 27 Mar 2016 17:27:20 -0300 Subject: [atlas] IPv6 working In-Reply-To: <56F83FBA.7000708@gmail.com> References: <56F83FBA.7000708@gmail.com> Message-ID: <56F84228.1030903@sokolov.eu.org> On 2016-03-27 05:16 PM, gboonie wrote: > > Also, I've done a few hundred pings and found that probes get their > "ipv6 works" only taken away after it has been failing for a few hours. > Could that please be changed to something short like 10 minutes? And if > possible, some stability tests so that if connectivity comes and goes > that if does not get back it's "works" status. Wouldn't that defy the purpose? If a probe can, generally, do something, but it is broken now, it doesn't make sense to take away the label. Because then it wouldn't be apparent that there is technical issue. It would just look like it can't do it in any case. BR Daniel AJ From gboonie at gmail.com Sun Mar 27 22:45:12 2016 From: gboonie at gmail.com (gboonie) Date: Sun, 27 Mar 2016 22:45:12 +0200 Subject: [atlas] IPv6 working In-Reply-To: <56F84228.1030903@sokolov.eu.org> References: <56F83FBA.7000708@gmail.com> <56F84228.1030903@sokolov.eu.org> Message-ID: <56F84658.20200@gmail.com> Op 27-3-2016 om 22:27 schreef Daniel AJ Sokolov: > > On 2016-03-27 05:16 PM, gboonie wrote: >> Also, I've done a few hundred pings and found that probes get their >> "ipv6 works" only taken away after it has been failing for a few hours. >> Could that please be changed to something short like 10 minutes? And if >> possible, some stability tests so that if connectivity comes and goes >> that if does not get back it's "works" status. > Wouldn't that defy the purpose? > > If a probe can, generally, do something, but it is broken now, it > doesn't make sense to take away the label. Because then it wouldn't be > apparent that there is technical issue. It would just look like it can't > do it in any case. > > BR > Daniel AJ > Good point. Maybe some other way of indicating that it is not fully working. Maybe "ipv6 partially working" instead. This probe has real bad connectivity. Dave From camin at ripe.net Wed Mar 30 10:58:41 2016 From: camin at ripe.net (Chris Amin) Date: Wed, 30 Mar 2016 10:58:41 +0200 Subject: [atlas] IPv6 working In-Reply-To: <56F84658.20200@gmail.com> References: <56F83FBA.7000708@gmail.com> <56F84228.1030903@sokolov.eu.org> <56F84658.20200@gmail.com> Message-ID: <56FB9541.4000007@ripe.net> On 27/03/2016 22:45, gboonie wrote: >>> Also, I've done a few hundred pings and found that probes get their >>> "ipv6 works" only taken away after it has been failing for a few hours. >>> Could that please be changed to something short like 10 minutes? And if >>> possible, some stability tests so that if connectivity comes and goes >>> that if does not get back it's "works" status. >> Wouldn't that defy the purpose? >> >> If a probe can, generally, do something, but it is broken now, it >> doesn't make sense to take away the label. Because then it wouldn't be >> apparent that there is technical issue. It would just look like it can't >> do it in any case. >> > Good point. Maybe some other way of indicating that it is not fully > working. Maybe "ipv6 partially working" instead. This probe has real > bad connectivity. Hi Dave, You're quite right that "IPv6 Works" is applied rather liberally. This is because we wanted it to be a broad indicator that it isn't a complete waste of time scheduling IPv6 measurements on a probe. We have discussed in the past creating some kind of "IPv6 Stable" or "IPv6 Reliable" tag to capture what you are talking about -- i.e. those probes where you can be pretty sure that IPv6 is going to work, barring some exceptional issues. I expect that we will work on this kind of tag in the future (although I can't currently say when), especially if we get more feedback along these lines. Kind regards, Chris Amin RIPE Atlas developer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mhi at ionescu.de Wed Mar 30 11:14:11 2016 From: mhi at ionescu.de (Michael Ionescu) Date: Wed, 30 Mar 2016 11:14:11 +0200 Subject: [atlas] USB drive Message-ID: <56FB98E3.4020702@ionescu.de> Hi all, I have a probe that's been down for several days now. I did contact RIPE about it, but support has been superficial. I also didn't yet find the level of technical detail I need in the information on the website and in this list's archives. The 8GB drive, when reformatted on a windows box with FAT32 as per support instructions, surprisingly only comes out with a 1GB partition. Inspecting the drive under linux, I find multiple partitions, with only the first containing an a fat32 filesystem: Platte /dev/sdc: 7927 MByte, 7927234560 Byte 244 K?pfe, 62 Sektoren/Spur, 1023 Zylinder, zusammen 15482880 Sektoren Einheiten = Sektoren von 1 ? 512 = 512 Bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Festplattenidentifikation: 0xc3072e18 Ger?t boot. Anfang Ende Bl?cke Id System /dev/sdc1 2048 2099199 1048576 b W95 FAT32 /dev/sdc2 2099200 4196351 1048576 83 Linux /dev/sdc3 4196352 6293503 1048576 83 Linux On first glance, the others contain ext2 filesystems # fsck -N /dev/sdc? fsck von util-linux 2.20.1 [/sbin/fsck.vfat (1) -- /dev/sdc1] fsck.vfat /dev/sdc1 [/sbin/fsck.ext2 (2) -- /dev/sdc2] fsck.ext2 /dev/sdc2 [/sbin/fsck.ext2 (3) -- /dev/sdc3] fsck.ext2 /dev/sdc3 but on further inspections do not contain a valid magic number in their superblocks, so they are effectively unformatted. I would therefore suspect that they are not being used by the probe. Now the question: What is the correct layout supposed to look like (primary/secondary, size, ID, FS-type)? I would like to get my probe back up and running. Bonus question: What can I expect to find in point of files/data on the drive, that would tell me whether the probe was working correctly until I cut power and removed the drive? Thanks, Michael From gert at space.net Wed Mar 30 11:19:36 2016 From: gert at space.net (Gert Doering) Date: Wed, 30 Mar 2016 11:19:36 +0200 Subject: [atlas] USB drive In-Reply-To: <56FB98E3.4020702@ionescu.de> References: <56FB98E3.4020702@ionescu.de> Message-ID: <20160330091935.GQ62900@Space.Net> Hi, On Wed, Mar 30, 2016 at 11:14:11AM +0200, Michael Ionescu wrote: > Now the question: > What is the correct layout supposed to look like (primary/secondary, size, ID, FS-type)? I would like to get my probe back up and running. dd if=/dev/zero of=/dev/ bs=1m count=1 just zero-out the partition sector and the probe will re-initialize everything (boot up without flash stick, re-insert emptied flash stick, wait an hour or so). This REALLY needs to go into the FAQ that is sent with every "hey, your probe is down!" mail. Plus, "we can hear its SOS requests, and it needs a flash replacement". RIPE NCC folks, are you listening? This is a major annoyance. 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 mhi at ionescu.de Wed Mar 30 13:08:23 2016 From: mhi at ionescu.de (Michael Ionescu) Date: Wed, 30 Mar 2016 13:08:23 +0200 Subject: [atlas] USB drive In-Reply-To: <20160330091935.GQ62900@Space.Net> References: <56FB98E3.4020702@ionescu.de> <20160330091935.GQ62900@Space.Net> Message-ID: <56FBB3A7.3000409@ionescu.de> Thanks Gert, that helped! The probe was back up after only a couple of minutes. Until the FAQ has been amended, the following might help others: To reset the USB Thumbdrive: Under Windows: https://tails.boum.org/doc/first_steps/reset/windows/index.en.html (stop after the "clean" step) Under Linux: dd if=/dev/zero of=/dev/ bs=512 count=1 Plug the thumbdrive back into the Probe AFTER the Probe has rebooted. SOS History (on the probe's RIPE Atlas Webpage - Network tab) should show Entries with "NO USB" after reboot and then regular entries with no errors, once the thumbdrive has been replaced. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From woeber at cc.univie.ac.at Wed Mar 30 13:15:47 2016 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Wed, 30 Mar 2016 13:15:47 +0200 Subject: [atlas] IPv6 working In-Reply-To: <56FB9541.4000007@ripe.net> References: <56F83FBA.7000708@gmail.com> <56F84228.1030903@sokolov.eu.org> <56F84658.20200@gmail.com> <56FB9541.4000007@ripe.net> Message-ID: <56FBB563.2010001@cc.univie.ac.at> On 2016-03-30 10:58, Chris Amin wrote: > On 27/03/2016 22:45, gboonie wrote: [...] > We have discussed in the past creating some kind of "IPv6 Stable" or > "IPv6 Reliable" tag to capture what you are talking about -- i.e. those > probes where you can be pretty sure that IPv6 is going to work, barring > some exceptional issues. Just another thought... I can see 2 different aspects here: - IPv6 "works", i.e. the probe can use IPv6 transport to connect to the controller (or do whatever you @ the NCC see as an indication), and - a) the reliability of IPv6-based connectivity to that "home", plus b) the "level" of accessibility to/from the IPv6-based Internet Fwiw, -ww144 > I expect that we will work on this kind of tag in the future (although I > can't currently say when), especially if we get more feedback along > these lines. > > Kind regards, > Chris Amin > RIPE Atlas developer > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From robert at ripe.net Wed Mar 30 13:48:03 2016 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 30 Mar 2016 13:48:03 +0200 Subject: [atlas] Plan to Implement RIPE Atlas WiFi Measurements Message-ID: <56FBBCF3.5010606@ripe.net> Dear colleagues, We wanted to update the community and let you know that we plan to start work on the proposed experiment with WiFi measurements in mid-2016. As we communicated in a recent RIPE Labs article, we will work with G?ANT as a test partner to learn more about the operational effects of introducing WiFi measurements to the RIPE Atlas system, in addition to the benefits we believe this could provide for the entire RIPE Atlas community. Please see the article for more details if you are interested: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-wifi-measurements-part-2 We will continue to update you once we?ve begun work on this plan, and we welcome your comments in the meantime. Regards, Robert Kisteleki RIPE NCC From philip.homburg at ripe.net Wed Mar 30 13:50:33 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 30 Mar 2016 13:50:33 +0200 Subject: [atlas] USB drive In-Reply-To: <56FB98E3.4020702@ionescu.de> References: <56FB98E3.4020702@ionescu.de> Message-ID: <56FBBD89.1030909@ripe.net> Hi Michael, > but on further inspections do not contain a valid magic number in their superblocks, so they are effectively unformatted. I would therefore suspect that they are not being used by the probe. > > Now the question: > What is the correct layout supposed to look like (primary/secondary, size, ID, FS-type)? I would like to get my probe back up and running. In general, the probe doesn't care what is on the USB stick. So wiping or formatting the stick is not needed. There is at the moment one rare exception. The filesystem can go corrupt to the point the fsck hangs. In that case, wiping the entire USB stick will help. To get the probe to reinitialise the USB stick, the correct procedure is to power on the probe without USB stick and then insert the USB stick after a few minutes (10 to be safe). The procedure suggested by Gert Doering will also work. But should not be necessary. The filesystems on the UDB stick are encrypted, that why you can't find any valid magic numbers. > Bonus question: > What can I expect to find in point of files/data on the drive, that would tell me whether the probe was working correctly until I cut power and removed the drive? You cannot find anything on the drive. Only the probe has the encryption keys. Currently the probes use an ext2 filesystem, because it is simple and seemed to work well enough. It worked well in artificially power cycling the probe for period of time. Of course, reality is worse. At some point I'll try to experiment with adding journaling to see if it makes a difference. Philip From gert at space.net Wed Mar 30 13:57:28 2016 From: gert at space.net (Gert Doering) Date: Wed, 30 Mar 2016 13:57:28 +0200 Subject: [atlas] USB drive In-Reply-To: <56FBBD89.1030909@ripe.net> References: <56FB98E3.4020702@ionescu.de> <56FBBD89.1030909@ripe.net> Message-ID: <20160330115728.GB85490@Space.Net> Hi, On Wed, Mar 30, 2016 at 01:50:33PM +0200, Philip Homburg wrote: > Currently the probes use an ext2 filesystem, because it is simple and > seemed to work well enough. It worked well in artificially power cycling > the probe for period of time. Of course, reality is worse. This might actually be the reason for the flash issues - from what I could gather, these USB stick controllers understand FAT well enough to do wear-leveling for it, but are not as smart as SSDs who handle "arbitrary block access patterns" properly - so, using "non-FAT" filesystems will make the USB stick (and SD-Cards, for that matter) wear out much faster. 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 mhi at ionescu.de Wed Mar 30 14:54:40 2016 From: mhi at ionescu.de (Michael Ionescu) Date: Wed, 30 Mar 2016 14:54:40 +0200 Subject: [atlas] USB drive In-Reply-To: <56FBBD89.1030909@ripe.net> References: <56FB98E3.4020702@ionescu.de> <56FBBD89.1030909@ripe.net> Message-ID: <56FBCC90.8090801@ionescu.de> Hi Philip, thanks for clearing this up. It would be really great to take some of the guesswork out of these cases, by adding one or two checks regarding the thumbdrive and file system status, transmitting negative results via descriptive SOS messages and/or system status tags. On my probe the USB problems led to a system tag "Firewall problem suspected". This is quite misleading. After your description I would suspect the FS issue impeded the probe so deeply that it wasn't able to call home at all anymore. To my understanding, probes should be fire-and-forget as much as possible, so I think any fsck should be run in a way that would not impede an otherwise functioning probe. Michael On 30.03.2016 13:50, Philip Homburg wrote: > Hi Michael, > [...] > In general, the probe doesn't care what is on the USB stick. So wiping > or formatting the stick is not needed. > > There is at the moment one rare exception. The filesystem can go corrupt > to the point the fsck hangs. > [...] > Philip