[atlas]Re: results page empty
Works for me in Edge David -- https://dprall.net On 7/16/2024 3:28 AM, Robert Kisteleki wrote: Hello, The page itself works (tried Firefox and Chrome) - I'm not sure why it would not work in Edge or Pale Moon - maybe some extensions/blockers are in the way? Regards, Robert On Tue, Jul 16, 2024 at 8:16 AM Marco Moock wrote: 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 - To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.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/ - To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.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/ - To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.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/
[atlas]Re: Can not target google.com with periodic measurement
Hi Robert, thanks for the clarification, now I know it is not a bug. With that said, I think this necessitates some form of house-keeping task seeing how long Atlas has been active. I looked at the 25 running measurements (attached), assuming [0] is the right request: - 23 ping measurements, 1 traceroute, 1 SSL - 7 are dead (-> /latest endpoint returns no results) - Average participant count of 5 probes - None have a scheduled stop time - The last one was started on 2023-01-11, so it was not possible to schedule measurements targeting google.com since then? I know the Atlas developers always have a lot on their plate, so I won't ask for anything, but maybe it would make sense to have a process that notifies users of long-running / infinite measurements that did not return results since x amount of time due to probes getting disconnected if they want to add new probes or cancel the measurement. And if they don't reply for y time, force cancel the measurement (or exclude them from the limit). Anyways, at least now it is clear to me what is happening, so thank you. Best, Malte [0] https://atlas.ripe.net/api/v2/measurements/?status=2=google.com msm_id,interval,participant_count,start_time,stop_time,type,num_latest_results,dead 1014026,240,0,2013-07-26 06:27:38+00:00,None,ping,0,dead 1014027,240,0,2013-07-26 06:28:09+00:00,None,ping,0,dead 7809418,240,8,2017-02-07 19:03:04+00:00,None,ping,1,alive 9196394,240,4,2017-07-17 20:00:00+00:00,None,ping,3,alive 13969316,240,1,2018-06-04 06:08:21+00:00,None,ping,0,dead 19236273,6600,10,2019-01-29 19:14:15+00:00,None,ping,4,alive 19505895,240,3,2019-02-12 13:05:52+00:00,None,ping,2,alive 19505931,240,3,2019-02-12 13:11:26+00:00,None,ping,2,alive 19505937,240,3,2019-02-12 13:13:04+00:00,None,ping,2,alive 22505481,240,1,2019-08-05 17:33:51+00:00,None,ping,0,dead 22755674,120,1,2019-09-07 04:56:43+00:00,None,ping,1,alive 22755675,120,1,2019-09-07 04:56:43+00:00,None,ping,1,alive 26439058,240,1,2020-07-24 04:33:38+00:00,None,ping,1,alive 38271854,240,1,2022-02-03 10:05:59+00:00,None,ping,0,dead 41775077,240,1,2022-06-15 19:32:26+00:00,None,ping,0,dead 41775453,900,1,2022-06-15 20:03:47+00:00,None,traceroute,0,dead 41852105,240,10,2022-06-20 00:32:01+00:00,None,ping,6,alive 41852107,240,10,2022-06-20 00:32:53+00:00,None,ping,5,alive 41852108,240,10,2022-06-20 00:32:53+00:00,None,ping,8,alive 42972399,240,10,2022-08-01 16:05:12+00:00,None,ping,4,alive 44168751,240,10,2022-08-27 22:08:14+00:00,None,ping,4,alive 44168752,900,10,2022-08-27 22:08:14+00:00,None,sslcert,4,alive 46113079,240,10,2022-10-19 16:45:29+00:00,None,ping,3,alive 46940768,60,4,2022-11-15 01:09:15+00:00,None,ping,4,alive 48695456,240,11,2023-01-11 12:19:58+00:00,None,ping,7,alive OpenPGP_0x7D82498BEF2E08F8.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ripe-atlas mailing list -- ripe-atlas@ripe.net To unsubscribe send an email to ripe-atlas-le...@ripe.net
[atlas]Re: Request RIPE Atlas Credit Donation
Thank you Stijn, I will share the report as soon as I finish it. Sincerely, Nishant Acharya On Wed, Jul 10, 2024 at 9:55 PM Stijn Jonker wrote: > Hi Nishant, > > 50m transferred, but kindly share the outcome of the project with the list. > > Groetjes, > Stijn > > On Thu, 11 Jul 2024, at 06:49, Nishant Acharya via ripe-atlas wrote: > > Hello All, > > I am Nishant, a PhD student at the University of California, > Davis—apologies for spamming the mailing list. > > I am working on a measurement research project that requires longitudinal > analysis of Internet exchange points which requires an active traceroute > campaign that we plan to do via RIPE Atlas. > > I have some credits to start the measurement but, I would require around > 50 million more credits to complete the measurements. > > Therefore, I am reaching out for help. It would be great if some of you > could offer me some RIPE Atlas credits. My account at RIPE NCC is on this > email: nacha...@ucdavis.edu > > Sincerely, > Nishant Acharya > -- > ripe-atlas mailing list -- ripe-atlas@ripe.net > To unsubscribe send an email to ripe-atlas-le...@ripe.net > > > -- ripe-atlas mailing list -- ripe-atlas@ripe.net To unsubscribe send an email to ripe-atlas-le...@ripe.net
[atlas]Re: Request RIPE Atlas Credit Donation
Hi Nishant, 50m transferred, but kindly share the outcome of the project with the list. Groetjes, Stijn On Thu, 11 Jul 2024, at 06:49, Nishant Acharya via ripe-atlas wrote: > Hello All, > > I am Nishant, a PhD student at the University of California, Davis—apologies > for spamming the mailing list. > > I am working on a measurement research project that requires longitudinal > analysis of Internet exchange points which requires an active traceroute > campaign that we plan to do via RIPE Atlas. > > I have some credits to start the measurement but, I would require around 50 > million more credits to complete the measurements. > > Therefore, I am reaching out for help. It would be great if some of you could > offer me some RIPE Atlas credits. My account at RIPE NCC is on this email: > nacha...@ucdavis.edu > > Sincerely, > Nishant Acharya > -- > ripe-atlas mailing list -- ripe-atlas@ripe.net > To unsubscribe send an email to ripe-atlas-le...@ripe.net > -- ripe-atlas mailing list -- ripe-atlas@ripe.net To unsubscribe send an email to ripe-atlas-le...@ripe.net
[atlas] Request RIPE Atlas Credit Donation
Hello All, I am Nishant, a PhD student at the University of California, Davis—apologies for spamming the mailing list. I am working on a measurement research project that requires longitudinal analysis of Internet exchange points which requires an active traceroute campaign that we plan to do via RIPE Atlas. I have some credits to start the measurement but, I would require around 50 million more credits to complete the measurements. Therefore, I am reaching out for help. It would be great if some of you could offer me some RIPE Atlas credits. My account at RIPE NCC is on this email: nacha...@ucdavis.edu Sincerely, Nishant Acharya -- ripe-atlas mailing list -- ripe-atlas@ripe.net To unsubscribe send an email to ripe-atlas-le...@ripe.net
[atlas]Re: Can not target google.com with periodic measurement
On 7/10/24 18:09, Mark Santcroos wrote: Educated guess: this is a limit for a total over all users? I am aware of the quotas described here [0], which describe the 25 measurement limit, but I understood them to be per user. If not, somebody could easily prevent others from performing measurements to a destination by scheduling 25 period measurements with one probe and an interval of a week or so. Btw. I had also two other users confirm to me that they have the same problem. [0] https://atlas.ripe.net/docs/getting-started/user-defined-measurements.html#quotas OpenPGP_0x7D82498BEF2E08F8.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ripe-atlas mailing list -- ripe-atlas@ripe.net To unsubscribe send an email to ripe-atlas-le...@ripe.net
[atlas]Can not target google.com with periodic measurement
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 OpenPGP_0x7D82498BEF2E08F8.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ripe-atlas mailing list -- ripe-atlas@ripe.net To unsubscribe send an email to ripe-atlas-le...@ripe.net
Re: [atlas] Atlas probes in non-production networks
Since we talk about usage of public service, I think that there is nothing to hide. Let me answer all questions. Problem refers to these PCCW AS3491 probes: 7007 7010 7032 7079 7080 7172 7198 1002754 1002771 1002785 1002844 1003737 1005609 They are are virtual anchor and software probes. PCCW has more probes but according to my data they are fine. Problem is observed for IPv6 routing. You can check built-in IPv6 traceroutes towards F root server. You can see that everything is routed into link between PCCW and HE AS6939 in Kuala Lumpur, MY. If you check PCCW routing towards F root server using their looking glass (so their production network) everything will look normal and won’t be routed via HE. As for now, these probes don’t have any tags or description that will allow you distinguish them from other, normal probes. Regards, Grzegorz From: ripe-atlas on behalf of "Ponikierski, Grzegorz via ripe-atlas" Reply to: "Ponikierski, Grzegorz" Date: Tuesday, 2 July 2024 at 11:38 To: "ripe-atlas@ripe.net" Subject: [atlas] Atlas probes in non-production networks Hi all! I discovered a disturbing practice how RIPE Atlas probes are used by at least one major provider which significantly impacts measurement results and interpretation of these results. I want to share it with you to open discuss about how to deal with such cases. I was doing traceroutes for one of Tier 1 provider which is very well covered by RIPE Atlas probes. I was surprised, that for some probes I got RTTs 100x worse than expected. After verification I discovered that routing for these probes is absurd and contact the provider to explain it. It turned out, that these probes are deployed in this part of their network that provide for some kind of internal service which is not provided for customers of this provider. In other words, these probes don't measure production network, but they measure some kind of hidden experimental network not available for the public. In my private opinion, this practice is against the whole idea of RIPE Atlas, and it is a form of appropriation of the platform for solely private purpose disregarding interest of the RIPE Atlas community. As far I understand, RIPE Atlas supposed to be used to measure public Internet and it was not prepared to be used as internal/private measurement platform. RIPE Atlas probes are not tagged and separated into groups that can be used appropriately for public and internal/private measurements. Therefore, descripted practice creates another uncomfortable situation for RIPE Atlas user because there is no way to tell which probe is deployed in public/production part of the network and which one in the experimental/non-production one. I guess that most of us want to measure production networks and if there is somebody that want to play with experimental stuff then it should be clearly marked as experimental. Please share your thoughts and ideas how to deal with it. Regards, Grzegorz Ponikierski Senior Network Engineer Akamai Technologies AS20940 -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] Atlas probes in non-production networks
Hi all! I discovered a disturbing practice how RIPE Atlas probes are used by at least one major provider which significantly impacts measurement results and interpretation of these results. I want to share it with you to open discuss about how to deal with such cases. I was doing traceroutes for one of Tier 1 provider which is very well covered by RIPE Atlas probes. I was surprised, that for some probes I got RTTs 100x worse than expected. After verification I discovered that routing for these probes is absurd and contact the provider to explain it. It turned out, that these probes are deployed in this part of their network that provide for some kind of internal service which is not provided for customers of this provider. In other words, these probes don't measure production network, but they measure some kind of hidden experimental network not available for the public. In my private opinion, this practice is against the whole idea of RIPE Atlas, and it is a form of appropriation of the platform for solely private purpose disregarding interest of the RIPE Atlas community. As far I understand, RIPE Atlas supposed to be used to measure public Internet and it was not prepared to be used as internal/private measurement platform. RIPE Atlas probes are not tagged and separated into groups that can be used appropriately for public and internal/private measurements. Therefore, descripted practice creates another uncomfortable situation for RIPE Atlas user because there is no way to tell which probe is deployed in public/production part of the network and which one in the experimental/non-production one. I guess that most of us want to measure production networks and if there is somebody that want to play with experimental stuff then it should be clearly marked as experimental. Please share your thoughts and ideas how to deal with it. Regards, Grzegorz Ponikierski Senior Network Engineer Akamai Technologies AS20940 -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] Minor nit in first monthly probe report after registration
Resent, hopefully without HTML formatting this time (sorry for earlier) Hi, A minor nit with regards to the availability time in the monthly probe report for the month the probe was registered in: The total availability indicated is bogus as the whole month is taken as the calculation interval as its basis, rather than only the time since probe registration. Calculation interval : 2024-06-01 00:00:00 - 2024-07-01 00:00:00 Total Connected Time : 0d 14:40 Total Disconnected Time : 29d 09:19 Total Availability : 2.04% +--+-+---+---+ | Disconnected for | Connected at (UTC) | Connected for | Disconnected at (UTC) | +--+-+---+---+ | - | 2024-06-30 08:52:15 | 0d 00:36 | 2024-06-30 09:29:07 | | 0d 00:04 | 2024-06-30 09:33:30 | 0d 03:20 | 2024-06-30 12:54:07 | | 0d 00:01 | 2024-06-30 12:55:49 | 0d 00:04 | 2024-06-30 13:00:17 | | 0d 00:04 | 2024-06-30 13:04:44 | 0d 01:35 | 2024-06-30 14:39:54 | | 0d 00:01 | 2024-06-30 14:40:55 | 0d 00:32 | 2024-06-30 15:13:10 | | 0d 00:10 | 2024-06-30 15:23:30 | 0d 00:02 | 2024-06-30 15:26:26 | | 0d 00:05 | 2024-06-30 15:32:13 | 0d 08:27 | Still connected | +--+-+---+---+ I guess just an optical issue rather than a problem, maybe a bit misleading. The UI seems to take the fractional aspect into account, which seems more relevant. Connection Information Probe's birthday: 2024-06-30 Time Connected Percent Last Week 21h 11m 97.87% Last Month 21h 11m 97.87% All Time 21h 11m 97.87% Kind regards, R. -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] Minor nit in first monthly probe report after registration
Hi,A minor nit with regards to the availability time in the monthly probe report for the month the probe was registered in:The total availability indicated is bogus as the whole month is taken as the calculation interval as its basis, rather than only the time since probe registration.Calculation interval : 2024-06-01 00:00:00 - 2024-07-01 00:00:00Total Connected Time : 0d 14:40Total Disconnected Time : 29d 09:19Total Availability : 2.04%+--+-+---+---+| Disconnected for | Connected at (UTC) | Connected for | Disconnected at (UTC) |+--+-+---+---+| - | 2024-06-30 08:52:15 | 0d 00:36 | 2024-06-30 09:29:07 || 0d 00:04 | 2024-06-30 09:33:30 | 0d 03:20 | 2024-06-30 12:54:07 || 0d 00:01 | 2024-06-30 12:55:49 | 0d 00:04 | 2024-06-30 13:00:17 || 0d 00:04 | 2024-06-30 13:04:44 | 0d 01:35 | 2024-06-30 14:39:54 || 0d 00:01 | 2024-06-30 14:40:55 | 0d 00:32 | 2024-06-30 15:13:10 || 0d 00:10 | 2024-06-30 15:23:30 | 0d 00:02 | 2024-06-30 15:26:26 || 0d 00:05 | 2024-06-30 15:32:13 | 0d 08:27 | Still connected |+--+-+---+---+I guess just an optical issue rather than a problem, maybe a bit misleading. The UI seems to take the fractional aspect into account, which seems more relevant.Connection InformationProbe's birthday: 2024-06-30Time Connected PercentLast Week 21h 11m 97.87%Last Month 21h 11m 97.87%All Time 21h 11m 97.87%Kind regards, R. -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] IPv4 Built-ins fail while IPv6 work
Hi,
The Edgerouter has been running as IPv4 and IPv6 router for my home network
sinc Januari and this is the first time I noticed the missing default router.
To be honest configuring openwrt is a bit strange to me being used to more
generic OS’s like FreeBSD or Solaris.
I see the built0-in graphs also started showing data now.
Thanks,
Paul
> On 26 Jun 2024, at 14:19, Michel Stam wrote:
>
> Hi Paul,
>
> The probe has reported a default route in the logs a little while ago, thats
> good.
>
> I just ran a measurement for you to ping 8.8.8.8 (id : 74399066), which
> yielded this:
> 2024-06-26 12:15:54 log_cron 16674 DEBUG ATLAS PRB_ID@1008458 ONEOFF
> /home/atlas/crons/oneoff evping -4 -c 3 -s 64 -i 1000 -A "74399066" 8.8.8.8
> 2024-06-26 12:15:54 log_sent 16674 DEBUG ATLAS PRB_ID@1008458 Crontab sent
> successfully to the probe
> 2024-06-26 12:15:58 _log 16448 DEBUG ATLAS PRB_ID@1008458 bdcsHA RECVD
> "lts":15, "time":1719404158, "dst_name":"8.8.8.8", "af":4,
> "dst_addr":"8.8.8.8", "src_addr":”YOUR_IP", "proto":"ICMP", "ttl":61,
> "size":64, "result": [ { "rtt":3.776701 }, { "rtt":3.619775 }, {
> "rtt":3.516480 } ] }
>
> That seems to work.
>
> No idea why it worked before, can it be that the sites you visit just happen
> to support IPv6?
>
> Regards,
>
> Michel
>> On 26 Jun 2024, at 14:10, RIPE wrote:
>>
>> HI,
>> That might be it. There was no default route configured on my Edgerouter. I
>> have now triied to configure one.
>> At the moment netstat -rn does show a default route for IPv4.
>> I have restarted the probe, I assume it may take a little time for the
>> measurements to show results.
>> What’s strange is is that it did work as a router for my home network. I
>> think I forced the link to the ISP to be the route somehow.
>>
>>
>> Thanks,
>> Paul
>>
>>
>>> On 26 Jun 2024, at 13:36, Michel Stam wrote:
>>>
>>> Hey Paul,
>>>
>>> I did a quick look in the logs and noticed that the probe doesn’t seem to
>>> have a default route for IPv4, but it does for IPv6. Can you check to see
>>> if this is a possible cause?
>>>
>>> Regards,
>>>
>>> Michel
>>>
>>>> On 26 Jun 2024, at 09:10, RIPE via ripe-atlas wrote:
>>>>
>>>> Hi,
>>>> My old hardware probe seems to have finally given up. So I installed a
>>>> soft probe on my openwrt edgerouter-X, using the openwrt opkg packages.
>>>> That seems to work except for all the IPv4 built-ins.
>>>> I have a hurricane.net tunnel as my ISP ( Odido) is stuck in the past and
>>>> does not provide IPv6.
>>>> The IPv6 built-ins all show data but the IPv4 ones show ‘No data available
>>>> for the period’
>>>>
>>>> From the shell I can ping the addresses used by the built-ins, the names
>>>> also resolve.
>>>>
>>>> Any idea what the cause could be ? Or how to find the cause.
>>>>
>>>>
>>>> Probe ID = 1008458
>>>> Running OpenWrt 23.05.3, r23809-234f1a2efa
>>>> Package: atlas-sw-probe
>>>> Version: 5080-2
>>>>
>>>> Regards,
>>>>Paul
>>>>
>>>>
>>>> --
>>>> ripe-atlas mailing list
>>>> ripe-atlas@ripe.net
>>>> https://lists.ripe.net/mailman/listinfo/ripe-atlas
>>>
>>>
>>
>
>
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] IPv4 Built-ins fail while IPv6 work
HI, That might be it. There was no default route configured on my Edgerouter. I have now triied to configure one. At the moment netstat -rn does show a default route for IPv4. I have restarted the probe, I assume it may take a little time for the measurements to show results. What’s strange is is that it did work as a router for my home network. I think I forced the link to the ISP to be the route somehow. Thanks, Paul > On 26 Jun 2024, at 13:36, Michel Stam wrote: > > Hey Paul, > > I did a quick look in the logs and noticed that the probe doesn’t seem to > have a default route for IPv4, but it does for IPv6. Can you check to see if > this is a possible cause? > > Regards, > > Michel > >> On 26 Jun 2024, at 09:10, RIPE via ripe-atlas wrote: >> >> Hi, >> My old hardware probe seems to have finally given up. So I installed a soft >> probe on my openwrt edgerouter-X, using the openwrt opkg packages. >> That seems to work except for all the IPv4 built-ins. >> I have a hurricane.net tunnel as my ISP ( Odido) is stuck in the past and >> does not provide IPv6. >> The IPv6 built-ins all show data but the IPv4 ones show ‘No data available >> for the period’ >> >> From the shell I can ping the addresses used by the built-ins, the names >> also resolve. >> >> Any idea what the cause could be ? Or how to find the cause. >> >> >> Probe ID = 1008458 >> Running OpenWrt 23.05.3, r23809-234f1a2efa >> Package: atlas-sw-probe >> Version: 5080-2 >> >> Regards, >> Paul >> >> >> -- >> ripe-atlas mailing list >> ripe-atlas@ripe.net >> https://lists.ripe.net/mailman/listinfo/ripe-atlas > > -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] IPv4 Built-ins fail while IPv6 work
Hi, My old hardware probe seems to have finally given up. So I installed a soft probe on my openwrt edgerouter-X, using the openwrt opkg packages. That seems to work except for all the IPv4 built-ins. I have a hurricane.net tunnel as my ISP ( Odido) is stuck in the past and does not provide IPv6. The IPv6 built-ins all show data but the IPv4 ones show ‘No data available for the period’ From the shell I can ping the addresses used by the built-ins, the names also resolve. Any idea what the cause could be ? Or how to find the cause. Probe ID = 1008458 Running OpenWrt 23.05.3, r23809-234f1a2efa Package: atlas-sw-probe Version: 5080-2 Regards, Paul -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] multiple probes down since Jun 24th?
Noticed a lot of disconnects from controller ktr-dub01 on our anchor 7361, is that the problematic one and is there any way that can be disabled? Regards, Peter Potvin On Tue, Jun 25, 2024 at 06:09 Johan ter Beest wrote: > Hi Ernst, > > Yes, indeed, your probe is on the problematic controller > > Cheers, > Johan > > On Tue, 25 Jun 2024 at 10:11, Ernst J. Oud wrote: > >> Hi, >> >> Same here: >> >> https://atlas.ripe.net/probes/1005072/ >> >> Down since yesterday. Tried restarting it, did not help. The PC it is >> running on is fine and has a working internet connection. The probe >> software is running, SOS messages are communicated every 3 minutes. >> >> Probably the same problem as mentioned here. >> >> Regards, >> >> Ernst J. Oud >> >> On 25 Jun 2024, at 09:19, Robert Kisteleki wrote: >> >> Hello, >> >> Indeed we are experiencing some trouble with one of our controllers. >> This can affect probes and anchors, seemingly up to 10% of the probe >> population. The team is investigating the issue. >> >> Regards, >> Robert >> >> On Tue, Jun 25, 2024 at 8:36 AM Andreas S. Kerber via ripe-atlas >> wrote: >> >> >> Hi, >> >> >> our probe is reported down since yesterday: >> https://atlas.ripe.net/probes/7054/ >> >> >> Since I couldn't find a problem on our side and rebooting didn't change >> the status, I checked other probes (not mine) and they are reported down >> since the exact downtime as mine. Is there any kind of known problem at the >> moment? >> >> >> >> Other probes with the same downtime: >> >> >> https://atlas.ripe.net/probes/7040 >> >> https://atlas.ripe.net/probes/7052 >> >> https://atlas.ripe.net/probes/7063 >> >> https://atlas.ripe.net/probes/7067 >> >> https://atlas.ripe.net/probes/7068 >> >> >> -- >> >> Andreas Kerber (Senior IT-Engineer/Consultant) >> >> >> a...@idkom.de >> >> ___ >> >> IDKOM Networks GmbH >> >> Dieselstraße 1 * D-87437 Kempten (Allgäu) >> >> >> Tel.: 0831 59090-200 >> >> Fax: 0831 59090-90 >> >> www.idkom.de >> >> >> Registergericht: Amtsgericht Kempten (HRB 6359) >> >> Geschäftsführer: Benjamin Mayer * Klaus Giehl >> >> >> Diese E-Mail und alle mitgesendeten Dateien sind vertraulich und >> ausschließlich für den Gebrauch durch den Empfänger bestimmt! >> >> >> -- >> >> ripe-atlas mailing list >> >> ripe-atlas@ripe.net >> >> https://lists.ripe.net/mailman/listinfo/ripe-atlas >> >> >> -- >> ripe-atlas mailing list >> ripe-atlas@ripe.net >> https://lists.ripe.net/mailman/listinfo/ripe-atlas >> >> -- >> ripe-atlas mailing list >> ripe-atlas@ripe.net >> https://lists.ripe.net/mailman/listinfo/ripe-atlas >> > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] multiple probes down since Jun 24th?
Hi, our probe is reported down since yesterday: https://atlas.ripe.net/probes/7054/ Since I couldn't find a problem on our side and rebooting didn't change the status, I checked other probes (not mine) and they are reported down since the exact downtime as mine. Is there any kind of known problem at the moment? Other probes with the same downtime: https://atlas.ripe.net/probes/7040 https://atlas.ripe.net/probes/7052 https://atlas.ripe.net/probes/7063 https://atlas.ripe.net/probes/7067 https://atlas.ripe.net/probes/7068 -- Andreas Kerber (Senior IT-Engineer/Consultant) a...@idkom.de ___ IDKOM Networks GmbH Dieselstraße 1 * D-87437 Kempten (Allgäu) Tel.: 0831 59090-200 Fax: 0831 59090-90 www.idkom.de Registergericht: Amtsgericht Kempten (HRB 6359) Geschäftsführer: Benjamin Mayer * Klaus Giehl Diese E-Mail und alle mitgesendeten Dateien sind vertraulich und ausschließlich für den Gebrauch durch den Empfänger bestimmt! -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] [ anchor] Quota on the usage of an anchor in measurement.
Hello. In my research, I am conducting multiple RTT measurements against different targets. During the measurement process, a single anchor stops getting scheduled for a requested measurement after some number of times or returns -1 as a result. I want to ask if there is a limit on how many times a single anchor can participate in a measurement. And what is its cooldown period if such a limit exists? With regards, Huseyn Gambarov Research Assistant PhD Student in Computer Science Case Western Reserve University -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] repetitive 2fa authentication on every login
Hi team, https://atlas.ripe.net/probes/mine requires new login upon every browser open. It even requires 2FA every time. Is it possible to keep the session active for maybe a month, or at least do not ask 2FA every single time? I would think as services like gmail.com, portal.azure.com, account.synology.com, etc., do not require 2fa on every browser close and reopen, it may not be as crucial to perform 2fa every time I need to check if my probes are online? It becomes a bit annoying, especially me using mobile browser. Please consider. Thank you. Jiri -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] How long is a year?
Hey, On 6/7/24 00:52, Edward Lewis wrote: I don’t know the first_connection_time, just the probe’s “birthday”. The connected time’s resolution is to the minute, but the birthday is only the day, not the minute. While not shown on the webinterface, you can get the precise times via the API, for example https://atlas.ripe.net/api/v2/probes/6425?fields=first_connected,total_uptime for probe 6425. Is one ‘y’ = 365 days or 365.25 or 365.2422 days (commonly held numbers for days in a year)? Comparing the total_uptime of the query above (172964827 seconds), with the time on the webinterface (5y 176d 21h 48m) I get 364.999 days, so I'd assume it uses y = 365 days if you include the seconds. Best, Malte OpenPGP_0x7D82498BEF2E08F8.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] How to be more helpful...
OK, here's my "problem." For starters I think the Atlas project is a great thing for the Internet, and I thank my local ISP, Comcast (USA), for encouraging me to sign up. But here's the thing for me. I have so many millions of points accumulated. When I see a message on this message list about someone asking for, say 20 million points, by the time I see that message, the requester has already received, typically, more than twice the number of points requested. (and I will say right now, private requests for points will be ignored) So my question becomes... I participate in this amazing project with a measurement device. But I also want to participate in the project by helping others, I guess I am asking, is there a way I can contribute points without having to check the list every hour or so? -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] TraceMON pages broken?
Hi, it seems like the TraceMON widget is currently broken. The tracemon-dist.js [0] file appears to be missing, which is required by the main traceroute-widget-main.js [1] file. Tried with Chromium and Firefox and both the old [2] and new [3] way. Would be happy about a fix :) Best, Malte [0] https://www-static.ripe.net/static/rnd-ui/atlas/static/measurements/widgets/tracemon/tracemon-dist.js [1] https://www-static.ripe.net/static/rnd-ui/atlas/static/measurements/widgets/tracemon/tracemon-widget-main.js [2] https://atlas.ripe.net/measurements/944/#tracemon [3] https://atlas.ripe.net/tracemon/944 OpenPGP_0x7D82498BEF2E08F8.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] random, but unique ASN probe selection
Hi Marco, let me plug a project of mine: https://ihr.iijlab.net/ihr/en-us/metis/selection you can enter the number of probes (aka unique ASes) you want to use in the form and then click on "Go". At the bottom of the page you will then find a JSON snippet which replaces the "probes" field of the API spec provided by the Atlas webinterface. This selection tries to prioritize ASes that are "far apart" from each other according to the distance metric in the form, so the order is not randomized, but depending on what you want to achieve might be random enough. If you want to do multiple iterations with a randomized AS set each time, I guess you will have to build this yourselfes. However, you could enter 4000 for the number of probes and the API spec will contain fields for all ASes with connected Atlas probes, which you could use as a starting point. Also note that you might not get the exact number of probes requested, since some ASes only have one probe and if it's overloaded it won't participate. Best, Malte OpenPGP_0x7D82498BEF2E08F8.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Request RIPE Atlas Credit Donation for Internet Routing Research
I will send 50 million campus credits to you, We are happy to help you in conducting research. Pada Sab, 4 Mei 2024 pukul 13.20 Shihan Lin menulis: > Dear RIPE Community, > > > My name is Shihan Lin, a PhD student in the Department of Computer Science > at Duke University. My colleagues and I are working on an Internet research > project led by Prof. Xiaowei Yang, and we are using RIPE Atlas probes in > our research project. However, we face a credit shortage in our account, > so we are writing to humbly request your consideration of a potential > credit donation to support our ongoing research efforts. > > > Our research project aims to improve cloud routing. We first need to > measure the existing cloud routing performance, so we need to send > traceroutes and pings from probes around the world to VMs in multiple > regions of three commercial cloud providers. With traceroute results, we > can detect clouds’ Points of Presence (PoPs) used by probes to reach the > VMs. By discovering the PoPs of a cloud, we can discover alternative paths > by selecting different PoPs to enter the cloud and thus improve the routing > latency. We finished a part of such measurements and discovered some better > alternative paths. However, we need another round of measurement to verify > our findings. Specifically, we need to send repeated pings from probes to > alternative PoPs to validate that such PoPs consistently offer lower > latency. > > > According to our calculation, we need about 50M credits for our remaining > measurement. Thus we are wondering whether we could ask for some donations > from the RIPE community. We greatly appreciate any assistance you can > offer. If it is possible, you can donate it to my RIPE Atlas account > LSHZY137 at gmail.com. > > > Thank you very much for your help and great generosity! Our research will > be submitted to a networking conference (SIGCOMM, NSDI, or IMC) to share > the knowledge with the public. > > > Many Thanks, > > Shihan Lin > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > -- Thank you for your consideration. Best regards, Fadloe Robby Telp/WA : 0812-5154-3201 Univeritas Lambung Mangkurat UPT PTIK Univeritas Lambung Mangkurat gedung Rektorat Lantai III Jalan Brigjen H. Hasan Basri Banjarmasin 70123 Telp./Fax. (0511) 330 5195, -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Request RIPE Atlas Credit Donation for Internet Routing Research
Hi Shihan, 50m transferred Groetjes, Stijn On Sat, 4 May 2024, at 07:18, Shihan Lin wrote: > Dear RIPE Community, > > > > My name is Shihan Lin, a PhD student in the Department of Computer Science at > Duke University. My colleagues and I are working on an Internet research > project led by Prof. Xiaowei Yang, and we are using RIPE Atlas probes in our > research project. However, we face a credit shortage in our account, so we > are writing to humbly request your consideration of a potential credit > donation to support our ongoing research efforts. > > > > Our research project aims to improve cloud routing. We first need to measure > the existing cloud routing performance, so we need to send traceroutes and > pings from probes around the world to VMs in multiple regions of three > commercial cloud providers. With traceroute results, we can detect clouds’ > Points of Presence (PoPs) used by probes to reach the VMs. By discovering the > PoPs of a cloud, we can discover alternative paths by selecting different > PoPs to enter the cloud and thus improve the routing latency. We finished a > part of such measurements and discovered some better alternative paths. > However, we need another round of measurement to verify our findings. > Specifically, we need to send repeated pings from probes to alternative PoPs > to validate that such PoPs consistently offer lower latency. > > > > According to our calculation, we need about 50M credits for our remaining > measurement. Thus we are wondering whether we could ask for some donations > from the RIPE community. We greatly appreciate any assistance you can offer. > If it is possible, you can donate it to my RIPE Atlas account LSHZY137 at > gmail.com. > > > > Thank you very much for your help and great generosity! Our research will be > submitted to a networking conference (SIGCOMM, NSDI, or IMC) to share the > knowledge with the public. > > > > Many Thanks, > > Shihan Lin > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Possible software probe "farming" on AS47583
Did anything come of this? I just ran a measurement to spot check
something and the same AS47583 probes make up a "hilarious" amount of
results: https://atlas.ripe.net/measurements/70655999#probes
On Tue, 20 Feb 2024 at 23:16, Ben Cartwright-Cox wrote:
>
> Those limits seem reasonable enough,
>
> My own intuition would suggest values of:
>
> X=2
> Y=3
> Z=5
>
> But otherwise, I welcome such a change being implemented!
>
> On Tue, 20 Feb 2024 at 15:43, Robert Kisteleki wrote:
> >
> >
> > > Is there an immediate way to report these probes other than this
> > > mailing list? I don't know of one and so I'm here :)
> >
> >
> > Dear Ben and others,
> >
> > Each new, connected RIPE Atlas probe provides incremental value to the
> > system and its users, but this value decreases with similarity to
> > existing probes ("diminishing returns"). At the same time connecting a
> > probe and processing results from it has some costs, so we'd like to be
> > conscious of the cost/benefit ratio.
> >
> > Since the potential pool of software probes is almost infinite, in
> > response to the highlighted case, we'd like to propose the following
> > mid-term approach:
> >
> > * No user/account should be allowed to run more than X SW probes from
> > the same IP (X=3 ?)
> >
> > * No user/account should be allowed to run more than Y SW probes from
> > the same IPv4/24 IPv6/48 (Y=5 ?)
> >
> > * Regardless of the user/account, no more than Z SW probes should be
> > allowed from the same IPv4/24 IPv6/48 (Z=10 ?)
> >
> > X, Y and Z are defaults, can be changed per account. This is done in
> > order to facilitate corner cases and overstepping the limits, if this is
> > warranted (given a good explanation). We are also reaching out to the
> > current "peak users" to understand their use cases and motivations - the
> > above limits can be enforced depending on the responses.
> >
> > In the longer term we believe a more flexible approach is to base this
> > on what has been termed "probe similarity metrics": a new probe that is
> > really similar to some existing one has less value to the system,
> > therefore after reaching a low enough limit it can be refused, or
> > alternatively, simply not gaining credits for its owner. This
> > diincentivises creating "probe farms".
> >
> > Regards,
> >
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Another research credit request
Fellow Peter, 25M sent :) Kind regards, Peter Potvin On Wed, Apr 24, 2024 at 9:19 AM Peter Thomassen wrote: > Dear friends of ATLAS, > > We're conducting a research project [1] involving ATLAS measurements with > multiple PQC signing implementations (Falcon, XMSS, Dilithium, Sphincs+) to > see how many clients choke, in various scenarios, depending on the response > packet properties that come with such responses. The idea is to help inform > how good or bad the situation is, and which aspects need further research. > > We'd like to do a very comprehensive measurement, and expect our > measurements to use around 25M credits total. (We currently have 3M.) > > If anyone is willing to donate the missing amount to this project, that > would be very much appreciated! > > My RIPE account is pe...@desec.io. Thank you very much for considering > and your generosity! > > Best, > Peter > > [1]: https://nlnet.nl/project/PQ-DNSSEC-Testbench/ > > -- > https://desec.io/ > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] ICMP error codes in measurement results
Hi Marco, I assume the pretty-printing part is simply not implemented for ICMPv6. "Unrecognized error codes are represented as integers" [0] And the err field is also set to code 6, here [1] so everything seems in order. Maybe Atlas will add better printing support for ICMPv6 in the future :) Best, Malte [0] https://atlas.ripe.net/docs/apis/result-format/#version-5000-traceroute-v6-traceroute [1] https://atlas.ripe.net/api/v2/measurements/70248021/results OpenPGP_0x7D82498BEF2E08F8.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] Understanding participating probes and probe requests
Hi, I'm currently looking at measurement metadata and am a bit confused about the different ways of getting the number of probes participating in a measurement and the number of probes requested by the user. I'd like to know how to... 1. get the number of probes _currently_ participating in a measurement (for ongoing measurements) 2. the number of probes that participated when the measurement finished (for stopped measurements) 3. the number of probes a user requested over the lifetime of a measurement The default response to /measurements returns a participant_count and a probes_requested value. However, there are also the optional fields current_probes and participation_requests and these do not add up. For example, this [0][1] measurement (not mine) has a participant_count of 0 (showing as "Actually Participating: None") in the web interface, but one probe listed in current_probes, which shows up in the "Latest Results" list and is still performing measurements (at least while writing this). So it seems like the current_probes list is more accurate to get the number of probes _currently_ (or when the measurement finished) participating in a measurement? Similarly, there are 35 probes_requested, which equals the sum of "requested" probes from the participation_requests, however, some request are actually "remove" actions, which should not be included in this count? Any hints on how to interpret these fields? I think the requested probes and participation requests are more a problem for long-running measurements, but the participant count is sometimes weird for one-offs as well. Thanks, Malte [0] https://atlas.ripe.net/measurements/67903255 [1] https://atlas.ripe.net/api/v2/measurements/67903255?optional_fields=current_probes,participation_requests OpenPGP_0x7D82498BEF2E08F8.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] New default settings for Atlas measurement form
Stephen, many thanks. Great idea. I see it useful. // Hans -- On 13.03.24 10:53, Ben Cartwright-Cox via ripe-atlas wrote: Thanks Stephen (and team) these are the common settings I change if I'm using the web UI, so I'm sure this will be helpful to many On Wed, Mar 13, 2024, 09:42 Stephen Suess wrote: Hello Atlas users, After an analysis of usage patterns in measurement creation, we have rolled out a couple of changes to the defaults in the measurement form (https://atlas.ripe.net/measurements/form/): - Under timing, the default is now one-off (instead of periodic as before) - Default probe selection is now 50 random, worldwide probes (instead of 10 as before) We hope you find these useful. Please let us know if you encounter any issues. Thanks! Stephen RIPE Atlas UI -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] New default settings for Atlas measurement form
Thanks Stephen (and team) these are the common settings I change if I'm using the web UI, so I'm sure this will be helpful to many On Wed, Mar 13, 2024, 09:42 Stephen Suess wrote: > Hello Atlas users, > > After an analysis of usage patterns in measurement creation, we have > rolled out a couple of changes to the defaults in the measurement form ( > https://atlas.ripe.net/measurements/form/): > > - Under timing, the default is now one-off (instead of periodic as before) > - Default probe selection is now 50 random, worldwide probes (instead of > 10 as before) > > We hope you find these useful. Please let us know if you encounter any > issues. > > Thanks! > Stephen > RIPE Atlas UI > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Possible software probe "farming" on AS47583
Those limits seem reasonable enough,
My own intuition would suggest values of:
X=2
Y=3
Z=5
But otherwise, I welcome such a change being implemented!
On Tue, 20 Feb 2024 at 15:43, Robert Kisteleki wrote:
>
>
> > Is there an immediate way to report these probes other than this
> > mailing list? I don't know of one and so I'm here :)
>
>
> Dear Ben and others,
>
> Each new, connected RIPE Atlas probe provides incremental value to the
> system and its users, but this value decreases with similarity to
> existing probes ("diminishing returns"). At the same time connecting a
> probe and processing results from it has some costs, so we'd like to be
> conscious of the cost/benefit ratio.
>
> Since the potential pool of software probes is almost infinite, in
> response to the highlighted case, we'd like to propose the following
> mid-term approach:
>
> * No user/account should be allowed to run more than X SW probes from
> the same IP (X=3 ?)
>
> * No user/account should be allowed to run more than Y SW probes from
> the same IPv4/24 IPv6/48 (Y=5 ?)
>
> * Regardless of the user/account, no more than Z SW probes should be
> allowed from the same IPv4/24 IPv6/48 (Z=10 ?)
>
> X, Y and Z are defaults, can be changed per account. This is done in
> order to facilitate corner cases and overstepping the limits, if this is
> warranted (given a good explanation). We are also reaching out to the
> current "peak users" to understand their use cases and motivations - the
> above limits can be enforced depending on the responses.
>
> In the longer term we believe a more flexible approach is to base this
> on what has been termed "probe similarity metrics": a new probe that is
> really similar to some existing one has less value to the system,
> therefore after reaching a low enough limit it can be refused, or
> alternatively, simply not gaining credits for its owner. This
> diincentivises creating "probe farms".
>
> Regards,
>
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Possible software probe "farming" on AS47583
On 20.02.2024 18:43, Robert Kisteleki wrote: * No user/account should be allowed to run more than X SW probes from the same IP (X=3 ?) Is there any rationale for allowing running multiple probes on the same IP (especially the same user)? They would have (almost) identical network topologies, and would not provide any benefits in terms of expanding the view of RIPE Atlas. -- Best regards, Semisol -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Meaning and the future of the project
I have been involved in this project for over 12 years. For the last few weeks I have been wondering what the point of this is. OK, I have given out credits to students for research, though sometimes they do not even say thank you. Not answering directly your question, but just a comment w.r.t. "what is the point". If you’re referring to what is the purpose of the platform, I can provide some feedback as someone who has experience in both industry and academia. Ripe Atlas is _fundamental_ to research. No other platform offers the same level of coverage in terms of diversity and number of vantage points, as well as real-time results. Plus, it's free of charge. Without it, many advancements in DNS, NTP, and routing wouldn't have been possible. There are numerous academic papers and several RFCs that have used RIPE Atlas, achievements that wouldn’t have been possible without it. /giovane -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] Meaning and the future of the project
Hello, I have been involved in this project for over 12 years. For the last few weeks I have been wondering what the point of this is. OK, I have given out credits to students for research, though sometimes they do not even say thank you. The firmware on the probes has not changed for years, the front-end except for cosmetic changes also does not go through shocking developments (still the same bugs), new features are not implemented, just discussed (e-mail notifications) etc. So I would actually just like to ask: - How many people are working full time on this project at RIPE? - What is the priority for RIPE? - What is the future? Any realistic plans? Thank you, Petr -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Possible software probe "farming" on AS47583
The same farming is observed in other AS47583 locations: US, UK, France, Netherlands, Lithuania, India, Singapore, Indonesia. Regards, Grzegorz -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Possible software probe "farming" on AS47583
I reported the problem in March 2022 but without good solution :/ https://www.ripe.net/ripe/mail/archives/ripe-atlas/2022-March/004961.html Filtering out all software probes is not a solution because many of them are good and useful. We should have filters to filter out probes which are useless and are deployed only for farming purposes and here we have totally such case. Regards, Grzegorz From: ripe-atlas on behalf of Randy Bush Date: Monday, 5 February 2024 at 18:54 To: Ben Cartwright-Cox via ripe-atlas Subject: Re: [atlas] Possible software probe "farming" on AS47583 While doing some measurement work earlier this weekend I discovered that there are a large amount of probes on AS47583 that look like they are being set up to farm credits. seems silly, as all one has to do to get a jillion credits is asl on the mailing list randy -- ripe-atlas mailing list ripe-atlas@ripe.net<mailto:ripe-atlas@ripe.net> https://urldefense.com/v3/__https://lists.ripe.net/mailman/listinfo/ripe-atlas__;!!GjvTz_vk!SDCX1ok7Fg4dHevsKnAsP6jnOnJYpKBHkT3XgSzeFCzXDPyVlJ59NDSYifR_pu5mr7XL9NCQCA$<https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atlas__;!!GjvTz_vk!SDCX1ok7Fg4dHevsKnAsP6jnOnJYpKBHkT3XgSzeFCzXDPyVlJ59NDSYifR_pu5mr7XL9NCQCA$> -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Possible software probe "farming" on AS47583
You can already do this, you select to exclude the "System: Software" tag On Mon, Feb 5, 2024 at 3:23 PM Ian Chilton wrote: > > Hi, > > On Mon, 5 Feb 2024, at 3:11 PM, Ben Cartwright-Cox via ripe-atlas wrote: > > Now while I myself don't particularly care about credit farming on > RIPE Atlas (After all RIPE Atlas credit is kind of like Monopoly > money), I do care about things becoming biased towards these software > probes. > > > Might be good when setting up a measurements, to have the option of using > only hardware probes. > > Ian > > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] Possible software probe "farming" on AS47583
:116" "45.128.160.124 2a02:4780:9:c0de::94" "45.143.83.65 2a02:4780:13:c0de::b" "45.143.83.66 2a02:4780:13:c0de::c" "45.143.83.67 2a02:4780:13:c0de::d" "45.143.83.68 2a02:4780:13:c0de::e" "45.143.83.69 2a02:4780:13:c0de::f" "45.143.83.70 2a02:4780:13:c0de::10" "45.143.83.71 2a02:4780:13:c0de::11" "45.143.83.72 2a02:4780:13:c0de::12" "45.143.83.73 2a02:4780:13:c0de::13" "45.143.83.74 2a02:4780:13:c0de::14" "45.143.83.75 2a02:4780:13:c0de::15" "45.143.83.76 2a02:4780:13:c0de::16" "45.143.83.77 2a02:4780:13:c0de::17" "45.143.83.78 2a02:4780:13:c0de::18" "45.143.83.79 2a02:4780:13:c0de::19" "89.116.146.65 2a02:4780:27:c0de::b" "89.116.146.66 2a02:4780:27:c0de::c" "89.116.146.67 2a02:4780:27:c0de::d" "89.116.146.68 2a02:4780:27:c0de::e" "89.116.146.69 2a02:4780:27:c0de::f" "89.116.146.70 2a02:4780:27:c0de::10" "89.116.146.71 2a02:4780:27:c0de::11" "89.116.146.72 2a02:4780:27:c0de::12" "89.116.146.73 2a02:4780:27:c0de::13" "89.116.146.74 2a02:4780:27:c0de::14" "89.116.146.75 2a02:4780:27:c0de::15" "89.116.146.76 2a02:4780:27:c0de::16" "89.116.146.77 2a02:4780:27:c0de::17" "89.116.146.78 2a02:4780:27:c0de::18" "89.116.146.79 2a02:4780:27:c0de::19" Now while I myself don't particularly care about credit farming on RIPE Atlas (After all RIPE Atlas credit is kind of like Monopoly money), I do care about things becoming biased towards these software probes. For example, when I had selected for a selection of probes in Brazil I ended up with several of these software probes giving me the exact same results. this is not very useful and this has the potential to bias academic measurements, had I not looked at the probe list results this would not have been immediately obvious. Is there an immediate way to report these probes other than this mailing list? I don't know of one and so I'm here :) Cheers Ben -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] destination_ip_responded field in traceroute measurements
On 1/12/24 20:31, Francesco Iannuzzelli wrote: We have just updated the documentation https://atlas.ripe.net/docs/apis/result-format Thanks! However, it seems like the field was added to the documentation for firmware version 4570 only? I honestly don't know where it should be added since it's a server-side feature, but my first place to look for documentation is the newest version, so I think it should be at least added there :) Best, Malte OpenPGP_0x1FE5C61A04A4159F.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] destination_ip_responded field in traceroute measurements
Hi, to my delight I discovered that there is now a "destination_ip_responded" field contained in traceroute measurement results. I often want to know this and had to handle it myself until now so I'm very happy that this seems to be a built-in field now. I only wonder if this is a feature to stay (since it's not in the documentation yet), and if it is server side, i.e., always available independent of the probe firmware? Best, Malte OpenPGP_0x1FE5C61A04A4159F.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] New coverage and statistics page
He Stephen, I can confirm! After a reload, it works. Also, all the countries now have different colors (they were all yellow before). Seems like Thomas Schäfer had the same problem. BR, Simon On 15.11.23 16:46, Stephen Suess wrote: Hi Simon, I think I see why this might happen sometimes, when you first load the data the page might have a slight timing issue depending on network conditions. A simple page reload should fix this for you, and I will have a bug fix for this shortly, thanks for reporting it. Kind regards, Stephen On 15 Nov 2023, at 16:02, Simon Brandt via ripe-atlas wrote: Hi Stephen, for me, the tooltip always shows: whatevercountry 0 probes (0,00%) Tried with Firefox and Chrome. BR, Simon On 15.11.23 14:33, Stephen Suess wrote: Hi Thomas, Thanks for the feedback. When you hover on a country you see a tooltip that displays (in addition to the number of probes) the percent of the total of probes. The legend gives you an idea (by color) of how many probes fall into each color range. Hope this clarifies. Kind regards, Stephen On 15 Nov 2023, at 13:40, Thomas Schäfer wrote: Hi Stephen, it looks nice. But what means "Show Percent Coverage Layer"? Because of "Percent" I would expect a scale from 1 to 100. But you have different ranges of Probes (per Square Meter?) - at the Moment the range of 0-200 never exceeds. Regards, Thomas Am 15.11.23 um 12:32 schrieb Stephen Suess: Hi Atlas Friends, As part of our continuing improvements to the Atlas UI, we have just pushed a major reworking of the coverage and statistics page. Among the improvements: - Cleaner, simpler interface - Vastly improved loading time - Single map integrates layer toggles for connected, disconnected and percent coverage - Top ASNs / Prefixes / Countries section are now clickable pie charts allowing you to see items in relation to each other or the entirety - Reworked line charts for users, probes, anchors - As with other Atlas improvements, this is now completely client side (except for the API getting data) You can find the new page athttps://atlas.ripe.net/coverage/ <https://atlas.ripe.net/coverage/> Hope you enjoy, please let us know what you think. Thanks! Stephen RIPE Atlas UI -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] New coverage and statistics page
Hi Stephen, for me, the tooltip always shows: whatevercountry 0 probes (0,00%) Tried with Firefox and Chrome. BR, Simon On 15.11.23 14:33, Stephen Suess wrote: Hi Thomas, Thanks for the feedback. When you hover on a country you see a tooltip that displays (in addition to the number of probes) the percent of the total of probes. The legend gives you an idea (by color) of how many probes fall into each color range. Hope this clarifies. Kind regards, Stephen On 15 Nov 2023, at 13:40, Thomas Schäfer wrote: Hi Stephen, it looks nice. But what means "Show Percent Coverage Layer"? Because of "Percent" I would expect a scale from 1 to 100. But you have different ranges of Probes (per Square Meter?) - at the Moment the range of 0-200 never exceeds. Regards, Thomas Am 15.11.23 um 12:32 schrieb Stephen Suess: Hi Atlas Friends, As part of our continuing improvements to the Atlas UI, we have just pushed a major reworking of the coverage and statistics page. Among the improvements: - Cleaner, simpler interface - Vastly improved loading time - Single map integrates layer toggles for connected, disconnected and percent coverage - Top ASNs / Prefixes / Countries section are now clickable pie charts allowing you to see items in relation to each other or the entirety - Reworked line charts for users, probes, anchors - As with other Atlas improvements, this is now completely client side (except for the API getting data) You can find the new page athttps://atlas.ripe.net/coverage/ <https://atlas.ripe.net/coverage/> Hope you enjoy, please let us know what you think. Thanks! Stephen RIPE Atlas UI -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] decommission of virtual probes
My bad. non-hardware probes are called "software probes" non-hardware anchors are called "virtual anchors" I mixed that up. I meant software probes. BR, Simon On 06.11.23 21:16, Ernst J. Oud wrote: Define “virtual probe” please? Do you mean a SW probe? To me a SW probe is as real as a HW probe. Or do you mean an abandoned probe? Regards, Ernst J. Oud On 6 Nov 2023, at 20:53, Simon Brandt via ripe-atlas wrote: Hello folks, dear Atlas team, I would like to discuss the case, where a virtual probe is decommissioned because the place where you ran it will no longer be available. For example, a VPS which you have rented somewhere, but you've decided to cancel that service. Does it make sense to create and keep a backup of the virtual probe, so that you can re-deploy it later (with another AS)? Or is it better to delete the virtual probe and create a new one? Also: is there an official way to decommission a virtual probe permanently? I felt like this could be interesting for other people too, so i decided to discuss this question publicly. BR, Simon -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] decommission of virtual probes
Hello folks, dear Atlas team, I would like to discuss the case, where a virtual probe is decommissioned because the place where you ran it will no longer be available. For example, a VPS which you have rented somewhere, but you've decided to cancel that service. Does it make sense to create and keep a backup of the virtual probe, so that you can re-deploy it later (with another AS)? Or is it better to delete the virtual probe and create a new one? Also: is there an official way to decommission a virtual probe permanently? I felt like this could be interesting for other people too, so i decided to discuss this question publicly. BR, Simon -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] NTP empty results ('result': [{'x': '*'}])
Hi folks,
I am getting some NTP results in the following format:
'result': [{'x': '*'}],
Does anyone know waht is this supposed to mean? is it like the
measurement did not run?
See blob below:
{'fw': 5080,
'mver': '2.6.2',
'lts': 20,
'dst_name': '186.155.28.147',
'dst_addr': '186.155.28.147',
'src_addr': '10.10.31.19',
'proto': 'UDP',
'af': 4,
'result': [{'x': '*'}],
'msm_id': 47867316,
'prb_id': 33745,
'timestamp': 1671799154,
'msm_name': 'Ntp',
'from': '85.238.41.3',
'type': 'ntp',
'group_id': 47867316,
'stored_timestamp': 1671799249}]
thanks,
/giovane
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Atlas fully down..
Consumption delay according to the main page is up to 16+ hours so something is indeed very wrong. Regards, Peter Potvin | Executive Director -- *Accuris Technologies Ltd.* On Tue, Sep 19, 2023 at 6:06 PM Randy Bush wrote: > > Considering the fact that all of Atlas is completely down for more > > than 24 hrs., I find the silence a bit deafening. No status updates, > > nothing. Weird. > > been down so long it looks like up to me [0] > > as you are probably too young for that reference, how about it looks > pretty up from here. perhaps a more specific symptom might help with > diagnosis. > > randy > > [0] https://en.wikipedia.org/wiki/Been_Down_So_Long_It_Looks_Like_Up_to_Me > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] What is the trick with "+Reuse a set from a measurement" ?????
Moin,
Any updates here?
To me it looks like as if this very useful feature is still not working.
Cheers,
Olli
Original Message
From: Malte Tashiro via ripe-atlas [mailto:ripe-atlas@ripe.net]
Sent: Monday, November 21, 2022 at 4:17 AM
To: ripe-atlas@ripe.net
Subject: [atlas] What is the trick with "+Reuse a set from a
measurement" ?
Hi Barry,
this function does indeed still work, but it appears that the web
interface for it is somewhat broken?
If I search for "traceroute" one of the results is measurement 1001589
[0], which has this term in the description, but searching for that
measurement id gives no result. And in any case, the only available
results seem to be very old looking at the ids.
What _does_ work is using the measurement API, for example:
"probes": [
{
"type": "msm",
"value": your_msm_id_here,
"requested": number_of_probes_here
}
]
Not sure this is the answer you wanted to hear, but maybe someone from
the Atlas development team can figure out what's up with the web interface.
Best,
Malte
[0] https://atlas.ripe.net/measurements/1001589
On 11/21/22 03:16, Barry Greene wrote:
Hi Team,
I’m trying to use “+Reuse a set from a measurement.” (See
https://atlas.ripe.net/docs/getting-started/user-defined-measurements.html
<https://atlas.ripe.net/docs/getting-started/user-defined-measurements.html>)
I’m going back to my own measurements and trying different Measurement
IDs. None of them work. I try from someone else’s test. None of them
work.
Q. Does this function work anymore?
Barry
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Link-Local ICMP messages for Atlas probe
69:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 >> Aug 10 08:57:19 kernel cannot forward src fe80:5::46aa:500f:fceb:ad66, dst >> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 >> Aug 10 05:47:09 kernel cannot forward src fe80:5::b68a:5f0f:fcb2:1040, dst >> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 >> Aug 10 03:24:58 kernel cannot forward src fe80:5::2a0:a50f:fcb6:5ea2, dst >> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 >> Aug 10 03:08:55 kernel cannot forward src fe80:5::2a0:a50f:fc90:9d4, dst >> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 >> Aug 10 00:17:07 kernel cannot forward src fe80:5::e65d:370f:fc44:15ba, dst >> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 >> Aug 10 00:07:07 kernel cannot forward src fe80:5::2a0:a50f:fcb7:7c, dst >> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 >> >> The messages occur in groups of three, spaced a few seconds apart. >> >> All of the messages start with fe80:5. Even if I strip off the "5", none of >> them seem to convert into MAC addresses, so I can't use that to figure out >> what type of device is pinging the probe. >> >> There are no entries in the NDP table corresponding to these messages. >> >> I have no idea how long this has been happening. I only noticed it when I >> was setting up a new server to host pfsense. >> >> My probe is RIPE-Atlas-Probe-52209. >> >> I'm interested to know if anyone else has experienced this. >> -- >> ripe-atlas mailing list >> ripe-atlas@ripe.net >> https://lists.ripe.net/mailman/listinfo/ripe-atlas >> >> >> -- >> ripe-atlas mailing list >> ripe-atlas@ripe.net >> https://lists.ripe.net/mailman/listinfo/ripe-atlas >> >> -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Link-Local ICMP messages for Atlas probe
inging the probe. There are no entries in the NDP table corresponding to these messages. I have no idea how long this has been happening. I only noticed it when I was setting up a new server to host pfsense. My probe is RIPE-Atlas-Probe-52209. I'm interested to know if anyone else has experienced this. -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] DoH and DoT measurements
It works! Thanks again :) Regards, Grzegorz From: Michel Stam Date: Wednesday, 26 July 2023 at 17:50 To: "Ponikierski, Grzegorz" Cc: "ripe-atlas@ripe.net" Subject: Re: [atlas] DoH and DoT measurements Hello Grzegorz, The resolve_on_probe flag is used to have the probe do DNS resolution, otherwise the backend takes care of that. Cheers, Michel On 26 Jul 2023, at 17:47, Ponikierski, Grzegorz wrote: Indeed “tls” flag seems to work. Thanks! After first try with DoT providers like one.one.one.one or dns.google<https://urldefense.com/v3/__http:/dns.google/__;!!GjvTz_vk!Vgjmvw5Pw99v1yQzbNV2B4F0p45L_46wzEaLDXTF1b9k3KYpG5OsTRQioReL-8q71701XHRsV8I$> I have additional question. When exactly FQDN from “target” is resolved to IP? Is RIPE Atlas resolve domain to IP only once during measurements creation or is each probe resolve domain to IP individually? It’s important details for me because I will work with FQDN that will resolve do different IP depending on user location so if it is resolved only once by RIPE Atlas system then probes will be using sub-optimal IPs to run tests. Regards, Grzegorz From: Michel Stam mailto:ms...@ripe.net>> Date: Wednesday, 26 July 2023 at 17:13 To: "Ponikierski, Grzegorz" mailto:gponi...@akamai.com>> Subject: Re: [atlas] DoH and DoT measurements Hey Grzegorz, It’s a bit hidden, but in the measurement definition I think the key ’tis’ needs to be set to the boolean value ’true’. That should enable DNS over TLS. Cheers, Michel On 26 Jul 2023, at 17:09, Ponikierski, Grzegorz mailto:gponi...@akamai.com>> wrote: I have reviewed API Manual and Reference but I don’t see anything about DoH or DoT. Maybe I have overlooked something? Regards, Grzegorz From: Michel Stam mailto:ms...@ripe.net>> Date: Wednesday, 26 July 2023 at 15:30 To: "Ponikierski, Grzegorz" mailto:gponi...@akamai.com>> Cc: "ripe-atlas@ripe.net<mailto:ripe-atlas@ripe.net>" mailto:ripe-atlas@ripe.net>> Subject: Re: [atlas] DoH and DoT measurements Hello Gzzegorz, If I saw correctly DNS over TLS should be possible. Some initial steps have been taken to implement DNS over HTTP(S) but such is not available yet. You will probably have to use the API to schedule one, though RIPE Atlas docs | RIPE Atlas Documentation | Docs<https://urldefense.com/v3/__https:/atlas.ripe.net/docs/__;!!GjvTz_vk!UIWbNOgesINdK7phtPcRFUNL6Ah4klT6w0UBrDN6eQQavoEWGbvHAf3Q-h2r1ErslWGKwtF0RHE$> atlas.ripe.net<https://urldefense.com/v3/__https:/atlas.ripe.net/docs/__;!!GjvTz_vk!UIWbNOgesINdK7phtPcRFUNL6Ah4klT6w0UBrDN6eQQavoEWGbvHAf3Q-h2r1ErslWGKwtF0RHE$> <https://urldefense.com/v3/__https:/atlas.ripe.net/docs/__;!!GjvTz_vk!UIWbNOgesINdK7phtPcRFUNL6Ah4klT6w0UBrDN6eQQavoEWGbvHAf3Q-h2r1ErslWGKwtF0RHE$> Hope this helps, Regards, Michel On 26 Jul 2023, at 15:09, Ponikierski, Grzegorz via ripe-atlas mailto:ripe-atlas@ripe.net>> wrote: Hi! Is it possible to run DNS over HTTPS and DNS over TLS measurements with RIPE Atlas? Regards, Grzegorz -- ripe-atlas mailing list ripe-atlas@ripe.net<mailto:ripe-atlas@ripe.net> https://lists.ripe.net/mailman/listinfo/ripe-atlas<https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atlas__;!!GjvTz_vk!UIWbNOgesINdK7phtPcRFUNL6Ah4klT6w0UBrDN6eQQavoEWGbvHAf3Q-h2r1ErslWGKT9WPC80$> -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] DoH and DoT measurements
Indeed “tls” flag seems to work. Thanks! After first try with DoT providers like one.one.one.one or dns.google I have additional question. When exactly FQDN from “target” is resolved to IP? Is RIPE Atlas resolve domain to IP only once during measurements creation or is each probe resolve domain to IP individually? It’s important details for me because I will work with FQDN that will resolve do different IP depending on user location so if it is resolved only once by RIPE Atlas system then probes will be using sub-optimal IPs to run tests. Regards, Grzegorz From: Michel Stam Date: Wednesday, 26 July 2023 at 17:13 To: "Ponikierski, Grzegorz" Subject: Re: [atlas] DoH and DoT measurements Hey Grzegorz, It’s a bit hidden, but in the measurement definition I think the key ’tis’ needs to be set to the boolean value ’true’. That should enable DNS over TLS. Cheers, Michel On 26 Jul 2023, at 17:09, Ponikierski, Grzegorz wrote: I have reviewed API Manual and Reference but I don’t see anything about DoH or DoT. Maybe I have overlooked something? Regards, Grzegorz From: Michel Stam mailto:ms...@ripe.net>> Date: Wednesday, 26 July 2023 at 15:30 To: "Ponikierski, Grzegorz" mailto:gponi...@akamai.com>> Cc: "ripe-atlas@ripe.net<mailto:ripe-atlas@ripe.net>" mailto:ripe-atlas@ripe.net>> Subject: Re: [atlas] DoH and DoT measurements Hello Gzzegorz, If I saw correctly DNS over TLS should be possible. Some initial steps have been taken to implement DNS over HTTP(S) but such is not available yet. You will probably have to use the API to schedule one, though RIPE Atlas docs | RIPE Atlas Documentation | Docs<https://urldefense.com/v3/__https:/atlas.ripe.net/docs/__;!!GjvTz_vk!UIWbNOgesINdK7phtPcRFUNL6Ah4klT6w0UBrDN6eQQavoEWGbvHAf3Q-h2r1ErslWGKwtF0RHE$> atlas.ripe.net<https://urldefense.com/v3/__https:/atlas.ripe.net/docs/__;!!GjvTz_vk!UIWbNOgesINdK7phtPcRFUNL6Ah4klT6w0UBrDN6eQQavoEWGbvHAf3Q-h2r1ErslWGKwtF0RHE$> <https://urldefense.com/v3/__https:/atlas.ripe.net/docs/__;!!GjvTz_vk!UIWbNOgesINdK7phtPcRFUNL6Ah4klT6w0UBrDN6eQQavoEWGbvHAf3Q-h2r1ErslWGKwtF0RHE$> Hope this helps, Regards, Michel On 26 Jul 2023, at 15:09, Ponikierski, Grzegorz via ripe-atlas mailto:ripe-atlas@ripe.net>> wrote: Hi! Is it possible to run DNS over HTTPS and DNS over TLS measurements with RIPE Atlas? Regards, Grzegorz -- ripe-atlas mailing list ripe-atlas@ripe.net<mailto:ripe-atlas@ripe.net> https://lists.ripe.net/mailman/listinfo/ripe-atlas<https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atlas__;!!GjvTz_vk!UIWbNOgesINdK7phtPcRFUNL6Ah4klT6w0UBrDN6eQQavoEWGbvHAf3Q-h2r1ErslWGKT9WPC80$> -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] DoH and DoT measurements
I have reviewed API Manual and Reference but I don’t see anything about DoH or DoT. Maybe I have overlooked something? Regards, Grzegorz From: Michel Stam Date: Wednesday, 26 July 2023 at 15:30 To: "Ponikierski, Grzegorz" Cc: "ripe-atlas@ripe.net" Subject: Re: [atlas] DoH and DoT measurements Hello Gzzegorz, If I saw correctly DNS over TLS should be possible. Some initial steps have been taken to implement DNS over HTTP(S) but such is not available yet. You will probably have to use the API to schedule one, though RIPE Atlas docs | RIPE Atlas Documentation | Docs<https://urldefense.com/v3/__https:/atlas.ripe.net/docs/__;!!GjvTz_vk!UIWbNOgesINdK7phtPcRFUNL6Ah4klT6w0UBrDN6eQQavoEWGbvHAf3Q-h2r1ErslWGKwtF0RHE$> atlas.ripe.net<https://urldefense.com/v3/__https:/atlas.ripe.net/docs/__;!!GjvTz_vk!UIWbNOgesINdK7phtPcRFUNL6Ah4klT6w0UBrDN6eQQavoEWGbvHAf3Q-h2r1ErslWGKwtF0RHE$> [eeBfPdm2eoBKnHEASUVORK5CYII=]<https://urldefense.com/v3/__https:/atlas.ripe.net/docs/__;!!GjvTz_vk!UIWbNOgesINdK7phtPcRFUNL6Ah4klT6w0UBrDN6eQQavoEWGbvHAf3Q-h2r1ErslWGKwtF0RHE$> Hope this helps, Regards, Michel On 26 Jul 2023, at 15:09, Ponikierski, Grzegorz via ripe-atlas wrote: Hi! Is it possible to run DNS over HTTPS and DNS over TLS measurements with RIPE Atlas? Regards, Grzegorz -- ripe-atlas mailing list ripe-atlas@ripe.net<mailto:ripe-atlas@ripe.net> https://lists.ripe.net/mailman/listinfo/ripe-atlas<https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atlas__;!!GjvTz_vk!UIWbNOgesINdK7phtPcRFUNL6Ah4klT6w0UBrDN6eQQavoEWGbvHAf3Q-h2r1ErslWGKT9WPC80$> -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] DoH and DoT measurements
Hi! Is it possible to run DNS over HTTPS and DNS over TLS measurements with RIPE Atlas? Regards, Grzegorz -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] RIPE Atlas Virtual Anchor Registration for Angola Cables (ao-lad-as37468)
Hi Team, I need your support to change the IP address of my registered Anchor in Luanda. I had a network issue in my virtualized servers. See below the new IP to be applied: IPv4:: 102.130.66.11 IPv6:: 2c0f:f828:2:100::102:130:66:11 Regards, Atenciosamente / Best Regards Inacio JoseAnalista I | Analyst Imob: +244927686227 | inacio.j...@angolacables.co.ao https://www.angolacables.co.ao | AS 37468 -Mensagem original- De: RIPE Atlas Enviada: terça-feira, 6 de junho de 2023 09:20 Para: Inacio Jose Assunto: RIPE Atlas Virtual Anchor Registration for Angola Cables (ao-lad-as37468) Dear Inacio Jose, Thank you for registering the technical information for your RIPE Atlas virtual anchor! Your FQDN is: ao-lad-as37468.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 at...@ripe.net You registered the following details: IPv4 address: 102.130.68.175 IPv4 ASN: 37468 IPv6 address: 2c0f:f828:2:100:102:130:68:175 IPv6 ASN: 37468 Kind regards, RIPE Atlas Team -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Credit request
Ana, 10 Million sent David -- https://dprall.net On 7/11/2023 2:37 PM, Ana Custura wrote: Hi everyone, I would like to schedule some experiments to look at the prevalence and types of load-balancing in v4 and v6 networks. Running traceroutes with 32 paris repetitions on many probes unfortunately burns very quickly through credits. If you have some to spare and can donate to my account it would be much appreciated! Thank you, Ana -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Credit request
I sent you 2,7 million.Am 11.07.2023 um 20:57 schrieb Michael J. Oghia :Hi Ana, I just sent you 13 million. Good luck, and please share any relevant results with us!Best,-MichaelOn Tue, Jul 11, 2023 at 2:37 PM Ana Custura <a...@erg.abdn.ac.uk> wrote:Hi everyone, I would like to schedule some experiments to look at the prevalence and types of load-balancing in v4 and v6 networks. Running traceroutes with 32 paris repetitions on many probes unfortunately burns very quickly through credits. If you have some to spare and can donate to my account it would be much appreciated! Thank you, Ana -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing listripe-atlas@ripe.nethttps://lists.ripe.net/mailman/listinfo/ripe-atlas-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] credit request
On 5/24/2023 1:25 PM, Mike via ripe-atlas wrote: > On 5/24/2023 12:50 PM, Michael Rabinovich wrote: >> Dear RIPE Atlas folks, >> >> I now received all the credits we needed, thank you very much! I don’t >> need more credits at this time, so please save them for the next needy >> person :) >> >> Cheers, >> —Misha >> > > > Too late... > > I already sent a few before i saw your comment... > fwiw... I've had a great private conversation with Mr Rabinovich. My credits will be put to great use. ... and that is why I participate here :) -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] credit request
On 5/24/2023 12:50 PM, Michael Rabinovich wrote: > Dear RIPE Atlas folks, > > I now received all the credits we needed, thank you very much! I don’t > need more credits at this time, so please save them for the next needy > person :) > > Cheers, > —Misha > Too late... I already sent a few before i saw your comment... -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] credit request
On 5/24/2023 11:29 AM, Michael Rabinovich wrote: > 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 > I tried to transfer some credits: michael.rabinov...@case.edu "Bad Request: /recipient That email address is not associated with any RIPE NCC Access user" -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] RIPE Anchor updates?
Hi Anand, Thanks for the response. I regularly despair with the RHEL ecosystem and its back ported fixes, Long live Debian! I was not on-list for the previous discussions you mention, but I think the release note might be a little ambiguous, and I also searched the docs for update/upgrade and I don't see how I would do that either? Did I miss something obvious? Thanks John -- John Howard Head of Network Infrastructure Proton AG Sent with Proton Mail secure email. --- Original Message --- On Tuesday, May 16th, 2023 at 14:20, Anand Buddhdev wrote: > On 16/05/2023 12:42, John Howard via ripe-atlas wrote: > > Hello John, > > > 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. > > > These RIPE Atlas anchors are running with an nginx package from Fedora > EPEL. Although it is an older version, it has been patched with fixes > for the CVEs you mentioned. We are currently running CentOS 7 on the > anchors, and it is still receiving security fixes, which we regularly apply. > > Later this year, or perhaps early in 2024, we will be updating the > operating system on the anchors, and that will bring in new versions of > all the software we run on them. > > > 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? > > You are referring to the software probe package. It used to ship with a > crontab that kept the software probe package up to date. There was a > discussion about it on this list, and a majority of users didn't like > it, and preferred to update their systems (including the software probe > package) using their preferred update policy. That's why the crontab was > removed. When new versions of the software probe package are available, > users can update to it as and when they wish. > > Regards, > Anand Buddhdev > RIPE NCC publickey - john.howard@proton.ch - 0x90E7CFE6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] RIPE Anchor updates?
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. publickey - john.howard@proton.ch - 0x90E7CFE6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Probe DHCPv6 support
Hi Michel, sorry, i don't have an OpenWrt device that's using DHCPv6 in client mode. But it should be easy. Make sure the 'odhcp6c' package is installed (which is the case by default). Then change the protocol option for the interface: /etc/config/network config interface 'eth0' option proto 'dhcpv6' Check out this link to see als available options for the DHCPv6 client mode: https://openwrt.org/docs/guide-user/network/ipv6/configuration#protocol_dhcpv6 As far is i can see, you can only use OpenWrt in DHCPv4 client mode _OR_ in DHCPv6 client mode. So i guess, you have to write a small script. First try DHCPv6 and check if you can successfully get a configuration. If not, fall back to DHCPv4. Continuously toggle between DHCPv6 and DHCPv4 as long as you don't get a configuration. I would begin this loop with DHCPv6. Also keep in mind, that some DHCP server respond slow, so better wait a little bit, before switching the protocol. BR, Simon On 15.05.23 09:12, Michel Stam wrote: Hi, Good discussion! I’m currently looking at basing all the probes (3, 4 and 5) on OpenWRT 22.03 which is the latest stable. What I’ll do is take this along in the deliberations, and see if I can fit this into the firmware image somehow. Simon: can you provide the exact setup you use for testing? (Config snippets etc) I typically don’t have a problem on my setup here, but thats RA + DHCPv6, I don’t use DHCPv6 for the actual assignment. Regards, Michel On 9 May 2023, at 20:27, Simon Brandt via ripe-atlas wrote: That should be "odhcp6c" https://openwrt.org/packages/pkgdata/odhcp6c https://github.com/openwrt/odhcp6c BR, Simon On 09.05.23 20:22, Philip Homburg wrote: In any case, Atlas probes run a stripped down version of OpenWRT. It may help if somebody can figure out which OpenWRT packages need to be added to enable DHCPv6. -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Probe DHCPv6 support
That should be "odhcp6c" https://openwrt.org/packages/pkgdata/odhcp6c https://github.com/openwrt/odhcp6c BR, Simon On 09.05.23 20:22, Philip Homburg wrote: In any case, Atlas probes run a stripped down version of OpenWRT. It may help if somebody can figure out which OpenWRT packages need to be added to enable DHCPv6. -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Probe DHCPv6 support
On 5/9/23 16:44, Philip Homburg wrote: Does OpenWRT out of the box support DHVPv6? Did you ever try that? If it does, it may help the Atlas team to just add the relevant OpenWRT packages. Sure, it does (also prefix delegation works here). - Daniel -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Creating an API key that is valid immediately
Jay, you can change “Valid From” date to today or even yesterday. Just click
and edit the field with the date.
Regards,
Grzegorz
From: Jay Borkenhagen
Reply to: Jay Borkenhagen
Date: Friday, 28 April 2023 at 17:53
To: "ripe-atlas@ripe.net"
Subject: [atlas] Creating an API key that is valid immediately
Hi RIPE Atlas,
I wanted to run some ad-hoc measurements using the Magellan tools, but
found that my RIPE Atlas API key had expired. "No problem," I
thought, "I'll just create a new API key from the web UI."
However, it seems that my ADI key created that way will only become
valid starting tomorrow at the earliest. Is there a way to create an
API key that is valid immediately?
Thanks.
Jay B.
--
ripe-atlas mailing list
ripe-atlas@ripe.net<mailto:ripe-atlas@ripe.net>
https://urldefense.com/v3/__https://lists.ripe.net/mailman/listinfo/ripe-atlas__;!!GjvTz_vk!QC49kVzAdseFoK9uJVOHcEmhhxdAU1cKPzku5BEh44jH-yCIza3Aor8T-swagqnZu2r9l3FgL9eWaTrY5hA_FA$<https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atlas__;!!GjvTz_vk!QC49kVzAdseFoK9uJVOHcEmhhxdAU1cKPzku5BEh44jH-yCIza3Aor8T-swagqnZu2r9l3FgL9eWaTrY5hA_FA$>
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Request RIPE Atlas Credit for Research
Sent 50,000,000 David -- https://dprall.net On 4/10/2023 1:08 AM, 卫蕴泽 wrote: 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@gmail.com <mailto:fenglan@gmail.com>, my education email is weiy...@mails.tsinghua.edu.cn <mailto:weiy...@mails.tsinghua.edu.cn> and my student ID is 2019011285. Many thanks for your help! Sincerely, Yunze Wei -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Request RIPE Atlas Credit for Research
dear Yunze Wei, I transfer 70,000,000 and can help research your graduation project, I hope the project will be completed quickly and successfully, and you can tell us the results of your project good luck Pada tanggal Sen, 10 Apr 2023 pukul 13.09 卫蕴泽 menulis: > 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@gmail.com, my education email is > weiy...@mails.tsinghua.edu.cn and my student ID is 2019011285. > Many thanks for your help! > > Sincerely, > Yunze Wei > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > -- Thank you for your consideration. Best regards, Fadloe Robby Telp/WA : 0812-5154-3201 Univeritas Lambung Mangkurat UPT PTIK Univeritas Lambung Mangkurat gedung Rektorat Lantai III Jalan Brigjen H. Hasan Basri Banjarmasin 70123 Telp./Fax. (0511) 330 5195, -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Request RIPE Atlas Credit for Research
Hey Yunze, Replied off-list :) Regards, Peter Potvin | Executive Director -- *Accuris Technologies Ltd.* 56A Mill St E, Unit #470, Acton, ON L7J 1H3 Canada Email: peter.pot...@accuristechnologies.ca Office: +1 (877) 352-6105 Network Operations Center: +1 (877) 321-1662 On Mon, Apr 10, 2023 at 1:09 AM 卫蕴泽 wrote: > 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@gmail.com, my education email is > weiy...@mails.tsinghua.edu.cn and my student ID is 2019011285. > Many thanks for your help! > > Sincerely, > Yunze Wei > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] Errors on Measurement web interface
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 -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Your Probe shipped
Dear Support, Can you why the probe is not yet delivered? As indicated below, it should already been delivered. Waiting for feedbacks, Regards, Atenciosamente / Best Regards Inacio JoseAnalista I | Analyst Imob: +244927686227 | inacio.j...@angolacables.co.ao https://www.angolacables.co.ao | AS 37468 -Mensagem original- De: RIPE Atlas Enviada: terça-feira, 6 de dezembro de 2022 15:41 Para: Inacio Jose Assunto: Your Probe shipped Dear Inacio Jose, We are happy to let you know that your probe has been shipped on 2022-11-25 08:39 UTC to the following address: Angola Cables Edifício Cellwave, Via AL5 Zona, XR6B Talatona, LUANDA SUL 15 Luanda 0 Luanda Angola Kind regards, RIPE Atlas Team at...@ripe.net --- Shipping information --- For single package we use Dutch postal (postnl) which is not traceable. Below is the duration of the delivery time from the moment you receive this email: Western Europe: 1-2 weeks Rest of Europe: 2-4 week. Rest of the world: 2-6 weeks -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Encouraging people to upgrade software probe versions
Hi Robert, The existence of software probes is great, but instead (or besides) of providing packages or source code, why not distribute a prebuild VM as OVF file? Advantages: - The RIPE Atlas team manages the whole OS, like it's doing for the hardware probes. Thus, updates can be deployed whenever needed. - You can even use OpenWRT as VM operatingsystem. This means all the same premises/conditions as for hardware probes. - an OVF file is easier to deploy, for the community - RXTXRPT switch is obsolete - No more false RXTXRPT data, since the report counts all traffic of the host, not only the traffic that is generated by the SW probe application. Is there an actual reason, why it was decided to let users manage the software probe installation? Please consider to distribute a prebuild VM *additionally* to the existing ways and see what happens. I'm sure, most new users will choose a prebuild VM. BR, Simon On 19.01.23 12:48, Robert Kisteleki wrote: That is reasonable; the difference is that we are not in control; the host OS is. Redhat/Fedora/derivatives as well as Debian/derivatives have an official solution to this via their package management services and I believe this is the standard way (surely with exceptions :-) ) of handling these matters. We are in the process of adopting these. -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] probes on mobile opérateurs
Hello Christel, For Germany, there a three major operators: - T-Mobile: 25993 55677 1000234 - Vodafone: 11158 50081 53236 - Telefonica (o2): 20261 25262 26320 51253 60481 1000568 1004094 1004531 1004571 1004854 1004947 1005061 Keep in mind, that some of the probes are IPv4 or IPv6 only. There are even more probes, but those are disconnected, that's why i did not include them here. BR, Simon On 13.01.23 10:31, Cristel Pelsser wrote: 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 -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] V3 Probe: USB Flash Drive Filesystem Corrupted
Hi Michel, the Probe ID is 25993. There are so many cheap USB sticks with extremely low write speed, even USB 3.0 sticks. What made me think that the sticks speed could cause the tag is, that my probe had it tagged for a long time, but still the probe did it's job. It was online, delivering results, etc. I have replaced the broken USB stick with a fast one from Transcend 6 days ago. Since then, the tag did not appear again. I haven't checked for the blink patterns, sorry. If the Tag will appear again, i will try a different power supply and cable, as you suggested. BR, Simon On 11.01.23 12:39, Michel Stam wrote: Hi Simon, I would expect a more recent USB stick to complete a write / read operation more quickly than one of its older counterparts. Thats not a guarantee, I know. Funny enough, I actually used an old stick on one of my development V3 the other week and was surprised how slow the performance was (but the system did still work). When the V3 probes have issues, usually its either: * Power supply failing * Cabling failing * USB stick corrupt (unlikely after 3 units). Working setups sometimes degrade over time. Something I’ve seen with a USB analyser a good few years back is that some USB sticks don’t report write errors when the stick dies. I will dig a bit where the flash filesystem corrupted tag comes from and get back to you. Can you message me the probe ids that are causing issues? (Privately if you want to keep it off-list). And if you have the possibility, please humour me and try a completely different power supply and cable. It has resolved issues for me before. Just to get it out of the way. Regards, Michel On 9 Jan 2023, at 20:36, ripe@toppas.net wrote: Hi Michel, Thanks for you answer. I'm using an Ikea KOPPLA (204.150.27) which provides 17W. It's powering two v3 probes and one v4 probe. The other probes work well, so i don't think that the power supply is causing this. What i meant was, that maybe some USB sticks are to slow and thus not able to perform writing of a big chunk of data in the expected time, and therefore the USB flash/filesystem is considered broken? Can you tell the exact cause for the "Flash drive filesystem corrupted"-tag is? What triggers this? I am aware that USB 3.0 is backwards compatible, but since USB 3.0 sticks are faster, maybe it makes sense to stick with them (hehe), to ensure that at least the full USB 2.0 potential is used. BR, Simon On 09.01.23 12:26, Michel Stam wrote: Hi Simon, First thing that comes to mind to me, do you maybe have a power problem? If the unit receives just enough power to boot the base TP-Link, but not to power the USB stick this may trigger these problems. Would you be able to boot the unit with a different power supply (try 5W at the least or 10W), to see if this makes a difference? Speed shouldn’t be much of an issue, USB to my knowledge is backwards compatible. Cheers, Michel On 31 Dec 2022, at 22:31,ripe@toppas.net wrote: 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 UTCProbe auto-taggedYour probe #x was automatically tagged as "system: Flash drive filesystem corrupted" 2022-12-22 @ 18:14:42 UTCProbe auto-untaggedYour probe #x 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 -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Proposal: Add support for STARTTLS measurements [STARTTLS]
Hi Robert, i really appreciate the introduction of STARTTLS measurements! But if you do so, i strongly recommend to also introduce four new System Tags: IPv4 FCrDNS working IPv4 FCrDNS not working IPv6 FCrDNS working IPv6 FCrDNS not working A lot of mailservers will block or cancel inbound connections, if the sending server has no Forward-confirmed reverse DNS record. Some mailservers do this immediately, others do it at a later communication stage. So, when someone would create a new STARTTLS measurement, it would be a huge help to be able to only choose probes, which have FCrDNS. It shouldn't matter, if it's a simple or obfuscated DNS record. Please also take into consideration, to make FCrDNS mandatory for (new) anchors. BR, Simon On 14.12.22 15:04, Robert Kisteleki wrote: 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 -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Encouraging people to upgrade software probe versions
I fully agree with Gert. There's nothing to add to his statement, except that we could consider to opt-out automatic updates? A small switch like RXTXRPT. But automatic updates set to enabled should be the default setting. BR, Simon On 09.01.23 10:52, Gert Doering wrote: Hi, On Mon, Jan 09, 2023 at 10:19:34AM +0100, Michel Stam wrote: The automatic update for the CentOS package was removed as of 5080. This means that the update to 5080 will still be automatic, but not any more after this (say 5090 onwards). This was a request by several users because Atlas forced the update, which violated their sysadmin policies. I find this surprising, to say the least. The whole point about ATLAS Probes is "RIPE NCC manages them" - as host of a handful of hardware probes, I have no say in whether I want them upgraded or not, or what they should do or not do. So I would expect all software probes to always upgrade themselves, and this be clearly communicated to SW probe hosts. If this violates your sysadmin policies, you shouldn't run 3rd-party maintained *and operated* software. Gert Doering -- NetMaster -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] V3 Probe: USB Flash Drive Filesystem Corrupted
Hi Michel, Thanks for you answer. I'm using an Ikea KOPPLA (204.150.27) which provides 17W. It's powering two v3 probes and one v4 probe. The other probes work well, so i don't think that the power supply is causing this. What i meant was, that maybe some USB sticks are to slow and thus not able to perform writing of a big chunk of data in the expected time, and therefore the USB flash/filesystem is considered broken? Can you tell the exact cause for the "Flash drive filesystem corrupted"-tag is? What triggers this? I am aware that USB 3.0 is backwards compatible, but since USB 3.0 sticks are faster, maybe it makes sense to stick with them (hehe), to ensure that at least the full USB 2.0 potential is used. BR, Simon On 09.01.23 12:26, Michel Stam wrote: Hi Simon, First thing that comes to mind to me, do you maybe have a power problem? If the unit receives just enough power to boot the base TP-Link, but not to power the USB stick this may trigger these problems. Would you be able to boot the unit with a different power supply (try 5W at the least or 10W), to see if this makes a difference? Speed shouldn’t be much of an issue, USB to my knowledge is backwards compatible. Cheers, Michel On 31 Dec 2022, at 22:31,ripe@toppas.net wrote: 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 UTCProbe auto-taggedYour probe #x was automatically tagged as "system: Flash drive filesystem corrupted" 2022-12-22 @ 18:14:42 UTCProbe auto-untaggedYour probe #x 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 -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] V3 Probe: USB Flash Drive Filesystem Corrupted
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 #x was automatically tagged as "system: Flash drive filesystem corrupted" 2022-12-22 @ 18:14:42 UTC Probe auto-untagged Your probe #x 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-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Probe 24434 down but pingable
Isn't simply dead/corrupted USB flash? (as I see, you're using tl-mr3020; there're such issues sometimes). There's article how to fix that... https://labs.ripe.net/author/philip_homburg/troubleshooting-ripe-atlas-probes-usb-sticks/ On 12/30/22 10:04, Dave wrote: Hi, One of my probes is pingable but the status is disconnected for over a day. Could it be that it has troubles with DNS over IPv6 and that it is not smart enough to fall back to IPv4? https://atlas.ripe.net/probes/24434/#tab-general <https://atlas.ripe.net/probes/24434/#tab-general> Thanks, Dave -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Low cost, low energy consumption probe
Hi Michel, For the $dayjob, I have access to today 13, soon even more locations with good (redundant) internet connectivity but very little compute hardware. To the extend that there is no hypervisor, however I personally really like the Atlas project. Will this add great value to the Atlas project, possibly not as the locations are kind a meh / non-exotic. So I perfectly understand me requesting a bunch of probes would be an issue. As such from personal pocket (depending on cost on the total #) I'm happy to source/buy a bunch of probes. For instance, if it would work, I would be happy to buy some TP-Link MR3020 (the V3 probe), which seems to be ±22 euro here, and some USB sticks (and POE to USB cables) and last enroll them into Atlas. Happy to discuss offlist further. -- Met vriendelijke groet, Stijn Jonker > On 21 Dec 2022, at 13:51, Michel Stam wrote: > > Hello Stijn, > > What kind of locations are you looking at for your probes? We don’t bite if > asked, but yes is not guaranteed :) > > The v5 hardware probe is a custom design based off the Turris Mox. > > If we would do something like this we would need to split the Atlas > application from the OS firmware, which for hardware probes currently is > bundled. This to some extent ensures that the probe is not doing anything > else (security). > > There’s a couple of considerations to be had here, mostly with regard to > support and security. > Can you detail why you want to BYOP (Build-Your-Own-Probe)? > > Regards, > > Michel > >> On 19 Dec 2022, at 18:10, Stijn Jonker via ripe-atlas >> wrote: >> >> Hi Ernst, Hi Others, >> >> I would be interested as well maybe even exploring the USB model/option. >> However I would be keen to pursue only if it would be low maintenance as the >> current HW probes (i.e. config via portal, sw updates covered etc). To be >> fair I think an additional option might be that instead of sending out >> probes for free, that somehow you can order a probe directly or via Ripe or >> some reseller by providing a kitlist. As I would be keen to deploy some >> additional probes here and there (think ±12 locations at the end) but don't >> dare to ask for additional probes... >> >> So maybe instead of reinventing the wheel, @ripe would it be an >> consideration to provide an kitlist/place to purchase the previous or >> current V5 HW model? >> >> -- >> Met vriendelijke groet, >> Stijn Jonker >> >> >> >> >>> On 19 Dec 2022, at 16:42, Ernst J. Oud wrote: >>> >>> Hi, >>> >>> I have probes running on VMware (CentOS), Ubuntu (native) and on Docker for >>> Windows. These small PC’s consume a lot more than the Ripe supplied HW >>> probes. >>> >>> So I looked for a cheap and *very* low energy alternative. >>> >>> TP-Link sells the WR802N mini travel router for around USD 20 (o.a. on >>> Amazon) that runs the latest version of OpenWRT fine and the Atlas probe SW >>> has been ported to it. With some acrobatics I managed to turn it into an >>> excellent alternative. Runs fine, energy consumption 700 mW (!). The device >>> is as small as the Ripe supplied probe. >>> >>> Since the flash memory of this device is too small for some of the required >>> libraries, the acrobatics involved copying them to RAM and putting links to >>> them in flash. This means that with FTP after a power outage a couple of >>> files need to be copied to the device and that one command must be given >>> after that. >>> >>> There is a more expensive version with a USB port so that a USB stick can >>> be used to store those files. Will investigate that option. >>> >>> If someone here wants a detailed write-up let me know and I will invest the >>> time to write it. >>> >>> Regards, >>> >>> Ernst J. Oud >>> -- >>> ripe-atlas mailing list >>> ripe-atlas@ripe.net >>> https://lists.ripe.net/mailman/listinfo/ripe-atlas >> >> >> -- >> ripe-atlas mailing list >> ripe-atlas@ripe.net >> https://lists.ripe.net/mailman/listinfo/ripe-atlas > -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Proposal: Measure well-known CDNs,[CDN-HTTP]
On 17.12.22 03:00, Massimo Candela wrote: On 17/12/2022 00:19, Barry Raveendran Greene wrote: On Dec 16, 2022, at 23:29, Stephane Bortzmeyer wrote: There is a larger problem here, a more strategic one: such a feature would contribute to the centralisation of the Internet, which is already too important. Tagging some targets are "important" and "worthy of measurements" would mean that we consider some HTTP servers to be more useful than others. That would be a bad message from RIPE. We’ve come full circle - we started with centralized PTTs - moved to a decentralized ASN/Paul Baran model - now Re-centralized based on marketing domination. +1 with Stephane’s observation. The selection of who to measure is a statement. +1 Also, while the data would be useful, I don't think the role of the ripe ncc is to grade commercial services. Let other companies or individual researchers do that. On the one hand i agree with Stephane, but on the other hand, it is a fact that there are a few large providers/CDNs who have a significant share... of specific webservices. I don't like that either, but i can't deny it either. I agree, that manually selecting those providers/CDNs for such a measurement could be understood as a statement. But maybe there's another way, to select which one of those providers/CDNs to measure? Instead of manually selecting them, there could be some sort of "threshold" which a provider/CDN has to reach, to be part of this kind of measurement. This way, it wouldn't be a statement, but a static delimitation. I am unsure what kind of threshold it could be, and how to detect it. It should probably be some sort of technical value. BR, Simon-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] Proposal: Measure well-known CDNs,[CDN-HTTP]
Hi RIPE Atlas users, I stumbled upon this thread and I wanted to chime in. I work for Cloudflare and we of course use a wide set of external visibility and performance management tools to track our visibility. But on occasions I also use the RIPE Atlas network to perform some specific reachability tests. I believe the distribution of probes and the fact that they're als in eyeball ASN is a really valuable factor that RIPE Atlas has. At the moment I'm running into a limitation around HTTP tests. I would like to use the RIPE Atlas network to curl some pages to retrieve and evaluate the HTTP headers. This is currently not possible with Atlas as it is only allowed to probe Anchors for safety reasons, which I fully understand and support (you don't want to turn Atlas into a botnet). The HTTP targets that I would like to probe would be all on our IP space, so I don't see a direct risk from the outbound part of the request. I can see there is some risk with the return part, where the content from an "unknown" system gets returned to a probe in someone's private network, with possible ramifications. So I was pondering about two possible options that can potentially help me, but not risk the Atlas project or demonstrate favoritism towards particular companies. 1) One of the options would be to open up some of our IP space to the probes for HTTP probes. 2) The other option would be for us to host an Anchor and put our CDN in front of it. That way RIPE has complete control over the returned data. I would love to hear the general consensus on such approach and the viability of it Best Regards, -- Dirk-Jan van Helmond On 17/12/2022 00:19, Barry Raveendran Greene wrote: > > >> On Dec 16, 2022, at 23:29, Stephane Bortzmeyer wrote: >> >> There is a larger problem here, a more strategic one: such a feature >> would contribute to the centralisation of the Internet, which is >> already too important. Tagging some targets are "important" and >> "worthy of measurements" would mean that we consider some HTTP servers >> to be more useful than others. That would be a bad message from RIPE. > > We’ve come full circle - we started with centralized PTTs - moved to a decentralized ASN/Paul Baran model - now Re-centralized based on marketing domination. > > +1 with Stephane’s observation. The selection of who to measure is a statement. +1 Also, while the data would be useful, I don't think the role of the ripe ncc is to grade commercial services. Let other companies or individual researchers do that. -- Dirk-Jan van Helmond Leader Solutions Engineering EMEA mobile: +31611645622 email: dirk...@cloudflare.com www.cloudflare.com <https://www.cloudflare.com/> -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Low cost, low energy consumption probe
Hi Ernst, Hi Others, I would be interested as well maybe even exploring the USB model/option. However I would be keen to pursue only if it would be low maintenance as the current HW probes (i.e. config via portal, sw updates covered etc). To be fair I think an additional option might be that instead of sending out probes for free, that somehow you can order a probe directly or via Ripe or some reseller by providing a kitlist. As I would be keen to deploy some additional probes here and there (think ±12 locations at the end) but don't dare to ask for additional probes... So maybe instead of reinventing the wheel, @ripe would it be an consideration to provide an kitlist/place to purchase the previous or current V5 HW model? -- Met vriendelijke groet, Stijn Jonker > On 19 Dec 2022, at 16:42, Ernst J. Oud wrote: > > Hi, > > I have probes running on VMware (CentOS), Ubuntu (native) and on Docker for > Windows. These small PC’s consume a lot more than the Ripe supplied HW probes. > > So I looked for a cheap and *very* low energy alternative. > > TP-Link sells the WR802N mini travel router for around USD 20 (o.a. on > Amazon) that runs the latest version of OpenWRT fine and the Atlas probe SW > has been ported to it. With some acrobatics I managed to turn it into an > excellent alternative. Runs fine, energy consumption 700 mW (!). The device > is as small as the Ripe supplied probe. > > Since the flash memory of this device is too small for some of the required > libraries, the acrobatics involved copying them to RAM and putting links to > them in flash. This means that with FTP after a power outage a couple of > files need to be copied to the device and that one command must be given > after that. > > There is a more expensive version with a USB port so that a USB stick can be > used to store those files. Will investigate that option. > > If someone here wants a detailed write-up let me know and I will invest the > time to write it. > > Regards, > > Ernst J. Oud > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]
Hello, I support Gert here, network operators (LIRs) can have valid reasons to make some their measurements non-public. So I don't support removal of this feature. It's a bad idea... If some probe host has problem with that, why don't mark such probes as not-available for private measurements (this can be implemented easily)? And I think there will be only minority of probes marked like that. Majority of hosts will not care at all... And keep in mind that Atlas is funded by LIRs and their money. All the big-data infrastructure (and also making of hardware probes) costs real (and not small) money. Existence of rivate measurements might be one reason, why LIRs allow spending money for this useful project. Probe hosting is only small piece in expenses within this project... - Daniel On 12/16/22 19:13, Gert Doering wrote: Hi, On Thu, Dec 15, 2022 at 10:41:42AM -0800, Steve Gibbard wrote: Atlas, and the RIPE NCC, have two fairly separate constituencies: researchers and operators. This. Operators (like me) are willing to host Atlas anchors and probes, and thus contribute to the system. I might be troubleshooting something in our network where I have no interest in making the results public. So I value the option to have non-public measurements. There's no "right to see all measurements" here - if someone wants to see something, they are free to run their own measurements with their own credits. What I do with my credits (which do not come for free) and who can see the results should be my decision. Gert Doering -- NetMaster -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]
Sorry Gert, but i strongly disagree.
I might be troubleshooting something in our network where I have no interest in
making the results public.
RIPE Atlas is primarily designed for INTERnet measurements, not Intranet. To
see, how things look like from other networks. If you want to troubleshoot
something inside your own network and need privacy, you can do it the classic
way, by using your internal test-equipment or monitoring.
There's no "right to see all measurements" here
I highly appreciate RIPE NCCs efforts for maximum transparency and open-data,
and i hope this will never change. This is what Atlas was intended to be (as
far as i can tell).
if someone wants to see something, they are free to run their own measurements
with their own credits.
In this point, i disagree as well. It shouldn't be necessary to run the same
measurement multiple times. For what reason? It would be a waste of credits,
time and ressources. Also, keep in mind that this redundant data has to be
stored somewhere.
If one has a problem with open-data philosophy, he shouldn't participate in
this project.
_There's only one exception_ i could agree with: measurements can be private,
if you only deploy your own probes/anchors for that measurement. But if you
decide to use other peoples probes, the results should be public.
BR,
Simon
On 16.12.22 19:13, Gert Doering wrote:
Hi,
On Thu, Dec 15, 2022 at 10:41:42AM -0800, Steve Gibbard wrote:
Atlas, and the RIPE NCC, have two fairly separate constituencies: researchers
and operators.
This.
Operators (like me) are willing to host Atlas anchors and probes, and
thus contribute to the system.
I might be troubleshooting something in our network where I have no
interest in making the results public. So I value the option to have
non-public measurements.
There's no "right to see all measurements" here - if someone wants to
see something, they are free to run their own measurements with their
own credits. What I do with my credits (which do not come for free)
and who can see the results should be my decision.
Gert Doering
-- NetMaster
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] redesign of the probe page
Hi Robert, here are some things that bothered me, when looking at the probe pages: 1. Network Tab: When a probe is connected via IPv4 and IPv6, the second IPv4 DNS resolver is not displayed on the probe page. If the Probe is connected via IPv4 only, both IPv4 resolvers are displayed. At least, that is what I have observed for my probes. 2. Network Tab: Connection Information: Instead of "Last Week" and "Last Month" it should be "Last 7 Days" and "Last 30 days". For example: in my understanding "last month" means time between 1. - 30. November since the current month is december. But the probe page counts the online-time of last 30 days. Maybe this is a regional thing... are there countries which differentiate between month and calendermonth? I would appreciate, if it would be X days instead of week and month, to avoid confusion. 3. General Tab: "Router Type" cannot be set for Anchors (at least for my two anchors). 4. Network Tab: Please take a look at these probes: https://atlas.ripe.net/probes/26320/#tab-network https://atlas.ripe.net/probes/1004823/#tab-network What is causing the probe page to display so much old IPv6 addresses? It doesn't matter of the probe is connected or not, this error can happen in both cases. I've opened a ticket for this two weeks ago (#536036), but got no response. 5. General Tab: Maybe provide a textfield where probe/anchor hosts can write some details. A description, public contact details or whatever. Thanks, Simon On 15.12.22 15:08, Robert Kisteleki wrote: On 2022-12-15 14:33, ripe@toppas.net wrote: Hi Chris, sorry for "stealing" this conversation, but it's interesting to hear that there will be a redesign of the probe page coming up soon. Can we have a discussion about that? There are several things, that bother me a bit... BR, Simon Hi, The team started thinking about how to improve these pages. We're using already collected user input, our own observations and including technical changes that are looming anyway. We're early in this work but are happy to take your input already :-) It can be a thread you start here (e.g. what do you like now? what do you dislike? what is missing? ... about probe pages) or in a "private interview" of some kind. Cheers, Robert -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Request for Atlas credits for teaching and research
Hi Nitinder,
I've send you another 10 million.
Let us know about your research, in case you publish the results :)
Best regards,
Simon
On 15.12.22 14:32, Michael J. Oghia wrote:
Hi Nitinder,
Just sent you 10 million, good luck! And please share your research when it's
available.
Best,
-Michael
__
Michael J. Oghia
Partnerships Manager, Datacenter Forum <https://datacenter-forum.com>
Communications Coordinator, Global
Conference on Cyber Capacity Building (#GC3B <https://gc3b.org>)
Belgrade, Serbia (CET) | LinkedIn <https://www.linkedin.com/in/mikeoghia> | Twitter
<https://www.twitter.com/MikeOghia>
+381621459730 | +31633512395
On Thu, Dec 15, 2022 at 2:29 PM Nitinder Mohan wrote:
Dear RIPE Atlas community,
I am a postdoctoral researcher in Technical University of Munich, Germany.
I am coming to you with a request to transfer some of your surplus Atlas
credits to my account nitinder.mo...@tum.de if possible. I work on several
Internet measurements research problems which rely on Atlas platform for
measurements. Additionally, I am also planning to give out a cloud connectivity
measurment assignment to my course students to give them hands-on experience
with Atlas -- which exceeds my local credit generation rate.
Your help will be highly appreciated!
Thanks and Regards
Nitinder Mohan
Technical University Munich (TUM)
https://www.nitindermohan.com/ <https://www.nitindermohan.com/>
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Non-public probes?
Hi Chris, sorry for "stealing" this conversation, but it's interesting to hear that there will be a redesign of the probe page coming up soon. Can we have a discussion about that? There are several things, that bother me a bit... BR, Simon On 15.12.22 13:51, Chris Amin wrote: You're right that the probe page is not shown, however the public details are available at https://atlas.ripe.net/api/v2/probes/1003690 The important point there is that the system has not granted the "system: IPv4 Works" tag, so is not available for IPv4 measurements. In general the scheduler doesn't know/care about a probe being marked as public or not. Can you confirm whether the same measurement request works for IPv6 (af=6) measurements? Note that if you schedule measurements together they must all be IPv6 in that case. In the meanwhile, we'll think about including the non-public probes (albeit with their somewhat restricted details) as part of a redesign of the probe page coming up soon. Cheers, Chris On 15/12/2022 13:12, Ernst J. Oud wrote: But what is going on then with: https://atlas.ripe.net/frames/probes/1003690 <https://atlas.ripe.net/frames/probes/1003690> This probe is within AS15435 and when I list all probes in that AS it is shown, but I cannot add it to a measurement, it is rejected. Using a curl request to: stat.ripe.net/data/atlas-probes/data.json?resouce=15435 shows this probe, with a tag “is_public” : false and I cannot access this probe’s info via the link above, I cannot add it to a measurement and I cannot access any data it collects. How does this rhyme to that non-public “probes are therefore contributing very nearly as much to the network as everybody else”? -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]
Hello, >From the linked page: > A total of 173 users scheduled at least one, 81 users have at least two, one > specific user scheduled 91.5% of all of these. That is surprising. What do those numbers look like if you zoom out to the past 6/12/24 months? If you can count on one hand the number of users using >90% of the private measurements over a longer timeframe than two weeks, then I submit that the choice is clear. Cheers, Alex -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] Proposal: Add support for STARTTLS measurements [STARTTLS]
Hello, As a security and privacy specialist, I am absolutely in favour of RIPE Atlas gaining the ability to detect and measure phenomena such as STARTTLS stripping, certificate replacement, etc. Cheers, Alex -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Proposal: remove per-hop “late” packets from traceroute [LATE-PACKETS]
Hi Robert, I support this proposal. I only recently learned through side channels how to correctly interpret this field, as I apparently misunderstood the description in the documentation, so replacing it with a counter is a good idea in my opinion. Best, Malte OpenPGP_0x1FE5C61A04A4159F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Atlas api down
Hi, > The event shows up in the "past incidents" section of the page. Is that what > you're looking for ? I'm sure it does now, but I was referring to this: > Dec 13, 2022 20:22:57 Ernst J. Oud : > > After some two hours it appears to work again. > > status.rip.net showed no problems… and: > Dec 14, 2022 09:39:25 Robert Kisteleki : > > I am updating the status page now. Dec 14, 2022 10:09:25 Robert Kisteleki : > > > On 2022-12-14 10:03, Alexander Burke via ripe-atlas wrote: >> Hi Robert, >> If the status page is manually updated, it should probably show a prominent >> note to that effect so that it is consumed well-salted. > > Hi, > > The event shows up in the "past incidents" section of the page. Is that what > you're looking for? > > Robert -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Atlas api down
Hi Robert, If the status page is manually updated, it should probably show a prominent note to that effect so that it is consumed well-salted. -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] atlas related mails come 4 times
Hi Endre, looking at your E-Mail-Address I'd suspect some issue at the service providing the "rediremail.com" addresses. Can you look at the full headers of all emails and see if you can finde differences in mail routing? I never had any problems of that kind with this list, so I suspect the problem lies somewhere else. Best regards, Pete. -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Unknown probe in my account
Hi Giuseppe, Did you apply for another probe some time ago? If so, that's probably why you see a probe in your user profile, that you don't own (yet). If you did not apply for a new probe, be patient and wait for an answer from at...@ripe.net. Maybe it happened by accident. BR, Simon On 26.11.22 21:29, Giuseppe Macario wrote: My working probe is https://atlas.ripe.net/probes/55083/ So, if I understand correctly, am I receiving a new probe? Il giorno sab 26 nov 2022 alle ore 21:11 Simon Brandt via ripe-atlas ha scritto: Hi Giuseppe, it's one of the new v5 probes. The RIPE Atlas team was not able to send out new probes for a while, due to a shortage of new probes. Did you apply for a new probe some time ago? New probes are currently being shipped. If you are about to receive a new probe, you can already see it in your userprofile, even before it arrives. -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Unknown probe in my account
Hi Giuseppe, it's one of the new v5 probes. The RIPE Atlas team was not able to send out new probes for a while, due to a shortage of new probes. Did you apply for a new probe some time ago? New probes are currently being shipped. If you are about to receive a new probe, you can already see it in your userprofile, even before it arrives. BR, Simon On 26.11.22 18:41, Giuseppe Macario wrote: Hello everyone, I have a probe that works properly but, a few weeks ago, my account also started to show a probe that doesn't work and that I don't know. I contacted atlas @ripe.net <http://ripe.net> to ask for clarification but I didn't get anything (apart from a semi-automated message). So could anyone delete this unknown probe? https://atlas.ripe.net/probes/63078/ Thank you. -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] What is the trick with "+Reuse a set from a measurement" ?????
Hi Barry,
this function does indeed still work, but it appears that the web interface for
it is somewhat broken?
If I search for "traceroute" one of the results is measurement 1001589 [0],
which has this term in the description, but searching for that measurement id gives no
result. And in any case, the only available results seem to be very old looking at the
ids.
What _does_ work is using the measurement API, for example:
"probes": [
{
"type": "msm",
"value": your_msm_id_here,
"requested": number_of_probes_here
}
]
Not sure this is the answer you wanted to hear, but maybe someone from the
Atlas development team can figure out what's up with the web interface.
Best,
Malte
[0] https://atlas.ripe.net/measurements/1001589
On 11/21/22 03:16, Barry Greene wrote:
Hi Team,
I’m trying to use “+Reuse a set from a measurement.” (See
https://atlas.ripe.net/docs/getting-started/user-defined-measurements.html
<https://atlas.ripe.net/docs/getting-started/user-defined-measurements.html>)
I’m going back to my own measurements and trying different Measurement IDs.
None of them work. I try from someone else’s test. None of them work.
Q. Does this function work anymore?
Barry
OpenPGP_0x1FE5C61A04A4159F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] RIPE Atlas SMTP Measurement
Hi Michel, Thanks for your feedback! Note: the SSL measurement currently does not use the OpenSSL library. Is that a reason to not use OpenSSL for SMTP measurements? Are there any reasons to not use OpenSSL? BR, Simon On 11.11.22 13:57, Michel Stam wrote: Hi Simon, This seems to have gotten a bit idle since RIPE85. Let me give a bit of an update: * Adding TLSv1.3 is gonna be tricky since the SSL measurement implements the first stages of the TLS handshake only. This means adding that complexity to the code, which as Niall commented to me is not trivial. Note: the SSL measurement currently does not use the OpenSSL library. * Other than retrieving the certificate from the peer, no other validation happens in the current SSL measurement. This includes not validating the certificate chain, which may be a self-signed certificate. * Adding STARTTLS the way OpenSSL has done it involves issuing the appropriate command after receiving certain output from the remote end, then starting the TLS handshake. This should be doable. Hope this helps, have a nice weekend! Regards, Michel On 20 Oct 2022, at 17:30, Michel Stam wrote: Hello Simon, I’ll first have a look at OpenSSL to gauge the amount of effort required. I’ll also look at the existing SSL measurement to see what that offers. That will likely provide the best path forward. Lastly, I’ll have an internal discussion on measuring SMTP/STARTTLS/etc. Ripe 85 is up next week, I’ll be attending there, so my response may be delayed somewhat. Please bear with me. Regards, Michel On 16 Oct 2022, at 03:37, ripe@toppas.net wrote: Hi Michael, Both netcat and openssl wait for the 220 to continue. If a timeout would occur during the STARTTLS phase, or before the 220, would this differ from a conclusion perspective? In other words, is it necessary to test once for the 220 to appear (or a timeout), then another time to see if the STARTTLS completes? If you have a timeout while waiting for the initial 220 response (service ready), the service is not available. Maybe the SMTP daemon is not running or not answering for some reason, or there's a network issue. If a timeout occurs later during the STARTTLS phase, the server is available and also the underlying network connection seems to be fine. So yes, the conclusion would be a different. But we still don't have to run two separate tests, i think. Could this be folded into a single test that does a 220, then the STARTTLS and will report error when there’s a fail in the process? Yes. Since we do not really want to send an e-mail, we can probably use OpenSSL for everything in a single run. If you use the -debug parameter, you'll get *very* detailed output which contains all informations we want (except for response-times, i think). There might be a more elegant way to get a better-looking output from OpenSSL. But I don't know how, to be honest. I haven't read the whole man-page :) $ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 <http://mahimahi.ripe.net:25/> -debug Most work is probably to study the OpenSSL documentation, to find out the different error messages we have to expect, depending on the problems we might face: - TCP handshake not successfull - Server does not reply with 220 (timeout) - Server does not reply with 220 (server replies with another 4xx or 5xx code) - Server is not ESMTP capable** - Connection successfull, but the server does not offer 250-STARTTLS (not supported or suppressed because of MITM attack) - 250-STARTTLS was offered, but establishing encryption was still not successful for some reason and maybe other typical certificate problems like: - certificate invalid (self-signed) - certificate invalid (expired) - certificate invalid (broken chain) ** SMTP Encryption is optional, but it is not supported by the original SMTP protocoll (RFC 821). To use STARTTLS, the mailserver has to support SMTP "Service Extensions" aka. ESMTP. ESMTP has been introduced 13 years later by RFC 1869. From a communication perspective, the main difference is, that the initiator of the SMTP connection (client) is using EHLO instead of HELO (EHLO = Enhanced HELO). If the server does support ESMTP, it will tell the client it's features. If the server does not support ESMTP, it will reply with an error. I don't know what the OpenSSL output looks like, if you try to connect to a server which does not support ESMTP. It will probably output some error message. This error should be evaluated by the Atlas SMTP measurement too. 99.9% of all mailservers nowadays should support ESMTP, but there might be some usecases... "special application blabla". It could be possible that someone would start a Atlas SMTP measurement for a non-ESMTP compliant target. That's why i am mention this. BR, Simon On 05.10.22 17:55, Michel Stam wrote: Hi Simon, Thanks for the rundown, that helps. The Atlas measurement code use
Re: [atlas] Credit sponsorship
Hi Finn, i've just send you 10 million as well. Have fun! Gruß, Simon On 06.11.22 09:02, Julian Panke via ripe-atlas wrote: Hi Finn, I have transferred 5 million tokens to your account. Mit freundlichen Grüßen Julian Panke Original-Nachricht Am 6. Nov. 2022, 08:57, schrieb Finn Holler < finn.hol...@student.uni-tuebingen.de>: Hello, I am looking for probe operators, with a credit surplus, who would want to transfer some credits to my RIPE Atlas account (email: finn.hol...@student.uni-tuebingen.de). These credits are required for me to interact with the measurement API, which I want to explore and ideally use, to implement a service indicating the connectivity status of various internet services to tenants of local student housing. The plan is to register some probes, so this credit sponsorship is only necessary for initial trials. Best, -Finn -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Credit sponsorship
Hi Finn, I have transferred 5 million tokens to your account. Mit freundlichen Grüßen Julian Panke \ Original-Nachricht Am 6. Nov. 2022, 08:57, schrieb Finn Holler < finn.hol...@student.uni-tuebingen.de>: > > Hello, I am looking for probe operators, with a credit surplus, who would > want to transfer some credits to my RIPE Atlas account (email: > finn.hol...@student.uni-tuebingen.de). These credits are required for me to > interact with the measurement API, which I want to explore and ideally use, > to implement a service indicating the connectivity status of various internet > services to tenants of local student housing. The plan is to register some > probes, so this credit sponsorship is only necessary for initial trials. > Best, -Finn -- ripe-atlas mailing list ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas publickey - EmailAddress(s=ml@julianpanke.com) - 0xFD7892A4.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] V4 probe looses connection
Hi, I have a probe (#53985, V4, fw: 5070) that goes offline after 1-2 days of uptime and does not recover unless rebooted. The probe responds to ping (even from a different subnet). Packet capture reveals that it renews its DHCP lease normally, but does not initiate any higher level connection. I will try to keep the probe online for a few days so that you can run some tests if you wish. Regards, Szabolcs -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
