- ripe-atlas - mailman.ripe.net

Can <contact@streamyard.com> please be unsubscribed?
by Carsten Schiefner 17 Jun '23

17 Jun '23

To whom it may concern… Thank you, -C.

3 2

Vergessen Sie nicht Ihre StreamYard-Einladung!
by StreamYard 17 Jun '23

17 Jun '23

StreamYard Inc. ( https://u7212249.ct.sendgrid.net/ls/click?upn=Ef-2BTvyZXeR9MIWcIdAYELFJPNYC… )

1 0

Sie wurden zu StreamYard eingeladen
by StreamYard 10 Jun '23

10 Jun '23

StreamYard Inc. ( https://u7212249.ct.sendgrid.net/ls/click?upn=Ef-2BTvyZXeR9MIWcIdAYELFJPNYC… )

1 0

upgrading an original soft probe
by Randy Bush 08 Jun '23

08 Jun '23

i have a probe, 1000004, on a deb 10 vm that was installed in the rotterdam hackathon. the detritus looks as if it was built using a deb install of atlasswprobe-5000-1.deb. two days ago, it stopped working in some way; i have not pursued, figuring i was dealing with an antique. is there a path to make it current? randy

4 9

Re: [atlas] credit request
by Michael Rabinovich 06 Jun '23

06 Jun '23

Many thanks! As I mentioned, I did get all the credits requested, but I am grateful to have them as it will allow us extra flexibility to do some exploratory measurements. Cheers, —Misha > On Jun 4, 2023, at 6:53 PM, DeuZa <proton(a)deuza.net> wrote: > > Sent 181 000 000 credits > > Sent from Proton Mail for iOS > > > Le mer. 24 mai 2023 à 17:29, Michael Rabinovich <michael.rabinovich(a)case.edu <mailto:Le mer. 24 mai 2023 %C3%A0 17:29, Michael Rabinovich <<a href=>> a écrit : >> >> Folks, >> >> As I posted couple months ago, we deployed and made available the instrumentation for longitudinal comparison of the performance implications of DNS resolver platforms, including ISP-provided and some influential publicly available resolvers ( https://dns-web-portal.netlify.app/). This work — and Nick Kernan’s MS thesis — was enabled by a generous donation of credits several years ago from the RIPE Atlas community — thanks a lot! Now to keep this measurement going requires ~20M credits per month. I’d like to assemble ~250M credits so we could keep this service up for a year. By then we should be able to see if it’s proved to be valued by the community and whether and how to keep it going beyond this time horizon. Would you please donate to my account what you can? >> >> Many thanks in advance! >> —Misha > <publicKey - proton(a)deuza.net - 0x714FB45F.asc>

1 0

credit request
by Michael Rabinovich 25 May '23

25 May '23

Folks, As I posted couple months ago, we deployed and made available the instrumentation for longitudinal comparison of the performance implications of DNS resolver platforms, including ISP-provided and some influential publicly available resolvers ( https://dns-web-portal.netlify.app/). This work — and Nick Kernan’s MS thesis — was enabled by a generous donation of credits several years ago from the RIPE Atlas community — thanks a lot! Now to keep this measurement going requires ~20M credits per month. I’d like to assemble ~250M credits so we could keep this service up for a year. By then we should be able to see if it’s proved to be valued by the community and whether and how to keep it going beyond this time horizon. Would you please donate to my account what you can? Many thanks in advance! —Misha

9 15

Probe DHCPv6 support
by Aleksi Pirttimaa 19 May '23

19 May '23

Hi! 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. You see, my ISP doesn't send router advertisements with the prefix for stateless autoconfiguration set, and instead DHCPv6 must be used. I believe their decision could have something to do with the fact that the regulating body here requires ISP's to prevent IP address spoofing in consumer plans. And to meet that requirement my ISP may be using a feature similar to Cisco's IP source guard, where switch ports and/or mac addresses are passively associated to leased ip's or prefixes, breaking SLAAC. Unfortunately they hate letting consumers talk with their engineers so it's difficult to speculate this further. For now, I've put a stateful firewall appliance in front of the probe which provides SLAAC, it works just fine. Do you think a DHCPv6 client should be implemented?

8 13

Measurement suggestions for new deployments.
by Gerardo Huerta Robles 18 May '23

18 May '23

Hello all, I'm a newbie with RIPE ATLAS Probes, We are currently working on deploying a new Probe network in Nicaragua as the first step for a measurement project. The second step will be to capture statistics of traffic to the internet, but we are not clear what kind of targets are the most relevant for internet statistics. I would like to ask you for suggestions of targets, what kind of public servers are relevant for user internet traffic? We are thinking of DNS servers like 8.8.8.8 or some public HTTP web pages like the government or social media like Facebook, youtube and so on. But what do you think? Do you have some advice? The project is intended to obtain the first statistics about internet traffic and make it public using RIPE Probes and schedule measurements. If you have some advice please let me know, Thank you. Regards

1 0

RIPE Anchor updates?
by John Howard 16 May '23

16 May '23

Hi folks, Proton hosts 3 RIPE Anchors (7120, 6847, 6854) and during routine vulnerability scanning we identified these appliances running nginx 1.20.1, which is potentially vulnerable to two CVEs (CVE-2022-41741 and CVE-2022-41742). Given the mp4 module pre-req, I doubt they are vulnerable in practice, but this highlighted that the nginx 1.20 train was deprecated 11 months ago, and 1.23/1.24 are the currently active releases. I note the last probe firmware update 5080 (which we run already) from Nov/22 disabled auto updates on the appliances, so I assume there will be regular updates coming from RIPE going forward instead? Thanks John -- John Howard Head of Network Infrastructure Proton AG Sent with Proton Mail secure email.

2 3

Request RIPE Atlas Credit for Research
by 卫蕴泽 28 Apr '23

28 Apr '23

Dear all, Greetings! I'm a senior student at Tsinghua University, China. Recently I'm working on my graduation project, which is a IP infrastructure mapping research that requires large-scale network measurement via RIPE Atlas to verify my method. However, a simple traceroute with 6 probes need 10K+ credits. As a new user I don't have any credit to proceed, and I've no time to earn them by myself. So I'm here to ask for help. Is it possible for anyone generous enough to offer me some RIPE Atlas credits (like, 10M)? My account at RIPE NCC is fenglan.chn(a)gmail.com, my education email is weiyz19(a)mails.tsinghua.edu.cn and my student ID is 2019011285. Many thanks for your help! Sincerely, Yunze Wei

6 6

a link for comparing DNS resolvers
by Michael Rabinovich 04 Apr '23

04 Apr '23

Folks, FYI, Nick Kernan, my Masters student, has deployed a web portal that facilitates the comparison between various DNS resolvers, including ISP-provided and some influential publicly available resolvers (Google’s public DNS, OpenDNS, Quad9, and Cloudflare). The comparison is based on two factors: the latency of DNS resolutions and the latency of TCP handshake with the CDN edge server selected through a given resolver. The results are based on recurrent monthly measurements from RIPE Atlas probes that have both IPv4 and v6 connectivity, have an ISP-provided resolver available for comparison, and which meet certain requirements regarding probe versions and reliability. You can specify the desired month of measurement, a region of interest, and the CDNs to analyze. You can access Nick’s portal through https://dns-web-portal.netlify.app/ <https://dns-web-portal.netlify.app/> The details of the methodology are in Nick’s thesis, which awaits some copyright permissions before being made publicly available. In the meantime, Nick (cc’ed) and I would be happy to answer any questions. Regards, —Misha Rabinovich

4 4

RIPE Atlas Quarterly Planning Q2 2023
by Robert Kisteleki 30 Mar '23

30 Mar '23

Dear colleagues, We’ve now published our quarterly planning for RIPE Atlas. These are available at: https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas This quarter, we'll continue the discussion on five proposals for changing RIPE Atlas behaviour and work on restructuring and renewing pages of the user interface. If you have any input on our plans or want to let us know what you would like to see us work on, please let us know. Kind regards, Robert Kisteleki RIPE NCC

1 0

Planned Maintenance: RIPE Atlas streaming API, 28-03-2023, 9.00am - 10.00am UTC
by Marco Giuliani 27 Mar '23

27 Mar '23

Hello, We will carry out planned maintenance on the RIPE Atlas streaming API. During this time, existing HTTP sessions will be briefly interrupted. Start: March, 28th, 2023 - 9.00am UTC End: March, 28th, 2023 - 10.00am UTC Kind regards, Marco Giuliani RIPE NCC

1 0

Join the DNS Hackathon on 20 and 21 May in Rotterdam (weekend before RIPE 86)
by Vesna Manojlovic 21 Mar '23

21 Mar '23

Dear colleagues, I am pleased to invite you to participate in the DNS hackathon that will take place the weekend before RIPE 86 at Ahoy in Rotterdam, on Saturday 20 May and Sunday 21 May 2023. The hackathon is organised by DNS-OARC, Netnod and the RIPE NCC and offers projects based on three challenges: DNS &... Sustainability Security (and privacy) Sovereignty You can also bring your own idea or project. To participate, apply here: https://www.ripe.net/participate/forms/apply/dns-hackathon-2023/ (first deadline is on Thursday, 23 March 2023) Read more at: https://www.netnod.se/join-the-dns-hackathon-2023 Feel free to share this invitation with your communities. Regards, Vesna Manojlovic -- Senior Community Builder, RIPE NCC https://labs.ripe.net/author/becha/

1 0

HTTP measurement proposals [CDN-HTTP] [GENERIC-HTTP] [PEERING-HTTP]
by Ethan Katz-Bassett 06 Mar '23

06 Mar '23

Hi Robert, all: I was considering emailing about the possibility of HTTP measurements to our PEERING <https://peering.ee.columbia.edu/> testbed when I stumbled on the five proposals that Robert posted in December. I want to express my strong support for the two HTTP proposals. Hourly [CDN-HTTP] would be great (eventually with HTTPS support). ([STARTTLS] also sounds good, but I haven't thought deeply about it, and [ONLY-PUBLIC] sounds good unless it costs RIPE Atlas support / probe hosts) I was wondering about the feasibility of allowing HTTP measurements towards PEERING experiments (meaning, towards our address space announced from an experiment via our routers). Is that something that you might be open to supporting? This came to mind because we are in the process of onboarding PEERING to some bring-your-own-prefix services offered by CDNs and cloud providers, and so an increasing number of PEERING experiments are about content delivery/cloud hosting, and it would be great if RIPE Atlas could act as measurement clients to provide widespread vantage points. One hands-off option that comes to mind is to set them up similar to the proposal for CDN-HTTP, where probes will regularly fetch an object at a fixed URL, say http://ripeatlas.ee.columbia.edu/testobject. Normally, that could resolve to our project webserver, which is hosted in AWS. When an experiment needs this HTTP capability (all experiments undergo review by at least 2 people for safety, and we enable only the capabilities they request and need, following the principle of least privilege), we could instead redirect it to a PEERING address allocated to the project that would host the same test object but that would be announced from cloud/CDN/PEERING sites however the experiment had configured. Alternatively, it could be a measurement available to approved accounts, and we could pass on which experiments are approved, or perhaps available to all accounts. We have fixed address space, if you have a way to whitelist. We maintain our list of prefixes as RS-PEERING-TESTBED on RIPE's IRR. I believe Johan recently contacted Kevin Vermeulen about talking to us about RIPE Atlas in the context of another one of our projects, so possibly we can have a discussion covering both topics. Thanks for all your work providing the platform -- it's great! Ethan -- http://www.columbia.edu/~ebk2141/

1 0

Errors on Measurement web interface
by ripe＠brite.cz 01 Mar '23

01 Mar '23

Hi team, I see issues with Latencymon, such as https://atlas.ripe.net/measurements/48750273/#latencymon Upon opening it displays message "Server is responding slowly", after a while it displays the default view. But when I expand the time range a bit, or make any change to the view, it will show nothing and after a while displays message "It is not possible to download data from the API" Tried Firefox and Chrome, same result. The same result when I open only the frame, such as https://atlas.ripe.net/frames/measurements/48750273#latencymon

2 1

Re: [atlas] Measurement question
by Michel Stam 20 Feb '23

20 Feb '23

Hello Roberto, I’ve done the exact same measurement too, using the 3 types of traceroute available (ICMP, UDP and TCP). UDP: (https://atlas.ripe.net/measurements/49826077/#general) TCP: (https://atlas.ripe.net/measurements/49826078/#general) ICMP: (https://atlas.ripe.net/measurements/49826076/#general) The way the traceroute works in Atlas is that if 5 hops have been received without response, the trace skips over to TTL 255 and ends the traceroute. This is what you see with TCP and ICMP. The traceroute stops for lack of response. To prove that, I’ve run the trace again, skipping hops 1-7, for both ICMP and TCP: https://atlas.ripe.net/measurements/49826868/#general https://atlas.ripe.net/measurements/49826959/#general Now for the interesting bits: 100.64.0.0/10 is CGN (Carrier Grade NAT), RFC 6598. Looking at the traceroute differently: Hop 1 (AS16509, Amazon EU West, Amazon-02) Hop 2-7 CGN Hop 8-9 (AS unknown, but between UK and US, IPROU3-ARIN, so Amazon IP routing 3) Hop 10 (AS unknown, but between UK and US, IPROU3-ARIN/ARMP-ARIN, Amazon IP routing) Hop 11-15 CGN Hop 16 (AS unknown, presumably US, IPROU3-ARIN/ARMP-ARIN, I presume Amazon IP routing still) Hop 17-19 CGN Hop 20 (AS13335, Cloudflare US) So it seems like every cloud zone interconnect (amazon Europe west, US, then Cloudflare) transitted goes through a CGN setup. Not sure but I can understand if this confuses some types of traffic. I don’t think there’s anything wrong with your setup, but the results are interesting. I’ve copied a couple of our researchers onto the mail as they may be interested in this as well. Regards, Michel > On 8 Feb 2023, at 11:33, roberto.lucignani(a)caleidos.it wrote: > > Hi Michael, > for example, one measure ID is this one: 49813750 > The result says there are 7 HOPS. > The result of the traceroute made directly on the host is the following one > traceroute to www.madghigno.tech (172.67.221.209), 30 hops max, 60 byte packets > 1 52.56.0.19 24.303 ms 52.56.0.31 9.067 ms 52.56.0.17 29.663 ms > 2 * 100.65.18.192 7.843 ms 100.65.19.176 6.252 ms > 3 100.66.8.254 1.563 ms 100.66.8.146 0.697 ms 100.66.8.168 1.449 ms > 4 100.66.10.138 8.469 ms 100.66.10.14 5.713 ms 100.66.10.6 8.127 ms > 5 100.66.7.77 1.653 ms 100.66.6.173 2.658 ms * > 6 100.66.4.75 2.726 ms 100.66.4.87 2.327 ms 100.66.4.89 1.550 ms > 7 100.65.10.65 0.533 ms 100.65.11.1 0.857 ms 100.65.10.161 8.616 ms > 8 15.230.158.29 2.062 ms 15.230.158.171 5.998 ms 15.230.158.27 1.617 ms > 9 15.230.158.164 1.315 ms 52.94.33.120 2.089 ms 15.230.158.40 1.484 ms > 10 54.239.101.83 1.440 ms 150.222.65.23 1.358 ms 54.239.101.87 1.897 ms > 11 100.91.211.7 1.368 ms 100.91.13.66 1.956 ms 100.91.13.100 5.077 ms > 12 100.91.210.16 1.837 ms 100.100.6.119 1.848 ms 52.93.134.81 2.178 ms > 13 100.100.73.70 2.434 ms 100.91.203.106 4.546 ms 100.100.85.70 1.139 ms > 14 100.91.207.15 1.289 ms * 100.100.72.67 1.767 ms > 15 100.100.2.76 3.616 ms 100.91.201.140 1.955 ms 100.91.205.18 1.744 ms > 16 99.83.89.19 6.820 ms 100.91.201.1 2.454 ms 100.91.201.97 2.415 ms > 17 100.91.211.89 17.823 ms 172.71.176.2 3.200 ms 172.70.160.2 4.450 ms > 18 100.100.6.77 1.805 ms 100.100.6.3 1.943 ms 100.100.6.111 2.005 ms > 19 100.100.80.70 1.980 ms 100.100.76.134 2.679 ms 100.100.69.134 2.081 ms > 20 172.67.221.209 2.799 ms 100.100.89.209 7.318 ms 100.100.89.17 6.869 ms > Since the website is served by cloudflare the route may vary between requests but the are always around 18/20 HOPS > I don’t understand if I0m missing something here. Let me know if you need further details > Regards, > Roberto > From: Michel Stam <mstam(a)ripe.net> > Date: Wednesday, 8 February 2023 at 10:13 > To: roberto.lucignani(a)caleidos.it <roberto.lucignani(a)caleidos.it> > Subject: Re: [atlas] Measurement question > Hello Roberto, > Would you be able to share screenshots/measurement ids so we can have a look? > Regards, > Michel > > > On 8 Feb 2023, at 09:04, roberto.lucignani(a)caleidos.it wrote: > I’m doing some measurement from one of my software probes, the measure is a traceroute to a destination. > The results I get are completely different from what I see doing the same traceroute directly on host where the probe is installed. I configured the measure to sue the DNS resolution on the probe.. > From the Atlas portal I get a traceroute with 7 hops, doing it directly on the host returns 28 hops, for the same destination. > Why this difference ? > Regards, > Roberto > -- > Mail sent with Outlook for Mac > This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this message from your system. E-mail transmission cannot be guaranteed to be secure or error-free, because information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmission. > -- > ripe-atlas mailing list > ripe-atlas(a)ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas

2 4

Offering a v1 probe for adoption in RU
by Roman Mamedov 20 Feb '23

20 Feb '23

Hello, I am offering my probe to someone else within Russia for "adoption" (ownership transfer). Despite being a v1, it still runs well with no downtime. Contact me on Telegram via @romanrm to discuss (in Russian or English), or via E-Mail if you don't have an account. Thanks -- With respect, Roman

1 0

Atlas V5 - Rack-Mounting Solution
by Johannes Schiemer 19 Feb '23

19 Feb '23

Dear all, As I have just received my Atlas V5 Probe and wanted to mount it in my Rack, I've decided to 3d-Print a holder for the probe. I've also decided to share it with all of you in the hopes that some of you might find it useful. This is the link to thingiverse: https://www.thingiverse.com/thing:5864347 Thanks! Greetings, Johannes

1 0

Missing ping and traceroute dumps for 2023-01-23
by Maxime Mouchet 15 Feb '23

15 Feb '23

Hi, I noticed that there is no ping and traceroute dumps for 2023-01-23: https://data-store.ripe.net/datasets/atlas-daily-dumps/2023-01-23/ The other days are fine though. Is there any chance to get these dumps? Or are they just lost? Thanks! Maxime

2 3

Measurement question
by roberto.lucignani＠caleidos.it 08 Feb '23

08 Feb '23

I’m doing some measurement from one of my software probes, the measure is a traceroute to a destination. The results I get are completely different from what I see doing the same traceroute directly on host where the probe is installed. I configured the measure to sue the DNS resolution on the probe.. >From the Atlas portal I get a traceroute with 7 hops, doing it directly on the host returns 28 hops, for the same destination. Why this difference ? Regards, Roberto -- Mail sent with Outlook for Mac This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this message from your system. E-mail transmission cannot be guaranteed to be secure or error-free, because information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmission.

1 0

New ripe-atlas-tools and ripe-atlas-cousteau
by Chris Amin 07 Feb '23

07 Feb '23

Dear colleagues, I'm pleased to announce the release of version 3.1.0 of the RIPE Atlas command-line tools, which allow you to use RIPE Atlas from the comfort of your shell: https://github.com/RIPE-NCC/ripe-atlas-tools/ The changes for this release include: * Improved probe-search and measurement-search, including machine-readable "csv" and "tab" output formats * --stream-timeout and --stream-limit added to measure command In addition, this release depends on the new ripe-atlas-cousteau==2.0.0, which uses the new WebSocket-based RIPE Atlas streaming API. Regards, Chris Amin RIPE NCC

1 0

Rate limiting on the APIs
by Robert Kisteleki 06 Feb '23

06 Feb '23

Dear all, We have seen in the past that even with the best intentions, every now and then some users are using excessive amounts of requests to the RIPE Atlas APIs, in some cases resulting in degraded performance to all users. An example for the curious: some AWS account asking the probe API for live queries once a day at 8am like clockwork; over a million queries for probe statuses (note: we don't have a million probes - every query is repeated hundreds or thousands of times) [1] We will apply rate limiting to protect from (some of) these. In particular: * The API in general will impose a limit of no more than 300 queries/second (if done over multiple connections) * The measurement API in particular will impose a limit of 150 queries/second (if done over multiple connections) * When reaching the limit, an HTTP response code of 429 (Too Many Requests; https://www.rfc-editor.org/rfc/rfc6585#section-4) will be given. According to our logs these limits will in general not be visible to users. Users going over these limits will see the 429 response code; client libraries should be able to handle this. We will observe the effect of these measures to determine if we need to tighten further - or perhaps relax them. We plan to apply these changes sometime next week; I'll let you know once they are in place. Regards, Robert [1] a much better way of doing this is to use the probe archive (https://ftp.ripe.net/ripe/atlas/probes/archive/); this is one-time fetch of 2MB or so and probe statuses are pretty stable in general

1 1

Fwd: Deprecating failed prefixes in the host
by Brian E Carpenter 02 Feb '23

02 Feb '23

FYI -------- Forwarded Message -------- Subject: Re: Deprecating failed prefixes in the host Date: Thu, 2 Feb 2023 17:14:22 +1300 From: Brian E Carpenter <brian.e.carpenter(a)gmail.com> To: IPv6 Operations <v6ops(a)ietf.org> Answering some of the comments made, the new version now at https://github.com/becarpenter/misc/blob/main/deprecator.py picks a random RIPE Atlas anchor probe as its ping target (unless the user supplies their own ping target). Thanks to the RIPE Atlas community for not shooting me down in flames. (An even better approach would be choose a new random ping target every hour or so, it's easy enough to code that too.) On my Windows host, I have noticed some odd behaviour of the source selection logic if a ULA is active. No such problem on Linux. For personal reasons I have no time to track that down right now. Again, there's no pretence that this is an operational solution; it's just a proof of half-baked concept. Regards Brian On 24-Jan-23 15:20, Brian E Carpenter wrote: > Hi, > > We keeping falling over the same issue with multi-provider multi-homing: routing magic can keep traffic away from the link to/from a failing provider, but hosts don't know about this and keep sending traffic *from* addresses within the failing provider's prefix. > > As Eduard Vasilenko has pointed out, source address selection at the host is the root cause of this, and RFC6724 doesn't specify a way to change source address selection automatically. Also, we don't currently have a mechanism for rapidly withdrawing a failing prefix. > > To be clear, a typical user program acting as a client uses getaddrinfo() to choose a destination address, but does not use bind() to set a source address - instead it uses connect() and the system chooses a source address. So the need is to avoid choosing a source address that lies within the prefix of a failing provider. > > This message suggests a host-only mechanism to achieve this. If you want a name for it, > consider "unhappy eyeballs". I'm not claiming originality, because it seems obvious to me. > > The mechanism is brutal: have a program running continuously on the host that regularly tests the liveness of each assigned source address, e.g., once a minute. The liveness test is simply a ping to some target address somewhere in the Internet, sourced from the address being tested (i.e., it *does* use bind()). If the ping fails several times in a row, deprecate the source address in question, i.e. set its preferred lifetime to zero. RFC6724 will then ignore it, so no new sessions will use it. Keep the deprecated address in the liveness test, and if it starts to work again, un-deprecate it (i.e. restore its lifetime). > > This is brutal because it does nothing for sessions that are already in progress when a source address fails. They will just time out. I'm sure that solutions such as TAPS is proposing will be much more elegant. It's also brutal because it doesn't know anything about prefixes, it just detects failing /128 addresses. (I don't know if there is a userland mechanism for deprecating a whole prefix.) But this works for legacy client code that simply uses connect(). > > Sounds horrible? Yes. It's also very hard to test; I don't have a setup that allows a proper test. But simulating a ping failure isn't so hard. > > You can find a quick and nasty Python version for Windows 10 and Linux at > https://github.com/becarpenter/misc/blob/main/deprecator.py > This is experimental software that might disturb network access; if you run it, it is entirely at your own risk. It needs sudo or Administrator privilege. > > There's an associated and harmless test program at > https://github.com/becarpenter/misc/blob/main/deptest.py > > (By the way, there seems to be an unexpected interaction between the RFC6724 source-selection algorithm and the presence of a ULA on Windows 10: under investigation.) > > Regards > Brian Carpenter

1 0

Encouraging people to upgrade software probe versions
by Seth David Schoen 01 Feb '23

01 Feb '23

Hi, I recently posted two threads ultimately related to the same question, where it turned out that a feature I wanted to use was present in the current software probe release, but not in the old version that I had installed. It was indeed relatively easy to upgrade (as a reply on this list predicted, the upgrade didn't break anything or require any reconfiguration). But I'd still say "relatively easy", because, on the other hand, the upgrade wasn't managed through my OS package manager like the rest of the software on my VPS server. It appears to me that a lot of software probes (like mine was until recently!) are still running whichever software probe version was current when they were first deployed. After all, I don't believe there's automatic software upgrade functionality in the methods that most people are using to deploy these. Is that true from the point of view of the rest of the Atlas community? Is there anything that might usefully be done to encourage people to upgrade periodically? (For example, either sending some kind of e-mail reminder, or distributing probe software via OS package managers, or even including a mechanism in the probe client itself by which it could upgrade itself -- even if as an opt-in feature?)

10 28