- ripe-atlas - mailman.ripe.net

credit transfer - 2 issues
by Paul Emmons 11 Jul '23

11 Jul '23

Hello all. First off, does the standing order for transferring credits form work? I have tried it a few times with no success on chrome and firefox. I submit it and nothing happens. And I can't seem to get a transfer done via a curl method - just get a invalid method response. A sample of the code we were trying is: curl -H "Content-Type: application/json" -H "Accept: application/json" -X POST -d '{ "amount":"1999999" , "recipient":"paul@somedomain" }' https://atlas.ripe.net/api/v2/credits/transfer/?key=a-real-key Thanks Paul

2 1

Accuracy of “Consumption Delay”
by Ernst J. Oud 01 Jul '23

01 Jul '23

L.S. To feed to the discussion… currently the “Consumption Delay” indicator is green while results of a new measurement still take a long time (half an hour or more) to be reported fully in the web interface. So this indicator cannot be fully relied on it seems. Met vriendelijke groet / Regards, Ernst J. Oud

1 0

Delays in backend…
by Ernst J. Oud 01 Jul '23

01 Jul '23

Hi, Measurements stream fine in Magellan, but results only show up in the web interface after - in extreme cases - hours. The RIPE status info says: Resolved This incident has been resolved. Posted 1 day ago. Jun 29, 2023 - 10:11 UTC Investigating We are experiencing issues with the RIPE Atlas backend and currently are investigating this issue. Posted 1 day ago. Jun 29, 2023 - 08:55 UTC But clearly this has not been resolved! Regards, Ernst J. Oud

2 3

RIPE Atlas Quarterly Planning Q3 2023
by Robert Kisteleki 28 Jun '23

28 Jun '23

Dear colleagues, We have published our next quarterly plans for RIPE Atlas on our website: https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas This quarter, we'll continue discussing the five proposals for changing the RIPE Atlas behaviour and start working on renewing the big data backend. 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

Magellan
by Ernst J. Oud 26 Jun '23

26 Jun '23

Hi, Perhaps someone can help me. I use Magellan to create a measurement using connected probes on AS15435. First I search for probes using Magellan and then I supply the ID’s returned of those probes reported as “connected” when creating the measurement. I don’t want to wait for the stream to time-out so I use the “stream-limit” parameter, equal to the number of supplied connected probes. So when that number of connected probes have supplied data the streaming is complete. However, it appears that probes are reported as connected by Magellan but do not supply data when specified for a measurement, for instance probe 2565. That probe is Reported by Magellan as connected but when I use it in a measurement it does not supply data. Thus streaming will only time-out and does not stop not when spevified connected probes have supplied data. Apparantly “connected” does not imply “can be used in a measurement”. How can I supply probe ID’s in a “create measurement” command using Magellan knowing for sure that these probes will supply data? Regards, Ernst J. Oud

2 2

Recovered probe v3
by Renny Leal 26 Jun '23

26 Jun '23

Hi folks I’ve recovered one V3 probe but sadly the person who got it flashed the tp-link original firmware to the device. Is there any way to get the ripe atlas firmware back to it? Thanks in advance Enviado desde Correo<https://go.microsoft.com/fwlink/?LinkId=550986> para Windows

2 1

Fw: Action Required: RIPE Atlas Probe 52974 and RIPE NCC Days Sofia invitation
by Endre Szabo 21 Jun '23

21 Jun '23

Hi folks, I've got a probe running at a very remote site. Since the energy prices were skyrocketing with the crisis here in Eastern Europe, the probe does not have 7x24 power anymore. It is down for 10-ish hours a weekday. It's been running like this for months now. Suddenly, I've just got this mail below about my probe. The probe is online every day and was online today as well. Does this mail mean that RIPE is unsatisfied with my uptime, and I must return the probe? Or is it some monitoring needing some tuning? --Endre ----- Forwarded message from RIPE Atlas <no-reply(a)ripe.net> ----- From: RIPE Atlas <no-reply(a)ripe.net> Subject: Action Required: RIPE Atlas Probe 52974 and RIPE NCC Days Sofia invitation Date: Tue, 20 Jun 2023 13:01:05 -0000 Dear Endre Szabo, We hope this email finds you well. We noticed that your probe with ID 52974 has been disconnected for some time now, and you have probably received reminders from our system asking you to reconnect it. We would like to request you to please either reconnect the probe, or if that is not possible, to return it to us to be refurbished. There is a long waiting list of people keen to receive new probes, and because of global component shortages, we have a very limited number available. 1. You can check your probe using this link below. https://atlas.ripe.net/probes/52974/#tab-status If your probe is already online, you can stop reading here! 2. If you need to troubleshoot a disconnected probe, you can take a look at our tutorials on YouTube, or write to us asking for assistance. https://www.youtube.com/watch?v=BGj1MDIclDQ 3. If the probe is beyond repair, please go here: https://atlas.ripe.net/probes/52974 and click on the "Write-off" button at the bottom of the page. This will allow you to choose a reason for writing off the probe. This will clear the probe host name, and you will no longer receive any more reminders from us about the probe. 4. If you no longer wish to host the probe, please follow step 3 and then send the probe back to us. We will refurbish and redistribute it. Please use this address for shipping: RIPE NCC P.O. Box 10096 1001 EB Amsterdam The Netherlands ===== RIPE NCC Days Sofia, Bulgaria And finally, join us at RIPE NCC Days Sofia, Bulgaria on 27-28 June 2023! This free event provides a unique opportunity for network operators and technical staff to share knowledge and experiences. Don't miss out – register now at https://www.ripe.net/participate/meetings/regional-meetings/ripe-ncc-days-s… . We look forward to seeing you there! ===== Thank you for continuing to support RIPE Atlas. Best regards, The RIPE Atlas Team ----- End forwarded message -----

2 2

Fw: Action Required: RIPE Atlas Probe 52974 and RIPE NCC Days Sofia invitation
by Endre Szabo 20 Jun '23

20 Jun '23

Hi folks, I've got a probe running at a very remote site. Since the energy prices were skyrocketing with the crisis here in Eastern Europe, the probe does not have 7x24 power anymore. It is down for 10-ish hours a weekday. It's been running like this for months now. Suddenly, I've just got this mail below about my probe. The probe is online every day and was online today as well. Does this mail mean that RIPE is unsatisfied with my uptime, and I must return the probe? Or is it some monitoring needing some tuning? --Endre ----- Forwarded message from RIPE Atlas <no-reply(a)ripe.net> ----- From: RIPE Atlas <no-reply(a)ripe.net> Subject: Action Required: RIPE Atlas Probe 52974 and RIPE NCC Days Sofia invitation Date: Tue, 20 Jun 2023 13:01:05 -0000 Dear Endre Szabo, We hope this email finds you well. We noticed that your probe with ID 52974 has been disconnected for some time now, and you have probably received reminders from our system asking you to reconnect it. We would like to request you to please either reconnect the probe, or if that is not possible, to return it to us to be refurbished. There is a long waiting list of people keen to receive new probes, and because of global component shortages, we have a very limited number available. 1. You can check your probe using this link below. https://atlas.ripe.net/probes/52974/#tab-status If your probe is already online, you can stop reading here! 2. If you need to troubleshoot a disconnected probe, you can take a look at our tutorials on YouTube, or write to us asking for assistance. https://www.youtube.com/watch?v=BGj1MDIclDQ 3. If the probe is beyond repair, please go here: https://atlas.ripe.net/probes/52974 and click on the "Write-off" button at the bottom of the page. This will allow you to choose a reason for writing off the probe. This will clear the probe host name, and you will no longer receive any more reminders from us about the probe. 4. If you no longer wish to host the probe, please follow step 3 and then send the probe back to us. We will refurbish and redistribute it. Please use this address for shipping: RIPE NCC P.O. Box 10096 1001 EB Amsterdam The Netherlands ===== RIPE NCC Days Sofia, Bulgaria And finally, join us at RIPE NCC Days Sofia, Bulgaria on 27-28 June 2023! This free event provides a unique opportunity for network operators and technical staff to share knowledge and experiences. Don't miss out – register now at https://www.ripe.net/participate/meetings/regional-meetings/ripe-ncc-days-s… . We look forward to seeing you there! ===== Thank you for continuing to support RIPE Atlas. Best regards, The RIPE Atlas Team ----- End forwarded message -----

1 1

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

Notification of brief downtime for anchor - ie-dub-as1213
by Mick O'Donovan 31 Jan '23

31 Jan '23

Hi all, I just wanted to give you a brief proactive notification that we, HEAnet, shall be taking our RIPE Atlas anchor called ie-dub-as1213 offline for a brief period as per the below to perform a network maintenance on the edge device it connects to. Date - 8th February 2023 Time - UTC 08:00 - 09:00 Regards, Mick -- Mick O’Donovan Senior Network Engineer HEAnet CLG Ireland's National Education and Research Network 1st Floor | 5 George's Dock | IFSC | Dublin D01 X8N7 | Ireland +353 1 6609040 | mick.odonovan(a)heanet.ie | www.heanet.ie Registered in Ireland, No. 275301 | CRA No. 20036270

1 0

Notification of brief downtime for anchor - ie-dub-as1213
by Mick O'Donovan 31 Jan '23

31 Jan '23

Hi all, I just wanted to give you a brief proactive notification that we, HEAnet, shall be taking our RIPE Atlas anchor called ie-dub-as1213 offline for a brief period as per the below to perform a network maintenance on the edge device it connects to. Date - 8th February 2023 Time - UTC 08:00 - 09:00 Regards, Mick -- Mick O’Donovan Senior Network Engineer HEAnet CLG Ireland's National Education and Research Network 1st Floor | 5 George's Dock | IFSC | Dublin D01 X8N7 | Ireland +353 1 6609040 | mick.odonovan(a)heanet.ie | www.heanet.ie Registered in Ireland, No. 275301 | CRA No. 20036270

1 0

Atlas anchors as ping targets
by Brian E Carpenter 30 Jan '23

30 Jan '23

Hi, I have a question about using Atlas anchors for a special purpose. Is the following acceptable, or would people have objections to the following idea? TL;DR: Is it OK to use Atlas anchors as random ping targets? Over in IETF-land we are (again) debating how to make IPv6 multi-provider multihoming work properly. There's a scenario description and picture at https://github.com/becarpenter/book6/blob/main/6.%20Management%20and%20Oper… One unsolved problem is that if one provider fails, many client applications may continue to use a source address belonging to that provider, instead of switching to a source address belonging to the other provider. One approach to solving this without any changes except in the host is to magically deprecate failing source addresses until they work again. One approach to that is a pure hack - a program that runs in the background pinging a remote target from various source addresses, to deprecate and undeprecate them as appropriate. There's code at https://github.com/becarpenter/misc/blob/main/deprecator.py. This is experimental software that might disturb network access. 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.) I am quite sure that this code is only of interest to a few IPv6 geeks. It could of course be instrumented for measurement purposes, but multihomed sites of this kind are so rare that I don't think there would be much to measure. Regards Brian Carpenter

3 4

Access to probes and documents
by Mccherry, Paul (Postgraduate Researcher) 30 Jan '23

30 Jan '23

Althiough I am logged in when trying to access various probes I do not seem to have the rights, probes such as 91,353,365,3094.... Additionally I noticed I cannot access any documents on RIPE labs such as 'RIPE IPmap: geolocating routes across the internet' or 'Five proposals for a better RIPE Atlas.' Can anyone resolve these access rights please ? Regards Paul McCherry Phd Researcher Lancaster University

2 2

TLS Certificate probes fail ("handshake failure") against Vercel servers
by Daniel Kahn Gillmor 25 Jan '23

25 Jan '23

Hi RIPE Atlas folks-- I noticed today that using the "SSL" probe (gathering X.509 certificates from a TLS endpoint) appears to fail against servers operated by Vercel. the failure is a uniform "handshake failure" according to the web interface. I think this might be a bug in the probe's implementation of the client side of TLS. Where could i find the specific implementation of that probe type so that i can debug it further? Or, if this is a known issue, where can i read up on it in more detail? I've demonstrated this by probing Vercel's own servers, since they appear to be eating their own dogfood. You can see this with measurement 49131334: https://atlas.ripe.net/measurements/49131334/#probes here is the definition of the query i made: { "definitions": [ { "target": "vercel.com", "af": 4, "port": 443, "hostname": "vercel.com", "description": "SSL measurement to vercel.com", "resolve_on_probe": true, "skip_dns_check": false, "type": "sslcert" } ], "probes": [ { "type": "area", "value": "WW", "requested": 10 } ], "is_oneoff": true, } This is pretty odd, since normal TLS clients appear to be able to connect to them fine. Here's me running a manual handshake debugger against vercel.com's servers: $ gnutls-cli-debug vercel.com GnuTLS debug client 3.7.8 Checking vercel.com:443 whether the server accepts default record size (512 bytes)... yes whether %ALLOW_SMALL_RECORDS is required... no whether we need to disable TLS 1.2... no whether we need to disable TLS 1.1... no whether we need to disable TLS 1.0... no whether %NO_EXTENSIONS is required... no for TLS 1.0 (RFC2246) support... no for TLS 1.0 (RFC2246) support with TLS 1.0 record version... no for TLS 1.1 (RFC4346) support... no fallback from TLS 1.1 to... failed for TLS 1.2 (RFC5246) support... yes for TLS 1.3 (RFC8446) support... yes for known TLS or SSL protocols support... yes TLS1.2 neg fallback from TLS 1.6 to... failed (server requires fallback dance) for HTTPS server name... Vercel for certificate chain order... sorted for safe renegotiation (RFC5746) support... yes for encrypt-then-MAC (RFC7366) support... no for ext master secret (RFC7627) support... no for heartbeat (RFC6520) support... no for version rollback bug in RSA PMS... yes whether the server ignores the RSA PMS version... yes whether small records (512 bytes) are tolerated on handshake... yes whether cipher suites not in SSL 3.0 spec are accepted... yes whether a bogus TLS record version in the client hello is accepted... yes whether the server understands TLS closure alerts... yes whether the server supports session resumption... yes for anonymous authentication support... no for RSA key exchange support... no |<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice for ephemeral Diffie-Hellman support... yes |<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice for RFC7919 Diffie-Hellman support... no for ephemeral EC Diffie-Hellman support... yes for VKO GOST-2012 (draft-smyshlyaev-tls12-gost-suites) support... no for curve SECP256r1 (RFC4492)... yes for curve SECP384r1 (RFC4492)... yes for curve SECP521r1 (RFC4492)... yes for curve X25519 (RFC8422)... yes for AES-GCM cipher (RFC5288) support... yes for AES-CCM cipher (RFC6655) support... no for AES-CCM-8 cipher (RFC6655) support... no for AES-CBC cipher (RFC3268) support... no for CAMELLIA-GCM cipher (RFC6367) support... no for CAMELLIA-CBC cipher (RFC5932) support... no for 3DES-CBC cipher (RFC2246) support... no for ARCFOUR 128 cipher (RFC2246) support... no for CHACHA20-POLY1305 cipher (RFC7905) support... yes for GOST28147-CNT cipher (draft-smyshlyaev-tls12-gost-suites) support... no for MD5 MAC support... no for SHA1 MAC support... no for SHA256 MAC support... no for GOST28147-IMIT MAC (draft-smyshlyaev-tls12-gost-suites) support... no for max record size (RFC6066) support... no for OCSP status response (RFC6066) support... yes $ Thanks for any pointers, --dkg

2 2

Duplicate packet detection in traceroute results
by Ana Custura 20 Jan '23

20 Jan '23

Hi everyone, Just a question on how Atlas detects duplicate ('dup') packets in a traceroute. Is the 'dup' field added to a result when two received packets are exactly the same, regardless of whether they were received for a different initial TTL? Or are any packets that were unexpectedly received for a specific TTL marked as duplicates (e.g. if you receive 6 replies from 2 different IP addresses to the 3 initial packets sent with TTL 1, will 3 of these replies be marked as duplicates)? Thanks for your help! Regards, Ana

2 2

Re: [atlas] ripe-atlas Digest, Vol 137, Issue 8
by Geert Jan de Groot 19 Jan '23

19 Jan '23

On 09/01/2023 11:32, ripe-atlas-request(a)ripe.net wrote: > 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. > > 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? One question perhaps is if a probe running very obsoleted probe code, is useful or perhaps at some time probes older than version 1234 should not be used for pool measurements? For instance, release 2345 enables measurements on 240/12 while older releases, including release 2344, 240/12 is broken. Then, having probes with software 2344 or lower will give bias on measurements for 240/12. And for that reason I wonder if it makes sense to have a policy to "phase out" probes that are running obsoleted code, however well intended? Geert Jan

2 1

probes on mobile opérateurs
by Cristel Pelsser 13 Jan '23

13 Jan '23

Hello, We are looking for RIPE atlas probes that are connected to mobile operators. Could you drop me an email with the id of the probe if you have such a probe? We found some but would like to enlarge our study. Best regards, Cristel

4 3

Proposal: Remove support for non-public measurements [ONLY-PUBLIC]
by Robert Kisteleki 11 Jan '23

11 Jan '23

Dear RIPE Atlas users, We recently published a RIPE Labs article containing a few proposals: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. We'd like to encourage you to express your comments about this proposal (if you'd like to share them) here. Regards, Robert Kisteleki For the RIPE Atlas team

15 24

V3 Probe: USB Flash Drive Filesystem Corrupted
by ripe.net＠toppas.net 11 Jan '23

11 Jan '23

Hello, i have two v3 probes and i'm experiencing issues: "USB Flash Drive Filesystem Corrupted" I have tried multiple USB Sticks, including brand new ones and also sticks from "good" brands like Lexar and Sandisk. The issue is not permanent, the error appears and disappears from time to time: 2022-12-22 @ 12:14:04 UTC Probe auto-tagged Your probe #xxxxx was automatically tagged as "system: Flash drive filesystem corrupted" 2022-12-22 @ 18:14:42 UTC Probe auto-untagged Your probe #xxxxx was automatically untagged as "system: Flash drive filesystem corrupted" This leads me to the thought, that the flash storage is not the real problem. It's unlikely, since i tried multiple dongles. Could it be possible, that not the flash storage is broken, but the speed of the USB dongles is too low? All dongles I tried were USB 2.0, not 3.0, since the TP-Link TL-MR3020 is not USB 3.0 capable anyway. But maybe USB 3.0 is a better choice? What do you think? BR, Simon

2 6

Proposal: Add support for STARTTLS measurements [STARTTLS]
by Robert Kisteleki 09 Jan '23

09 Jan '23

Dear RIPE Atlas users, We recently published a RIPE Labs article containing a few proposals: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. We'd like to encourage you to express your comments about this proposal (if you'd like to share them) here. Regards, Robert Kisteleki For the RIPE Atlas team

4 3

Re: [atlas] Ability to traceroute to 240/4 - software vs. hardware probes
by Seth David Schoen 09 Jan '23

09 Jan '23

Hi! I noticed that Phillip Homburg merged a RIPE Atlas client patch in November of last year, based on our request, that removes the Atlas probe's inability to test addresses in 0/8 and 240/4. https://github.com/RIPE-NCC/ripe-atlas-probe-measurements/commit/59475f848b… So, I just tried a couple of measurements to 240.1.2.3 to see how Atlas would handle them: https://atlas.ripe.net/measurements/48100582/ https://atlas.ripe.net/measurements/48100585/ (I don't expect these to succeed, as no part of 240/4 is publicly announced in BGP; the interesting information to be garnered from this isn't whether the probes succeed, but how they fail.) For the first measurement, with ping, 6 hardware probes and 4 software probes all gave the same result: "Unreachable" (which is what you would get if you ran this on any ordinary Internet host with command-line ping). For the second measurement, with traceroute, 6 hardware probes all actually attempted the traceroute (getting failures after some small number of network hops), while 3 software probes all reported back "!address not allowed". What could account for the difference in how hardware and software probes handle this task? I would have thought that the change from last November would make software probes willing to attempt these.

2 2

Magellan report on built-in measurement 1
by Ernst J. Oud 09 Jan '23

09 Jan '23

Asked this question before but that post did not make it to the mailing list: Why can’t Magellan report on built-in measurement 1 (first hop)? It always shows “No packets found”. Met vriendelijke groet/Regards, Ernst J. Oud

2 1

Positively meant critique …
by Ernst J. Oud 09 Jan '23

09 Jan '23

LS. Is there a kind of common understanding what this mailing list is about? What its purpose is? I see important discussions such as those on private measurements but no conclusions… I ask questions that lead to response from a RIPE employee but not to answers/solutions… (For instance on why results from first hop measurement to ping.ripe.net cannot be reported on by Magellan.) Can RIPE give some explanation what the use for them is of this mailing list? Are there other entries into RIPE for support questions? Would some kind of forum not be a much better solution to discuss matters with probe “owners” instead of using old fashioned unstructured mailing lists… the way we did things when the internet was in its infancy? Regards, Ernst J. Oud

2 1

New version of the WR802N probe write-up
by Ernst J. Oud 04 Jan '23

04 Jan '23

L.S. Added a paragraph on security. Shame on me not adding that in the first version. Available at http://www.kineta.nl/atlas/wr802n-write-up-v2.pdf Regards, Ernst J. Oud

1 0

Use TP-Link WR802N as an Atlas probe
by Ernst J. Oud 04 Jan '23

04 Jan '23

Hi, I promised to create a write-up on how to turn the low cost, energy efficient, TP-Link travel router WR802N into a fully functional Atlas probe. This write-up is now available at: http://www.kineta.nl/atlas/wr802n-write-up-v1.pdf Might be an idea perhaps to also mention the document somewhere on the RIPE Atlas blog pages? My email address is on the last page of the document for any questions. In case you wonder, kineta.nl is the (very, very old) website of my company before I retired. The .pdf is malware free (at least that is what Microsoft Defender says). If your house burns down following the actions in the document don't blame me. Happy hacking. Regards, Ernst

3 2

Updating software probe version (with .deb package)
by Seth David Schoen 31 Dec '22

31 Dec '22

Hi, I have a software probe which I installed by creating a Debian package from source (as described in INSTALL.rst). The documentation suggests that one should regularly update software probe versions, and I'm interested in upgrading mine -- I was reminded by my earlier question about 240/4, as I may be running a client version from prior to when the patch allowing 240/4 scans was merged. The documentation doesn't specifically mention how to upgrade; can I assume that making a new .deb from current sources, and then installing that with dpkg on a machine where an older .deb is installed, will maintain the credentials and identity of my existing probe? It won't wipe everything out and require me to re-register as a new software probe, right?

2 1