[atlas] Wohoo: Your RIPE Atlas Probe (ID: 12724) has reconnected

[Gert Doering]

Hi,

wohoo, "I'm back" notifications!!

Thanks very much to whoever silently implemented this :-)  (this was a
provider outage, and the probe was indeed offline and came back, so
when I got up I found the "it's back, all is well" note already in
my mail).

If you're bored and want to optimize this: add an "In-Reply-To:" to the
original "it's gone"-mail, so there is threading (in case you only see
the original mail when it's already back)...

cheers,

gert
- Forwarded message from RIPE Atlas  -

Date: Tue, 09 Apr 2024 05:00:00 -
From: RIPE Atlas 
To: g...@space.net
Subject: Your RIPE Atlas Probe (ID: 12724) has reconnected

Dear RIPE Atlas probe host,

We're just letting you know that your probe (#12724 ) has re-established its 
link to our network and we are again receiving data from it. For your own 
records, it appears that the reconnection took place at .

If you have any questions, please contact us at at...@ripe.net. Thank you for 
supporting RIPE Atlas. 

Best regards,

RIPE Atlas Team

**
You can change your notification settings on your probe page (go to "My Atlas" 
and then "Probes" when logged into the RIPE Atlas website).

- End forwarded message -


-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard,
   Ingo Lalla, Karin Schuler
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] IP & MAC

[Gert Doering]

Hi,

On Tue, Mar 05, 2024 at 08:35:42AM -0800, Randy Bush wrote:
> i have a remote probe.  on the web gui, how can i see what its lan
> address (it is behind a soho nat) and mac are?  i thought i knew how
> to do this, but the moon must be in klutz.

The "Network" tab on the probe has the LAN IP address ("Local Address"),
the "General" Tab has the MAC Address.

Unfortunately, as far as I can see, this seems to be only visible
for your own probes (and you need to be logged in).

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer,
   Ingo Lalla, Karin Schuler
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] auto probe renewal

[Gert Doering]

Hi,

On Tue, Dec 12, 2023 at 01:42:58PM +0100, Robert Kisteleki wrote:
> We started working on a feature where you'll be able to ask the system
> itself to remove disconnected probes, and to "top it up" with other probes
> (similar to the original ones.

Cool :-)

gert
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] auto probe renewal

[Gert Doering]

hi,

On Mon, Dec 11, 2023 at 04:44:49PM +, POULET Benoit wrote:
> When I start a never-ending ping measurement with several probes like 20.
> 
> What happened if several probes are going off-line ?
> 
> Will Atlas remove the probes who are dead, and assign new to the measurement 
> ? Or will the measurement die slowly ?

My understanding is that the measurement will die slowly... (and I've 
been asking for a "automatic refill, please" feature since day one :) )

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Disconnect notification

[Gert Doering]

Hi,

On Mon, Nov 20, 2023 at 10:41:29PM +0100, Gert Doering wrote:
> Wasting enough time every day on needless chores that computers are
> supposedly good in automating.

... and having to explain this *again* every few years falls into the
same category of time-wasting annoyances...

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Disconnect notification

[Gert Doering]

Hi,

On Mon, Nov 20, 2023 at 10:12:31PM +0100, Ernst J. Oud wrote:
> One of my ISP???s had an outage today, which made my probe on that connection 
> report the disconnect by email. Fine, but the question popped up why a probe 
> cannot be configured to send an email when it is able to connect again. Could 
> this be implemented in the future perhaps?

Yes, please.

For me, this is one of the most annoying misfeatures of ATLAS today - I
get notified "it went down" just fine, but if this happens, like, at
night (due to a DSL outage at the site where the probe lives) it might
be all fine again when I see the "down!" mail.

So, I go to the Atlas portal to see "is it really down, like, USB flash
broken again?" and no, it says "nah, it was fine all the time, except
for those 5 minutes".

So, having a "it's back!" mail - for bonus points, threaded to the "down!"
mail - would really really improve an old man's grumpy mood.

Wasting enough time every day on needless chores that computers are
supposedly good in automating.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Changes to RIPE Atlas API auth status codes on 2 Oct

[Gert Doering]

Hi,

On Tue, Sep 19, 2023 at 10:38:29AM +0200, Chris Amin wrote:
> This temporary measure is guaranteed to work for the rest of 2022, 

So which iteration of 2022 would that be?

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Link-Local ICMP messages for Atlas probe

[Gert Doering]

Hi,

On Thu, Aug 17, 2023 at 03:50:03PM -0700, Daryl Morse wrote:
> I used WireShark on the WAN interface and I can confirm that the messages
> are all ping requests. Further, I can confirm that all of the addresses have
> been mangled. They are logged as fe80:5::, but the correct addresses are
> fe80::. I created a bug report.

Now that might be an API artefact.  Some of the BSD based OSes report the
interface ID in bits 16..31 when returning a fe80:: address in a
sockaddr structure.

The usual code to deal with it does something like this... from OpenVPN's
"give me the current IPv6 default gateway via a routing socket query" code:

/* get gateway addr and interface name */

struct sockaddr_in6 *s6 = (struct sockaddr_in6 *)gate;
struct in6_addr gw = s6->sin6_addr;

/* You do not really want to know... from FreeBSD's route.c
 * (KAME encodes the 16 bit scope_id in s6_addr[2] + [3],
 * but for a correct link-local address these must be :: )
 */
if (gate->sa_len == sizeof(struct sockaddr_in6)
&& IN6_IS_ADDR_LINKLOCAL() )
{
gw.s6_addr[2] = gw.s6_addr[3] = 0;
}


Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Link-Local ICMP messages for Atlas probe

[Gert Doering]

Hi,

On Mon, Aug 14, 2023 at 09:57:22AM +0200, Michel Stam wrote:
> Can???t say I???ve seen it before, can the firewall be a bit too strict?

If a device sends packets with link-local addresses towards off-link
GUA addresses, such packets MUST be dropped.

Unfortunately, not all implementations do that - but not doing so is
a violation of one of the basic IPv6 RFCs.

(Also, forwarding LLA sourced packets off-link has no use case really -
where should the reply go to?)

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Probe DHCPv6 support

[Gert Doering]

Hi,

On Thu, May 18, 2023 at 04:41:58PM +0200, Michel Stam wrote:
> Do you have examples for that on relevant DHCPv6 implementations?

With ISC-DHCPv6, it's very straightforward

# global options
option dhcp6.name-servers 2001:608::2, 2001:608::1;
option dhcp6.domain-search "space.net", "test.space.net";
default-lease-time 86400;
preferred-lifetime 7200;

# Set preference to 255 (maximum) in order to avoid waiting for
# additional servers when there is only one
option dhcp6.preference 255;

# SpaceNet TestNetz wifi
subnet6 2001:608:0:99::/64 {
range6 2001:608:0:99:a000::100 2001:608:0:99:a000::500;
ddns-rev-domainname "ip6.arpa";
ddns-domainname "test.space.net";
}


Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Probe DHCPv6 support

[Gert Doering]

Hi,

On Tue, May 09, 2023 at 04:44:05PM +0200, Philip Homburg wrote:
> It seems that networks that support only DHCPv6 IN_NA for IPv6 are quite 
> rare. 

Enterprises love DHCPv6 (because, among others, reverse DNS, some amount
of control, and no pesky privacy addresses).

That you do not see more of it is mostly Android's fault - because
enterprises get told "it will not work with half the mobile devices",
so they go and postpone IPv6 deployment instead (in places where the
control bit is strictly required)...

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Probe DHCPv6 support

[Gert Doering]

Hi,

On Fri, Dec 27, 2019 at 10:03:29PM +, Aleksi Pirttimaa wrote:
> I recently received my v4 probe and I'm very happy with it. But unfortunately 
> it doesn't support DHCPv6. I present a practical reason for implementing a 
> DHCPv6 client on the probe.

After quite a bit of fruitless debugging "why does my Atlas probe not
succeed in getting a DHCPv6 IA_NA lease?" today, google showed this old
thread from 2019.

Dear RIPE Atlas folks, why doesn't Atlas probes support DHCPv6 in 2023?

All the stubborn reasons given why Android can't support DHCPv6 do not
apply, and for the environment my v4 probe is running in, DHCPv6 is what
we use - so it's DHCPv6 or no v6...

Gert Doering
-- grumpy old man
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Encouraging people to upgrade software probe versions

[Gert Doering]

Hi,

On Mon, Jan 30, 2023 at 01:24:38PM +0100, Robert Kisteleki wrote:
> On 2023-01-29 20:11, Gert Doering wrote:
> 
> > First and foremost, a RIPE Atlas probe is a centrally managed piece of
> > software, and this is what it needs to be: centrally managed, centrally
> > upgraded, always at the upgrade level the central controller wants it
> > to be.
> 
> As I tried to explain before, this is true for the HW probes, not so 
> much for SW.

And I keep totally ignoring all arguments why it should stay that way.

So, yes, *today* it is the way it is, and I think "automated and mandatory
updates" should have been designed into SW probes from day one - that 
boat has sailed, but I still think that this is a desirable goal.

To repeat my argument: if I schedule a measurement across 100 probes,
I do not want to deal with different results purely caused by different
probe software versions (like, "30 of them do not support TLS1.3 yet,
the other 970 do", which might look like "something is interfering
with TLS1.3 measurements for these 30 probes").

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Atlas anchors as ping targets

[Gert Doering]

Hi,

On Mon, Jan 30, 2023 at 01:08:25PM +0100, Robert Kisteleki wrote:
> > Would it be OK to choose the probe target by picking an Atlas anchor at 
> > random? (I have running code for that, but will not post it to github if 
> > there are objections.)
> 
> The anchors are in a full measurement mesh - meaning they ping and trace 
> each other. Also, all anchors are assigned some probes to measure them. 
> You can find these measurements on the anchors' pages.
> 
> This may mean you don't need to set up new measurements. If so, it's 
> always nicer to reuse existing data :-)

The idea here is

 - I have a host in a "home network" that has 2 ISPs, with a global IPv6
   address from each of them

 - one of the ISPs fails, but the host does not know, and keeps using
   the "broken" IPv6 source address

 - by cyclic measurements, Brian's tool will see "nah, that address stopped
   working" and will de-preference it on the host -> host starts using the
   other IPv6 source address -> connectivity restored (over the other ISP)

and the test envisioned would be "ping something willing to be pinged" :-)

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Encouraging people to upgrade software probe versions

[Gert Doering]

Hi,

On Fri, Jan 27, 2023 at 02:15:44AM +0100, Robert Scheck wrote:
> On Mon, 09 Jan 2023, Gert Doering wrote:
> > So don't do OS updates.  But *do* update the probe software, automatically,
> > and in normal intervals.
> 
> writing while wearing my hat as a RPM packager: I'm not really sure how
> this shall work practically: If the probe software is run on regular (non-
> hardware probe) systems, there are runtime dependencies to other software,
> e.g. due to dynamic linking. Latter is encouraged by Linux distributions,
[..]

This is all good and true - so, do not distribute as RPM.

Distribute as Docker image, or Flatpack, or whatever all these new
"encapsulate a program and all its dependencies" approaches are called,
and I'm sure some of them have mechanisms to enforce timely updates.

First and foremost, a RIPE Atlas probe is a centrally managed piece of
software, and this is what it needs to be: centrally managed, centrally
upgraded, always at the upgrade level the central controller wants it
to be.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Encouraging people to upgrade software probe versions

[Gert Doering]

Hi,

On Mon, Jan 09, 2023 at 11:25:50AM +0100, Michel Stam wrote:
> Thank you for pitching in.
> 
> The hardware probes are fully managed by RIPE NCC, and their only purpose is 
> to execute measurements. I agree here, whether to update is up to RIPE NCC.
> On software probes, RIPE NCC is not in control of the unit. The software 
> probe may run other services and updating is up to its local sysadmin. 
> Consider operating system updates, which are updated by RIPE NCC on the 
> hardware probes, but cannot be updated on software probes.

So don't do OS updates.  But *do* update the probe software, automatically,
and in normal intervals.

Having probes out there with wildly varying firmware is not helping
measurement accuracy.

> To automatically update, the solution here is a simple CRON job which 
> executes yum -q update atlasswprobe periodically (say once per day or so), 
> which was the solution that was part of the RPM up to 5080. Would it help if 
> we add this to the instructions?

I'm very much of the opinion that upgrades should not be an opt-in service,
*and not even an opt-out*.

If you want a measurement box that does something non-ATLAS based on
ATLAS software - all good, but do not call it an ATLAS probe.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Encouraging people to upgrade software probe versions

[Gert Doering]

Hi,

On Mon, Jan 09, 2023 at 10:19:34AM +0100, Michel Stam wrote:
> The automatic update for the CentOS package was removed as of 5080. This 
> means that the update to 5080 will still be automatic, but not any more after 
> this (say 5090 onwards).
> This was a request by several users because Atlas forced the update, which 
> violated their sysadmin policies.

I find this surprising, to say the least.

The whole point about ATLAS Probes is "RIPE NCC manages them" - as host
of a handful of hardware probes, I have no say in whether I want them
upgraded or not, or what they should do or not do.

So I would expect all software probes to always upgrade themselves,
and this be clearly communicated to SW probe hosts.

If this violates your sysadmin policies, you shouldn't run 3rd-party
maintained *and operated* software.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[Gert Doering]

Hi,

On Fri, Dec 30, 2022 at 08:42:18AM -0800, Randy Bush wrote:
> i asked this quietly before, but let me be more direct.
> 
> how much private data is there actually?  what percentage of the stored
> data is private?

Indeed, this is a good question.  If it turns out that there is a lone
private measurement from me, or "in the sub-percent range", I'm willing
to let myself be convinced in the name of "make the measurement backend
more simple = robust"...

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] (Robert Kisteleki)

[Gert Doering]

Hi,

On Fri, Dec 16, 2022 at 07:13:15PM +, Renny Leal wrote:
> May the non-public measurements cost more in terms of credits or even money 
> to support the infrastructure?

To be able to run "non-public measurements", people need to have earned
the credits beforehand - those do not fall from the sky.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[Gert Doering]

Hi,

On Fri, Dec 16, 2022 at 08:07:14PM +0100, ripe@toppas.net wrote:
> Sorry Gert, but i strongly disagree.
> 
> > I might be troubleshooting something in our network where I have no 
> > interest in making the results public.
> RIPE Atlas is primarily designed for INTERnet measurements, not Intranet. To 
> see, how things look like from other networks. If you want to troubleshoot 
> something inside your own network and need privacy, you can do it the classic 
> way, by using your internal test-equipment or monitoring.

I am an ISP.  So I *must* see how things look like from the outside - 
but in case I've done stupid things to my own networks before, I might
not want the world to see that.

> > There's no "right to see all measurements" here
> I highly appreciate RIPE NCCs efforts for maximum transparency and open-data, 
> and i hope this will never change. This is what Atlas was intended to be (as 
> far as i can tell).

All my probes do public and open measurements "for everyone", and they
are happy to do measurements for you.  And I'm happy to bear the costs
for that (an Atlas Anchor costs real money).

> > if someone wants to see something, they are free to run their own 
> > measurements with their own credits.
> In this point, i disagree as well. It shouldn't be necessary to run the same 
> measurement multiple times. For what reason? It would be a waste of credits, 
> time and ressources. Also, keep in mind that this redundant data has to be 
> stored somewhere.

You wouldn't run the same measurements that I want to do, if I have to
do some troubleshooting.

> If one has a problem with open-data philosophy, he shouldn't participate in 
> this project.

> _There's only one exception_ i could agree with: measurements can be private, 
> if you only deploy your own probes/anchors for that measurement. But if you 
> decide to use other peoples probes, the results should be public.

This is a valid opinion for a network researcher, I guess.

For those that actually run the show here, we might see things in a
different light...  (as I'm not the only one explaining the desire for
private measurements).

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[Gert Doering]

Hi, 

On Fri, Dec 16, 2022 at 07:13:25PM +0100, Gert Doering wrote:
> There's no "right to see all measurements" here - if someone wants to
> see something, they are free to run their own measurements with their
> own credits.  What I do with my credits (which do not come for free)
> and who can see the results should be my decision.

... I could see a compromise here, making non-public measurements
require more credits, or so...

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[Gert Doering]

Hi,

On Thu, Dec 15, 2022 at 10:41:42AM -0800, Steve Gibbard wrote:
> Atlas, and the RIPE NCC, have two fairly separate constituencies:  
> researchers and operators.

This.

Operators (like me) are willing to host Atlas anchors and probes, and
thus contribute to the system.

I might be troubleshooting something in our network where I have no
interest in making the results public.  So I value the option to have
non-public measurements.

There's no "right to see all measurements" here - if someone wants to
see something, they are free to run their own measurements with their
own credits.  What I do with my credits (which do not come for free)
and who can see the results should be my decision.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Assigned AS vs. Advertising AS

[Gert Doering]

Hi,

On Wed, Jun 29, 2022 at 10:30:22AM +0200, Simon Brandt via ripe-atlas wrote:
> Another example would be a multi ASN company which announces all
> prefixes from a single ASN via BGP, even though the prefixes are
> assigned to various AS numbers. Since the RIRs do have the information,
> to which AS a specific prefix is assigned to,

prefixes are not assigned to "AS" numbers, ever.

prefixes are assigned to entities, as are AS numbers.

ROAs and/or route(6): objects are used to tie both together - and it's
in the authority of the network (prefix) holder to state which AS is
allowed and expected to announce a given prefix, not the RIR.

Repeat: the RIR has no say in "which AS is tied a prefix".

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Credits Request

[Gert Doering]

Hi,

On Tue, Jun 28, 2022 at 06:42:20PM +, Martin, Noah S wrote:
> I???m a new PhD student at Tufts University in Boston, and I'm starting to 
> work on a cloud latency project. If anyone has credits to spare, donations 
> would be greatly appreciated! My account is 
> noah.mar...@tufts.edu 100k credits would be 
> perfect to get started on my experiments.

And another 10M :-)

gert
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Overuse of software probes

[Gert Doering]

Hi,

On Mon, Apr 04, 2022 at 02:30:19PM +0200, Andreas Härpfer wrote:
> I totally agree.  As I said, I was only guessing, but I
> couldn't come up with a better explanation why someone
> would want to have 15 probes within the same /24.  If
> I am missing out on other cool things that can only be
> done with this kind of setup, I'd be happy to learn :-)

They might use the probes to do in-AS measurements...   

Historic anecdote: at some time, DECIX had multiple TTM boxes ("back 
then") to monitor their fabric across different locations in Frankfurt.
So this might be something similar.

Or not, maybe just a student competition "who can get more probes
into Atlas" :-)

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] All-Probe Traceroute + detect RFC1918 addresses

[Gert Doering]

Hi,

On Fri, Sep 17, 2021 at 04:17:47PM +0200, Bjørn Mork wrote:
> > Section 5:
> >
> >It is strongly recommended that routers which connect enterprises to
> >external networks are set up with appropriate packet and routing
> >filters at both ends of the link in order to prevent packet and
> >routing information leakage.
> >
> > I think that speaks very clearly about "you can do in your network
> > whatever you want, but nobody else wants to see that"
> 
> This fails to consider the situation where you are using RFC1918
> addresses on that link, which is common for mobile network access today.

It doesn't.  It is very clear that *if* you do, it's your responsibility
to ensure ICMP packets are not sent from a RFC1918 address.

This is not a fault in the RFC, it's a fault in the way these people
build their networks.

> My example didn't make that clear, but the traceroute probes are sent
> from an RFC1918 address:
> 
>  bjorn@miraculix:~$ ip route get 130.67.15.198
>  130.67.15.198 dev wwan0 src 10.82.241.88 uid 1000 
>  cache 
> 
> So you should drop packets using RFC1918 addresses on that link?

"What happens inside your network happens inside your network" (and
the RFC explicitly permits that, of course), but we do not want to 
see it on someone else's network.

> > Given the age of the document, the language used to be less STRONG
> > back then.
> 
> Sure. Assigning RFC1918 addresses to customers was also unheard of, and
> didn't even need to be mentioned.

If that is CGN'ed, it's not violating the RFC.

Leaking packets from addresse that do not belong to you does.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] All-Probe Traceroute + detect RFC1918 addresses

[Gert Doering]

HBi,

On Fri, Sep 17, 2021 at 03:43:29PM +0200, Bjørn Mork wrote:
> Gert Doering  writes:
> > On Fri, Sep 17, 2021 at 03:23:24PM +0200, Bjørn Mork wrote:
> >> Using RFC1918 on links in your own network is fine. And having
> >> them show up in traceroutes is a feature.
> >
> > s/feature/sign of sloppy network design, and a RFC1918 violation/
> 
> Sorry for being slow. but I need a direct reference to the paragraph
> this violates.

Section 5:

   It is strongly recommended that routers which connect enterprises to
   external networks are set up with appropriate packet and routing
   filters at both ends of the link in order to prevent packet and
   routing information leakage.

I think that speaks very clearly about "you can do in your network
whatever you want, but nobody else wants to see that"

Given the age of the document, the language used to be less STRONG
back then.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] All-Probe Traceroute + detect RFC1918 addresses

[Gert Doering]

Hi,

On Fri, Sep 17, 2021 at 03:23:24PM +0200, Bjørn Mork wrote:
> Using RFC1918 on links in your own network is fine. And having
> them show up in traceroutes is a feature.

s/feature/sign of sloppy network design, and a RFC1918 violation/

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] All-Probe Traceroute + detect RFC1918 addresses

[Gert Doering]

Hi,

On Wed, Sep 15, 2021 at 06:58:50PM +0200, Philip Homburg wrote:
> My router at home gets a lot of error icmps with link local source, from 
> quite a few hops away...

*wake up*  IPv4 "link local" (169.254.*) or IPv6 LLA (fe80::)?

The latter would make me very curious what sort of intermediate devices
are forwarding these (which is strictly forbidden).

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] Satellite based "last mile" and Atlas probes

[Gert Doering]

Hi,

On Mon, Apr 26, 2021 at 04:45:11PM +0200, Annika Wickert wrote:
> V6 only ;)

This is the spirit! :-)

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] Probe #1000165 showed as down in tab#status

[Gert Doering]

Hi,

On Tue, Mar 02, 2021 at 12:46:05PM +0100, Viktor Naumov wrote:
> There was a network maintenance in Hetzner last night. Few days before 
> the ctr-fsn01 was reinstalled. Due to minor network misconfiguration the 
> controller's  IPv6 connectivity was not restored.

I know people that have preached "if you do IPv6, *always* remember to
monitor IPv4 *and* IPv6, all the time, for all services" for like 15+
years now...

And I've been told that you have the largest monitoring system ever
at your disposal... :-)

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses

[Gert Doering]

Hi,

On Tue, Feb 16, 2021 at 03:51:57PM +0100, Robert Kisteleki wrote:
> Before embarking on evaluating what it takes for RIPE Atlas to 
> contribute to this, I'd like to ask for some input from the community; 
> is this something we should spend energy on? More specifically, would it 
> be worthwhile for us to spend time on evaluating the cost of / 
> implementing such measurements in RIPE Atlas?

I think the answer very much depends on who you ask.

Those that have beein doing IPv6 since ages would claim that any time
spent on "making formerly-reserved IPv4 addresses usable world-wide" is
energy lost on making IPv4 go away instead... so, "no".

Those that want to avoid deploying IPv6 will, of course, support anything,
no matter how expensive, which gives them the illusion that this is a viable
strategy :-)

I think my response might be a bit biased.

But actually it might be interesting to know...

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] Automating software probe creation?

[Gert Doering]

Hi,

On Mon, Jan 04, 2021 at 12:42:19PM +, Colin Johnston wrote:
> And automated up probe alerting needed as well :)

this!

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] Probe operator notifications

[Gert Doering]

Hi,

On Sat, Dec 12, 2020 at 09:03:54AM +0100, r...@brite.cz wrote:
> For this purpose I use an online ping check service.
> Your probe need to have IPv6 or public IPv4 and ICMP be not blocked by a 
> firewall to be able to respond pings from outside.

This is not the point.  Of course I could use our monitoring for that.

The thing is "the system sends a DOWN report, but no UP report", and having
to resort to external monitoring (which will not work for probes behind
customer links with NAT) is quite lame.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] Probe operator notifications

[Gert Doering]

Hi,

On Thu, Dec 10, 2020 at 04:31:48PM -0500, Edward Lewis wrote:
> I do get the ???your probe went off-line??? notices.  I would like ???your 
> probe came back on-line??? notices as well.  If we had those, I may have 
> noticed it stayed down after the last message I saw.

Yes, please!!

I have voiced the wish for "back on-line notice" like two years ago, and
was told "it's complicated"... well... doesn't have to be millisecond-
accurate, but if it saves me driving to a remote location, a few minutes
delay are not that bad.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] dead v1 probe

[Gert Doering]

Hi,

On Tue, Jun 02, 2020 at 08:32:30PM +0200, Carsten Schiefner wrote:
> Mine is fine, Gert. :-)

Then it's maybe just old age (and the location is not particularily
well air-conditioned)...

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

[atlas] dead v1 probe

[Gert Doering]

Hi,

have there been software updates for v1 probes recently?  I've heard
about a few v1 probes that have died "just last week" - mine among
them (#461), fell off the net with "Firewall Problems Suspected",
but it's no longer even ARPing properly (= either it totally lost
its config and wants DHCP now, which there isn't in this network,
or it just died)...

So knowing whether this is a more widespread issue and possible reasons
would help me to decide how much effort to invest in debugging this.

gert
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] RIPE Atlas Software Probes

[Gert Doering]

Hi,

On Wed, Feb 12, 2020 at 10:53:47AM +0100, Philip Homburg wrote:
> We are glad to announce that, after several months of development and
> testing, we are now accepting applications for RIPE Atlas software
> probes. With several different installation options to choose from,
> software probes provide future hosts a whole new way to get involved
> with RIPE Atlas.

Will these be tagged and de-selectable for new measurements?

IOW, I've had enough bad experience with hypervisor packet loss and
weird jitter for "anything that is not TCP based" that I wouldn't want
to run anything where I'm interested in more than "might it be able
to ping the target (at all)?" on VMs running on unknown hypervisors.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] SSL Certificates for ripe anchors

[Gert Doering]

Hi,

On Fri, Aug 30, 2019 at 09:59:02PM +, Jóhann B. Guðmundsson wrote:
> Given that Let's encrypt own root which was supposed to be pushed out this
> July but got delayed til 2020 is widely trusted by browser, one can hardly
> claim that the browser community is run by some "cert cabal"

Well, the pieces sort of nicely fit.  Push everybody to do "https everywhere!"
(why not?  LE is free!), and of course for *real* security companies must
have EV certs from "real" CAs... for heaps of money.

Money flows.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] SSL Certificates for ripe anchors

[Gert Doering]

Hi,

On Fri, Aug 30, 2019 at 03:08:06PM +, Jóhann B. Guðmundsson wrote:
> > Yep. I wish the use of TLSA was more wide spread. It doesn't require third 
> > parties to "certify" who is who.
> 
> The third parties that "certify" are for others to establish trust in 
> that you are who you claim to be not because its "required" and the 
> security industry has deemed those who do not atleast get some other 
> entity to validate, not to be worthy of trust.

TLSA does all this, without requiring some other entity that follows their
own agenda to "certify" anything.  You need to trust the DNS root KSK,
of course, but everything else follows the normal DNSSEC chain.

> Just because Trump says he's a genius and the "chosen one" does not make 
> him one now does it...

No, but that is slighly missing the point.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] Why has probe growth stagnated?

[Gert Doering]

Hi,

On Wed, Feb 20, 2019 at 06:52:28AM +0200, Hank Nussbacher wrote:
> On Tue, 19 Feb 2019, s...@gibbard.org wrote:
> 
> ASN coverage is just 5.6%.  That really doesn't give a complete global 
> view for stats.  Rather than return money to LIRs every year in their 
> bill, why not state that any LIR running an active probe within their ASN 
> will get a 50Euro credit on their bill?  That alone would increase ASN 
> footprint coverage quickly within RIPE.

I like that suggestion :-)

(Not sure how that will pan out if we reach 50% of all LIRs, but to get
from 5% to 20%, it might definitely be an idea)

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] New on RIPE Labs: RIPE Atlas Probes: Delays in Distribution

[Gert Doering]

Hi,

On Fri, Feb 08, 2019 at 03:32:38PM +0100, Philip Homburg wrote:
> On 2019/02/08 13:45 , Micha Bailey wrote:
> > Interesting. This seems like a much higher power device. What are the
> > actual power requirements? So far my probe has been powered from the USB
> > port on the router, and I???m concerned that this may make the
> > installation of future probes more difficult.
> 
> The power requirements are quite reasonable when used as an Atlas probe.
> There should be no problem powering a v4 probe from a USB port.

My v4 probe is fed from an USB port on an older Mac Mini, with no
adverse effects I can see.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] Probe v1 disconnecting every 2 hours

[Gert Doering]

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 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] Probe questions - reporting clearly busticated probe configs?

[Gert Doering]

Hi,

On Wed, Jan 23, 2019 at 09:52:19AM +, 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 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [atlas] New RIPE Labs article on RIPE Atlas v3 Anchors

[Gert Doering]

Hi,

On Fri, Sep 29, 2017 at 02:15:46PM +0200, Romeo Zwart wrote:
> > I seem to remember
> > that there was an initial "maximum supported lifetime" set for these to
> > avoid the TTM issue ("10+ year old boxes still having to be supported")...
> 
> We may come to a point in future, when we are unable to further support
> the remaining v2 anchors. When that happens we will of course announce
> that well in advance so that hosts can plan for replacements if they
> would want to.

Works for me :-) - thanks.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


signature.asc
Description: PGP signature

Re: [atlas] New RIPE Labs article on RIPE Atlas v3 Anchors

[Gert Doering]

Hi,

On Thu, Sep 28, 2017 at 02:18:12PM +0200, Alun Davies wrote:
> In this RIPE Labs article the RIPE NCC looks into hardware specifications and 
> logistics for the next generation of RIPE Atlas anchors:
> 
> https://labs.ripe.net/Members/alun_davies/introducing-ripe-atlas-v3-anchors

Cool.

Do you have current plans for upgrading the v2 hardware?  I seem to remember
that there was an initial "maximum supported lifetime" set for these to
avoid the TTM issue ("10+ year old boxes still having to be supported")...

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


signature.asc
Description: PGP signature

Re: [atlas] Notify time setting does not work

[Gert Doering]

Hi,

On Fri, Aug 18, 2017 at 01:01:48PM +0200, Viktor Naumov wrote:
> Here how it (always) works.
> 
> There is a job started every 30 minutes. If a probe is down longer than 
> the "Notify time" you will get a notification. So in your case (10 
> minutes) you should get an email within interval of [10 , 40) minutes.

This is a bit awkward...  can this be improved, like, run this job every
minute or so?

A single "select id from probes where downtime>notify and not is_notified"
statement shouldn't cost much...  (no ideas about your table setup, 
though :-) )

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


signature.asc
Description: PGP signature

Re: [atlas] Link aggregation for anchors?

[Gert Doering]

Hi,

On Thu, Jul 20, 2017 at 07:44:46AM +0200, Tore Anderson wrote:
> * Gert Doering <g...@space.net>
> 
> > (active/passive linux bonding would work well for us, while LACP
> > wouldn't due to conscious design decision to de-couple control planes
> > of primary/secondary switches)
> 
> Active/passive fail-over à la Linux bonding would work for me too. The
> biggest disadvantage of that is that you waste half your available
> bandwidth, but that probably isn't a big deal for the Atlas Anchors.

Not really, given a GigE uplink and just a few mbits in use :-)

> It is quite possible to create a setup that does 802.3ad if an LACP
> neighbour is detected, falling back on active/passive fail-over if not.
> That said, you do lose most of the error detection capabilities of LACP
> that way. Quite possibly not worth the engineering effort if it's not
> already implemented in whatever software you're using.

Linux bonding can do ARP probing on both member interfaces, which does
the most important "real world" part of the error detection - "will this
port work for me to reach the default gateway?" (so you can even failover
on an uplink outage).

> I'd rather you spent that time implementing LLDP support, come to think
> of it. (That would be useful on the non-Anchor probes as well.)

Minimalistic LLDP support would also be nice ("device, port").

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


signature.asc
Description: PGP signature

Re: [atlas] Link aggregation for anchors?

[Gert Doering]

Hi,

On Wed, Jul 19, 2017 at 02:35:14PM +0200, Robert Kisteleki wrote:
> In the meantime, it'd be useful to know if others are interested in this
> as well...? Just to be able to check the expected amount of work against
> the demand.

*second*

(active/passive linux bonding would work well for us, while LACP
wouldn't due to conscious design decision to de-couple control planes
of primary/secondary switches)

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


signature.asc
Description: PGP signature

Re: [atlas] Anchors as target hosts for SLA

[Gert Doering]

Hi,

On Tue, Jun 06, 2017 at 06:48:33PM +0200, Antonio Prado wrote:
> This Internet transit should meet the following criteria:
> 
> average round trip delay (echo request, echo reply) toward
> $NEAREST_ATLAS_ANCHOR should be less than 100ms on a 10k packets stream
> of pings; packet loss equal or less than 0.02%
> 
> pros, cons, recommendations?

Too simple.  What if that anchor is down, or the anchor host network has
a network bottleneck towards the transit provider you are using?

So you need something that averages over multiple anchors - we used to
do that via TTM ("if our TTM hosts can reach more than 80% of all other
TTM hosts, we declare the Internet to be in good working condition" - note
the "80%", because something is always down somewhere) but haven't come
around to define & implement something based on ATLAS yet.

With the large amount of anchors nowadays, just using the anchor matrix
is actually quite similar to what TTM had, just better... :-)

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


signature.asc
Description: PGP signature

Re: [atlas] Are there plans for faster than 1G anchors?

[Gert Doering]

Hi,

On Thu, Apr 20, 2017 at 03:26:11PM +0100, Colin Johnston wrote:
> vm virtual image would be great though so that underlying network would be 
> transparent to the application.

Welcome back, we've missed your contributions.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


signature.asc
Description: PGP signature

Re: [atlas] New on RIPE Labs: Another Look at RIPE Atlas Probe Lifetimes

[Gert Doering]

Hi,

On Thu, Aug 25, 2016 at 03:37:06PM +0100, Colin Johnston wrote:
> maybe virtual vm probes might be useful 

You're not giving up on this, are you?

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


signature.asc
Description: PGP signature

Re: [atlas] Reconnecting probe 3508 - troubleshooting

[Gert Doering]

Hi,

On Tue, Aug 23, 2016 at 08:24:17PM +0100, Michael-John Turner wrote:
> Oddly, even after receiving an IP the first time, it was able to do DNS
> requests (they showed up in the SOS log on the Atlas site), but it wasn't
> able to report via ssh on 443 (which works fine from other hosts on the
> same network).

Well, it can *send*.  It might not be able to *hear* the answer to the
DNS requests, so the fact that the SOS messages are seen at Atlas Central
doesn't really say anything about receiving of packets after the initial
DHCP packet...

So, it could just be borderline broken... if cold enough, it works, if
the room is warming up, it no longer receives packets...

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


signature.asc
Description: PGP signature

Re: [atlas] USB drive more harmful than helpful?

[Gert Doering]

Hi,

On Fri, May 20, 2016 at 04:10:47PM +0200, Philip Homburg wrote:
> We have no clear idea why they fail. It seems that time to failure is
> highly variable.

Can you correlate tests-until-failure or data-written-until-failure?

One of mine has failed at least two times now, and it could be that 
people just *love* to run tests from 3320...

My gen 1 probe in 5539 has never had *any* issues.

gert
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


signature.asc
Description: PGP signature

Re: [atlas] USB drive more harmful than helpful?

[Gert Doering]

Hi,

On Fri, May 20, 2016 at 02:37:44PM +0200, Michael Ionescu wrote:
> >From both my own (short term) experience and from what's being written on 
> >this list, I'm getting the impression that the USB drive may be costing more 
> >than it's worth. 
[..]
> Any thoughts?

The USB outages and the lack of proper guidance for probe hosts about
the problem status and how to get the probes back has been my gripe #1
for a while now.

So, yes, this needs fixing, one way or the other.

gert
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


signature.asc
Description: PGP signature

Re: [atlas] Local network checks

[Gert Doering]

Hi,

On Mon, Apr 11, 2016 at 01:49:04PM +0200, Alison Wheeler wrote:
> Sadly, there was nothing in there to indicate a problem, other than no 
> records:
> 
> 74.125.47.144 2016-04-07 18:57:44 A   0h 1m   
> 74.125.47.140 2016-04-07 18:57:44 0h 1m   
> 2a00:1450:400c:c08::116   2016-03-26 00:58:46 A   8d 9h 17m   
> 74.125.47.14  2016-03-26 00:58:46 8d 9h 17m
> 

These are not the SOS messages.

> and as I don't check the probe's status daily (mea culpa!) it wasn't until I 
> was mailed after a week of it being down that I knew there was an issue. But 
> even then, if the RIPE servers can't 'see' the probe I can't do anything via 
> the web interface, hence my wondering if there is any way to awaken it via a 
> local network action (analogous to sending a WakeOnLAN ping)

Most likely it will need flash stick cyling.  But you'll see that in the
SOS messages.

(Repating myself, it would be *so* helpful if the mail "hey, your probe
is down!" actually included availble SOS diagnostics...)

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


signature.asc
Description: PGP signature

Re: [atlas] Probe offline

[Gert Doering]

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 AGVorstand: 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


pgptvHBHi5pYr.pgp
Description: PGP signature

Re: [atlas] Atlas probe offline

[Gert Doering]

Hi,

On Mon, Jan 11, 2016 at 11:53:29AM +0100, Robert Kisteleki wrote:
> However, we're working on a feature to give probe hosts more guidance about
> what's going on (and especially what's going wrong) with their probe (*),
> and here we will make it clear if the USB replacement is in order.

This is much appreciated... I've bitten by USB outages a few times, and
it wasn't always obvious why the probe was acting up.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


pgp_UkVuCcIK5.pgp
Description: PGP signature

Re: [atlas] Turris Omnia as probe Platform?

[Gert Doering]

On Fri, Dec 04, 2015 at 11:30:34PM +0100, Daniel Suchy wrote:
> I don't fully agree here. There're always so many things, which may
> involve measurement realiability just on first from the probe. You
> always believe, that "hardware" probe is more reliable. Not, it isn't -
> current probe itself is quite cheap piece of not-so-powerfull hardware.
> And if someone want's to trick measurement, he can - there're so many
> ways. You don't have any kind of control on network behind the probe -
> and that's more important part in terms of reliable measurements...

The thing is "we perfectly well know the characteristics of the measuring
device".  Everything deviating from the norm will be caused by the network,
not "something in the VM environment".

> Many thing are going virtual around us (even on high-end routing
> platforms). Virtualised probe can be more reliable in terms of computing
> power compared to small TP-Links & so-on.

Computing power is totally unimportant as compared to reproduceability
of a given measurement on a given probe.

Of course a VM is more powerful than either of these probes, but does this
make it more suitable to be part of Atlas?  I say no, because for a
measurement platform, "raw power" is not the key issue.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


smime.p7s
Description: S/MIME cryptographic signature

Re: [atlas] Turris Omnia as probe Platform?

[Gert Doering]

Hi,

On Fri, Dec 04, 2015 at 09:09:14PM +0700, Kessler, Thomas wrote:
> This might be an interesting platform for running an VM probe?!

I think there is no lack of "interesting platforms to host a VM", but 
the point of the discussion was "virtualizing measurements leads to 
unreliable results as you do not control the hardware well enough" - and
for that reason, I'd strongly discourage *any* sort of VM solution.

gert


-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


pgpkaiNr3c4v4.pgp
Description: PGP signature

Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)

[Gert Doering]

Hi,

On Tue, Nov 10, 2015 at 09:33:01AM +0100, Daniel Karrenberg wrote:
> >From my personal, informal assessment I advise against supporting VMs. I
> recommend a thorough assessment of the data quality, the costs and the
> effects on RIPE Atlas as a whole before diving into soloutioneering.

From experience running a recursive DNS on a VM platform,  I'd also speak
against supporting VMs.  Unpredictable load elsewhere on the same host
can (and does) lead to UDP/ICMP packet loss, which the "Atlas VM" won't
be able to differenciate from "something on the path is broken/lossy".

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


pgpjPq0TYEUQD.pgp
Description: PGP signature

Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)

[Gert Doering]

Hi,

On Tue, Nov 10, 2015 at 11:18:37AM +0100, Stephan Wolf wrote:
> ANCHOR as an VM would really make sense.
> What do you think about this ?

Even less so than a probe - as the anchor needs to provide reliable and
robust measurements *and* responses to probes.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


pgpqZJQu9fL0k.pgp
Description: PGP signature

Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)

[Gert Doering]

Hi,

On Tue, Nov 10, 2015 at 01:50:41PM +0100, Philip Homburg wrote:
> For ordinary probes, we have absolutely no control over the network.
> Probe hosts don't have to guarantee anything. So I wonder if blackbox
> testing would even allow distinguishing between an overloaded VM and a
> probe on a very bad consumer line.

But isn't this a significantly different statement?  "Here's a bad line"
is something you can only assess if you know that your probe is sane.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


pgpEVCM6eygMF.pgp
Description: PGP signature

Re: [atlas] Dead probes - slightly OT

[Gert Doering]

hi,

On Wed, Oct 28, 2015 at 05:30:49PM +0100, Wilfried Woeber wrote:
> This seems to imply that the probes can bootstrap (off the 'net?)  without
> the USB stick present ? If this is the case, what is the USB stick used for?

As far as I understand from the "firmware upgraded"-messages, the internal
flash has some sort of immutable emergency recovery firmware on it, which
is good enough to pull an upgrade from the master, install to USB stick,
and reboot into it.  Or so.

And, for measurement data :-)

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


pgpfZXNAhF6HL.pgp
Description: PGP signature

Re: [atlas] 3rd generation probe doesn't appear as online

[Gert Doering]

Hi,

On Thu, Oct 08, 2015 at 10:08:23AM +0200, Daniel Suchy wrote:
> dead external USB flash can be also one of reasons (I had such issue).
> You can try replace it with new one.

Yeah, the v3 probes seem to be a bit flakey in that regard - I have
3 of them, and two had flash that the box just did not like (but which
seems to be working nicely elsewhere).  Flash replaced, box happy.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


smime.p7s
Description: S/MIME cryptographic signature

Re: [atlas] 3rd generation probe doesn't appear as online

[Gert Doering]

Hi,

On Thu, Oct 08, 2015 at 09:54:55AM -0300, Thiago Ayub wrote:
> How can I repair the flash memory? Is there an image file online I can
> download it and  write it to a new flash memory and insert it at the
> TP-Link device?

Turn off, remove flash stick, turn off (it will now boot from internal
memory), after a few minutes, insert new flash stick, wait.  For me,
this was usually sufficient to get the boxes back to live.

Also, you can look on the "my probes" page under "network", all the
way down, for the last SOS DNS messages the probe sent - it will usually
tell the system (via queries like "INO-USB.$probeid....ripe.net")
what is wrong.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


pgpSLuTysjIdX.pgp
Description: PGP signature