[atlas] Probe on OpenWRT does not load telnetd
- Previous message (by thread): [atlas] RIPE Atlas Quarterly Planning Q3 2022
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ernst J. Oud
ernstoud at gmail.com
Thu Jun 30 16:24:28 CEST 2022
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://lists.ripe.net/mailman/listinfo/ripe-atlas > 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: <https://lists.ripe.net/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: <https://lists.ripe.net/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: <https://lists.ripe.net/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://lists.ripe.net/mailman/listinfo/ripe-atlas > > > ------------------------------ > > End of ripe-atlas Digest, Vol 130, Issue 20 > *******************************************
- Previous message (by thread): [atlas] RIPE Atlas Quarterly Planning Q3 2022
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]