Re: [atlas] Possible software probe "farming" on AS47583

[Jared Mauch]

I would think that type=software && bgp_prefix = same (at least the same /24 
and /48) would be a decent method to define similar.

- Jared
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Future of Software Anchors

[Jared Mauch]

> On May 28, 2022, at 10:27 AM, Lukas Magauer via ripe-atlas 
>  wrote:
> 
> Hi everybody!
>  
> I have been running a Software probe on CentOS 8 since mid 2020. (and since 
> switched it to Rocky Linux 8)
> It’s unsupported, but also didn’t really make any problems, just worked fine 
> with the yum repo distributed package!
>  
> Great that there are already plans to support newer versions as well!
>  
> And has there something changed in the distribution of the package?
> Because the latest changes of version 5070 don’t look like they appeared in 
> the GitHub repo?
>  
> Best regards,
> Lukas

I just made a new anchor the other day, and CentOS 7 is still the requirement, 
I also rebuilt one of the original VM anchors as well - it had a different 
partition scheme and I wasn’t asked to fix it, but apparently it was causing an 
issue on the back-end.

I’m expecting they will do an OS upgrade, but also CentOS doesn’t really like 
providing upgrade paths, so I suspect the job will be to just re-image the VM 
with a newer CentOS ISO and kickstart file at some point, or they will find a 
repeatable series of dnf commands that will step the VM from 7 -> SomethingNewer

- Jared


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Probes suffering DNS interception?

[Jared Mauch]

> On Dec 10, 2020, at 12:29 PM, Ray Bellis  wrote:
> 
> Is there any RIPE policy about whether nodes that are subject to DNS
> interception should be excluded from results (or maybe even dropped
> altogether) ?
> 
> While these probes are perhaps still useful for ping and traceroute
> tests, they are effectively useless for DNS related tests other than as
> a proxy measure for how prevalent that practise actually is.
> 
> For the visualisation I've just been building based on the Root System's
> "hostname.bind" data returned by Atlas it was pretty difficult to figure
> out how to exclude those probes on the client side.
> 
> If there was a heuristic that could be applied on the probe itself or
> within the RIPE data collector that tagged the probe as having "bad DNS"
> that would help a lot.

I think this is valuable, you can get an idea of what part of the population is 
being tampered with either by bad NETGEAR devices or otherwise.  It’s clear you 
need to design something to measure for this, but I don’t think they should be 
automatically excluded.

There are providers that do strange things like TTL lengthening which are 
problematic, but you often can’t see these non-compliant resolvers without a 
much more in-depth investigation.  (No, I’m not talking about serve-stale 
either, that I think is a fine behavior).

- Jared

Re: [atlas] RIPE Atlas Software Probes

[Jared Mauch]

Wondering if it makes sense to have a Debian and raspbian repo stood up for 
this. I could easily add this to my clusters of raspi to make the coverage 
broader. 

Sent from my iCar

> On Feb 12, 2020, at 6:03 AM, Paul Eagles  wrote:
> 
> Great news!
> 
> I'm having a few issues getting the Debian .deb file to build, I don't know 
> if it's something specific to my environment (though I've tried it on a few 
> different boxes) or an issue with the git repository, but:
> 
> [pauleagles@dns2 ~]$ git clone --recursive 
> https://github.com/RIPE-NCC/ripe-atlas-software-probe.git
> Cloning into 'ripe-atlas-software-probe'...
> remote: Enumerating objects: 197, done.
> remote: Counting objects: 100% (197/197), done.
> remote: Compressing objects: 100% (120/120), done.
> remote: Total 485 (delta 86), reused 137 (delta 58), pack-reused 288
> Receiving objects: 100% (485/485), 112.47 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (203/203), done.
> Checking connectivity... done.
> Submodule 'github-busybox' 
> (https://github.com/RIPE-NCC/ripe-atlas-probe-busybox.git) registered for 
> path 'probe-busybox'
> Cloning into 'probe-busybox'...
> remote: Enumerating objects: 310, done.
> remote: Counting objects: 100% (310/310), done.
> remote: Compressing objects: 100% (226/226), done.
> remote: Total 8634 (delta 117), reused 224 (delta 83), pack-reused 8324
> Receiving objects: 100% (8634/8634), 10.21 MiB | 14.91 MiB/s, done.
> Resolving deltas: 100% (3657/3657), done.
> Checking connectivity... done.
> fatal: reference is not a tree: 0615d3803b7b68cf85f959957b433f1c9fe2f3e6
> Unable to checkout '0615d3803b7b68cf85f959957b433f1c9fe2f3e6' in submodule 
> path 'probe-busybox'
> [pauleagles@dns2 ~]$
> 
> [pauleagles@dns2 ~]$ 
> ./ripe-atlas-software-probe/build-config/debian/bin/make-deb
> ./ripe-atlas-software-probe/build-config/debian/bin/make-deb: 30: cd: can't 
> cd to 
> /home/pauleagles/atlasswprobe-5010-1-work/probe-busybox/libevent-2.1.11-stable
> [pauleagles@dns2 ~]$
> 
> I need to head out now, but I'll have a deeper look into it later.
> 
> Cheers,
> 
> Paul.
> 
> -Original Message-
> From: ripe-atlas  On Behalf Of Philip Homburg
> Sent: 12 February 2020 09:54
> To: ripe-atlas@ripe.net; mat...@ripe.net
> Subject: [atlas] RIPE Atlas Software Probes
> 
> Dear colleagues,
> 
> We are glad to announce that, after several months of development and 
> testing, we are now accepting applications for RIPE Atlas software probes. 
> With several different installation options to choose from, software probes 
> provide future hosts a whole new way to get involved with RIPE Atlas.
> 
> For more details, see our new article on RIPE Labs:
> 
> https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes
> 
> Kind regards,
> Philip
> 

Re: [atlas] Software probes ?

[Jared Mauch]

I had written up instructions for the VM based anchor method of installing with 
KVM/QEMU. You need to apply for an anchor and be approved and then set it up 
for them. It's not that hard. 

https://labs.ripe.net/Members/kistel/outcome-of-the-ripe-atlas-anchor-vms-pilot

Likely has the best info. 

Sent from my iCar

> On Sep 27, 2019, at 4:22 AM, Toussaint OTTAVI  wrote:
> 
>  Hi,
> 
> I just saw a survey last June about software probes. I would be greatly 
> interested by them. Can we have some news about this project ?
> 
> I know I can deploy software anchors. But I'm on a tiny island. I have very 
> few bandwidth, and it's very expensive; then I can't afford spending too much 
> of it :-)
> 
> Kind regards,
> -- 
> Toussaint OTTAVI
> MEDI INFORMATIQUE
> Tel : 04 95 20 10 03
> GSM : 06 10 28 41 72
> Email : t.ott...@medi.fr 
> 

Re: [atlas] Request RIPE Atlas Credit for Research

[Jared Mauch]

> On Mar 6, 2019, at 7:21 AM, Hugh Saunders  wrote:
> 
> I see the big spenders are out in force today, anybody got an GBP for 
> research? 
> 
> ;-)

If the payments are in atlas credits sure.

I also sent a few credits over as well.

- Jared

(Riches, I earn 273,600.00 credits / hour!)

Re: [atlas] Why has probe growth stagnated?

[Jared Mauch]

I think it’s quite easy to get a VM these days as well, so the needs have 
perhaps changed somewhat.

I know that hosting a VM anchor is a lot easier now, and people may have an 
easier time hosting a VM than a probe in some cases.

- Jared

> On Feb 14, 2019, at 12:13 PM, James Gannon  wrote:
> 
> Hard to get new probes these days.
> 
> On 14.02.19, 18:10, "ripe-atlas on behalf of Hank Nussbacher" 
>  wrote:
> 
>On 12/02/2019 18:22, Hank Nussbacher wrote:
> 
>As I am preparing my presentation I went to the stats page:
>https://atlas.ripe.net/results/maps/network-coverage/
>and found that even user growth continues upward as well as number of 
>anchor probes, the number of actual probes has more or less tapered off 
>as of mid-2017 and ends close to 10,000 probes.  Why is that?
>Since Nov 2015 when we passed the 9000 probe mark, probe growth is 
>negligible.
>Why have all these new users (20,000 new uses since Nov 2015!) not added 
>probes?
>What are we doing wrong to entice users to install probes?
> 
>Regards,
>Hank
> 
>> I have been invited to a large CS dept in a university to give a 40 
>> minute intro into
>> what is RIPE ATLAS, how does it work, how do you get credits, how many 
>> probes
>> are there, what is an anchor, where are they located, how does the GUI 
>> work, what type of measurements
>> can one do, etc.  Very very introductory - just to whet their 
>> appetite.  A basic intro to RIPE ATLAS.
>> So I looked in:
>> https://atlas.ripe.net/resources/training-and-materials/
>> and didn't find anything (PS the webinar link is broken).
>> I am sure there must be some PPT/PDF presentation out there for this.
>> Pointers?
>> 
>> Thanks,
>> Hank
> 
> 
> 
> 
> 

Re: [atlas] Probe questions - reporting clearly busticated probe configs?

[Jared Mauch]

> On Jan 16, 2019, at 1:18 PM, Christopher Morrow 
>  wrote:
> 
> Howdy!
> I've been running a few measurements over the last while and looked at the 
> raw results like:
> 
> [{"dst_name":"2001:4860:4860::8844","error":{"socket":"connect failed Network 
> is 
> unreachable"},"from":"fd84:d527:5183:0:a2f3:c1ff:fec4:63a8","fw":4940,"group_id":18903906,"lts":21,"msm_id":18903906,"msm_name":"Tdig","prb_id":13635,"
> "from":"2001:db8:4447:0:eade:27ff:fec9:7134","fw":4940,"group_id":18903906,"lts":7,"msm_id":18903906,"msm_name":"Tdig","prb_id":26725,"...]
> 
> I'm curious if/how atlas reports back to probe owners: 
>   "Hey, your ipv6 connectivity is implausible/impossible"
> 
> since, at least for:
>   https://atlas.ripe.net/probes/26725/#!tab-network
> and:
>   https://atlas.ripe.net/probes/13635/#!tab-network
> 
> there's no way their v6 addresses can work... (one is documentation prefix 
> the other is ULA I think?)
> 
> I suppose test requestors should check the ipv6 prefix to see if it's at 
> least plausibly correct until some signal back to the owners can be attempted?

You should be selecting probes with the system-ipv6-works tag

https://atlas.ripe.net/docs/probe-tags/

- jared

Re: [atlas] New on RIPE Labs: Plan of Action for RIPE Atlas Anchor VMs

[Jared Mauch]

Similarly happy to help.

- Jared

> On Dec 21, 2017, at 6:03 AM, Colin Johnston  wrote:
> 
> Happy to help with vm work as well if needed as I was one asking for VM probe 
> functionality.
> 
> Colin
> 
> 
>> On 21 Dec 2017, at 11:00, Mirjam Kuehne  wrote:
>> 
>> Dear colleagues,
>> 
>> Members of the RIPE Atlas community have asked us to implement RIPE
>> Atlas vantage points as Virtual Machines (VMs). In order to address
>> these requests, we came up with a plan of action:
>> 
>> https://labs.ripe.net/Members/kistel/plan-of-action-for-ripe-atlas-anchor-vms
>> 
>> Kind regards,
>> Mirjam Kühne
>> RIPE NCC
>> 
> 

Re: [atlas] Trying to measure Quad9 latency

[Jared Mauch]

> On Nov 22, 2017, at 2:05 PM, Stephane Bortzmeyer  wrote:
> 
> On Wed, Nov 22, 2017 at 06:27:42PM +,
> Eduardo Duarte  wrote 
> a message of 289 lines which said:
> 
>> When I got the results from the measurement they were not what I
>> expected The measurements to Quad9 had high value of REFUSAL.
> 
> You did not set the RD (Recursion Desired) bit. Most resolvers refuse
> these queries, to avoid cache snooping.
> 
> Compare with #10290443, which have:
> 
> Recursion desired True

I also created this measurement, which is a ping one to measure latency to 
identify what countries receive a poor response.

https://atlas.ripe.net/measurements/10291137/#!probes

- jared

Re: [atlas] Three improvement suggestions

[Jared Mauch]

> On May 30, 2017, at 8:50 AM, Neal Daringer  wrote:
> 
> not sure if this is appropriate for the list or not, but I definitely am in 
> the same boat. I don't use my credits and would love for them to be put to 
> use.
> 
> On Tue, May 30, 2017 at 8:23 AM, Michael Oghia  wrote:
> Dear all,
> 
> I have three suggestions for how to improve the Atlas program:
> 
> 1. Set up an automatic transfer system? That way, if someone accrues credits 
> they would like to transfer, we can set it up to do so automatically once we 
> hit 1,000,000 credits (think of it as similar to a bank's auto-pay system).
> 
> 2. A system where, if someone needs extra credits, they can automatically 
> request them to be deducted (with those who opt-in) from someone like myself 
> with unused / extra credits.
> 
> 3. Email notifications of when we have accrued 1,000,000 credits (my 
> apologies if this is already a feature).
> 
> I say this because I don't use my credits, so I don't want them to go to 
> waste. It would be much more efficient if someone who needed them could 
> access them any time (assuming I already gave permission for that 
> (opted-in)). 
> 
> Let me know if anyone needs clarification about my suggestions.

My problem is always finding someone to send credits to.  You can share 
credits, but I don’t know who would want them.

- jared

Re: [atlas] Need host with very large ping times

[Jared Mauch]

> On May 26, 2017, at 12:42 PM, Roman Mamedov  wrote:
> 
> On Fri, 26 May 2017 14:51:49 +0300
> Marat Khalili  wrote:
> 
>> I have an interesting problem: I need some host that doesn't mind being 
>> pinged but with several seconds of RTT (that's thousands milliseconds; 
>> from Moscow, but it probably doesn't matter).
> 
> Just something to keep in mind, if they have such a terrible network
> connection, they probably would not appreciate being pinged (if you mean
> continuously or at any degree of regularity), chipping away at their miniscule
> network bandwidth in favor of some random person's unrelated research...

My experience is it’s not always about the lack of connectivity, it’s about odd
buffering behaviors of devices.  The Juniper M40 would buffer an incredible 
amount
of data on the FPC for a T1 speed link whereas a OC48 FPC had the same buffer 
sizes
for much higher rates.

Of course, this all assumes you know what you’re measuring, which is a critical 
part of it.

- Jared

Re: [atlas] Surplus RIPE Atlas credits

[Jared Mauch]

I sent you some. Let me know if you need more. 

Jared Mauch

> On Jan 13, 2017, at 6:20 AM, Max Mühlbronner <m...@42com.com> wrote:
> 
> Hi,
> 
> 
> very kind of you, yes i am always in need of RIPE credits. Currently claiming 
> the 1 million free credits every month, but also using it up quickly.. :)
> 
> BR
> 
> Max M.
> 
>> On 13.01.2017 12:09, Michael Oghia wrote:
>> Hi everyone,
>> 
>> I host a probe but do not create measurements. As such, I have a large
>> surplus of unused credits. Is anyone in need of credits and would like for
>> me to transfer them?
>> 
>> Best,
>> -Michael
>> __
>> 
>> Michael J. Oghia
>> iGmena <http://igmena.org/> communications manager
>> Independent #netgov consultant & editor
>> 
>> Belgrade, Serbia
>> Skype: mikeoghia
>> Twitter <https://www.twitter.com/MikeOghia> *|* LinkedIn
>> 
>> <https://www.linkedin.com/in/mikeoghia>
>> 
> 
> 
> -- 
> Max Mühlbronner
> 42com Telecommunication GmbH
> Straße der Pariser Kommune 12-16
> 10243 Berlin
> E-Mail: m...@42com.com
> Web: www.42com.com
> 
> Firmenangaben/Company information:
> Handelsregister/Commercial register: Amtsgericht Berlin HRB 99071 B
> Umsatzsteuer-ID/VAT-ID: DE223812306
> Geschäftsführer/CEO: Thomas Reinig, Alexander Reinig
> 
> Diese E-Mail enthält Informationen von 42com Telecommunication GmbH. Diese 
> sind möglicherweise vertraulich und ausschließlich für den Adressaten 
> bestimmt.
> Sollten Sie diese elektronische Nachricht irrtümlicherweise erhalten haben, 
> so informieren Sie uns bitte unverzüglich telefonisch oder per E-Mail.
> This message is intended only for the use of the individual or entity to 
> which it is addressed.
> If you have received this message by mistake, please notify us immediately.

Re: [atlas] New on RIPE Labs: Another Look at RIPE Atlas Probe Lifetimes

[Jared Mauch]

> On Aug 25, 2016, at 4:46 PM, Gert Doering  wrote:
> 
> On Thu, Aug 25, 2016 at 03:37:06PM +0100, Colin Johnston wrote:
>> maybe virtual vm probes might be useful 
> 
> You're not giving up on this, are you?

It’s way easier for me to spin up 25 virtual probes than 25 physical ones :)

Hoping that virtual probe is making progress :)

- Jared

Re: [atlas] evaluating ripe atlas

[Jared Mauch]

I will hand out 10m credits to folks who email me a proper address. 

Jared Mauch

> On May 18, 2016, at 8:19 AM, Boris Fersing <r...@fersing.eu> wrote:
> 
> Hi Rafal,
> 
> I can also donate some credits, let me know.
> 
> Boris
> 
> May 18 2016 8:09 AM, "Marat Khalili" <m...@rqc.ru> wrote:
> Hello Rafał,
> 
> How many do you need and what for? I have some spare credits, other people 
> here may have them too.
> 
> 
>  
>> 
>> Hosting probe is not something feasible for me  at the moment.
> I wonder why. All you need is USB charger and internet connection.
>  
> --
> 
> With Best Regards,
> Marat Khalili
>  
>> On 18/05/16 14:52, rafal.jankow...@thomsonreuters.com wrote:
>>  
>> Dear Ripe Atlas Users,
>> I would like to evaluate ripe atlas features. Is there any quick and simple 
>> way to earn credits? From what I can see becoming sponsorship begins from 
>> 1000 EUR which is above my budget for evaluating the tool. Hosting probe is 
>> not something feasible for me  at the moment. Is there any option to buy 
>> credits for something like 100 EUR? Also I wanted to see webinar recording 
>> https://www.youtube.com/watch?v=oJMFGuM0kMo linked on 
>> https://atlas.ripe.net/resources/training-and-materials/ but it seems to be 
>> unavailable.
>> Regards,
>> Rafał
>>  
>> 
>> This e-mail is for the sole use of the intended recipient and contains 
>> information that may be privileged and/or confidential. If you are not an 
>> intended recipient, please notify the sender by return e-mail and delete 
>> this e-mail and any attachments. Certain required legal entity disclosures 
>> can be accessed on our website.

Re: [atlas] Support for arbitrary DNS queries

[Jared Mauch]

> On Dec 9, 2015, at 2:39 PM, Randy Bush  wrote:
> 
>> I'd like to request the ability to have RIPE Atlas probes be able to issue
>> DNS queries for arbitrary record types, and have that capability exposed in
>> the API. I'm particularly interested in newer DANE record types like TLSA,
>> OPENPGPKEY, SMIMEA, etc but a general purpose mechanism would be useful.
>> 
>> Is this feasible? Are others interested in this capability?
> 
> definitely!  both for research and for monitoring my own services.

Perhaps a method to just set the RRType as integer would work in the interim?

- Jared

Re: [atlas] Sharing credits with colleagues

[Jared Mauch]

Or you can ask me for credits.  I transfer credits to people who ask.  My 
credit cup runneth over.

- Jared

> On Nov 9, 2015, at 8:02 AM, Oliver Haake  wrote:
> 
> Thank you Robert, that sounds awesome.
> Keep up the good work.
> 
> 
> Cheers,
> Oliver
> 
> 
> 
> 
> 
> On 09.11.2015 13:27, Robert Kisteleki wrote:
>> On 2015-10-29 16:56, Oliver Haake wrote:
>>> Hey there,
>>> 
>>> I'm very curious if you guys have an ETA for the "Sharing credits with
>>> colleagues" feature.
>>> 
>>> Any ideas?
>>> 
>>> 
>>> 
>>> Cheers,
>>> Oliver
>> 
>> Hello,
>> 
>> This task is coming up shortly, so I expect that we can deliver it soon. At
>> the moment we think it'll result in two functions:
>> 
>> 1. Make "standing orders": automatically spread the excess amount of credits
>> to other accounts if I have more than X, AND/OR
>> 2. Let me make a measurement that will be billed to someone else, who
>> authorised me before to do this
>> 
>> These two will fit a lot of use cases with (we believe) a low amount of
>> complexity.
>> 
>> Cheers,
>> Robert
>> 
> 
> 
> -- 
> Oliver Haake  | Tier3 Network Engineer | euNetworks
> Theodor-Heuss-Allee 112 | 60486 Frankfurt/Main
> +49 69 905 542 49 office
> 
> Für weitere Informationen über euNetworks oder für Informationen über
> unsere Unternehmen, darunter euNetworks GmbH, besuchen Sie bitte unsere
> Webseite www.eunetworks.de.
> 
> Diese E-Mail und oder Anhänge können vertrauliche und/oder gesetzlich
> privilegierte Information enthalten. Wenn Sie nicht der beabsichtigte
> Empfänger sind, löschen Sie bitte die E-Mail, ohne sie zu lesen, und
> benachrichtigen Sie den Absender.
> euNetworks GmbH Geschäftsführer: Joachim Piroth Sueleyman Karaman Myriam
> Buchheister  Amtsgericht Frankfurt am Main HRB 88224 Steuernummer
> 04523251638 Umsatzsteuer ID: DE 201 739 716