[atlas] Probe on OpenWRT does not load telnetd

Just a tip for OpenWRT users.

I noticed that during most reboots my new SW probe on OpenWRT 21.02 does not load the telnetd daemon. No idea why but I saw that its priority in init.d is rather high (S30), i.e. it loads rather early. Perhaps that is the problem but instead I test for telnetd running in the ATLAS loop and load the daemon if not.

Regards,

Ernst J. Oud



Met vriendelijke groet,

Ernst J. Oud
> On 30 Jun 2022, at 12:00, ripe-atlas-request at ripe.net wrote:
> 
> Send ripe-atlas mailing list submissions to
>  ripe-atlas at ripe.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>  https://mailman.ripe.net/
> or, via email, send a message with subject or body 'help' to
>  ripe-atlas-request at ripe.net
> 
> You can reach the person managing the list at
>  ripe-atlas-owner at ripe.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ripe-atlas digest..."
> 
> 
> Today's Topics:
> 
> 1. Re:  Overuse of software probes (Emile Aben)
> 2. Re:  Probe on sailboat with Starlink (Daniel Karrenberg)
> 3. Re:  Assigned AS vs. Advertising AS (ripe.net at toppas.net)
> 4. Re:  Overuse of software probes (Romain Fontugne)
> 5.  RIPE Atlas Quarterly Planning Q3 2022 (Robert Kisteleki)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 29 Jun 2022 14:34:08 +0200
> From: Emile Aben <emile.aben at ripe.net>
> To: "Ponikierski, Grzegorz" <gponikie at akamai.com>, RIPE Atlas
>  <ripe-atlas at ripe.net>
> Subject: Re: [atlas] Overuse of software probes
> Message-ID: <7f053467-59c6-69e0-6a33-44a1b42efdd2 at ripe.net>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
>> Emile Aben, I would be happy to see code for detecting overly similar
>> probes. It would save a lot of time spend on data filtering.
> 
> These are snapshots of data for probe similarity detection [1] in IPv4 
> and IPv6
> 
> https://sg-pub.ripe.net/emile/probe-similarity/probe_similarity_ipv4-2022-06-29.csv
> https://sg-pub.ripe.net/emile/probe-similarity/probe_similarity_ipv6-2022-06-29.csv
> 
> This calculates 3 similarity values between 0 and 1 (the last 3 values 
> in the csv). Pick the middle one if you don't care about the details.
> 
> There are 54k probe-pairs with similarity values over 0.5,
> 7.4k with value over 0.95
> 6.7k with value over 0.99
> 
> My gut feeling is that anything over 0.95 is likely very redundant for 
> many types of measurements.
> 
> There seems to be a cluster of about 400 probes that are very similar to 
> each other, and a couple of smaller clusters too.
> 
> Happy to work with you and others to see if we can make this into 
> something that is operationally valuable.
> 
> kind regards,
> Emile Aben
> RIPE NCC
> 
> [1] Holterbach, Thomas, et al. "Measurement vantage point selection 
> using a similarity metric." Proceedings of the Applied Networking 
> Research Workshop. 2017.
> https://trac.ietf.org/trac/irtf/export/478/www/content/anrw/2017/anrw17-final9.pdf
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 29 Jun 2022 14:46:26 +0200
> From: Daniel Karrenberg <dfk at ripe.net>
> To: Stephen Strowes <s at sdstrowes.co.uk>, ripe-atlas at ripe.net
> Subject: Re: [atlas] Probe on sailboat with Starlink
> Message-ID: <2df11fd5-5385-ee11-e5fc-ded5839a6beb at ripe.net>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> 
> 
>> On 28-06-2022 19:46, Stephen Strowes wrote:
>> ... I have no idea how starlink decides what ground station to bounce
>> your service down onto, it might be interesting to see how it works
>> the further you get from home.
> 
> https://starlink.sx/ is a nice *simulation* that provides some graphical 
> insight in what POPs might be used and why.
> NB: one can set the user location at the top right.
> 
> Daniel
> 
> PS: Receiving my starlink RV in a few days. I will test it at home 
> first. If there is a spare probe, I'll be happy to connect it later.
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 29 Jun 2022 18:05:44 +0200
> From: ripe.net at toppas.net
> To: Gert Doering <gert at space.net>
> Cc: ripe-atlas at ripe.net
> Subject: Re: [atlas] Assigned AS vs. Advertising AS
> Message-ID: <9049c43c-8f51-8710-9061-6ce680a83eeb at toppas.net>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> 
> Hi Gert,
> 
> thanks for your clarification! But you still get my point, do you?
> If a prefix was assigned to an entity other than the one that is advertising the prefix, for example: 80.187.128.0/22
> 
> Announcing: Deutsche Telekom AG (AS3320)
> Assigned: T-Mobile Deutschland GmbH (AS44178)
> 
> The information (original prefix receiver) is stored in the RIPE DB, right? It could be compared to what we see via BGP.
> I am aware that a single entity can have multiple AS numbers, but when different entities are "involved", more transparency would be great.
> 
> Or am i missing something here?
> 
> BR,
> Simon
> 
>> On 29.06.22 10:54, Gert Doering wrote:
>> Hi,
>>> On Wed, Jun 29, 2022 at 10:30:22AM +0200, Simon Brandt via ripe-atlas wrote:
>>> Another example would be a multi ASN company which announces all
>>> prefixes from a single ASN via BGP, even though the prefixes are
>>> assigned to various AS numbers. Since the RIRs do have the information,
>>> to which AS a specific prefix is assigned to,
>> prefixes are not assigned to "AS" numbers, ever.
>> prefixes are assigned to entities, as are AS numbers.
>> ROAs and/or route(6): objects are used to tie both together - and it's
>> in the authority of the network (prefix) holder to state which AS is
>> allowed and expected to announce a given prefix, not the RIR.
>> Repeat: the RIR has no say in "which AS is tied a prefix".
>> Gert Doering
>>       -- NetMaster
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: </ripe/mail/archives/ripe-atlas/attachments/20220629/5470f81c/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 4
> Date: Thu, 30 Jun 2022 14:49:02 +0900
> From: Romain Fontugne <romain at iij.ad.jp>
> To: Michael Rabinovich <michael.rabinovich at case.edu>, Randy Bush
>  <randy at psg.com>
> Cc: "Ponikierski, Grzegorz via ripe-atlas" <ripe-atlas at ripe.net>,
>  Nicholas Kernan <nlk39 at case.edu>, Emile Aben <emile.aben at ripe.net>
> Subject: Re: [atlas] Overuse of software probes
> Message-ID: <1ff34c1d-6d32-b67b-b425-a225abc8e605 at iij.ad.jp>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> 
>> On 6/29/22 00:23, Michael Rabinovich wrote:
>> Looking forward to reading Emile?s paper, but in the meantime: Nick
>> Kernan, a graduate student of mine, wrote a python script for selecting
>> a geographically diverse set of probes from a list of probes.
> 
> The paper describes a similar approach, but using topological distances 
> (e.g. AS path length, RTT). It is not perfect but more useful than 
> Atlas' world-wide probe selection.
> 
> Results are weekly updated here:
> https://ihr.iijlab.net/ihr/en-us/metis/selection
> 
> We've also extended this approach to find places where deploying new 
> Atlas probes would add more diversity to Atlas:
> https://ihr.iijlab.net/ihr/en-us/metis/deployment
> 
> The paper is now available:
> https://tma.ifip.org/2022/wp-content/uploads/sites/11/2022/06/tma2022-paper18.pdf
> 
> 
> Thanks,
> Romain
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: OpenPGP_0xDA13CA6E034AA51C.asc
> Type: application/pgp-keys
> Size: 3143 bytes
> Desc: OpenPGP public key
> URL: </ripe/mail/archives/ripe-atlas/attachments/20220630/a3742074/attachment-0001.bin>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: OpenPGP_signature
> Type: application/pgp-signature
> Size: 840 bytes
> Desc: OpenPGP digital signature
> URL: </ripe/mail/archives/ripe-atlas/attachments/20220630/a3742074/attachment-0001.sig>
> 
> ------------------------------
> 
> Message: 5
> Date: Thu, 30 Jun 2022 09:51:47 +0200
> From: Robert Kisteleki <robert at ripe.net>
> To: "ripe-atlas at ripe.net" <ripe-atlas at ripe.net>
> Subject: [atlas] RIPE Atlas Quarterly Planning Q3 2022
> Message-ID: <fbe15621-9f7d-fe91-da0f-07fc9b8e1b38 at ripe.net>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Dear colleagues,
> 
> The quarterly plans for RIPE Atlas can now be found at:
> https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas
> 
> In this quarter, we will continue with the development of the v5 RIPE 
> Atlas hardware probes among other items as well as start working on two 
> proposals to implement general availability of HTTP measurements and 
> restricting the ability to schedule "non-public measurements".
> 
> The goal of our quarterly planning is to communicate the work we?re 
> doing for the coming months, get your input and start a discussion on 
> other developments we should work on.
> 
> If you have any input on our plans or want to let us know what you would 
> like to see us work on, please let us know.
> 
> Kind regards,
> 
> Robert Kisteleki
> Research and Development Manager
> RIPE NCC
> 
> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas at ripe.net
> https://mailman.ripe.net/
> 
> 
> ------------------------------
> 
> End of ripe-atlas Digest, Vol 130, Issue 20
> *******************************************