- ripe-atlas - mailman.ripe.net

Re: v1 probe loses connection after a while (and webui needs more love)
by Sulev-Madis Silber 04 Aug '24

04 Aug '24

and, it also seems to try on v6, gets reply but doesn't seem to get connection up for some reason

1 0

v1 probe loses connection after a while (and webui needs more love)
by Sulev-Madis Silber 04 Aug '24

04 Aug '24

i have a old probe here. it's v1 or maybe it was v2. anyway... there were recent updates to system and i had to take everything off power for a few hours. after i put i back and it really is always on here, despite being home. the probe didn't reconnect. i don't have it on pdu. i have never needed it to cycle it before in previous 11 years. taking power off fixed it. now it's down again while on power and network. i went to looked what my atlas vlan does and found probe having both v4 and v6. and looks like it periodically tries to reconnect to ssh, gets reply and then... what happens next? it reports fw issue and trying to reconnect. but what kind of issue suddenly appeared when i have done none of fw changes. it's connection is via fbsd box i have full control over. can somebody check wtf is it and maybe fix it if needed. or maybe it just is too old? it works tho. i'm amazed how long it has been running. before next power cycle, can somebody diagnose it. it seems to connect out well? but just v4 i see. v4 is natted there while v6 is native and routed directly. probe id is 4415 p.s.: new webui tiles are really easy to accidentally mess up with finger on phone screen. never know when you scroll page and when you drag and drop. it's annoying

1 0

Probe #7030 may have specified the wrong location
by Marek Küthe 04 Aug '24

04 Aug '24

Hello, I noticed the probe #7030 [1] during the measurement #76522525 [2]. It has China as its location. However, the probe itself probably belongs to AS23961 [3]. You can see their locations on their website [4]. However, the probe does not appear to be in China, but in Hong Kong. Hong Kong is listed as an extra country/region in the RIPE NCC Atlas and I think this should be used accordingly so as not to falsify results. Could someone adjust the location? Regards Marek Küthe [1] https://atlas.ripe.net/probes/7030 [2] https://atlas.ripe.net/measurements/76522525 [3] https://bgp.tools/as/23961 [4] https://www.misaka.io/services/mc2 -- Marek Küthe m.k(a)mk16.de er/ihm he/him

1 0

REST API: Optional Fields for DNS Measurements
by Richter, Robert 03 Aug '24

03 Aug '24

Dear fellow RIPE Atlases, I am looking for the full definition of all optional field of the RIPE Atlas REST API for creating measurements. Especially the one for creating a DNS measurement. I only find the one defining the required attributes for a DNS measurement. But is there also a list constituting the optional fields? Best regards, Robert

2 1

RIPE Atlas data backend maintenance on 29 July 2024
by Francesco Iannuzzelli 29 Jul '24

29 Jul '24

Dear RIPE Atlas users, On 29 July 2024, between 9:00-18:00 (CEST), we will carry out planned maintenance on the data storage backend of RIPE Atlas. During this time, RIPE Atlas will be available but will serve stale data until work will be completed. Results for existing measurements will still be collected and stored. Measurement scheduling will be available but new measurements will be executed after the maintenance window. Results streaming will continue unaffected. We apologise for the inconvenience this may cause. Best regards, Francesco RIPE Atlas Team

1 1

[atlas]Installing Software Probe
by Milad Afshari 22 Jul '24

22 Jul '24

Dear RIPE Atlas Team, I encountered the following error while trying to download the RIPE Atlas software probe from the RIPE NCC GitHub repository: fatal: remote error: upload-pack: not our ref d72872cc6bb9ed5da47dcf1dc726fd8a36c6058f fatal: Fetched in submodule path 'probe-busybox', but it did not contain d72872cc6bb9ed5da47dcf1dc726fd8a36c6058f. Direct fetching of that commit failed. Can you please assist me with this issue? Kind regards, Milad Afshari

3 4

[atlas]API Not Working
by MARC BOSCH MARTINEZ 21 Jul '24

21 Jul '24

Hi all! Is anyone having problems issuing SSL measurements from the API? Seems that issuing them via the website works fine, but I've been having issues lately with the ones that I created using the API, leading to measurements in which all or most probes state "No Report Available". Best, Marc

2 1

[atlas]results page empty
by Marco Moock 16 Jul '24

16 Jul '24

Hello! https://atlas.ripe.net/measurements/75882685/results If I try to access the results, the page is empty. I tried Pale Moon and MS Edge. In Tor Browser, I can access it. Is something faulty at my side or is that a general problem? -- kind regards Marco

3 2

[atlas]Can not target google.com with periodic measurement
by Malte Tashiro 15 Jul '24

15 Jul '24

Hi, there seems to be something wrong (?) with the measurement creation process, or maybe some rules have changed? I'm trying to schedule a toy measurement to google.com, however, as soon as I set the timing to periodic, I get the error message: "We do not allow more than 25 concurrent measurements to the same target: google.com" I am not running any measurements at the moment. This behavior is independent of the measurement type (ping, traceroute, SSL) and the number of probes (error appears with one probe requested). It seems to solely be a problem of the timing. So far this message only appears for google.com and 8.8.8.8, other targets work. If I schedule the measurement in the future, I can actually submit it, but get a "Scheduling denied" measurement, for example: https://atlas.ripe.net/measurements/75418006/details I don't know if this is related, but it seems like somebody is hammering Atlas with a large number of geolocation measurements (500 probes per measurement) and DNS lookups (1 probe) at the moment. In the last hour 5582 measurements were scheduled, which is 1.5 measurements per second! Best, Malte

5 7

New status field in probes API, probe archive API
by Johan ter Beest 13 Jul '24

13 Jul '24

Dear Atlas hosts, A while ago we introduced the option for hosts to write off their probes in case they were sure it was never going to be connected again. For instance if it was broken or lost in the mail, a software probe you only used for testing. etc. This written off status was recorded in the database and we show it on the current probe page but it was not reflected in the probe API or on the probe archive API. Starting today, this will change. There is now a new status ID: 4 in the probe API and after we create the probe archive for today, this will also be visible there. Sometime today we will update the status field on the previously written off probes. This will add roughly 5500 probes to this status and will lower the number of abandoned probes with the same amount. Please let us know if you notice any unexpected behaviour. We hope that this change will make the status of probes more clear to both hosts and users. Happy measuring! Johan ter Beest RIPE Atlas Team

3 4