From christopher.morrow at gmail.com Fri Jan 11 20:27:09 2019 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Fri, 11 Jan 2019 14:27:09 -0500 Subject: [atlas] credit differences between probes? Message-ID: howdy! (long time listener, first time caller...) I have some probes deployed, and for some period of time I was accruing credits at about the same rate per day per probe. Recently (last week or so?) I noticed that I now accrue at one rate for 1 device and a different rate for 2 other devices. The devices have been up for at least the last 24hrs: morrowc-fios 4 days, 5 hours 21.6k morrowc-comcast 1 week, 2 days 65.7k Atlas at deteque-IAD 3 weeks 21.6k (unsure why the fios one bobbled...but it's still be up for ~4days) Is this expected? or maybe I'm just in some wonky space with the accruals anyway? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eject.in.ua at gmail.com Sun Jan 13 11:02:49 2019 From: eject.in.ua at gmail.com (Evgeniy S.) Date: Sun, 13 Jan 2019 11:02:49 +0100 Subject: [atlas] Probe firmware source code Message-ID: Dear community let me ask if probe os and services (aka firmware) source code available in public? Where I find it if yes, and why it's not public if not available? -- -- With regards, Eugene S -------------- next part -------------- An HTML attachment was scrubbed... URL: From inigo at infornografia.net Sun Jan 13 13:54:20 2019 From: inigo at infornografia.net (=?UTF-8?Q?I=C3=B1igo_Ortiz_de_Urbina?=) Date: Sun, 13 Jan 2019 13:54:20 +0100 Subject: [atlas] Probe firmware source code In-Reply-To: References: Message-ID: Hi Evgeniy On Sun, 13 Jan 2019 at 11:03, Evgeniy S. wrote: > Dear community let me ask if probe os and services (aka firmware) source > code available in public? Where I find it if yes, and why it's not public > if not available? > https://atlas.ripe.net/resources/source-code/ HTH, > -- "If you want to go fast, go alone. If you want to go far, go together." -------------- next part -------------- An HTML attachment was scrubbed... URL: From eject.in.ua at gmail.com Sun Jan 13 16:41:46 2019 From: eject.in.ua at gmail.com (Evgeniy S.) Date: Sun, 13 Jan 2019 16:41:46 +0100 Subject: [atlas] Probe firmware source code In-Reply-To: References: Message-ID: Hi I?igo, thank you for helping I overlooked that information on website and Github repository. Btw, I see some discrepancy there (which can be improved): 1) commit to Gihub repository - last was Jun 14, 2018; 2) listed firmware (last 4790 from Jun 27 2017) on https://atlas.ripe.net/resources/source-code/ page; 3) actual firmware version we have installed on probes 4940 (I found no way to fund when it was released and when probe was updated); -- Evgeniy S On Sun, Jan 13, 2019 at 1:54 PM I?igo Ortiz de Urbina < inigo at infornografia.net> wrote: > Hi Evgeniy > > On Sun, 13 Jan 2019 at 11:03, Evgeniy S. wrote: > >> Dear community let me ask if probe os and services (aka firmware) source >> code available in public? Where I find it if yes, and why it's not public >> if not available? >> > > https://atlas.ripe.net/resources/source-code/ > > HTH, > >> -- > "If you want to go fast, go alone. If you want to go far, go together." > -- -- With regards, Eugene Sudyr -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.morrow at gmail.com Sun Jan 13 22:48:09 2019 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Sun, 13 Jan 2019 16:48:09 -0500 Subject: [atlas] credit differences between probes? In-Reply-To: References: Message-ID: On Fri, Jan 11, 2019 at 2:27 PM Christopher Morrow < christopher.morrow at gmail.com> wrote: > howdy! > (long time listener, first time caller...) > > I have some probes deployed, and for some period of time I was accruing > credits at about the same rate per day per probe. Recently (last week or > so?) I noticed that I now accrue at one rate for 1 device and a different > rate for 2 other devices. > > The devices have been up for at least the last 24hrs: > morrowc-fios 4 days, 5 hours 21.6k > morrowc-comcast 1 week, 2 days 65.7k > Atlas at deteque-IAD 3 weeks 21.6k > > These changed again, so there's some sort of algorithm which isn't clear to me (just a regular user). Currently the fios is accruing at: ~82k while the others are unchanged. I suppose: "it's an algorithm silly!" is a fine answer. (unsure why the fios one bobbled...but it's still be up for ~4days) > > Is this expected? or maybe I'm just in some wonky space with the accruals > anyway? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno.pagani at ens-lyon.org Sun Jan 13 23:31:48 2019 From: bruno.pagani at ens-lyon.org (Bruno Pagani) Date: Sun, 13 Jan 2019 23:31:48 +0100 Subject: [atlas] credit differences between probes? In-Reply-To: References: Message-ID: <97b52907-fcc5-3ad9-6528-46d1939b6ef6@ens-lyon.org> Le 13/01/2019 ? 22:48, Christopher Morrow a ?crit?: > > > On Fri, Jan 11, 2019 at 2:27 PM Christopher Morrow > > > wrote: > > howdy! > (long time listener, first time caller...) > > I have some probes deployed, and for some period of time I was > accruing credits at about the same rate per day per probe. > Recently (last week or so?) I noticed that I now accrue at one > rate for 1 device and a different rate for 2 other devices. > > The devices have been up for at least the last 24hrs: > ? ? ? ??? ?morrowc-fios4 days, 5 hours 21.6k > ? ?morrowc-comcast?1 week, 2 days 65.7k > Atlas at deteque-IAD3 weeks? ? ? ? ?21.6k > > > These changed again, so there's some sort of algorithm which isn't > clear to me (just a regular user). > Currently the fios is accruing at: ~82k while the others are unchanged. > > I suppose: "it's an algorithm silly!" is a fine answer. > > (unsure why the fios one bobbled...but it's still be up for ~4days) > > Is this expected? or maybe I'm just in some wonky space with the > accruals anyway? > AFAIR, you gain credits from two things: 1. Just hosting the probe in working conditions. 2. Having your probe used in measurements. So, what you see is likely one probe being used for something.?;) Regards, Bruno -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.morrow at gmail.com Mon Jan 14 16:42:21 2019 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 14 Jan 2019 10:42:21 -0500 Subject: [atlas] credit differences between probes? In-Reply-To: <97b52907-fcc5-3ad9-6528-46d1939b6ef6@ens-lyon.org> References: <97b52907-fcc5-3ad9-6528-46d1939b6ef6@ens-lyon.org> Message-ID: On Sun, Jan 13, 2019 at 5:31 PM Bruno Pagani wrote: > Le 13/01/2019 ? 22:48, Christopher Morrow a ?crit : > > > > On Fri, Jan 11, 2019 at 2:27 PM Christopher Morrow < > christopher.morrow at gmail.com> wrote: > >> howdy! >> (long time listener, first time caller...) >> >> I have some probes deployed, and for some period of time I was accruing >> credits at about the same rate per day per probe. Recently (last week or >> so?) I noticed that I now accrue at one rate for 1 device and a different >> rate for 2 other devices. >> >> The devices have been up for at least the last 24hrs: >> morrowc-fios 4 days, 5 hours 21.6k >> morrowc-comcast 1 week, 2 days 65.7k >> Atlas at deteque-IAD 3 weeks 21.6k >> >> > These changed again, so there's some sort of algorithm which isn't clear > to me (just a regular user). > Currently the fios is accruing at: ~82k while the others are unchanged. > > I suppose: "it's an algorithm silly!" is a fine answer. > > (unsure why the fios one bobbled...but it's still be up for ~4days) >> >> Is this expected? or maybe I'm just in some wonky space with the accruals >> anyway? >> > AFAIR, you gain credits from two things: > > 1. Just hosting the probe in working conditions. > 2. Having your probe used in measurements. > > So, what you see is likely one probe being used for something.?;) > > oh cool! ok, well I'm glad it's being used :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno.pagani at ens-lyon.org Mon Jan 14 16:45:39 2019 From: bruno.pagani at ens-lyon.org (Bruno Pagani) Date: Mon, 14 Jan 2019 16:45:39 +0100 Subject: [atlas] credit differences between probes? In-Reply-To: References: <97b52907-fcc5-3ad9-6528-46d1939b6ef6@ens-lyon.org> Message-ID: <683821a1-2d24-4e50-b2ab-4971486a2af7@ens-lyon.org> Le 14/01/2019 ? 16:42, Christopher Morrow a ?crit?: > > > On Sun, Jan 13, 2019 at 5:31 PM Bruno Pagani > > wrote: > > Le 13/01/2019 ? 22:48, Christopher Morrow a ?crit?: >> >> >> On Fri, Jan 11, 2019 at 2:27 PM Christopher Morrow >> > > wrote: >> >> howdy! >> (long time listener, first time caller...) >> >> I have some probes deployed, and for some period of time I >> was accruing credits at about the same rate per day per >> probe. Recently (last week or so?) I noticed that I now >> accrue at one rate for 1 device and a different rate for 2 >> other devices. >> >> The devices have been up for at least the last 24hrs: >> ? ? ? ??? ?morrowc-fios4 days, 5 hours 21.6k >> ? ?morrowc-comcast?1 week, 2 days 65.7k >> Atlas at deteque-IAD3 weeks? ? ? ? ?21.6k >> >> >> These changed again, so there's some sort of algorithm which >> isn't clear to me (just a regular user). >> Currently the fios is accruing at: ~82k while the others are >> unchanged. >> >> I suppose: "it's an algorithm silly!" is a fine answer. >> >> (unsure why the fios one bobbled...but it's still be up for >> ~4days) >> >> Is this expected? or maybe I'm just in some wonky space with >> the accruals anyway? >> > AFAIR, you gain credits from two things: > > 1. Just hosting the probe in working conditions. > 2. Having your probe used in measurements. > > So, what you see is likely one probe being used for something.?;) > > oh cool! ok, well I'm glad it's being used :) > Now that I?m back on a computer, I confirm what I said above and also can tell you that the detail is available at: https://atlas.ripe.net/user/credits/ You?ll see ?Probe uptime? entries of 21600 (or below in case of downtime) and some ?For results delivered? with various amounts. Regards, Bruno -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From christopher.morrow at gmail.com Mon Jan 14 17:01:49 2019 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 14 Jan 2019 11:01:49 -0500 Subject: [atlas] credit differences between probes? In-Reply-To: <683821a1-2d24-4e50-b2ab-4971486a2af7@ens-lyon.org> References: <97b52907-fcc5-3ad9-6528-46d1939b6ef6@ens-lyon.org> <683821a1-2d24-4e50-b2ab-4971486a2af7@ens-lyon.org> Message-ID: On Mon, Jan 14, 2019 at 10:45 AM Bruno Pagani wrote: > Now that I?m back on a computer, I confirm what I said above and also can > tell you that the detail is available at: > > https://atlas.ripe.net/user/credits/ > > You?ll see ?Probe uptime? entries of 21600 (or below in case of downtime) > and some ?For results delivered? with various amounts. > > Ah! ok, yes I see 21600 for just being alive and slightly different amounts for 'results delivered'. thanks for the pointer. -chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.morrow at gmail.com Wed Jan 16 19:18:03 2019 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 16 Jan 2019 13:18:03 -0500 Subject: [atlas] Probe questions - reporting clearly busticated probe configs? Message-ID: Howdy! I've been running a few measurements over the last while and looked at the raw results like: [{"dst_name":"2001:4860:4860::8844","error":{"socket":"connect failed Network is unreachable"},"from":"fd84:d527:5183:0:a2f3:c1ff:fec4:63a8","fw":4940,"group_id":18903906,"lts":21,"msm_id":18903906,"msm_name":"Tdig","prb_id":13635,".... "from":"2001:db8:4447:0:eade:27ff:fec9:7134","fw":4940,"group_id":18903906,"lts":7,"msm_id":18903906,"msm_name":"Tdig","prb_id":26725,"...] I'm curious if/how atlas reports back to probe owners: "Hey, your ipv6 connectivity is implausible/impossible" since, at least for: https://atlas.ripe.net/probes/26725/#!tab-network and: https://atlas.ripe.net/probes/13635/#!tab-network there's no way their v6 addresses can work... (one is documentation prefix the other is ULA I think?) I suppose test requestors should check the ipv6 prefix to see if it's at least plausibly correct until some signal back to the owners can be attempted? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Wed Jan 16 19:55:00 2019 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 16 Jan 2019 13:55:00 -0500 Subject: [atlas] Probe questions - reporting clearly busticated probe configs? In-Reply-To: References: Message-ID: <8CE68A0B-52A3-47B7-973A-066055732E96@puck.nether.net> > On Jan 16, 2019, at 1:18 PM, Christopher Morrow wrote: > > Howdy! > I've been running a few measurements over the last while and looked at the raw results like: > > [{"dst_name":"2001:4860:4860::8844","error":{"socket":"connect failed Network is unreachable"},"from":"fd84:d527:5183:0:a2f3:c1ff:fec4:63a8","fw":4940,"group_id":18903906,"lts":21,"msm_id":18903906,"msm_name":"Tdig","prb_id":13635,".... > "from":"2001:db8:4447:0:eade:27ff:fec9:7134","fw":4940,"group_id":18903906,"lts":7,"msm_id":18903906,"msm_name":"Tdig","prb_id":26725,"...] > > I'm curious if/how atlas reports back to probe owners: > "Hey, your ipv6 connectivity is implausible/impossible" > > since, at least for: > https://atlas.ripe.net/probes/26725/#!tab-network > and: > https://atlas.ripe.net/probes/13635/#!tab-network > > there's no way their v6 addresses can work... (one is documentation prefix the other is ULA I think?) > > I suppose test requestors should check the ipv6 prefix to see if it's at least plausibly correct until some signal back to the owners can be attempted? You should be selecting probes with the system-ipv6-works tag https://atlas.ripe.net/docs/probe-tags/ - jared From christopher.morrow at gmail.com Wed Jan 16 20:16:14 2019 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 16 Jan 2019 14:16:14 -0500 Subject: [atlas] Probe questions - reporting clearly busticated probe configs? In-Reply-To: <8CE68A0B-52A3-47B7-973A-066055732E96@puck.nether.net> References: <8CE68A0B-52A3-47B7-973A-066055732E96@puck.nether.net> Message-ID: On Wed, Jan 16, 2019 at 1:55 PM Jared Mauch wrote: > > > > On Jan 16, 2019, at 1:18 PM, Christopher Morrow < > christopher.morrow at gmail.com> wrote: > > > > Howdy! > > I've been running a few measurements over the last while and looked at > the raw results like: > > > > [{"dst_name":"2001:4860:4860::8844","error":{"socket":"connect failed > Network is > unreachable"},"from":"fd84:d527:5183:0:a2f3:c1ff:fec4:63a8","fw":4940,"group_id":18903906,"lts":21,"msm_id":18903906,"msm_name":"Tdig","prb_id":13635,".... > > > "from":"2001:db8:4447:0:eade:27ff:fec9:7134","fw":4940,"group_id":18903906,"lts":7,"msm_id":18903906,"msm_name":"Tdig","prb_id":26725,"...] > > > > I'm curious if/how atlas reports back to probe owners: > > "Hey, your ipv6 connectivity is implausible/impossible" > > > > since, at least for: > > https://atlas.ripe.net/probes/26725/#!tab-network > > and: > > https://atlas.ripe.net/probes/13635/#!tab-network > > > > there's no way their v6 addresses can work... (one is documentation > prefix the other is ULA I think?) > > > > I suppose test requestors should check the ipv6 prefix to see if it's at > least plausibly correct until some signal back to the owners can be > attempted? > > You should be selecting probes with the system-ipv6-works tag > > DOH! :( ok, fine. (thanks) > https://atlas.ripe.net/docs/probe-tags/ > > - jared > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.morrow at gmail.com Wed Jan 16 20:18:52 2019 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 16 Jan 2019 14:18:52 -0500 Subject: [atlas] Probe questions - reporting clearly busticated probe configs? In-Reply-To: References: <8CE68A0B-52A3-47B7-973A-066055732E96@puck.nether.net> Message-ID: On Wed, Jan 16, 2019 at 2:16 PM Christopher Morrow < christopher.morrow at gmail.com> wrote: > > > On Wed, Jan 16, 2019 at 1:55 PM Jared Mauch wrote: > >> >> >> > On Jan 16, 2019, at 1:18 PM, Christopher Morrow < >> christopher.morrow at gmail.com> wrote: >> > >> > Howdy! >> > I've been running a few measurements over the last while and looked at >> the raw results like: >> > >> > [{"dst_name":"2001:4860:4860::8844","error":{"socket":"connect failed >> Network is >> unreachable"},"from":"fd84:d527:5183:0:a2f3:c1ff:fec4:63a8","fw":4940,"group_id":18903906,"lts":21,"msm_id":18903906,"msm_name":"Tdig","prb_id":13635,".... >> > >> "from":"2001:db8:4447:0:eade:27ff:fec9:7134","fw":4940,"group_id":18903906,"lts":7,"msm_id":18903906,"msm_name":"Tdig","prb_id":26725,"...] >> > >> > I'm curious if/how atlas reports back to probe owners: >> > "Hey, your ipv6 connectivity is implausible/impossible" >> > >> > since, at least for: >> > https://atlas.ripe.net/probes/26725/#!tab-network >> > and: >> > https://atlas.ripe.net/probes/13635/#!tab-network >> > >> > there's no way their v6 addresses can work... (one is documentation >> prefix the other is ULA I think?) >> > >> > I suppose test requestors should check the ipv6 prefix to see if it's >> at least plausibly correct until some signal back to the owners can be >> attempted? >> >> You should be selecting probes with the system-ipv6-works tag >> >> > DOH! :( ok, fine. > (thanks) > > hey wait.... The first of my examples: https://atlas.ripe.net/probes/26725/#!tab-general has: System Tags V3 Resolves A Correctly Resolves AAAA Correctly IPv4 Works IPv6 Works IPv4 Capable IPv6 Capable IPv4 RFC1918 IPv4 Stable 90d suspiciously: "system-ipv6-works" is in that list... even though the v6 address is: 2001:db8:4447:0:eade:27ff:fec9:7134/64 at least the second one (https://atlas.ripe.net/probes/13635/#!tab-general) has: V3 Resolver Mangles Case IPv4 Works IPv6 Doesn't Work IPv4 Capable IPv6 Capable IPv6 ULA IPv4 RFC1918 IPv4 Stable 1d "system-ipv6-doesn't work" > https://atlas.ripe.net/docs/probe-tags/ >> >> - jared >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From adavies at ripe.net Thu Jan 17 13:04:57 2019 From: adavies at ripe.net (Alun Davies) Date: Thu, 17 Jan 2019 13:04:57 +0100 Subject: [atlas] New on RIPE Labs: Redesigning the RIPE Atlas Measurement Details Page Message-ID: <562E6496-5823-4F14-A968-7DD548B1966A@ripe.net> Dear colleagues, Today we published an article on some of the changes we?ve made to the RIPE Atlas measurement details page. The redesign follows work we?ve been doing to move over to a new back-end storage solution for RIPE Atlas measurement metadata. Click the link to find out more: https://labs.ripe.net/Members/jasper_den_hertog/new-design-and-functionality-for-the-ripe-atlas-measurement-detail-page Kind regards, Alun Davies RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2627 bytes Desc: not available URL: From robert at ripe.net Fri Jan 18 11:11:22 2019 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 18 Jan 2019 11:11:22 +0100 Subject: [atlas] credit differences between probes? In-Reply-To: References: <97b52907-fcc5-3ad9-6528-46d1939b6ef6@ens-lyon.org> <683821a1-2d24-4e50-b2ab-4971486a2af7@ens-lyon.org> Message-ID: On 2019-01-14 17:01, Christopher Morrow wrote: > > > On Mon, Jan 14, 2019 at 10:45 AM Bruno Pagani > wrote: > > Now that I?m back on a computer, I confirm what I said above and > also can tell you that the detail is available at: > > https://atlas.ripe.net/user/credits/ > > You?ll see ?Probe uptime? entries of 21600 (or below in case of > downtime) and some ?For results delivered? with various amounts. > > Ah! ok, yes I see 21600 for just being alive and slightly different > amounts for 'results delivered'. thanks for the pointer. > -chris I can confirm this to be "the algorithm" :-) This "bonus" was introduced a couple of years ago mostly because some probes are much more popular than others and it just seemed fair to recognise and rewaerd this. Regards, Robert From camin at ripe.net Fri Jan 18 11:40:42 2019 From: camin at ripe.net (Chris Amin) Date: Fri, 18 Jan 2019 11:40:42 +0100 Subject: [atlas] Probe questions - reporting clearly busticated probe configs? In-Reply-To: References: <8CE68A0B-52A3-47B7-973A-066055732E96@puck.nether.net> Message-ID: <05a44c45-cece-0561-e2aa-61a1904ea6bf@ripe.net> Hi Christopher, On 16/01/2019 20:18, Christopher Morrow wrote: > > hey wait.... The first of my examples: > ??https://atlas.ripe.net/probes/26725/#!tab-general > > > has: > System TagsV3 Resolves A Correctly Resolves AAAA Correctly IPv4 Works > IPv6 Works IPv4 Capable IPv6 Capable IPv4 RFC1918 IPv4 Stable 90d > > suspiciously: "system-ipv6-works" is in that list... even though the v6 > address is: > ? 2001:db8:4447:0:eade:27ff:fec9:7134/64 This probe has the "system-ipv6-works" tag because it can successfully ping at least one IPv6 target. You can see at https://atlas.ripe.net/probes/26725/#!tab-builtins that it can in fact reach a number of IPv6 targets. Note that the probe host for 26725 has tagged the probe as "IPv6NAT", maybe this explains the discrepancy you are seeing? Regards, Another Christopher From ripe at brite.cz Sat Jan 19 08:14:44 2019 From: ripe at brite.cz (ripe at brite.cz) Date: Sat, 19 Jan 2019 08:14:44 +0100 Subject: [atlas] =?utf-8?q?IPv6_Doesn=27t_Work?= Message-ID: <20190119081444.E83FFDE4@centrum.cz> Hi, I have Probe #2413 here, it shows label " IPv6 Doesn't Work". It has IPv6 address assigned: IPv6 Current Configuration Addresses 2a00:1028:8d1c:90da:220:4aff:fee0:2026/64 ASN 5610 Gateway(s) fe80::1 I'm not sure what's the issue. My provider provides IPv6, but I personally don't use IPv6 on any of my devices. I read https://atlas.ripe.net/about/faq/#i-have-an-ipv6-only-network-will-the-probe-work-on-it but in this case it is not IPv6 only. I tried to give it static config but I couldn't find out what config to use. Any idea? Thanks Jiri From lists at eckel-edv.de Sat Jan 19 11:26:33 2019 From: lists at eckel-edv.de (Peter Eckel) Date: Sat, 19 Jan 2019 11:26:33 +0100 Subject: [atlas] IPv6 Doesn't Work In-Reply-To: <20190119081444.E83FFDE4@centrum.cz> References: <20190119081444.E83FFDE4@centrum.cz> Message-ID: Hi Jiri, for me it looks like you're not reachable indeed: > pete at charon.net.hindenburgring.com> traceroute inet6 2a00:1028:8d1c:90da:220:4aff:fee0:2026 > traceroute6 to 2a00:1028:8d1c:90da:220:4aff:fee0:2026 (2a00:1028:8d1c:90da:220:4aff:fee0:2026) from , 64 hops max, 12 byte packets > [...] > 3 2a00:19e0:ffff:fffc::1 (2a00:19e0:ffff:fffc::1) 23.579 ms 23.308 ms 23.495 ms > 4 2a00:19e0:ffff:ffff::3 (2a00:19e0:ffff:ffff::3) 29.521 ms 29.738 ms 29.822 ms > 5 ae0-401.fra10.core-backbone.com (2a01:4a0:1338:2::1) 30.063 ms 29.215 ms 36.436 ms > 6 ae2-2001.nbg30.core-backbone.com (2a01:4a0:0:2001::1) 32.540 ms 31.789 ms 51.790 ms > 7 ae1-2053.prg10.core-backbone.com (2a01:4a0:0:2053::22) 37.175 ms 36.355 ms 35.141 ms > 8 nix4-ipv6.pater.iol.cz (2001:7f8:14::29:1) 39.033 ms 36.891 ms 37.997 ms > 9 dynamic-2a00-1028-0001-0160-0000-0000-0000-0002.ipv6.broadband.iol.cz (2a00:1028:1:160::2) 38.403 ms 41.560 ms 37.239 ms > 10 dynamic-2a00-1028-0001-02a5-0000-0000-0000-0002.ipv6.broadband.iol.cz (2a00:1028:1:2a5::2) 37.214 ms 50.273 ms 51.604 ms > 11 * * * > 12 dynamic-2a00-1028-8d1c-90d8-0000-0000-0000-0001.ipv6.broadband.iol.cz (2a00:1028:8d1c:90d8::1) 44.291 ms 58.819 ms 49.810 ms > 13 * * * > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > [...] Are you by any chance filtering ICMPv6 on your ingress router? Regards, Peter. From ripe at brite.cz Sat Jan 19 17:23:04 2019 From: ripe at brite.cz (ripe at brite.cz) Date: Sat, 19 Jan 2019 17:23:04 +0100 Subject: [atlas] =?utf-8?q?IPv6_Doesn=27t_Work?= In-Reply-To: 00010000190e000ecf58046f8db8 References: 00010000190e000ecf58046f8db8 Message-ID: <20190119172304.73D48889@centrum.cz> No filtering here. Furthermore it seems the Atlas Probe is not able to get anywhere out via IPv6 too. I'm wondering is the Gateway setting correct? [Gateway(s) fe80::1] --------------------------------- Peter Eckel lists at eckel-edv.de Sat Jan 19 11:26:33 CET 2019 Hi Jiri, for me it looks like you're not reachable indeed: > pete at charon.net.hindenburgring.com> traceroute inet6 2a00:1028:8d1c:90da:220:4aff:fee0:2026 > traceroute6 to 2a00:1028:8d1c:90da:220:4aff:fee0:2026 (2a00:1028:8d1c:90da:220:4aff:fee0:2026) from , 64 hops max, 12 byte packets > [...] > 3 2a00:19e0:ffff:fffc::1 (2a00:19e0:ffff:fffc::1) 23.579 ms 23.308 ms 23.495 ms > 4 2a00:19e0:ffff:ffff::3 (2a00:19e0:ffff:ffff::3) 29.521 ms 29.738 ms 29.822 ms > 5 ae0-401.fra10.core-backbone.com (2a01:4a0:1338:2::1) 30.063 ms 29.215 ms 36.436 ms > 6 ae2-2001.nbg30.core-backbone.com (2a01:4a0:0:2001::1) 32.540 ms 31.789 ms 51.790 ms > 7 ae1-2053.prg10.core-backbone.com (2a01:4a0:0:2053::22) 37.175 ms 36.355 ms 35.141 ms > 8 nix4-ipv6.pater.iol.cz (2001:7f8:14::29:1) 39.033 ms 36.891 ms 37.997 ms > 9 dynamic-2a00-1028-0001-0160-0000-0000-0000-0002.ipv6.broadband.iol.cz (2a00:1028:1:160::2) 38.403 ms 41.560 ms 37.239 ms > 10 dynamic-2a00-1028-0001-02a5-0000-0000-0000-0002.ipv6.broadband.iol.cz (2a00:1028:1:2a5::2) 37.214 ms 50.273 ms 51.604 ms > 11 * * * > 12 dynamic-2a00-1028-8d1c-90d8-0000-0000-0000-0001.ipv6.broadband.iol.cz (2a00:1028:8d1c:90d8::1) 44.291 ms 58.819 ms 49.810 ms > 13 * * * > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > [...] Are you by any chance filtering ICMPv6 on your ingress router? Regards, Peter. From ripe at brite.cz Sat Jan 19 17:26:44 2019 From: ripe at brite.cz (ripe at brite.cz) Date: Sat, 19 Jan 2019 17:26:44 +0100 Subject: [atlas] =?utf-8?q?IPv6_Doesn=27t_Work?= In-Reply-To: 000000007e0700000990046f8d22 References: 000000007e0700000990046f8d22 Message-ID: <20190119172644.C0CDAF5B@centrum.cz> all the IPv6 traceroutes go like this: Latest Traceroute Result for Measurement #2009 2019-01-19 15:25 UTC Traceroute to 2001:503:ba3e::2:30 (2001:503:ba3e::2:30), 40 byte packets 1 * 2a00:1028:8d1c:90da:220:4aff:fee0:2026 dynamic-2a00-1028-8d1c-90da-0220-4aff-fee0-2026.ipv6.broadband.iol.cz AS5610 2191.889ms !H 3010.564ms !H ______________________________________________________________ > Od: ripe at brite.cz > Komu: ripe-atlas at ripe.net > Datum: 19.01.2019 17:23 > P?edm?t: Re: [atlas] IPv6 Doesn't Work > >No filtering here. Furthermore it seems the Atlas Probe is not able to get anywhere out via IPv6 too. >I'm wondering is the Gateway setting correct? [Gateway(s) fe80::1] > >--------------------------------- >Peter Eckel lists at eckel-edv.de >Sat Jan 19 11:26:33 CET 2019 > >Hi Jiri, > >for me it looks like you're not reachable indeed: > >> pete at charon.net.hindenburgring.com> traceroute inet6 2a00:1028:8d1c:90da:220:4aff:fee0:2026 >> traceroute6 to 2a00:1028:8d1c:90da:220:4aff:fee0:2026 (2a00:1028:8d1c:90da:220:4aff:fee0:2026) from , 64 hops max, 12 byte packets >> [...] >> 3 2a00:19e0:ffff:fffc::1 (2a00:19e0:ffff:fffc::1) 23.579 ms 23.308 ms 23.495 ms >> 4 2a00:19e0:ffff:ffff::3 (2a00:19e0:ffff:ffff::3) 29.521 ms 29.738 ms 29.822 ms >> 5 ae0-401.fra10.core-backbone.com (2a01:4a0:1338:2::1) 30.063 ms 29.215 ms 36.436 ms >> 6 ae2-2001.nbg30.core-backbone.com (2a01:4a0:0:2001::1) 32.540 ms 31.789 ms 51.790 ms >> 7 ae1-2053.prg10.core-backbone.com (2a01:4a0:0:2053::22) 37.175 ms 36.355 ms 35.141 ms >> 8 nix4-ipv6.pater.iol.cz (2001:7f8:14::29:1) 39.033 ms 36.891 ms 37.997 ms >> 9 dynamic-2a00-1028-0001-0160-0000-0000-0000-0002.ipv6.broadband.iol.cz (2a00:1028:1:160::2) 38.403 ms 41.560 ms 37.239 ms >> 10 dynamic-2a00-1028-0001-02a5-0000-0000-0000-0002.ipv6.broadband.iol.cz (2a00:1028:1:2a5::2) 37.214 ms 50.273 ms 51.604 ms >> 11 * * * >> 12 dynamic-2a00-1028-8d1c-90d8-0000-0000-0000-0001.ipv6.broadband.iol.cz (2a00:1028:8d1c:90d8::1) 44.291 ms 58.819 ms 49.810 ms >> 13 * * * >> 14 * * * >> 15 * * * >> 16 * * * >> 17 * * * >> 18 * * * >> 19 * * * >> [...] > >Are you by any chance filtering ICMPv6 on your ingress router? > >Regards, > > Peter. > > > From philip.homburg at ripe.net Mon Jan 21 12:05:25 2019 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 21 Jan 2019 12:05:25 +0100 Subject: [atlas] Probe firmware source code In-Reply-To: References: Message-ID: <6b2709e0-8611-df9f-2528-c784b5d57926@ripe.net> On 2019/01/13 16:41 , Evgeniy S. wrote: > thank you for helping I overlooked that information on website and > Github repository.? > > Btw, I see some discrepancy there (which can be improved): > 1) commit to?Gihub repository - last was Jun 14, 2018; > 2) listed firmware (last 4790 from Jun 27 2017) > on?https://atlas.ripe.net/resources/source-code/?page; > 3) actual firmware version we have installed on probes 4940 (I found no > way to fund when it was released and when probe was updated); Thank you for your interest in the measurement source code. Based on community feedback we switched from releasing tar-balls to publishing our git repository on github. However, this transition requires a bit more work: 1) The structure of the git repository needs to be improved. At the moment there is one branch per release. That should be switched to a release branch with tags. 2) It is not clear what should be done with the old tar files. Note that currently we publish only the measurement source code. We are working toward releasing the remaining code (a collection of shell scripts) as well to allow people to create software probes. The complete project for making software probes possible is more involved, it requires backend and procedural changes as well. Philip From sds at ripe.net Tue Jan 22 10:51:50 2019 From: sds at ripe.net (Stephen D. Strowes) Date: Tue, 22 Jan 2019 10:51:50 +0100 Subject: [atlas] IPv6 Doesn't Work In-Reply-To: <20190119172644.C0CDAF5B@centrum.cz> References: <20190119172644.C0CDAF5B@centrum.cz> Message-ID: <973782a7-d5c2-1bdf-0e96-a45c788b66d3@ripe.net> Hi, On 19/01/2019 17:26, ripe at brite.cz wrote: > Traceroute to 2001:503:ba3e::2:30 (2001:503:ba3e::2:30), 40 byte packets > 1 * 2a00:1028:8d1c:90da:220:4aff:fee0:2026 dynamic-2a00-1028-8d1c-90da-0220-4aff-fee0-2026.ipv6.broadband.iol.cz AS5610 2191.889ms !H 3010.564ms !H From `man traceroute6`: > !H? Address unreachable >? ????? The? host? address? is not reachable for some other reasons, particularly a link- >? ????? layer failure (e.g. Neighbor discovery failure). Obviously that's not great! The probe has a v6 address, so it's solicited and received some network config when it was booted or when your network config changed a couple days ago. Question is, what happened next. Guessing around the symptoms, if it's not receiving subsequent periodic RAs (either the router isn't sending them or something is preventing the probe from receiving them), then its local routing state will expire. Questions I'd try and answer are: when you connect a device to the same network, does it a) receive a v6 network & generate an address, then b) does v6 work immediately after that, and c) does it fail after a while? S. > > ______________________________________________________________ >> Od: ripe at brite.cz >> Komu: ripe-atlas at ripe.net >> Datum: 19.01.2019 17:23 >> P?edm?t: Re: [atlas] IPv6 Doesn't Work >> >> No filtering here. Furthermore it seems the Atlas Probe is not able to get anywhere out via IPv6 too. >> I'm wondering is the Gateway setting correct? [Gateway(s) fe80::1] >> >> --------------------------------- >> Peter Eckel lists at eckel-edv.de >> Sat Jan 19 11:26:33 CET 2019 >> >> Hi Jiri, >> >> for me it looks like you're not reachable indeed: >> >>> pete at charon.net.hindenburgring.com> traceroute inet6 2a00:1028:8d1c:90da:220:4aff:fee0:2026 >>> traceroute6 to 2a00:1028:8d1c:90da:220:4aff:fee0:2026 (2a00:1028:8d1c:90da:220:4aff:fee0:2026) from , 64 hops max, 12 byte packets >>> [...] >>> 3 2a00:19e0:ffff:fffc::1 (2a00:19e0:ffff:fffc::1) 23.579 ms 23.308 ms 23.495 ms >>> 4 2a00:19e0:ffff:ffff::3 (2a00:19e0:ffff:ffff::3) 29.521 ms 29.738 ms 29.822 ms >>> 5 ae0-401.fra10.core-backbone.com (2a01:4a0:1338:2::1) 30.063 ms 29.215 ms 36.436 ms >>> 6 ae2-2001.nbg30.core-backbone.com (2a01:4a0:0:2001::1) 32.540 ms 31.789 ms 51.790 ms >>> 7 ae1-2053.prg10.core-backbone.com (2a01:4a0:0:2053::22) 37.175 ms 36.355 ms 35.141 ms >>> 8 nix4-ipv6.pater.iol.cz (2001:7f8:14::29:1) 39.033 ms 36.891 ms 37.997 ms >>> 9 dynamic-2a00-1028-0001-0160-0000-0000-0000-0002.ipv6.broadband.iol.cz (2a00:1028:1:160::2) 38.403 ms 41.560 ms 37.239 ms >>> 10 dynamic-2a00-1028-0001-02a5-0000-0000-0000-0002.ipv6.broadband.iol.cz (2a00:1028:1:2a5::2) 37.214 ms 50.273 ms 51.604 ms >>> 11 * * * >>> 12 dynamic-2a00-1028-8d1c-90d8-0000-0000-0000-0001.ipv6.broadband.iol.cz (2a00:1028:8d1c:90d8::1) 44.291 ms 58.819 ms 49.810 ms >>> 13 * * * >>> 14 * * * >>> 15 * * * >>> 16 * * * >>> 17 * * * >>> 18 * * * >>> 19 * * * >>> [...] >> Are you by any chance filtering ICMPv6 on your ingress router? >> >> Regards, >> >> Peter. >> >> >> > From ripe at brite.cz Tue Jan 22 17:53:55 2019 From: ripe at brite.cz (ripe at brite.cz) Date: Tue, 22 Jan 2019 17:53:55 +0100 Subject: [atlas] =?utf-8?q?IPv6_Doesn=27t_Work?= In-Reply-To: 000000007e0f000017e0046f8d7c References: <20190119172644.C0CDAF5B@centrum.cz> 000000007e0f000017e0046f8d7c Message-ID: <20190122175355.2E29C9A4@centrum.cz> Hi, you pointed me to the right way. I enabled IPv6 on my Windows Laptop and it show the same symptoms - it receives an IPv6 address but is not able to reach any IPv6 target. My setup looks like this: Atlas Probe > Ubiquiti airRouter > provider's WIFI AP When I connect my laptop stright to the provider's WIFI AP then IPv6 works all fine. When I connect to LAN port of my airRouter, it receives an IPv6 address but is not able to reach any IPv6 target. So the point of failure seems to be my router. It is set to Bridge mode with WIFI as a client, connected to provider's AP. Per the Manual: ---------------------------------------------------------- Bridge In Bridge mode, the AirRouter forwards all network management and data packets from one network interface to the other without any intelligent routing. For simple applications this provides an efficient and fully transparent network solution. WLAN (wireless) and LAN (Ethernet) interfaces belong to the same network segment and share the same IP address space. WLAN and LAN interfaces form the virtual bridge interface while acting as the bridge ports. The bridge has assigned IP settings for management purposes. ---------------------------------------------------------- The Bridge management interface shows following addresses assigned: 10.0.0.29 2A00:1028:8D1C:90DA:DE9F:DBFF:FE5C:632B/64 FE80::DE9F:DBFF:FE5C:632B/64 I would think the Bridge mode should not interfere the traffic in any way. I have read only access to the provider's AP - it is cheap router with IPv4 NAT and IPv6 interfaces. It shows an IPv6 address [starting with 2a00:1028:] on its WAN IPv6, LAN IPv6, IPv6 Default Gateway, IPv6 DNS server, etc. As I said, when I connect laptop stright to the provider's AP, IPv6 works. I'm unable to to setup my airRouter for IPv6 to work. It supports IPv6, but in bridge mode it has no settings available. I tried multiple factory resets, with various settings, and also tried to switch the airRouter to SOHO Router mode, then there is IPv6 Enable checkbox. While it is checked, I tried various settings, such as SLAAC, DHCPv6, etc. No go. Looks the IPv6 support in this router is broken. It's a pity I cannot connect Atlas Probe v3 stright to the provider's WIFI eventhough it has WIFI hardware onboard. There is no way I could connect stright by LAN cable to the provider. It looks for now I have to leave the Probe live with IPv6 broken. Cheers Jiri ______________________________________________________________ > Od: "Stephen D. Strowes" > Komu: ripe at brite.cz, ripe-atlas at ripe.net > Datum: 22.01.2019 10:51 > P?edm?t: Re: [atlas] IPv6 Doesn't Work > >Hi, > >On 19/01/2019 17:26, ripe at brite.cz wrote: >> Traceroute to 2001:503:ba3e::2:30 (2001:503:ba3e::2:30), 40 byte packets >> 1 * 2a00:1028:8d1c:90da:220:4aff:fee0:2026 dynamic-2a00-1028-8d1c-90da-0220-4aff-fee0-2026.ipv6.broadband.iol.cz AS5610 2191.889ms !H 3010.564ms !H > > From `man traceroute6`: > > > !H? Address unreachable > >? ????? The? host? address? is not reachable for some other reasons, >particularly a link- > >? ????? layer failure (e.g. Neighbor discovery failure). > >Obviously that's not great! > >The probe has a v6 address, so it's solicited and received some network >config when it was booted or when your network config changed a couple >days ago. Question is, what happened next. > >Guessing around the symptoms, if it's not receiving subsequent periodic >RAs (either the router isn't sending them or something is preventing the >probe from receiving them), then its local routing state will expire. > >Questions I'd try and answer are: when you connect a device to the same >network, does it a) receive a v6 network & generate an address, then b) >does v6 work immediately after that, and c) does it fail after a while? > > >S. > > > > >> >> ______________________________________________________________ >>> Od: ripe at brite.cz >>> Komu: ripe-atlas at ripe.net >>> Datum: 19.01.2019 17:23 >>> P?edm?t: Re: [atlas] IPv6 Doesn't Work >>> >>> No filtering here. Furthermore it seems the Atlas Probe is not able to get anywhere out via IPv6 too. >>> I'm wondering is the Gateway setting correct? [Gateway(s) fe80::1] >>> >>> --------------------------------- >>> Peter Eckel lists at eckel-edv.de >>> Sat Jan 19 11:26:33 CET 2019 >>> >>> Hi Jiri, >>> >>> for me it looks like you're not reachable indeed: >>> >>>> pete at charon.net.hindenburgring.com> traceroute inet6 2a00:1028:8d1c:90da:220:4aff:fee0:2026 >>>> traceroute6 to 2a00:1028:8d1c:90da:220:4aff:fee0:2026 (2a00:1028:8d1c:90da:220:4aff:fee0:2026) from , 64 hops max, 12 byte packets >>>> [...] >>>> 3 2a00:19e0:ffff:fffc::1 (2a00:19e0:ffff:fffc::1) 23.579 ms 23.308 ms 23.495 ms >>>> 4 2a00:19e0:ffff:ffff::3 (2a00:19e0:ffff:ffff::3) 29.521 ms 29.738 ms 29.822 ms >>>> 5 ae0-401.fra10.core-backbone.com (2a01:4a0:1338:2::1) 30.063 ms 29.215 ms 36.436 ms >>>> 6 ae2-2001.nbg30.core-backbone.com (2a01:4a0:0:2001::1) 32.540 ms 31.789 ms 51.790 ms >>>> 7 ae1-2053.prg10.core-backbone.com (2a01:4a0:0:2053::22) 37.175 ms 36.355 ms 35.141 ms >>>> 8 nix4-ipv6.pater.iol.cz (2001:7f8:14::29:1) 39.033 ms 36.891 ms 37.997 ms >>>> 9 dynamic-2a00-1028-0001-0160-0000-0000-0000-0002.ipv6.broadband.iol.cz (2a00:1028:1:160::2) 38.403 ms 41.560 ms 37.239 ms >>>> 10 dynamic-2a00-1028-0001-02a5-0000-0000-0000-0002.ipv6.broadband.iol.cz (2a00:1028:1:2a5::2) 37.214 ms 50.273 ms 51.604 ms >>>> 11 * * * >>>> 12 dynamic-2a00-1028-8d1c-90d8-0000-0000-0000-0001.ipv6.broadband.iol.cz (2a00:1028:8d1c:90d8::1) 44.291 ms 58.819 ms 49.810 ms >>>> 13 * * * >>>> 14 * * * >>>> 15 * * * >>>> 16 * * * >>>> 17 * * * >>>> 18 * * * >>>> 19 * * * >>>> [...] >>> Are you by any chance filtering ICMPv6 on your ingress router? >>> >>> Regards, >>> >>> Peter. >>> >>> >>> >> > > From christopher.morrow at gmail.com Wed Jan 23 05:48:04 2019 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Tue, 22 Jan 2019 23:48:04 -0500 Subject: [atlas] Probe questions - reporting clearly busticated probe configs? In-Reply-To: <05a44c45-cece-0561-e2aa-61a1904ea6bf@ripe.net> References: <8CE68A0B-52A3-47B7-973A-066055732E96@puck.nether.net> <05a44c45-cece-0561-e2aa-61a1904ea6bf@ripe.net> Message-ID: On Fri, Jan 18, 2019 at 5:40 AM Chris Amin wrote: > Hi Christopher, > > On 16/01/2019 20:18, Christopher Morrow wrote: > > > > hey wait.... The first of my examples: > > https://atlas.ripe.net/probes/26725/#!tab-general > > > > > > has: > > System TagsV3 Resolves A Correctly Resolves AAAA Correctly IPv4 Works > > IPv6 Works IPv4 Capable IPv6 Capable IPv4 RFC1918 IPv4 Stable 90d > > > > suspiciously: "system-ipv6-works" is in that list... even though the v6 > > address is: > > 2001:db8:4447:0:eade:27ff:fec9:7134/64 > > This probe has the "system-ipv6-works" tag because it can successfully > ping at least one IPv6 target. You can see at > https://atlas.ripe.net/probes/26725/#!tab-builtins that it can in fact > reach a number of IPv6 targets. > > Note that the probe host for 26725 has tagged the probe as "IPv6NAT", > maybe this explains the discrepancy you are seeing? > oh nat in v6 .. of course :( I thought the whole point of v6 was to not have nat, joy! ok, you're probably 100% correct. #learningalways. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Chown at jisc.ac.uk Wed Jan 23 10:52:19 2019 From: Tim.Chown at jisc.ac.uk (Tim Chown) Date: Wed, 23 Jan 2019 09:52:19 +0000 Subject: [atlas] Probe questions - reporting clearly busticated probe configs? In-Reply-To: References: <8CE68A0B-52A3-47B7-973A-066055732E96@puck.nether.net> <05a44c45-cece-0561-e2aa-61a1904ea6bf@ripe.net> Message-ID: <8D124D9E-1BA5-44EC-B579-998293695315@jisc.ac.uk> > On 23 Jan 2019, at 04:48, Christopher Morrow wrote: > > On Fri, Jan 18, 2019 at 5:40 AM Chris Amin wrote: > Hi Christopher, > > On 16/01/2019 20:18, Christopher Morrow wrote: > > > > hey wait.... The first of my examples: > > https://atlas.ripe.net/probes/26725/#!tab-general > > > > > > has: > > System TagsV3 Resolves A Correctly Resolves AAAA Correctly IPv4 Works > > IPv6 Works IPv4 Capable IPv6 Capable IPv4 RFC1918 IPv4 Stable 90d > > > > suspiciously: "system-ipv6-works" is in that list... even though the v6 > > address is: > > 2001:db8:4447:0:eade:27ff:fec9:7134/64 > > This probe has the "system-ipv6-works" tag because it can successfully > ping at least one IPv6 target. You can see at > https://atlas.ripe.net/probes/26725/#!tab-builtins that it can in fact > reach a number of IPv6 targets. > > Note that the probe host for 26725 has tagged the probe as "IPv6NAT", > maybe this explains the discrepancy you are seeing? > > oh nat in v6 .. of course :( > I thought the whole point of v6 was to not have nat, joy! > ok, you're probably 100% correct. > #learningalways. It may be NPTv6, rather than NATv6, but .... Tim From gert at space.net Wed Jan 23 10:55:33 2019 From: gert at space.net (Gert Doering) Date: Wed, 23 Jan 2019 10:55:33 +0100 Subject: [atlas] Probe questions - reporting clearly busticated probe configs? In-Reply-To: <8D124D9E-1BA5-44EC-B579-998293695315@jisc.ac.uk> References: <8CE68A0B-52A3-47B7-973A-066055732E96@puck.nether.net> <05a44c45-cece-0561-e2aa-61a1904ea6bf@ripe.net> <8D124D9E-1BA5-44EC-B579-998293695315@jisc.ac.uk> Message-ID: <20190123095533.GC1543@Space.Net> Hi, On Wed, Jan 23, 2019 at 09:52:19AM +0000, Tim Chown wrote: > It may be NPTv6, rather than NATv6, but .... https://www.youtube.com/watch?v=v26BAlfWBm8 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer 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: 833 bytes Desc: not available URL: From christopher.morrow at gmail.com Wed Jan 23 16:38:52 2019 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 23 Jan 2019 10:38:52 -0500 Subject: [atlas] Probe questions - reporting clearly busticated probe configs? In-Reply-To: <20190123095533.GC1543@Space.Net> References: <8CE68A0B-52A3-47B7-973A-066055732E96@puck.nether.net> <05a44c45-cece-0561-e2aa-61a1904ea6bf@ripe.net> <8D124D9E-1BA5-44EC-B579-998293695315@jisc.ac.uk> <20190123095533.GC1543@Space.Net> Message-ID: On Wed, Jan 23, 2019 at 4:55 AM Gert Doering wrote: > Hi, > > On Wed, Jan 23, 2019 at 09:52:19AM +0000, Tim Chown wrote: > > It may be NPTv6, rather than NATv6, but .... > > https://www.youtube.com/watch?v=v26BAlfWBm8 > > 'yer killin me smalls' :) (I think the overall problem I have is figuring out all the 'random' filtering options, which is something shiould have spent more time figuring out :( ha! also, still love this video, thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.morrow at gmail.com Thu Jan 24 06:39:49 2019 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Thu, 24 Jan 2019 00:39:49 -0500 Subject: [atlas] Making a bunch of tests/measurements to a single destination is 'tedious' Message-ID: howdy! So, if I have a dns server somewhere and I want to make a bunch of measurements: "how does NYC see my dns?" (pick N probes near NYC) "How does DEN see my dns?" (pick N probes near DEN) "How does LHR see my dns?" (pick N probes near LHR) "how does ...." ...you get the idea... I'm trying to characterize my service from a 'user' perspective by large Metropolis, well within N km of that metropolis anyway :) but across ~70 or so metros, in v4 and v6 and with authoritative and non-authoritative queries with each test running for 4 days so i can see some daily cycles in traffic patterns/etc. The number of measurements is large in total, breaking up by 3-4 metropolis chunks is super tedious :( Can I request an API key (or some other thing) which can make that sort of request happen for all my measurements in one go? The thing I'm probing is very able to handle a few extra thousand queries per second.. and I'd only be hurting myself i get my estimate wrong :) thanks! -chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Thu Jan 24 09:41:21 2019 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 24 Jan 2019 09:41:21 +0100 Subject: [atlas] Making a bunch of tests/measurements to a single destination is 'tedious' In-Reply-To: References: Message-ID: On 2019-01-24 06:39, Christopher Morrow wrote: > howdy! > So, if I have a dns server somewhere and I want to make a bunch of > measurements: > ? "how does NYC see my dns?" (pick N probes near NYC) > ? "How does DEN see my dns?" (pick N probes near DEN) > ? "How does LHR see my dns?" (pick N probes near LHR) > ? "how does ...."? > > ...you get the idea... I'm trying to characterize my service from a > 'user' perspective by large Metropolis, well within N km of that > metropolis anyway :) but across ~70 or so metros, in v4 and v6 and with > authoritative and non-authoritative queries with each test running for 4 > days so i can see some daily cycles in traffic patterns/etc. The number > of measurements is large in total, breaking up by 3-4 metropolis chunks > is super tedious :( > > Can I request an API key (or some other thing) which can make that sort > of request happen for all my measurements in one go? The thing I'm > probing is very able to handle a few extra thousand queries per second.. > and I'd only be hurting myself i get my estimate wrong :) > > thanks! > -chris Hi, Note taht we have a large amount of measurements already against 8.8.8.8, 1.1.1.1 and such, perhaps reusing data from these is an option? (I'd be particularly happy if it was, since one of the very reasons we wanted to make this whole network really open is to be able to reuse data from others' measurements.) If that's not possible, then I'd advise you to run a small script that issues a measurement request and parametrises it with cantage point / target pairs, and use an API key for it. Perhaps also ask for a quota increase first :-) Cheers, Robert From shane at time-travellers.org Thu Jan 24 09:52:38 2019 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 24 Jan 2019 09:52:38 +0100 Subject: [atlas] Making a bunch of tests/measurements to a single destination is 'tedious' In-Reply-To: References: Message-ID: <5fcad8e8-1a49-7132-a239-c97d1654bac3@time-travellers.org> Chris, On 24/01/2019 06.39, Christopher Morrow wrote: > howdy! > So, if I have a dns server somewhere and I want to make a bunch of > measurements: > ? "how does NYC see my dns?" (pick N probes near NYC) > ? "How does DEN see my dns?" (pick N probes near DEN) > ? "How does LHR see my dns?" (pick N probes near LHR) > ? "how does ...." > > ...you get the idea... I'm trying to characterize my service from a > 'user' perspective by large Metropolis, well within N km of that > metropolis anyway :) but across ~70 or so metros, in v4 and v6 and with > authoritative and non-authoritative queries with each test running for 4 > days so i can see some daily cycles in traffic patterns/etc. The number > of measurements is large in total, breaking up by 3-4 metropolis chunks > is super tedious :( > > Can I request an API key (or some other thing) which can make that sort > of request happen for all my measurements in one go? The thing I'm > probing is very able to handle a few extra thousand queries per second.. > and I'd only be hurting myself i get my estimate wrong :) I was part of a team on a hackathon a while back which needed to compute distances between points on the globe, including Atlas probes: https://github.com/shane-kerr/ripe-atlas-anycast-work I see that the openflights project has since moved to GitHub, and so you can get the IATA airport data here: https://github.com/jpatokal/openflights/blob/master/data/airports.dat I guess I should update the README.md... The repository is basically a last-point-in-time snapshot of the hackathon work, so it a bit rough. ? Anyway, this code is probably the closest to what you want: https://github.com/shane-kerr/ripe-atlas-anycast-work/blob/master/add-dist.py Turning the great_circle_dist() function into a filter across the set of all probes (meta-probes.json, which you can download in advance) should get you something like what you want. Note that this was all done 4 years ago according to GitHub, so maybe Atlas provides better tools for this nowadays. ? Cheers, -- Shane From adavies at ripe.net Thu Jan 24 10:45:51 2019 From: adavies at ripe.net (Alun Davies) Date: Thu, 24 Jan 2019 10:45:51 +0100 Subject: [atlas] New on RIPE Labs: RIPE Atlas Anchors 400+ Message-ID: <63F18ABC-3217-456B-972C-DB284CC1C81B@ripe.net> Dear colleagues, We have published an article looking at how the quick uptake in RIPE Atlas VM anchors and other developments have helped us hit 400 connected anchors. https://labs.ripe.net/Members/alun_davies/ripe-atlas-anchors-400 Kind regards, Alun Davies RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2627 bytes Desc: not available URL: From christopher.morrow at gmail.com Thu Jan 24 16:42:09 2019 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Thu, 24 Jan 2019 10:42:09 -0500 Subject: [atlas] Making a bunch of tests/measurements to a single destination is 'tedious' In-Reply-To: <5fcad8e8-1a49-7132-a239-c97d1654bac3@time-travellers.org> References: <5fcad8e8-1a49-7132-a239-c97d1654bac3@time-travellers.org> Message-ID: On Thu, Jan 24, 2019 at 3:52 AM Shane Kerr wrote: > Chris, > > On 24/01/2019 06.39, Christopher Morrow wrote: > > howdy! > > So, if I have a dns server somewhere and I want to make a bunch of > > measurements: > > "how does NYC see my dns?" (pick N probes near NYC) > > "How does DEN see my dns?" (pick N probes near DEN) > > "How does LHR see my dns?" (pick N probes near LHR) > > "how does ...." > > > > ...you get the idea... I'm trying to characterize my service from a > > 'user' perspective by large Metropolis, well within N km of that > > metropolis anyway :) but across ~70 or so metros, in v4 and v6 and with > > authoritative and non-authoritative queries with each test running for 4 > > days so i can see some daily cycles in traffic patterns/etc. The number > > of measurements is large in total, breaking up by 3-4 metropolis chunks > > is super tedious :( > > > > Can I request an API key (or some other thing) which can make that sort > > of request happen for all my measurements in one go? The thing I'm > > probing is very able to handle a few extra thousand queries per second.. > > and I'd only be hurting myself i get my estimate wrong :) > > I was part of a team on a hackathon a while back which needed to compute > distances between points on the globe, including Atlas probes: > > https://github.com/shane-kerr/ripe-atlas-anycast-work > > I see that the openflights project has since moved to GitHub, and so you > can get the IATA airport data here: > > https://github.com/jpatokal/openflights/blob/master/data/airports.dat > > The geo data wasn't problematic for me, once I found: github.com/kelvins/geocoder which apparently uses: https://raw.githubusercontent.com/jpatokal/openflights/master/data/airports.dat oh hai! It looks like I didn't do it the 'insane way', mostly :) (I should make the repository of code I wrote available, oops) I guess I should update the README.md... > > The repository is basically a last-point-in-time snapshot of the > hackathon work, so it a bit rough. ? Anyway, this code is probably the > closest to what you want: > > > https://github.com/shane-kerr/ripe-atlas-anycast-work/blob/master/add-dist.py > > i think you are just sorting through measurement response data to find things near/around/at your points of interest here, right? that seems useful. > Turning the great_circle_dist() function into a filter across the set of > all probes (meta-probes.json, which you can download in advance) should > get you something like what you want. > > looks neat ;) > Note that this was all done 4 years ago according to GitHub, so maybe > Atlas provides better tools for this nowadays. ? > > they do have a method to request probes based on geo data and a radius from that point, which is what I am doing. They also have filters (which I've apparently sucked at reading completely!) to limit based on type/ip-version/activity/etc. mostly you can query for: "probes near here with these sets of attributes" which works pretty well ;) my main problem was/is (I think) that I want to say: "For these M metros, please find 10 (or so) probes with working address family (v4||v6) and probe dns server (V4||V6 address) with a (non-)authoritative request" my M number is ~70+. I didn't want (for some reason?) to try and gather the probes across the globe into less measurements but more probes... huh, I could try that I guess, then I'd only have 4 measurements not M*4. Cheers, > > -- > Shane > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.morrow at gmail.com Thu Jan 24 17:19:00 2019 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Thu, 24 Jan 2019 11:19:00 -0500 Subject: [atlas] Making a bunch of tests/measurements to a single destination is 'tedious' In-Reply-To: References: Message-ID: On Thu, Jan 24, 2019 at 3:41 AM Robert Kisteleki wrote: > > > On 2019-01-24 06:39, Christopher Morrow wrote: > > howdy! > > So, if I have a dns server somewhere and I want to make a bunch of > > measurements: > > "how does NYC see my dns?" (pick N probes near NYC) > > "How does DEN see my dns?" (pick N probes near DEN) > > "How does LHR see my dns?" (pick N probes near LHR) > > "how does ...." > > > > ...you get the idea... I'm trying to characterize my service from a > > 'user' perspective by large Metropolis, well within N km of that > > metropolis anyway :) but across ~70 or so metros, in v4 and v6 and with > > authoritative and non-authoritative queries with each test running for 4 > > days so i can see some daily cycles in traffic patterns/etc. The number > > of measurements is large in total, breaking up by 3-4 metropolis chunks > > is super tedious :( > > > > Can I request an API key (or some other thing) which can make that sort > > of request happen for all my measurements in one go? The thing I'm > > probing is very able to handle a few extra thousand queries per second.. > > and I'd only be hurting myself i get my estimate wrong :) > > > > thanks! > > -chris > > Hi, > > Note taht we have a large amount of measurements already against > 8.8.8.8, 1.1.1.1 and such, perhaps reusing data from these is an option? > perhaps. I can go digging. i was/am particularly interested in performance for v4/v6 cached/not from the same vantage point at as nearly the same time. I didn't think that was going to be fruitful in searching existing measurements :( I should have taken a bit longer to dig though. > (I'd be particularly happy if it was, since one of the very reasons we > wanted to make this whole network really open is to be able to reuse > data from others' measurements.) > > If that's not possible, then I'd advise you to run a small script that > issues a measurement request and parametrises it with cantage point / > target pairs, and use an API key for it. Perhaps also ask for a quota > increase first :-) > I have this script, but I need to have something that runs over many days (or maintains state) and issues the measurements at a pace which maximizes my measurement speed and minimizes my inolvement :) It wasn't apparent that the restriction I'm seeing is 'per api key', I thought it was 'per target'. > > Cheers, > Robert > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rami.dalky at gmail.com Mon Jan 28 14:33:11 2019 From: rami.dalky at gmail.com (Rami Al-Dalky) Date: Mon, 28 Jan 2019 08:33:11 -0500 Subject: [atlas] EDNS Client Subnet Message-ID: Hello, I was exploring the possibility of using RIPE Atlas probes to do some study on EDNS Client Subnet (ECS), however, the way it is implemented on the probes makes it less interesting. When I tried to create a DNS measurement, I found that the only way to send DNS query with option is to set default_client_subnet to True. However, by setting this option, a DNS query will be sent with 0.0.0.0/0 as client subnet. According to the RFC, a compliant resolver which receives such content SHOULD NOT forward the client IP to the Auth. DNS server (which the same behavior when you set the flag to False). That's make it impossible to study the protocol from Auth. DNS perspective. Is there a reason why ECS is implemented that way? If it for privacy issue, the RFC recommends to sent the client IP with /24 prefix for IPv4 and /56 for IPv6 to preserve the privacy. Thanks in advance! Rami -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Mon Jan 28 14:41:34 2019 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 28 Jan 2019 14:41:34 +0100 Subject: [atlas] EDNS Client Subnet In-Reply-To: References: Message-ID: On 2019/01/28 14:33 , Rami Al-Dalky wrote: > When I tried to create a DNS measurement, I found that the only way to > send DNS query with option is to set default_client_subnet to True. > However, by setting this option, a DNS query will be sent with 0.0.0.0/0 > as client subnet.? > > Is there a reason why ECS is implemented that way? If it for privacy > issue, the RFC recommends to sent the client IP with /24 prefix for IPv4 > and /56 for IPv6 to preserve the privacy. Let me point out that we chose 0.0.0.0/0 to avoid all privacy issues. The recommendation just reduces privacy issues. At the same time, it was not clear to us what additional benefit it would bring to RIPE Atlas measurements to include longer prefixes. In particular, we assumed that the main purpose of this option would be to measure interference by firewalls or other middle boxes. Philip From pmaechler at glattwerk.ch Mon Jan 28 14:50:02 2019 From: pmaechler at glattwerk.ch (=?UTF-8?Q?Philippe_M=c3=a4chler?=) Date: Mon, 28 Jan 2019 14:50:02 +0100 Subject: [atlas] DNSEC Tag for Probes Message-ID: <1f4fcbef-a2fe-7586-bd09-8cfbafcf2b2e@glattwerk.ch> Hello RIPE Atlas Users I?d like to some measurements about DNSSEC with RIPE Atlas and need a way to check if the probe does DNSSEC validation The docs mention the system-tags e.g resolvs A and resolvs AAAA. Is there something like ?system: does DNSSEC validation? if not, is there any other way or is this on the roadmap? ? Freundliche Gr?sse / best regards Philippe M?chler From rami.dalky at gmail.com Mon Jan 28 15:13:00 2019 From: rami.dalky at gmail.com (Rami Al-Dalky) Date: Mon, 28 Jan 2019 09:13:00 -0500 Subject: [atlas] EDNS Client Subnet In-Reply-To: References: Message-ID: On Mon, Jan 28, 2019, 8:41 AM Philip Homburg On 2019/01/28 14:33 , Rami Al-Dalky wrote: > > When I tried to create a DNS measurement, I found that the only way to > > send DNS query with option is to set default_client_subnet to True. > > However, by setting this option, a DNS query will be sent with 0.0.0.0/0 > > as client subnet. > > > > Is there a reason why ECS is implemented that way? If it for privacy > > issue, the RFC recommends to sent the client IP with /24 prefix for IPv4 > > and /56 for IPv6 to preserve the privacy. > > Let me point out that we chose 0.0.0.0/0 to avoid all privacy issues. > The recommendation just reduces privacy issues. > Right. However, recursive resolvers already have access to end-user IP address and there is no evidence whether or not they preserve the privacy of those queries (by sharing them with third party). If we talk about preserve the end-user privacy from Auth. DNS, those clients will eventually contact the content server (for instance, HTTP server) which would have access to the end-user IP. So there an arguement that someone can make. If we talk about the privacy of the probes, I can't see how sending the probe's /24 would violate the privacy of the probes (anyone can harvest the public IP addresses of the probes). > > At the same time, it was not clear to us what additional benefit it > would bring to RIPE Atlas measurements to include longer prefixes. In > particular, we assumed that the main purpose of this option would be to > measure interference by firewalls or other middle boxes. One could study the behavior of different components in DNS ecosystem (for instance, recursive resolvers or Auth. DNS) with this option. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugh at wherenow.org Wed Jan 30 16:50:37 2019 From: hugh at wherenow.org (Hugh Saunders) Date: Wed, 30 Jan 2019 15:50:37 +0000 Subject: [atlas] Probe v1 disconnecting every 2 hours Message-ID: Hey All, My probe v1 (id:65[1]) has started disconnecting roughly every 2 hours. I read a previous post[2] that said this may be related to power, so changed the USB power supply to one that provides 1A (the FAQ says the need 500ma) but no improvement. I don't notice connectivity issues every couple of hours with any other devices on the same switch. Any suggestions welcome :) Thanks. [1] https://atlas.ripe.net/probes/65/ [2] https://www.ripe.net/participate/mail/forum/ripe-atlas/PDI1MDc1YjM1LTA5MTctOGYyNS05MGMzLWM1YmFiZjNmNTY4NEBzb2tvbG92LmV1Lm9yZz4= -- Hugh Saunders -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.morrow at gmail.com Wed Jan 30 18:04:45 2019 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 30 Jan 2019 09:04:45 -0800 Subject: [atlas] Probe v1 disconnecting every 2 hours In-Reply-To: References: Message-ID: maybe the flash card is going sad? and just doing the proscribed :"get new card, power down, swap card, wait for 30 mins, profit" will make things happy again? worse case it costs you a 4g flash card :) On Wed, Jan 30, 2019 at 7:51 AM Hugh Saunders wrote: > Hey All, > My probe v1 (id:65[1]) has started disconnecting roughly every 2 hours. I > read a previous post[2] that said this may be related to power, so changed > the USB power supply to one that provides 1A (the FAQ says the need 500ma) > but no improvement. I don't notice connectivity issues every couple of > hours with any other devices on the same switch. > > Any suggestions welcome :) > > Thanks. > > [1] https://atlas.ripe.net/probes/65/ > [2] > https://www.ripe.net/participate/mail/forum/ripe-atlas/PDI1MDc1YjM1LTA5MTctOGYyNS05MGMzLWM1YmFiZjNmNTY4NEBzb2tvbG92LmV1Lm9yZz4= > > -- > Hugh Saunders > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed Jan 30 18:16:30 2019 From: gert at space.net (Gert Doering) Date: Wed, 30 Jan 2019 18:16:30 +0100 Subject: [atlas] Probe v1 disconnecting every 2 hours In-Reply-To: References: Message-ID: <20190130171630.GV1543@Space.Net> Hi, On Wed, Jan 30, 2019 at 09:04:45AM -0800, Christopher Morrow wrote: > maybe the flash card is going sad? and just doing the proscribed :"get new > card, power down, swap card, wait for 30 mins, profit" will make things > happy again? > worse case it costs you a 4g flash card :) v1 probes do not have USB flash yet - which is good, because that particular annoyance doesn't happen :-) OTOH, it might be just dieing of old age, after like 8-9 years. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer 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: 833 bytes Desc: not available URL: From christopher.morrow at gmail.com Wed Jan 30 19:08:54 2019 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 30 Jan 2019 10:08:54 -0800 Subject: [atlas] Probe v1 disconnecting every 2 hours In-Reply-To: <20190130171630.GV1543@Space.Net> References: <20190130171630.GV1543@Space.Net> Message-ID: On Wed, Jan 30, 2019 at 9:16 AM Gert Doering wrote: > Hi, > > On Wed, Jan 30, 2019 at 09:04:45AM -0800, Christopher Morrow wrote: > > maybe the flash card is going sad? and just doing the proscribed :"get > new > > card, power down, swap card, wait for 30 mins, profit" will make things > > happy again? > > worse case it costs you a 4g flash card :) > > v1 probes do not have USB flash yet - which is good, because that > particular annoyance doesn't happen :-) > > oh, bummer :( also good... sort of :) > OTOH, it might be just dieing of old age, after like 8-9 years. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael > Emmer > 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 -------------- An HTML attachment was scrubbed... URL: From ckeck at texoma.net Wed Jan 30 19:49:31 2019 From: ckeck at texoma.net (Cornelius Keck) Date: Wed, 30 Jan 2019 12:49:31 -0600 Subject: [atlas] Probe v1 disconnecting every 2 hours In-Reply-To: <20190130171630.GV1543@Space.Net> References: <20190130171630.GV1543@Space.Net> Message-ID: Mine has been acting up lately as well. Changed the router (no dice), ethernet cable (likewise), then the power supply, which improved matters quite some until earlier today. Right now it's still down, despite the router it is hooked up to functioning as it should. It has been up close to eight years. Going to change routers again tonight when I get home (5 static IPs, 5 routers, so there are options). I'm wondering, in case the probe continues to have issues, is there a way to get a replacement? Or, come to think of it, replace the probe with some code on smallish hardware, like a Raspberry Pi? Thx! -Cornelius Gert Doering wrote: > Hi, > > On Wed, Jan 30, 2019 at 09:04:45AM -0800, Christopher Morrow wrote: >> maybe the flash card is going sad? and just doing the proscribed :"get new >> card, power down, swap card, wait for 30 mins, profit" will make things >> happy again? >> worse case it costs you a 4g flash card :) > > v1 probes do not have USB flash yet - which is good, because that > particular annoyance doesn't happen :-) > > OTOH, it might be just dieing of old age, after like 8-9 years. > > Gert Doering > -- NetMaster > From philip.homburg at ripe.net Wed Jan 30 21:00:50 2019 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 30 Jan 2019 21:00:50 +0100 Subject: [atlas] Probe v1 disconnecting every 2 hours In-Reply-To: References: <20190130171630.GV1543@Space.Net> Message-ID: On 2019/01/30 19:49 , Cornelius Keck wrote: > I'm wondering, in case the probe continues to have issues, is there a > way to get a replacement? Yes, you can always ask for a replacement. We are still quite a bit behind in shipping probes because the transition from v3 to v4 probes was quite a bit of work. > Or, come to think of it, replace the probe > with some code on smallish hardware, like a Raspberry Pi? We are looking into this. There is no timeline, or even a commitment to provide this option. But we are actively preparing for a pilot. Philip From philip.homburg at ripe.net Thu Jan 31 14:16:27 2019 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 31 Jan 2019 14:16:27 +0100 Subject: [atlas] Bug in DNS client subnet measurement Message-ID: Hi, We got a bug report that using the DNS client subnet option in a measurement results in a form error. It turns out that probe firmware version 4940 will send a malformed DNS query. Code cleanup related to other changes fixes this issue in the upcoming firmware. We expect to release the new firmware in about one month from now. Philip From eject.in.ua at gmail.com Thu Jan 31 14:23:15 2019 From: eject.in.ua at gmail.com (Evgeniy S.) Date: Thu, 31 Jan 2019 14:23:15 +0100 Subject: [atlas] Columns in Web UI for measurement results can't be sorted Message-ID: Hi, I can't sort by any column in measurement results for traceroute (worked before by mouse click). [image: Screen Shot 2019-01-31 at 2.14.52 PM.png] There is my measurement results page short link https://goo.gl/iQrxWC -- -- With regards, Eugene Sudyr -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2019-01-31 at 2.14.52 PM.png Type: image/png Size: 103400 bytes Desc: not available URL: From kyle.schomp at gmail.com Thu Jan 31 14:23:49 2019 From: kyle.schomp at gmail.com (Kyle Schomp) Date: Thu, 31 Jan 2019 13:23:49 +0000 Subject: [atlas] EDNS Client Subnet In-Reply-To: References: Message-ID: On Mon, Jan 28, 2019 at 1:41 PM Philip Homburg wrote: > On 2019/01/28 14:33 , Rami Al-Dalky wrote: > > When I tried to create a DNS measurement, I found that the only way to > > send DNS query with option is to set default_client_subnet to True. > > However, by setting this option, a DNS query will be sent with 0.0.0.0/0 > > as client subnet. > > > > Is there a reason why ECS is implemented that way? If it for privacy > > issue, the RFC recommends to sent the client IP with /24 prefix for IPv4 > > and /56 for IPv6 to preserve the privacy. > > Let me point out that we chose 0.0.0.0/0 to avoid all privacy issues. > The recommendation just reduces privacy issues. > > What privacy issues are concerned when allowing a measurement creator to specify an ECS value that the probe should send along with DNS queries? Is it that some actors on the Internet might assume that the arbitrary ECS value actually originated the DNS query without any validation? I think this becomes a non-issue if you restrict the ECS prefix length to something sane like <=24. > At the same time, it was not clear to us what additional benefit it > would bring to RIPE Atlas measurements to include longer prefixes. In > particular, we assumed that the main purpose of this option would be to > measure interference by firewalls or other middle boxes. > > I think the benefit here is somewhat clear for measuring the behavior of recursive resolvers and authoritative nameservers when ECS data is present. > Philip > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adavies at ripe.net Thu Jan 31 14:55:24 2019 From: adavies at ripe.net (Alun Davies) Date: Thu, 31 Jan 2019 14:55:24 +0100 Subject: [atlas] New RIPE Atlas measurement details page Message-ID: Dear colleagues, We have made the switch to the new and improved user interface for RIPE Atlas measurement details. To see the new interface right now, simply click on any measurement ID on the RIPE Atlas measurement listing page: https://atlas.ripe.net/measurements/ Please note that, for a limited time, you will still be able to revert back to the old interface via the yellow banner at the top of the measurement details page. For further details on exactly what changes have been made and why, please see the following article on RIPE Labs: https://labs.ripe.net/Members/jasper_den_hertog/new-design-and-functionality-for-the-ripe-atlas-measurement-detail-page Kind regards, Alun Davies RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2627 bytes Desc: not available URL: From gboonie at gmail.com Thu Jan 31 20:04:52 2019 From: gboonie at gmail.com (Dave .) Date: Thu, 31 Jan 2019 20:04:52 +0100 Subject: [atlas] New RIPE Atlas measurement details page In-Reply-To: References: Message-ID: Hi, The traceroutes give a nice list like a normal traceroute would do when clicking on the blue i-icon. Could we get such a button for DNS tests? I'd like to be able to see the full result from the web page, just like for traceroute. Thanks, Dave Op do 31 jan. 2019 om 14:55 schreef Alun Davies : > Dear colleagues, > > We have made the switch to the new and improved user interface for RIPE > Atlas measurement details. To see the new interface right now, simply click > on any measurement ID on the RIPE Atlas measurement listing page: > https://atlas.ripe.net/measurements/ > > Please note that, for a limited time, you will still be able to revert > back to the old interface via the yellow banner at the top of the > measurement details page. > > For further details on exactly what changes have been made and why, please > see the following article on RIPE Labs: > > https://labs.ripe.net/Members/jasper_den_hertog/new-design-and-functionality-for-the-ripe-atlas-measurement-detail-page > > Kind regards, > Alun Davies > RIPE NCC > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: