- ripe-atlas - mailman.ripe.net

Conflicting tags for resolver
by RIPE 22 Dec '24

22 Dec '24

Hi, I just noticed my probe (1008458) shows a strange status: System Resolves A or AAAA Records Incorrectly But looking at the tags I see both the resolves correctly and the resolves incorrectly tags are set for both A and AAAA. That looks like a strange combination of tags. Any idea what’s causing this ? Cheers, Paul

1 0

Probe on ctr-dub-hw01 disconnected
by Ernst J. Oud 22 Dec '24

22 Dec '24

Hi, My probe 55795 disconnected from ctr-dub-hw01. Could it be that this controller has an issue? My other probes on other controllers are fine. Regards, Ernst J. Oud

2 2

cannot forward src on fbsd
by Sulev-Madis Silber 22 Dec '24

22 Dec '24

i have fbsd box with pf that routes my traffic i get this endlessly: cannot forward src fe80:24::4e6d:580f:fc89:81ae, dst 2001:7d0:8437:13bf:da58:d7ff:fe 03:1274, nxt 58, rcvif vlan3, outif vlan91 cannot forward src fe80:24::4e6d:580f:fc89:81ae, dst 2001:7d0:8437:13bf:da58:d7ff:fe 03:1274, nxt 58, rcvif vlan3, outif vlan91 cannot forward src fe80:24::4e6d:580f:fc89:81ae, dst 2001:7d0:8437:13bf:da58:d7ff:fe 03:1274, nxt 58, rcvif vlan3, outif vlan91 sometimes androids do this a few times, but probes do it all the time. multiple hw ver probes. for a decade i get few obscure results when i look that up but don't know what this is or why i tried to sniff and iirc i found weird icmp ttl exceeded packets i think kernel is correct on that cannot forward part. i'm unsure what measurements my probes actually run the src is apparently some linklocal, dst is my probe v6, recv if is vlan3, this is my v4/v6 wan to isp, out is vlan91, this is dedivated v5 probe vlan in local network did i misconfigure something or isp or ripe or else or? does it affect measurements? i'm not sure what this issue is. i think you can't forward that traffic indeed, from ll ip to global ip? google doesn't help to even shed some light on this weird behaviour, let alone any fix doesn't bother me, just curious i'm not surprised, as this device sends and receives traffic i don't have any control of. and is specifically ip measuring device so, unsure... about all this!

1 0

Why measurements using api are apt to fail while those using web interface can usually succeed?
by 孙乐童 20 Dec '24

20 Dec '24

Dear all, I have been attempting to use Atlas to launch traceroute measurements recently. Initially, I used ripe.atlas.cousteau to run the measurements in batches, keeping the total number under 10,000 to avoid exceeding the measurement limit. However, only 10% of the measurements returned successful results, while the other 90% showed the status "scheduling denied." Next, I tried launching only 12 measurements in batch, where each measurement contained one traceroute from a specific probe to a designated IPv4 destination. Out of these, 4 succeeded and the other 8 showed the status "specified". Following that, I launched the 12 measurements one by one with 2-second intervals, resulting in a success rate of 6 out of 12. However, when I increased the interval to 3 seconds, the success rate dropped to 4 out of 12. Interestingly, when I created the same measurements for the designated probes and destinations through the web interface, all of them were successful. Below is the Python code I used to launch the measurements: fromripe.atlas.cousteauimport ( Traceroute, AtlasSource, AtlasRequest, AtlasCreateRequest, AtlasResultsRequest, AtlasLatestRequest, ProbeRequest ) traceroute=Traceroute(af=4, target=dstip, description="traceroute subpref ip {} from {}{}".format(dstip, probe_type, probe_value), protocol='ICMP') if probe_type =='asn': probe_value =int(probe_value) source = AtlasSource(type=probe_type, value=probe_value, requested=1, tags={"include": ["system-ipv4-capable"]}) _key = ATLAS_API_KEY_2 for _ inrange(2): atlas_request = AtlasCreateRequest( start_time=datetime.utcnow() + timedelta(random.randint(0, 1)), key=_key, measurements=[traceroute], sources=[source], is_oneoff=True ) (is_success, response) = atlas_request.create() if is_success: print('create_task', dstip, is_success, response) msm_id = response['measurements'][0] return Could you kindly let me know if there might be an issue with my approach or provide any advice on how to improve this process? I would greatly appreciate any guidance. Thank you very much! Best regards, Sun Letong

3 6

Requested and participating probes
by Huseyn Gambarov 13 Dec '24

13 Dec '24

Hello. I am currently working on a project that heavily relies on Ripe Atlas Ping measurements. During the development, I noticed that sometimes when, let’s say, I request 3 probes, only 2 are participating in the measurement. In the Ripe Archive, I found that there was a similar discussion here - https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/thread/D6QZS4WC5… I have two questions, that I could not find answers to, and I would be very grateful if you could help me with them. First, in the mentioned discussion it is said that there are multiple reasons why fewer probes are participating and there is ongoing work to allow users to obtain information about specific conditions that occurred during the measurement creation. Can you tell, if there is a way to get that information via API? Second, do you know if there is a reasonable timeout to wait before a new attempt to reschedule the probe that failed to participate in the first measurement? Thank you for your help. With regards, Huseyn Gambarov.

2 1

Understanding how to use the `paris` parameter
by Bhaskar, Abhishek Vasisht 13 Dec '24

13 Dec '24

Hello y'all! I'm a PhD student from Georgia Tech and had a question about the "paris" field when performing traceroute measurements. The RIPE documents states that ```Paris - A number greater than 0 will indicate the number of variations to be used for a Paris traceroute. Setting the value to 0 makes the measurement use the standard traceroute``` But regardless of what Paris value I give to the traceroute measurement, I only get one path with a single paris_id. I would expect that if I gave a paris value of 10, I should see 10 potential variations of the path between A and B, correct? Please correct me if I'm wrong. Here is an example measurement https://atlas.ripe.net/measurements/84562046 Thanks! -- Abhishek Vasisht Bhaskar Student, PhD in Computer Science Georgia Institute of Technology https://abhishekvasishtb.github.io/

1 0

MTU tracepath in RIPE atlas
by Marco Moock 12 Dec '24

12 Dec '24

Hello! Maybe some people here know the Linux tracepath application. It tests the PMTU to a destination. Could such a feature be implemented in RIPE Atlas? -- kind regards Marco Send unsolicited bulk mail to 1734020167muell(a)stinkedores.dorfdsl.de

1 0

Join Us for the "Exploring the RIPE Atlas UI" Webinar on 17 December 2024
by Michela Galante 11 Dec '24

11 Dec '24

Dear all, We are excited to invite you to the upcoming Exploring the RIPE Atlas UI Webinar, scheduled for Tuesday, 17 December 2024. Join Stephen Suess for a 45-minute webinar showcasing the key features and tools of the RIPE Atlas UI. This interactive session is designed to enhance your understanding and usage of this powerful platform. By the end of this webinar, you will be able to: • Identify and utilise key RIPE Atlas UI features to efficiently find and analyse existing Internet measurements. • Evaluate various data visualisation and analysis tools to gain meaningful insights from measurement results. • Customise the RIPE Atlas UI to suit specific usage patterns and prioritise the information you need. For more information and to register, please visit: https://learning.ripe.net/w/courses/64-exploring-the-ripe-atlas-ui/305 Kind regards, Michela Galante Senior Community Development Officer RIPE NCC

1 0

Re: Transfer of Atlas anchor ownership
by Robert Kisteleki 03 Dec '24

03 Dec '24

Hi, Can you please see to this change request? Thanks, Robert On Thu, Nov 28, 2024 at 4:05 PM Luuk Hendriks <luuk(a)nlnetlabs.nl> wrote: > Hi Robert, > > > We'd like to transfer the ownership of the Atlas anchor that I installed > at the University of Twente many moons ago. It's attached to my personal > account and we could not find a way to transfer it via the web > interface. > > It's anchor ID 6113, currently under ripe(a)luukhendriks.eu > and should go to Roland's account, roland(a)nlnetlabs.nl . > > > If there's anything more you need from me, please let me know. > > > Cheers, > luuk >

1 0

Probe #2413 somehow failing
by ripe＠brite.cz 29 Nov '24

29 Nov '24

Hi team, please have a look at Probe #2413, it shows connected but it seems it is not providing any measurements results. I tried different cables, power sources, connected to different switch, and finally move it to completely different location. It is v1 so it does not have USB memory stick. Please advise. Thanks Jiri

7 8

v2 probe repair?
by Phillip Remaker 28 Nov '24

28 Nov '24

Hello! I have an 11+ year old v2 probe Seems to be in a reboot loop. Starts up, all LEDs go blank, and it repeats. Any diagnostics I can do? Any repairs? https://atlas.ripe.net/probes/4111/#tab-network

3 6

Streaming result data missing probe information with "enrichProbes: true"
by Wouter de Vries 27 Nov '24

27 Nov '24

Hi folks, When using the Streaming API there is an option called "enrichProbes" which should cause probe metadata to be added to every result. That seems to have worked for a while, but it has stopped working. Example code (in python) to reproduce (it's the example from the docs, with just enrichProbes set to true): import json import websocket ws = websocket.WebSocket() ws.connect("wss://atlas-stream.ripe.net/stream/") params = {"streamType": "result", "msm": 1001, "enrichProbes": True} ws.send(json.dumps(["atlas_subscribe", params])) for data in ws: print(data) Example result: ["atlas_result",{"fw":5080,"mver":"2.6.2","lts":66,"dst_name":"193.0.14.129","af":4,"dst_addr":"193.0.14.129","src_addr":"192.168.1.20","proto":"ICMP","ttl":56,"size":32,"result":[{"rtt":21.447667},{"rtt":21.226292},{"rtt":21.253375}],"dup":0,"rcvd":3,"sent":3,"min":21.226292,"max":21.447667,"avg":21.3091113333,"msm_id":1001,"prb_id":50274,"timestamp":1731917452,"msm_name":"Ping","from":"85.107.81.62","type":"ping","step":240}] As you can see there is no probe metadata present. I'm fairly sure I'm doing this right and I think this worked previously. Is something broken in the backend? Best regards, Wouter

2 2

UI feature wish: "Daily Credits Balance" pie chart widget
by ripe＠nurfuerspam.de 26 Nov '24

26 Nov '24

Hi, I very much like/liked the "Daily Credits Balance" pie chart widget from the old UI dashboard (https://atlas.ripe.net/my/). It gives an instant overview of the credit revenue and expenditure stream, not only the grand total, but also the _share_ of individual probes and measurements in the revenue and expenditure streams. With the actual number being shown when hovering over an individual slice of the pie. And clicking on a slice would take one to the page of the respective probe or measurement (though it seems currently broken for measurements, possibly because of the ongoing restructuring). Is there a way to get it back in the new dashboard, refreshed obviously, and integrated into the new overall site layout? Thanks! Kind regards, R.

2 1

Probe flash drive corrupted
by Michael J. Oghia 20 Nov '24

20 Nov '24

Hi team, all: I just checked my dashboard, and one of my probes is offline. The error message says: "Your probe was automatically untagged as "system: Flash drive filesystem corrupted." Does anyone know how to fix it? Or does it require me to change the probes? If the latter is the case, how can I go about doing that? Kind regards, -Michael

2 4

Feature idea: new status "Probe (temporarily) closed for new UDMs"
by ripe＠nurfuerspam.de 20 Nov '24

20 Nov '24

Hi, Obviously, measurements are the purpose of being of the RIPE Atlas system. Thus, e.g., I take greate care to maximize probe uptime so measurements scheduled on them don't get disrupted by local events that are likely not representative of what most measurements are looking at. However, sometimes, temporary disruption may be known to come up, but is unavoidable, e.g., for maintenance of, or around the probe. Or a probe needs to be taken out of service "for good". In those cases, it is obviously hardly possible to avoid long-running measurements from being impacted, either by a short-term disruption, or by the removal of a probe altogether. And measurement owners obviously are aware of that, and need to take that into account in a way specific to each measurement's purpose. And it is obviously possible to remove, e.g., defunct probes from a running measurement and replace them with new ones. However, when a probe host knows _ahead of time_ that their probe will experience some event potentially disrupting measurements (like during planned maintenance activities), or will have to be decommissioned at a specific time in the future, how about if they could signal that condition to the Atlas infrastructure, and the infrastructure would at least not schedule _new_ measurements on such probes? E.g., by having a new probe "status" that can be explicitly set by the probe host to say, "this probe shall (perhaps just temporarily) not get any _new_ UDMs scheduled at this time (while the status is set)". Just a thought, not sure how much effort that would be to implement, and whether that would be worth the benefit of disrupting "fewer" measurements in case of foreseeable issues with a probe (or anchor), especially also upon an upcoming need to decommission one entirely. Thanks! Kind regards, R.

1 0

Re: [opensource-wg] RV: [ripe-list] Update on the Community Projects Fund 2024
by Rodolfo García Peñas (kix) 18 Nov '24

18 Nov '24

Hello, I would like to congratulate all the projects selected by the Community Projects Fund. I also wish to express my gratitude to the organising committee for initially selecting our project, 'RIPE Atlas distributed network telescope'. I am currently engaged in doctoral research on IBR traffic, and together with my supervisory team, we have proposed this project. We saw this as an ideal opportunity for the community to collect IBR traffic and make it available. We currently have a small working network of sensors (HoDiNT, Home Distributed Network Telescope [1]) and our objective is to extend the network and have RIPE manage the traffic collected. The HoDiNT sensors receive IBR traffic forwarded from the home connection router and forward it to a collector for analysis. They are fully compatible with Atlas sensors. This would enrich the traffic of other research centres, such as CAIDA or Merrit, and offer other students and research centres the possibility of having IBR traffic available for analysis. I was delighted that our project was selected, but a few hours later the organisation sent us an email stating that the RIPE Atlas team had raised some concerns about our proposal which may impact our ability to receive funding. We were requested to attend a meeting with the organisation and the RIPE Atlas team to discuss the proposal a few days later. The meeting was unfortunately not attended by a representative of RIPE Atlas. We were informed that the project was not deemed feasible. I would like to thank Alastair, who had to pass on the news to us, which is not an easy situation. I accept the decision taken, although I do not agree with either the substance or the form. I think we should have been given the opportunity to reformulate the project, maintaining the original objective but circumventing the limitations exposed. We will continue to improve HoDiNT in order to make it available to the community as soon as possible. If anyone is interested in contributing to the project, improving the code (mainly Python) and/or hosting sensors, please contact us. Due to limited resources, it is not possible to add sensors to the network openly, and we are doing so with sensors from colleagues and friends whom we thank for their time and resources. Regards, Rodolfo. [1] https://www.sciencedirect.com/science/article/pii/S138912862400402X [2] https://drive.google.com/file/d/1VGJ4PEcf-kHtFVT7rsXd9QYDqRL6rGH6/view?usp=… -- Rodolfo García Peñas (kix) http://www.kix.es/ "I asked him once how to change the key bindings and Dave said 'You use the Change Configuration command. On Unix it is abbreviated as cc.' Dave Conroy and Lawrence Stewart. On Friday, November 15th, 2024 at 14:18, Marcos Sanz via opensource-wg <opensource-wg(a)ripe.net> wrote: > FYI. Sorry for the cross-posting. > > > -----Mensaje original----- > > De: Alastair Strachan projectsfund(a)ripe.net > > Enviado el: jueves, 14 de noviembre de 2024 12:55 > > Para: ripe-list(a)ripe.net > > Asunto: [ripe-list] Update on the Community Projects Fund 2024 > > > > Dear all, > > > > After the announcement of this year’s Community Projects Fund recipients, > > some challenges emerged with the RIPE Atlas distributed network telescope > > project which would have prevented the project from achieving the goals > > outlined in the project plan. > > > > After careful consideration, the Selection Committee made the difficult > > decision to withdraw funding for the project. While we understand this is > > really disappointing for the recipients, we sincerely hope they will continue > > initiatives that bring value to our community and the Internet. > > > > The Selection Committee has now chosen another project to support from our > > pool of finalists: OpenPenny - An open-source tool to identify non-spoofed > > traffic. You can read about the project on the Community Projects Fund 2024 > > page: > > https://www.ripe.net/community/community-initiatives/cpf/previous- > > funding-recipients/funding-recipients-2024/ > > <https://www.ripe.net/community/community-initiatives/cpf/previous- > > funding-recipients/funding-recipients-2024/> > > > > Warm regards, > > Alastair Strachan > > Community Projects Fund Coordinator > > ----- > To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/opensource-wg.ripe.net/ > As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. > More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

2 1

RIPE Atlas Community Project Update
by Michael J. Oghia 15 Nov '24

15 Nov '24

Hi all, See the message below from Alastair from NCC. Does anyone know if the project can re-apply for the next round of funding? Kind regards, -Michael ---------- Forwarded message --------- From: Alastair Strachan <projectsfund(a)ripe.net> Date: Fri, Nov 15, 2024 at 8:48 AM Subject: [ripe-list] Update on the Community Projects Fund 2024 To: <ripe-list(a)ripe.net> Dear all, After the announcement of this year’s Community Projects Fund recipients, some challenges emerged with the RIPE Atlas distributed network telescope project which would have prevented the project from achieving the goals outlined in the project plan. After careful consideration, the Selection Committee made the difficult decision to withdraw funding for the project. While we understand this is really disappointing for the recipients, we sincerely hope they will continue initiatives that bring value to our community and the Internet. The Selection Committee has now chosen another project to support from our pool of finalists: OpenPenny - An open-source tool to identify non-spoofed traffic. You can read about the project on the Community Projects Fund 2024 page: https://www.ripe.net/community/community-initiatives/cpf/previous-funding-r… Warm regards, Alastair Strachan Community Projects Fund Coordinator

2 2

Probe registration problem
by Robert Kisteleki 13 Nov '24

13 Nov '24

Hello, I just put up a status page entry to https://status.ripe.net/ as follows: We're experiencing a problem with accepting new and reconnecting probes in the infrastructure. Probe that are currently connected, as well as new and ongoing measurements and data delivery are not affected. Regards, Robert

1 1

Probe disconnected, will not register. Registration servers down?
by Ernst J. Oud 13 Nov '24

13 Nov '24

My software probe 1009171 disconnected yesterday, precisely when my WAN IP address changed. Since then it tries to register but fails. So I restored it from a backup with the same result. What it tries to do, over and over again already for 9 hours, is: —- /var/atlas-probe/status/reginit.vol does not exist try new reg Ping failed start reg ATLAS registration starting there is WAIT, REG_WAIT_UNTIL , now is 1731484426 REG_WAIT_UNTIL expired go re-reg 1731484366 now 1731484426 REGHOSTS reg03.atlas.ripe.net 193.0.19.246 2001:67c:2e8:11::c100:13f6 reg04.atlas.ripe.net 193.0.19.247 2001:67c:2e8:11::c100:13f7 ssh -p 443 atlas(a)reg04.atlas.ripe.net INIT reg server asked us to wait or there was an error. REG_WAIT_UNTIL 1731484557 condmv: not moving, destination '/var/atlas-probe/data/out/v6addr.txt' exists condmv: not moving, destination '/var/atlas-probe/data/out/simpleping' exists —- The address it uses for the ssh session to the registration server cycles between the 2 IPv4 and 2 IPv6 addresses shown on the REGHOSTS line above. Is this a problem on my end or are the registration servers down? Regards, Ernst J. Oud

4 4

probes getting free "stress test" by postal system
by Sulev-Madis Silber 13 Nov '24

13 Nov '24

i think we need more fun here. actually it's serious too i received my v1/v2 in post in just envelope with corner open my v3 came from our vesna herself (by hands) now, v5, came in huge box with just paper sheet and probe in it. the one corner was smashed in. and poor device had been flapping around, naked, in that box, so, that introduction leaflet developed several holes in it from sharp corners of probe enclosure sure, it's free, hence maybe it's unfair but maybe they need more love. unsure who even packs them. i would guess there could be *some* padding available to stuff there? from yt comments on probe introduction video i learned that they sometimes are questionable quality too. mass produced cheap? mine survived all this abuse and i attributed the flimsily glued box to what i learned from elsewhere, that it's a budget stuff but unsure what to think...

2 1

Anomaly in NTP measurement data
by ripe＠nurfuerspam.de 13 Nov '24

13 Nov '24

Hi, In the data to date of an NTP measurement (#80845985), I find a single strange outlier with respect to the RTT value calculated: { "fw": 5090, "mver": "2.6.4", "lts": 281, "dst_name": "time2.cloud.tencent.com", "ttr": 0.413039, "dst_addr": "119.28.229.79", "src_addr": "45.11.104.146", "proto": "UDP", "af": 4, "li": "no", "version": 4, "mode": "server", "stratum": 2, "poll": 8, "precision": 1.19209E-7, "root-delay": 0.0000915527, "root-dispersion": 0.0249329, "ref-id": "647a24c4", "ref-ts": 3939345482.4404373, "result": [ { "origin-ts": 3939346062.989854, "receive-ts": 3939346062.999974, "transmit-ts": 3939346063.0000167, "final-ts": 3939346062.995442, "rtt": 4294967296.005545, "offset": -0.007347 } ], "msm_id": 80845985, "prb_id": 7030, "timestamp": 1730357262, "msm_name": "Ntp", "from": "45.11.104.146", "type": "ntp", "group_id": 80845985, "stored_timestamp": 1730357293 }, When I do the math by hand, the "rtt" value I get is 0.0055453, nicely matching the fractional part found in the measurement data. Does anyone have an explanation as to where the weird integer part might come from? Some overflow/underflow or other issue with decimal math on a binary machine? (I am not sufficiently versed in computer science to fully understand that topic, just that there are challenges in that area.) Thanks! Kind regards, R.

2 1

request for RIPE Atlas credits
by 权晓文 30 Oct '24

30 Oct '24

Hello! I'm a PhD student at Tsinghua University in China. I'm currently involved in a measurement research project, which undertakes large - scale measurements similar to Ping and Tracert by means of RIPE Atlas. As a new user, I have no credits for further progress. Therefore, I'm asking for help. I would be very grateful if someone could provide me with some RIPE Atlas credits. Thank you so much.

5 8

Fwd: RIPE Atlas Virtual Anchor Registration for DCS1 (sg-sin-as37989)
by Sanjeev Gupta 30 Oct '24

30 Oct '24

Good morning, https://atlas.ripe.net/probes/7247 I had setup an anchor last year, on a VM. I realised today while cleaning up my Atlas account, that the anchor was shown as "Down". From what I can figure out, the VM was unregistered/deleted 6 months ago. Should I apply for a new Anchor, or can I re-install and re-register (I assume the ISO will be Atlas-specific). Regards -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane ---------- Forwarded message --------- From: RIPE Atlas <no-reply(a)ripe.net> Date: Thu, 27 Jul 2023 at 22:22 Subject: RIPE Atlas Virtual Anchor Registration for DCS1 (sg-sin-as37989) To: Sanjeev Gupta <ghane0(a)gmail.com> Dear Sanjeev Gupta, Thank you for registering the technical information for your RIPE Atlas virtual anchor! Your FQDN is: sg-sin-as37989.anchors.atlas.ripe.net You will need now to setup the Virtual Machine according to these instructions: (https://atlas.ripe.net/docs/anchor-installation-vm/). It is important that once you have setup the virtual machine, you log in to your RIPE Atlas account, go to the "My Atlas" menu and then "Anchors", and check the boxes “Software is installed” and "Anchor is connected to the network" so we are notified and can begin the tests. Please note that your anchor will not be fully activated until we have finished these internal tests. We will notify you once we have finished testing and your virtual anchor is ready to use. If you have any questions, please do not hesitate to contact us at atlas(a)ripe.net You registered the following details: IPv4 address: 203.123.48.20 IPv4 ASN: 37989 IPv6 address: 2405:fc00::20 IPv6 ASN: 37989 Kind regards, RIPE Atlas Team

1 0

The MAT session is about to start
by Massimo Candela 29 Oct '24

29 Oct '24

A reminder that the Measurement, Analysis and Tools (MAT) session of RIPE89 is about to start in the main room at RIPE89! Streaming: https://ripe89.ripe.net/live/main/ Agenda: https://ripe89.ripe.net/programme/meeting-plan/mat-wg/ Ciao, Massimo On 17/10/2024 23:48, Massimo Candela wrote: > Dear all, > > > The MAT working group session will take place on Tuesday 29 October at > 16:00 CET. > > This is the agenda: > > 16:00 - 16:05 - Welcome - Chairs > 16:05 - 16:20 - Measuring and Visualizing DNS Watersheds - Jim Cowie > 16:20 - 16:30 - A First Look at User-Installed Residential Proxies From > a Network Operator's Perspective - Etienne Khan > 16:30 - 16:45 - IoT bricks over v6 - Tianrui Hu > 16:45 - 17:00 - Target Acquired? Evaluating Target Generation Algorithms > for IPv6 - Lion Steger > 17:00 - 17:15 - What’s in the Dataset? Unboxing the APNIC User > Populations - Vasilis Giotsas > 17:15 - 17:25 - RPKI flutter - Emile Aben > 17:25 - 17:30 - Closing Remarks - Chairs > > > If you are not already registered: https://ripe89.ripe.net/attend/register/ > > See you in Prague! > > Ciao, > Massimo (for the MAT WG chairs) > ----- > To unsubscribe from this mailing list or change your subscription > options, please visit: https://mailman.ripe.net/mailman3/lists/mat- > wg.ripe.net/ > As we have migrated to Mailman 3, you will need to create an account > with the email matching your subscription before you can change your > settings. More details at: https://www.ripe.net/membership/mail/ > mailman-3-migration/

1 0

Request for Atlas Credits
by Felix Hoffmann 29 Oct '24

29 Oct '24

Hello All, I am Felix, a Master student at the University of Potsdam (Hasso-Plattner-Institut). I am working on a measurement research project that requires longitudinal data to validate censorship (at least that is what I want to try). For that, I would like to perform measurements like Ping, DNS, and HTTP. As it's just the start of the project, I can not yet estimate how many credits I need. For the beginning, it would be great to get some and then go from there. Therefore, I am reaching out for help. I would appreciate it if some of you could offer me some RIPE Atlas credits. My account at RIPE NCC is on this email: felix.hoffmann(a)student.hpi.uni-potsdam.de Best, Felix Hoffmann

11 15

Re: Request for Atlas Credits
by Ziad Attia 29 Oct '24

29 Oct '24

Hi Felix, 30 million credits have been sent. Best of luck with your project. Kindest regards Ziad On Oct 29, 2024 11:22, Felix Hoffmann <felix.hoffmann(a)student.hpi.uni-potsdam.de> wrote: Hello All, I am Felix, a Master student at the University of Potsdam (Hasso-Plattner-Institut). I am working on a measurement research project that requires longitudinal data to validate censorship (at least that is what I want to try). For that, I would like to perform measurements like Ping, DNS, and HTTP. As it's just the start of the project, I can not yet estimate how many credits I need. For the beginning, it would be great to get some and then go from there. Therefore, I am reaching out for help. I would appreciate it if some of you could offer me some RIPE Atlas credits. My account at RIPE NCC is on this email: felix.hoffmann(a)student.hpi.uni-potsdam.de<mailto:felix.hoffmann@student.hpi.uni-potsdam.de> Best, Felix Hoffmann

1 0

Re-activated SW probe: How to get rid of red banner?
by ripe＠nurfuerspam.de 27 Oct '24

27 Oct '24

Hi I successfully reactivated and reconnected my software probe #1005585 that I had officially written off a few weeks ago. Now, how do I get rid of the red banner at the top of the probe management page reading "Note: this probe is most likely not operational, and as such it has been written off [...]"? Thanks! Kind regards, R.

1 0

Recycling software
by Ernst J. Oud 24 Oct '24

24 Oct '24

Hi, I get emails for RIPE to reconnect or return my abandoned probes. However, how do I send these software probes back to them? Is there a bit bucket email address or something? LOL. Regards, Ernst

7 7

Wrong IPv6 detected for my probe
by Matteo Bonora 23 Oct '24

23 Oct '24

Hello everyone, maybe it's me that I have an unusual configuration, but I was wondering if any of you are experiencing the same behavior... For IPv6 I use in my local network an ULA prefix, to maintain an abstraction layer between my network and the IPv6 prefixes assigned by my ISPs. Each ULA address of any of my devices gets translated via NPTv6 by my router to a global address compatible with my ISP assigned prefix. My probe as well has an ULA address and a public/global address that gets correctly detected by Atlas servers via IP Echo Service, but is the wrong IP that gets elected as the reference address within the Probe Address Discovery section. The correct one should come from IP Echo Service, but the ULA seems to be the preferred one. [image: 2024-10-23_00h07_14.png] Any ideas? Is there a way to force the selection of the IP Echo one? Thanks Matteo

3 2

Re: Changes to RIPE Atlas API keys
by Ponikierski, Grzegorz 22 Oct '24

22 Oct '24

Hi! > * We'll deprecate and remove the ability to use the URL form in about a > year (around October 2024). > * We plan to send further reminders about this change over time, as well > as reaching out to heavy users of the to-be-removed format. It’s October 2024. Is this plan still valid? I admit that I have a bunch of tools which use URL form which I would have to update to use "Authorization" header. Regards, Grzegorz From: Robert Kisteleki <robert(a)ripe.net> Organisation: RIPE NCC Date: Tuesday, 19 September 2023 at 12:11 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Changes to RIPE Atlas API keys Dear RIPE Atlas users, We'd like to update you on some upcoming changes regarding API keys in RIPE Atlas. TL;DR nothing changes regarding how you can use your API keys in the short term - as long as you're actually using them. However, we'll change how unused or forgotten keys are handled as well as remove the less secure in-URL use of them. At the moment RIPE Atlas users can query their existing API keys via the UI and API, including the possibility to retrieve old keys. In order to improve the security of how we handle these, we'll introduce the following changes in October 2023: * The listing (retrieval) of keys will only reveal parts of the keys (enough to identify them) in the API as well as in the UI. * We'll add the ability to "regenerate" an API key, which will replace the secret UUID of the key while keeping exactly the same permissions. * Unused API keys will automatically be frozen after 1 year of not being used. Active keys (i.e. the ones that have been used at least once) will not be frozen. You still have the ability to save your keys until these changes are done and, as written above, you will be able to regenerate them later. We'll notify this list when the changes are about to be done. In addition, in order to further increase the security of our system, in the long run we'll make changes about how these API keys are communicated to the API: * At the moment the API accepts these either in HTTP headers ("Authorization" header) or in the URL (?key=xyz), although the Authorization header version has been documented as the preferred version for some time. * We'll deprecate and remove the ability to use the URL form in about a year (around October 2024). * We plan to send further reminders about this change over time, as well as reaching out to heavy users of the to-be-removed format. Regards, Robert Kisteleki RIPE Atlas team -- ripe-atlas mailing list ripe-atlas(a)ripe.net<mailto:ripe-atlas@ripe.net> https://urldefense.com/v3/__https://lists.ripe.net/mailman/listinfo/ripe-at…<https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atl…>

2 3

webui dashboard is hard to use on mobile
by Sulev-Madis Silber 21 Oct '24

21 Oct '24

there has been some updates iirc but same issue remains got my busted v1/v2 -> v5 shipped and went to preconfigure it at dashboard, in phone, on android firefox, it's extremely hard to scroll dashboard without it dragging all the elements all over place it's also hard to open and close them, keep clicking 10 times around the open/close element and finally got it to react could maybe someone verify it, and fix maybe. perhaps lock it down somewhere? you must use some touch device for this as issue is in hold and drag really annoying each (rare) time i go there

3 2

HTTPS resource record.
by dikshie 18 Oct '24

18 Oct '24

Hi, Any plan to support HTTPS resource record in DNS measurement? example: ------------------- ;; ANSWER SECTION: www.ripe.net. 60 IN CNAME www.ripe.net.cdn.cloudflare.net. www.ripe.net.cdn.cloudflare.net. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.18.4.245,104.18.5.245 ipv6hint=2606:4700::6812:4f5,2606:4700::6812:5f5 --------------------- Best Regards, -- -dikshie-

2 1

Re: Change git to repository (Randy Bush)
by ripe＠nurfuerspam.de 14 Oct '24

14 Oct '24

> and how does one "using the UI to replace the key?" On your probe's management page (e.g., https://atlas.ripe.net/ probes/1000006/), at the bottom of the page under the "General" tab, there is the option to add a new key. On a 5080 software probe, unless paths were changed during the build, one should find the public ssh key under /var/atlas-probe/etc/probe_key.pub (at least that's where it is on my Debian 12 system).

2 1

Change git to repository
by Jimmy Huybrechts 14 Oct '24

14 Oct '24

Hi, Currently my software probe on Debian 12 is using the git repository as there was no official deb when mine was deployed. Now I wish to change it out for the official repo, how can this be done? Or should I register the repository one as a new probe? -- Jimmy

4 6

Software Probe version 5100
by Michel Stam 07 Oct '24

07 Oct '24

Dear colleagues, We’d like to inform you that a new version of the software probe has been released, version 5100. Please find the changes below: All platforms As of this version, the ripe-atlas-probe-measurements repository on GitHub is deprecated. Its code has been merged into the ripe-atlas-software-probe repository Package can now be built with arbitrary shell shebangs. Note that only OpenWRT ash and bash are officially supported Bug fixed where permissions are wrong when systemd is disabled (reported by César de Tassis Filho <ctassisf(a)gmail.com>) A new code signing key has been introduced. It only signs Debian packages currently, but will sign the RHEL packages in an upcoming release as well. The current RHEL key will then be deprecated. This release already supports code signed using the new key Software probes Streamlined deployment on RHEL CI/CD systemd unit ownership moved to probe and anchor packages Debian 11/12 x86_64 support added Support for OpenWRT software probes and the hardware probes v3, 4 and 5 will be added in a future release. If you run RHEL or Debian, we encourage you to upgrade to the latest version: https://github.com/RIPE-NCC/ripe-atlas-probe-doc/blob/master/manuals/Linux-… https://github.com/RIPE-NCC/ripe-atlas-probe-doc/blob/master/manuals/RHEL8-… https://github.com/RIPE-NCC/ripe-atlas-probe-doc/blob/master/manuals/RHEL9-… https://github.com/RIPE-NCC/ripe-atlas-probe-doc/blob/master/manuals/Debian… https://github.com/RIPE-NCC/ripe-atlas-probe-doc/blob/master/manuals/Debian… Best regards, Michel Stam, RIPE Atlas development team

2 3

Some built-ins are not working anymore
by Ernst J. Oud 07 Oct '24

07 Oct '24

I guess due to the new controller infra, the built-ins measurements for: ctr-ewr01.atlas.ripe.net ctr-fnc01.atlas.ripe.net ctr-sin02.atlas.ripe.net are invalid now? They don’t produce data since October 1st it seems. Will the new controllers be included as built-ins? Regards, Ernst J. Oud Met vriendelijke groet, Ernst J. Oud

2 1

About the recent connection problems
by Robert Kisteleki 02 Oct '24

02 Oct '24

Dear colleagues, As many of you have noticed, we have been experiencing some technical issues with RIPE Atlas over the past few weeks. I would like to explain some of these in this email. Earlier this year, we began the process of migrating our infrastructure from our on-premise and co-located data centres to a cloud-based solution. Significant work has gone into rewriting code for multiple components and to renew the underlying infrastructure, to containerise and adapt it for the new cloud environment. In the process of this, we have encountered unforeseen bugs and bottlenecks. The RIPE Atlas team has been working to fix these issues as we find them. We are largely done with the migration of the controlling infrastructure so we hope to have a more stable system in the coming days. We are deploying new code and fixes fairly often to prevent these issues from arising, but it is possible that you might experience unexpected disconnects, but hopefully on a smaller scale than the past weeks. In the coming weeks, we will also begin the migration of the website (the user interface and the API). To clarify some questions that we heard on the list: - We will be looking for a solution to compensate credits for the missing connection times. - In the vast majority of cases, we don’t expect data loss when probes are not connected. The measurement results are delayed until the probes can reconnect and submit the results. - We apologise for the many connection and disconnection emails you might have received when your probe is disconnected. Please note that you can change your email notification preferences on your probe status page. I understand that many of you will want a more detailed explanation. We will be publishing an article on RIPE Labs, and we plan to present our work at the MAT Working Group session at RIPE 89. Regards, Robert Kisteleki RIPE NCC

1 1

Atlas UI update 2024-09-23
by Stephen Suess 23 Sep '24

23 Sep '24

Hello Atlas fans, We just released an update to the UI that includes: - NEW: Results ASNs visualisation in DNS measurement overview map - CHANGE: Anchor list improvements (status, search, sorting) - CHANGE: Ambassador Probe card now allows inline note editing In addition, we have some improvements to the new advanced search in the probes and measurements lists, and some other under the hood improvements. If you want to see the full list of what has changed, you can check the release notes here: https://atlas.ripe.net/docs/releases/website/2024-09-23.html As always, we hope you find these changes useful and we welcome your feedback. Kind regards, Stephen Atlas UI

1 0

LACNIC42 IMWG call for presentation LAST DAYS!
by Elisa 19 Sep '24

19 Sep '24

Dear all, LACNIC 42 / LACNOG 2024 (7-11 October 2024, Asunción, Paraguay) is coming up and we will have a session for the Internet Measurements Working Group (IMWG)! We are looking for presentations on Internet measurements, network data collection, data analysis and tools. Please, submit your presentation proposal by sending an email to imwg-owner(a)listas.nog.lat We prefer talks of 15min. Include in your email: 1) a title; 2) a draft of the presentation; 3) a paragraph describing what you will talk about and why the topic is of interest for the community; 4) if you are planning to present in person or remotely. Thanks! Cheers, -- Elisa Peirano *Analista de Datos I+D* R&D Data Analyst /www.lacnic.net <http://www.lacnic.net> Latin American and Caribbean Internet Addresses Registry/

1 0

Not only are probes disconnecting…
by Ernst J. Oud 18 Sep '24

18 Sep '24

Current Atlas status shows a delay of over 16 hours. I created a measurement and no data is returned. It appears this is not a problem with only probes disconnecting… Ernst J. Oud

3 3

Auto reconnect?
by Ernst J. Oud 17 Sep '24

17 Sep '24

Is it true that probes will always automatically reconnect? Probe 60200 was down for a total f 17 hours (with a short reconnect of some minutes in the middle of that period). I just did a power recycle and it immediately reconnected. All my probes have reconnected now. Thanks for resolving this. Regards, Ernst J. Oud

1 0

Re: Again probe disconnects on ctr-dub-hw01 (Robert Kisteleki)
by ripe＠nurfuerspam.de 17 Sep '24

17 Sep '24

> they will > continue to run the defined measurements, reconnect when they can, and > send in all the stored results Actually, that seems not entirely true, at least not in all cases. That is how I mostly notice that one of my probes (likely) had a disconnect lasting more than a few minutes (but not enough to get a notification mail), because gaps in the RIPEstat graphs are noticeably visible as vertical gray bars without data points, or short gaps in an otherwise continuous line (at the typical graph resolution for a relevant measurement).

1 0

Again probe disconnects on ctr-dub-hw01
by Ernst J. Oud 17 Sep '24

17 Sep '24

Today my probes 60200 and 61071 experience several disconnects of upto an hour, both on controller ctr-dub-hw01. It appears this supposedly fixed disfunction has not been completely fixed. Regards, Ernst J. Oud

8 10

Subject-line in (dis)connect mails
by Marco Davids (Private) 11 Sep '24

11 Sep '24

Dear Atlas folks, I was wondering if it is possible to bring dis- and reconnect messages of RIPE Atlas probes more in line with each other. The disconnect mail has a subject like this: "Probe ID is disconnected (Name (ISP))" The reconnect mail has this: "Your RIPE Atlas Probe (ID: XXX) has reconnected" For me this is a bit confusing. When I sort my inbox alphabetically on subject, it would be really nice if the messages are grouped close together, which currently is not the case. It would helpful to me if this could be improved, by adjusting the specific text in the subject a bit. Thanks. -- Marco

5 10

probes do not register
by Randy Bush 10 Sep '24

10 Sep '24

on a SOHO LAN that used gto have a good running v3 probe (25867 but it went where so many v3 probes go, dead for a few months now. yes i did usb recovery, to no avail. you gotta love v3 probes.) i unpack an unused v3 (25909) i had in my back pocket for a few years. plug it into the LAN. wait a few hours. it does not register. power LED on, LED to right of it blinks about every two seconds. web page for it, https://atlas.ripe.net/probes/25909/ shows it has been down for 1 year 11 months while, in fact, it has never been up. oddly that web page shows the correct AS, comcast, 7922, but no IP addressing. tcpdump is my friend. pcap can be found at https://archive.psg.com/240907.atlas-25909.pcap it gets dhcp etc. then twice successfully pings to nl-ams-as3333-3.anchors.atlas.ripe.net (193.0.0.164) then it does successful DNS AAAA queries for woolsey.atlas.ripe.net and reg02.atlas.ripe.net. but it never reaches out to them that i can see. then it does a successful ARP for the default gateway, 192.168.0.1 then silence and much more silence unpack another unused antique from its envelope, 25918. dns queries for different controllers, but otherwise the same story. pcap avaliable as https://archive.psg.com/240907.atlas-25918.pcap. how to further debug? randy

3 5

RIPE Atlas Anchor Operating System Upgrade
by Paul de Weerd 02 Sep '24

02 Sep '24

Dear colleagues, RIPE Atlas anchors are scheduled for an Operating System (OS) upgrade soon since the current OS will reach its end-of-life on 30 June 2024 [1]. We are currently implementing and testing the necessary changes to support a smooth transition to the new OS without service interruption. Consequently, all live anchors will be upgraded by 31 August 2024. During this period, anchors will run on an outdated OS for a couple of months, but we do not anticipate any security issues here. For the few outward-facing services or lower-level software (such as the kernel) running on anchors, we will provide backports of necessary packages. If needed, we will shut down affected services or the anchor until the upgrade is complete. Due to this upgrade process, we have now paused applications for new anchors. New applications will resume from 15 July 2024 with anchors that will be provisioned with the new OS. If you have any questions please email gii-requests(a)ripe.net. Kind regards, Paul de Weerd RIPE NCC [1] https://www.redhat.com/en/topics/linux/centos-linux-eol

3 4

account e-mail change?
by Fallon Albrecht 29 Aug '24

29 Aug '24

Hi there, Thank you for your feedback. For security reasons, it is unfortunately not possible to change your RIPE NCC Access e-mail address. More information on this topic is available at: https://www.ripe.net/publications/documentation/disclosures-and-reports/rip… However, you can do the following: - Create a new RIPE NCC Access account with the new email address https://access.ripe.net/registration - You will need to enable two-factor authentication (2FA) to activate the account. - Transfer Atlas credits to the new SSO account If you need help or have any questions about this procedure, please contact ncc(a)ripe.net. We are always striving to improve RIPE NCC Access and our current work plans are available at : https://www.ripe.net/publications/documentation/quarterly-planning/business… Kind regards, Fallon Albrecht Product Owner RIPE NCC

1 0

Re: Globalping
by Ernst J. Oud 27 Aug '24

27 Aug '24

Stephane, That is precisely why I became interested, for a quick ping or trace they have a CLI where one can do a quick measurement or via the API. With Atlas Magellan in a docker container this is also possible, it streams the results to the console but Globalping might be a good add on tool in the toolkit. Thanks for the input. Regards, Ernst J. Oud Met vriendelijke groet, Ernst J. Oud > On 27 Aug 2024, at 14:03, Stephane Bortzmeyer <bortzmeyer(a)nic.fr> wrote: > > On Tue, Aug 27, 2024 at 12:42:18PM +0200, > Ernst J. Oud <ernstoud(a)gmail.com> wrote > a message of 12 lines which said: > >> It might be “cursing in the church” as we say in NL, but does anyone >> here have experience with the Globalping monitoring tools? > > https://www.jsdelivr.com/globalping ? > > No real practical experience but it seems interesting. The API is > well documented and a shell script as simple as: > > curl -H "Content-Type: application/json" \ > --data-binary @- \ > https://api.globalping.io/v1/measurements \ > <<EOF > { > "limit": 10, > "locations": [], > "target": "ayla.bortzmeyer.org", > "type": "ping", > "measurementOptions": { > "packets": 3 > } > } > EOF > > is enough to launch a measurement. You can see the resulting JSON at > https://api.globalping.io/v1/measurements/bqXml2MiDAoawobv if you want > an idea.

2 1

account e-mail change?
by Sulev-Madis Silber 27 Aug '24

27 Aug '24

i noticed i can't change my account mail address. unsure why we have such limitation here. i have mail i used for 25 years, or literally more than half of my entire lifetime, and now i want to change it. reason being it's ispmail i had since dialup. and they sold it. now i still have access to it but service sucks, despite expensive. a very good reason to change it. yet ripe seems to have account mail is permanent policy for no reason at all. i expect this to change after more updates. there was huge ui update but this feature is not coming. why? most of things allow me to change mail. with only handful of services insisting it being for life. i don't know if next one is lifetime long but at least now it's my own domain. hoping to change it. or at least given reason why i can't

5 8

Globalping
by Ernst J. Oud 27 Aug '24

27 Aug '24

L.S. It might be “cursing in the church” as we say in NL, but does anyone here have experience with the Globalping monitoring tools? Not as comprehensive as Atlas and a lot less probes but at first glance it has some useful features. Your thoughts? Regards, Ernst J. Oud

3 2