>> i have a dead probe, 25898, which i have tried all known means to
>> revive. how do i set the RIP status?
> Head to https://atlas.ripe.net/probes/25898/ (while logged in), click
> the «Edit» button next to the «Write off your probe» header near the
> bottom of the page.
missed that. thanks.
whoops. here is it's MAC on the LAN
192.168.0.166ether c4:6e:1f:3a:e6:3a
randy
-
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
i have a dead probe, 25898, which i have tried all known means to
revive. how do i set the RIP status?
i replaced it with a probe i had in stash, 25893. when i went to
https://atlas.ripe.net/probes/25893 it claims it is disconnected for "1
year, 9 months" from comcast.
clue bat please
randy
done
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
> Unfortunately, as far as I can see, this seems to be only visible
> for your own probes (and you need to be logged in).
aha! that was it. sigh.
thanks.
randy
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
i have a remote probe. on the web gui, how can i see what its lan
address (it is behind a soho nat) and mac are? i thought i knew how
to do this, but the moon must be in klutz.
thanks.
randy
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
> 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,
> 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
> Randy provided me with a replacement probe to install and it's now
> online (#25898).
so now we need to learn how to retire and replace
randy
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
> how can i share access to the probe management page(s) with someone?
had to go to each probe and add the user
randy
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
how can i share access to the probe management page(s) with someone?
randy
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
> Consumption delay according to the main page is up to 16+ hours so
> something is indeed very wrong.
aha! a symptom. thanks.
indeed, an issue
randy
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
> 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.
michel,
> You should be able to order a stick from the net. I would also check
> the USB power cable (the USB A - Mini-B cable), and the power
> supply. If the unit doesn’t get enough power a similar problem may
> occur.
power measures as good. will order a usb replacement. but, in the
probe 25898 had a usb failure. i did the unplug usb, power cycle, wait,
replug usb. it worked for most of a day and then failed again. rinse
repeat. oops, this last time, it has yet to return.
can i just order a usb off the net and replace it? or do i just replace
the unit?
randy
--
> did you miss that thread ?
>
> https://www.ripe.net/ripe/mail/archives/ripe-atlas/2023-January/thread.html#5322
what a a classic bikeshed discussion. i want docker, i want rpm, i want
comic sans.
> I would also to be happy to have a repository, so the atlas gets
> updated, when I update the
michael
> You may try and build a 5080 package, then upgrade from debian. I’d
> keep a backup of the keys in /var/atlas-probe/etc (top of my head)
> just in case.
is there a path where a simple `apt update; apt upgrade` will work
ongoing? building and installing debs is s last century.
and
i have a probe, 104, on a deb 10 vm that was installed in the
rotterdam hackathon. the detritus looks as if it was built using a deb
install of atlasswprobe-5000-1.deb.
two days ago, it stopped working in some way; i have not pursued,
figuring i was dealing with an antique.
is there a path
hi robert,
and thanks
> I seem to remember that a typical non-public measurement is a one-off,
> and as such the data volume collected and stored is likely to be
> relatiely low.
interesting
> I don't have the numbers readily available to me at this moment, but
> we can certainly dig up recent
i asked this quietly before, but let me be more direct.
how much private data is there actually? what percentage of the stored
data is private?
randy
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
i do not understand the big fuss here. so a teensie fraction of probes
are not public. big deal.
some weeks we seem to want to be maxed out regulators and keepers of the
total moral truth. the net is complex and rich. this is a good thing.
randy
--
ripe-atlas mailing list
grzegorz:
your work sounds fun, interesting, and useful. but your message pushed
one of my minor buttons. just some food for thought, not a critique of
any of these efforts. i really like them.
maybe it is because i am more routing/forwarding oriented; but i think
more about topology more
> IMHO it’s most likely credit farming.
which is amusing, as a note on this list or nanog asking for credits
usually requires a pickup truck.
> 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.
"Metis: Better
> BTW, a hard limit of one probe per /24 e.g. also sounds like a useful
> limitation to me.
i have one hard and one soft on the same /24 lan so we can compare them.
which would you like me to remove?
as the elected legislators in my country are doing so scarily horribly,
i am cheered that so
>>> The solution suggested by the Atlas team was simply
>>> to register the new instance with the ID number I
>>> had been using before. This worked.
>>>
>>> IIUC, each hardware probe is pre-registered. This
>>> may be an obstacle; I don’t know.
>>
>> i suspect the probe or actually the back end
> The solution suggested by the Atlas team was simply
> to register the new instance with the ID number I
> had been using before. This worked.
>
> IIUC, each hardware probe is pre-registered. This
> may be an obstacle; I don’t know.
i suspect the probe or actually the back end would have an
a sweet old v1 probe, 2285, in a hard to access (due to covid) place
died 19 months ago. i want to swap in a v3, 25898, this weekend. i
know i could create a new entry, but how do i delete the old; or better
yet, move the data from old to new? stop laughing. :)
randy
> To expand on the immediate area of research, I'd like to have a distributed
> system where nodes self-identify what location they're in. There are a
> number of situations - be it operator misconfiguration or active attempts
> to misreport where it is more concrete to instead have nodes report
would you care to share reasons for suspicion which would warrant
raising the level of authenticity?
randy
---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery
> In short, supporting this request is going to take only a tiny bit of
> time to support.
don't forget to include the time to read all the email discussion about
it. :)
> I just did a small experiment with the probe firmware. Allowing
> 240.0.0.0/4 and 0.0.0.0/8 is a two line change. I tested
> I think the answer very much depends on who you ask.
with my researcher hat on, i am curious yellow. with a minor concern
for how much of the lab's resources it would consume.
with my operator hat on, kinda meh. the long tail of recalcitrant
devices is likely to be far too operationally
howdy
so i wanted info about a probe's config, specifically what dns
resolver(s) it is using. i could not figure out how to do this.
assuming it was a lack of clueons, i asked a friend with far deeper
atlas fu. they said such queries are not available. really?
[ yes we have bright ideas on
> Another way is to setup a script listening at measurement id
> 7000. This logs all the probes connection/disconnection to RIPE
> controllers.
does that not put a disproportionate load on central servers just to
tell me if my one probe is up or down?
randy
i have a few dead v1s. but they are a kkm away, where we would have
to send remote hands in :(
randy
hi anurag
> Eventually found that issue was with the Ubnt edgerouter which used
> tweaked VyOS and in their latest version 2.0.8 it was breaking the
> secondary routing tables running on the device after every 4-5 days of
> uptime.
lovely
in this case, it is a pretty stable (seming) openwrt on
i keep getting these
> Your probe 2285 has been disconnected from the RIPE Atlas
> infrastructure since 2020-03-18 06:43:44 UTC.
status shows it down
but i can ping6 the probe, and from the local gateway, i can ping4
it's natted address
psg.com:/usr/home/randy> ping6
> To be fair the v1 and v2 (ID<=5000) are 9+ years old tiny embedded
> devices
ageist!!!
if someone wants to compare, 4981 (a lovable old v1), 104, and
106 are on the same lan segment in the same pop with the same vrrp
exit etc.
randy
why do a number of my probes, e.g. 4959 and 4981, show all the built-ins
as Latest data point shown is from 2019-08-15 07:05 UTC or whatever?
randy
been using LE+TLSA for a lng time. like 94 of us, i have recipies
(for LE for sites w/o web services) if you need them. please do it.
it's prudent.
randy
> Push everybody to do "https everywhere!" (why not? LE is free!), and
> of course for *real* security companies must have EV certs from "real"
> CAs... for heaps of money.
upcoming chrome and ffox will not green light ev
randy
> There is still too much money in the CA business.
well, though on the surface i agree, i do not take it as a motivation to
add one more chunk of sysadmin.
> Which is the reason why no major browser does TLSA validation.
well. there is the extra protocol turn. agl tried and backed off,
>> We've been looking at user-to-user connections, based on RIPE Atlas
>> measurements and ISP market share estimates provided by the APNIC.
> /// eyeball
btw, sorry to be picky. but those apnic data are mislabeled too often.
the article is a nice piece. an intuitive
> All of my RIPE Atlas measurement requests (pings in this case) are
> suddenly failing with a status "title" field value "Forbidden". Why is
> this happening?
you might get a better answer if you identified the experiment
randy
For now I have manually set the location of the probe to the last
known location of the ship.
thanks. i think :)
randy
> doesnt the ship have sat internet and wired cat5 to the countainer
> with usb power from solar battery :)
look at the picture again. can you say "funky?" i just hope they do
not drop the container containing our stuff.
randy
hi chris,
>> i have a probe, 2283, which has unplugged from its old home and is in
>> suspended animation in a suitcase until it reaches its new home in a
>> month or two.
>
> There's nothing you have to do when a probe is down; it is automatically
> marked as disconnected almost immediately, and
i have a probe, 2283, which has unplugged from its old home and is in
suspended animation in a suitcase until it reaches its new home in a
month or two.
the location map will not let me pur it in the middle of the pacific.
and i can not see how to mark it as dormant/down. clue bat please.
randy
ok, it is pretty cool. many creds.
is there an api to which, for example, nlring folk could hook
ring-trace?
randy, always making trouble
>>> It was recently called to our attention that certain emails we send
>>> out to RIPE Atlas probe hosts, concerning probe connection issues,
>>> have been somewhat abrupt in their tone. We are working to address the
>>> issue.
>>
>> the mind boggles
>>
> Randy, have you never had the one that
> It’s way easier for me to spin up 25 virtual probes than 25 physical
> ones :)
it is even easier to spin up 1,000 prngs
where do i file a feature requenst for anchors with ipv6 to display
"connectivity may suck?"
randy
> 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
> Computing power is totally unimportant as compared to reproduceability
> of a given measurement on a given probe.
100% with you there.
but, for example, is fetching a dane tlsa or a browser cert gonna be
bothered by the kinds of things which vms do to us? the problem with
this path is that we
> I think there is no lack of "interesting platforms to host a VM", but
> the point of the discussion was "virtualizing measurements leads to
> unreliable results as you do not control the hardware well enough" - and
> for that reason, I'd strongly discourage *any* sort of VM solution.
i
> It was mostly of a matter of that there was no obvious NTP measurement
> for a built-in and nobody expressed a strong desire to have one.
no one expected ntp to become popular
no one expected the spanish inquisition :)
randy
> who is a power user?
i don't think it is productive to go down this path
randy
who is a power user?
>>> i don't think it is productive to go down this path
>> randy, you read my mind
>
> You mean not productive trying to place the blame, or not productive
> to have shady anonymous "power users" being arbitrarily and
> behind-the-scenes granted the whole atlas
58 matches
Mail list logo
