[atlas] Tomhais STARTTLS: Cad a tharla?
Back in December 2022, there was a proposal to support STARTTLS measurements. (https://www.ripe.net/ripe/mail/archives/ripe-atlas/2022-December/005234.html) I wonder, whether this proposal was implemented ? I've just tried using the measurement definition form (https://atlas.ripe.net/measurements/form/), where the only TLS-related option seems to need the target to be ready to receive a client hello. /Niall -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Probe with ever changing upstreams/ASs?
On 3 Aug 2023, at 18:53, Robert Kisteleki wrote: > At the end of the day, measurements involving this probe would give varying > results depending on time. It's totally real, but is it useful? Hmm. If Carsten (or anyone else who may wish to offer a bit of [] bandwidth to "the world") would find it useful to know something about the availability and performance of their Freifunk "contribution", then that would answer the question, at least from one POV. OTOH, people running measurements may find it frustrates their intent. Would a new system tag, automagically added when systematic AS-hopping is observed, make sense? Dunno really. €0,02 Niall PS. "Ceci, c'est peut-être du n'importe-quoi" is so much more elegant than "Maybe this is just b-ll-x." 8-) /N -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Probe DHCPv6 support
On 15 May 2023, at 19:57, Simon Brandt via ripe-atlas wrote: > As far is i can see, you can only use OpenWrt in DHCPv4 client mode _OR_ in > DHCPv6 client mode. IIUC, this is true per interface, but it's possible to configure more than one interface on a single hardware device. The WAN link on my Turris Omnia uses both DHCPv4 and DHCPv6 (IA-PD). Here's how the good folks at NIC.CZ configured that: config interface 'wan' option proto 'dhcp' option ipv6 '1' option device 'eth2' config interface 'wan6' option proto 'dhcpv6' option noserverunicast '1' option device 'eth2' For IA-NA, I don't know what needs to be changed. lgdg, /Niall -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Shiny new v5 probe reveals problem with virtual probe
On 1 Dec 2022, at 9:50, Michel Stam wrote: FYI he v5 is basically a modified Turris Mox. You’re getting a nice Turris collection there :) Truly! World domination from Prague. 8-) IPv6 works is a tag that is added based on the result of a few measurements, see here: https://atlas.ripe.net/docs/getting-started/probe-tags.html#basic-connectivity Hope this helps Yes, thanks; it seems that each unit performs an IPv6 ping test. I'm puzzled as to why only one is successful, as their physical connections are adjacent. Time for some head-scratching ... /Niall -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] Shiny new v5 probe reveals problem with virtual probe
Hello, everyone. TL; DR: clue needed configuring Turris Omnia for virtual Atlas probe. I'm delighted to have a shiny new v5 probe, which is operation since the day before yesterday. The new probe has been automatically tagged "IPv6 Works". On account of this, I've noticed that my virtual probe, running on my Turris Omnia, has the complementary tag, "IPv6 Doesn't Work." I suspect that I've not configured firewalling on my Turris properly. If any of you have sorted this, I would appreciate some clue. Thanks in anticipation. Niall -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Tagging probes which are using the ISP's DNS server?
On 10 Oct 2022, at 13:42, Robert Kisteleki wrote: Here's a quick-and-dirty answer to this: what the tags could look like if we applied them. This is about the ~12K connected probes, which collectively have ~23K resolver entries. Note: in this experiment the "more specific tags win", i.e. if quad1 is applied, then outside-asn tag is not. Thanks for this quick and useful report, Robert. What I take from it is that - (a) for most of the categories of interest, the one which (most closely) matches a given probe may readily be determined, and - (b) only one category seems ambiguous with regard to Max's original question, since "inside ASN" doesn't necessarily correspond to "using the ISP's DNS server". I'm wondering whether this ambiguity matters in the context of Max's question, and reckon that his opinion on this is a significant one. For my own network, I have always the option of reconfiguring to use ULA/RFC1918 (both private) instead of GLA/RFC1918 (inside-ASN/private). Thanks again, Niall (hat off) -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] V5 probes
On 6 Oct 2022, at 11:11, Daniel AJ Sokolov wrote: > That's pretty cool! +1 > So my v1 is not that rare, given there are still some 440 connected. -1; mine died ... Niall -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Tagging probes which are using the ISP's DNS server?
On 6 Oct 2022, at 13:32, Simon Brandt via ripe-atlas wrote: If the distinction isn't to difficult to implement, I would prefer these three types as system tags: Inside-AS DNS Outside-AS DNS RFC1918 DNS At least these are necessary, but I'm not sure that they are sufficient. For example, "Inside-AS" masks the distinction between on-site and ISP-provided resolvers, which are distinct on my domestic network (RFC1918 + GLA) and still (I believe) on the campus network where I once had a day job (Gv4 + GLA). Apart from that, should there be separate tags for RFC1918 and ULA? €0,02 Niall -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] swapping a v1 for a v3
On 10 Dec 2021, at 0:37, Randy Bush wrote: > 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. :) I’m not laughing! 8-) I know that the kind of administrative trick you suggest is possible, at least for software probes. I discovered this when, during a Turris OS upgrade, I “lost” such a probe. 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. /Niall
