Re: [atlas] Probe question - Issue

On 2015/06/23 8:38 , Daniel Karrenberg wrote: I can tell you that the USB Flash only stores results, the OS is on the internal flash and that the most common problem is insufficient or unstable USB power to the unit. I hope this helps until the pros arrive at the office. Hi, It is a

Re: [atlas] LLDP / LLDP-MED support?

Hi Pekka, It is not clear what you want out of LLDP. RIPE Atlas probes should minimize the amount of data they collect about the local network. So most of LLDP seems irrelevant to probes. There is also something about VLANs. But I prefer to keep probes on untagged ethernets. Network

Re: [atlas] Case sensitive DNS queries from the probe

On 2015/07/29 15:13 , Yang Yu wrote: Looking through DNS queries log I saw tons of queries from the probe for case sensitive names. Can someone please enlighten me what the possible use cases are? query: wWw.FacebOOK.COm IN A Many years ago there was a proposal for stub resolvers to

Re: [atlas] [UDM] Consistency in the timeout parameter

Hi Stephane, I guess the answer is that it isn't requested often enough. For ping, we have a ticket somewhere to add it. For DNS I can't remember anyone talking out it. Do you have a specific use case? Philip

Re: [atlas] Dead probes

On 2015/10/22 23:30 , Marty Strong wrote: > I've got 1 or 2 dead probes, they power on but I see no mac address from > them. They have the first 2 lights on, but none of the others. > > I don't see this combination listed > on >

Re: [atlas] ntp built-in measurements?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2015/10/29 16:12 , Bajpai, Vaibhav wrote: > Do the probes not run (new) NTP measurements as built-in > measurements? — I was glancing over the measurement data pushed by > my probe, but I do not see any NTP measurement data. Although, when > I

Re: [atlas] Dead probes - slightly OT

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2015/10/28 17:50 , Gert Doering wrote: > On Wed, Oct 28, 2015 at 05:30:49PM +0100, Wilfried Woeber wrote: >> This seems to imply that the probes can bootstrap (off the 'net?) >> without the USB stick present ? If this is the case, what is the >>

Re: [atlas] Feature request for IP record route feature in RIPE Atlas

On 2015/11/09 10:04 , Pavel Odintsov wrote: > But RIPE Atlas offer really huge coverage over the World and we could > reach really any host with <7 hops. But we haven't this feature in > RIPE Atlas. > > Finally with this feature we could build full adjacently map over all the > World. > > I

Re: [atlas] RIPE Atlas anchor self assembly

On 2015/11/10 16:56 , Colin Johnston wrote: > Can we have link to image so we can can convert to a VM image for hosting via > virtual instead :) > > maybe useful cost saving :) The image contains not much more than CentOS, a compiled version of the Atlas source code (which is published) and a

Re: [atlas] HTTP measurements at willing targets / protocol suggestion

On 2015/11/16 12:00 , Emil Stahl Pedersen wrote: > ​+1 ​ > Sounds like a perfect solution > ​ ​ Sounds like it is open for abuse. Someone registers evil.whatever, passes all validation checks and can then serve any content he likes. No way to find out who set it up.

Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)

On 2015/11/10 14:01 , Colin Johnston wrote: >> One way of looking at it, are the people who want a VM willing to >> guarantee that the VM performs better than the current Soekris boxes we >> use for anchors? And is there is way of monitoring that they live up to >> their promises. >> > A well

Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2015/11/10 14:05 , Gert Doering wrote: > Hi, > > On Tue, Nov 10, 2015 at 01:50:41PM +0100, Philip Homburg wrote: >> For ordinary probes, we have absolutely no control over the >> network. Probe hosts don't have to gua

Re: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops

On 2015/12/08 16:45 , Daniel Karrenberg wrote: > Real resolvers > - use caching, > - retry queries, > - can use all authoritative servers for a zone, > - perform recursion, and (again) > - use caching. > > The typical TTL for caching in the root zone is 48 hours. I

Re: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops

On 2015/12/08 17:08 , Daniel Karrenberg wrote: >> I wonder if in the case of local DNSSEC validating resolvers behind >> DNSSEC-unware resolvers in CPEs, this model is still valid. > > At the risk of turning this into another DNS discussion list: Why are > you wondering exactly? DNSSEC validating

Re: [atlas] Support for arbitrary DNS queries

On 2015/12/10 13:43 , Gil Bahat wrote: > what could be very interesting though, is to map DNS servers supporting > EDNS0 and ones not supporting it (i.e. which network operators should be > bugged to support it...). it would be very good for network operators to > see e.g. in-country adoption rate

Re: [atlas] Dead probes - slightly OT

On 2015/12/01 11:34 , Marty Strong wrote: > I have a dead probe that I've tried both waiting 10 minutes with the USB > stick out and placing a fresh USB stick in, but it still sits on what > looks like running from internal flash. > > Is there another method anybody knows that can bring this old

Re: [atlas] Ping option DF

On 2016/02/29 16:12 , dave wrote: > It seems atlas sends out ping with fragmentation allowed. Why is there no > option to enable DF? Hi Dave, As far as I know, there never was a request for such an option. Note that traceroute does have this option and if you the set the start hop high enough,

Re: [atlas] No Ethernet activity on new probe

On 2016/01/27 11:10 , Marat Khalili wrote: > Every time after the boot sequence ends first light glows steadily and > adjacent one blinks slowly, like it is supposed to be according to > https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean > . Looks like the interface

Re: [atlas] Local network checks

On 2016/04/11 13:54 , Gert Doering wrote: > Most likely it will need flash stick cyling. But you'll see that in the > SOS messages. > > (Repating myself, it would be *so* helpful if the mail "hey, your probe > is down!" actually included availble SOS diagnostics...) There is a project to try to

Re: [atlas] Probe not flagged as "IPv4 works"

On 2016/03/22 20:37 , gboonie wrote: > It is connected via a 4G LTE router. The router is up and everything > else works. I could just reboot the modem and the probe but I'm > wondering why it fails to get flagged with "IPv4 works". The "built in" > test seem to work fine. > > What could be the

Re: [atlas] USB drive more harmful than helpful?

On 2016/05/20 14:57 , Hank Nussbacher wrote: > Has anyone tested how many writes are going on to the ATLAS thumb > drive? Perhaps with all the failures within a year of start, perhaps > too many writes are taking place? We have no clear idea why they fail. It seems that time to failure is highly

Re: [atlas] SixXS issues

On 2016/05/11 10:07 , Rolf Sommerhalder wrote: > Just to make sure we are talking about the same v1 Probe #2922 which > sits at home (on a DOCSIS cable connection, behind a NAT firewall). > This is the one which had worked quite stable for months, even years, > also through the SixXs tunnel.

Re: [atlas] SixXS issues

Hi, On 2016/05/05 15:11 , Alison Wheeler wrote: > I received my second probe* yesterday (different ASNs) and it is connects via > SixXS for IPv6 as the ISP isn't supplying native v6 (despite repeatedly > asking when they will catch up on something around for twenty years!). It > booted fine

Re: [atlas] ping measurements and high lts

Hi, On 2016/05/09 23:06 , Clinton Work wrote: > When looking at the ping measurement json results I found some probes are > reporting a very high lts (last time synchronized). Is it normal for very > high lts values to be reported? > > These two anchors seem chronic: > Probe 6161, max lts

[atlas] New analysis of version 3 probes on RIPE Labs

with the complete analysis: https://labs.ripe.net/Members/philip_homburg/further-analysis-of-ripe-atlas-version-3-probe?pk_campaign=atlas_kwd=list-atlas We’ll continue looking into these issues, so stay tuned for future articles. Philip Homburg RIPE NCC

Re: [atlas] Probe reported as disconnected but is actually online

Hi, On 2016/08/04 14:18 , Colin Johnston wrote: > surely a fsck via the mini operating system, of the affected flash drive file > system should able to be attempted remotely before reinstall of new image ? The problem is that the mini operating system on the built-in flash doesn't notice that

Re: [atlas] Verbatim stick falled in read only

Hi Francesco, On 2016/08/04 14:23 , Francesco Molitierno wrote: > The verbatim stick of my probe seems falled in a read-only state, there > is something that i can try to fix? Unfortunately, when the USB stick is read-only it should be considered broken an has to be replaced. Any USB stick of 4

Re: [atlas] sometimes no RTT?

On 2016/07/08 14:27 , Alex Saroyan wrote: > Do you mean packet was returned later then timeout value ? > How long is timeout value then ? Yes, otherwise there would be a rtt value. The per packet timeout defaults to 4 seconds but can be set explicitly when the measurement is created. Philip

Re: [atlas] Incrementing LTS For probe 6106

On 2016/08/09 17:21 , Clinton Work wrote: > Probe 6106 has an LTS value of at least 187450 and it continues to grow. The code that manages the lts value does a consistency check with the time on the controller. The problem with the anchor is that the connection to the controller (in Amsterdam) is

Re: [atlas] traceroute measurement with abnormally small RTT

Hi, On 2017/01/18 18:01 , Wenqin SHAO wrote: > It’s a IPv4 traceroute measurement toward DNS b root, 192.228.79.201. > What you’ll see is: > starting from hop 14, the 3 measurements for the same hop come from > different IP address: > > hop 14: 184.105.80.202, 72.52.92.122 > hop 15:

Re: [atlas] meaning of error message in Ping measurements

Hi, > Could someone please help me figure out what these error messages in result > field of ping measurement mean? > - error: sendto failed: Invalid argument (related to name resolve?) > - error: sendto failed: Bad file descriptor These are errors returned by the sendto system call on the

Re: [atlas] Reconnecting probe 3508 - troubleshooting

On 2016/08/22 22:14 , Michael-John Turner wrote: > The reason why the probe was offline originally was that it stopped > accepting DHCPOFFERs for some reason, with the result that it would > continually send DHCPDISCOVERs every few seconds but never ACK an OFFER and > never connect properly to the

Re: [atlas] tp-link probev3 tl-mr3020

On 2016/11/25 13:27 , folkert wrote: > I have one of those tp-link probes, a v3 it looks like. > Now when I got it, I was warned to put it on a 1A powersource. Now that > is a bit of a problem so I started to measure its power usage to verify > if I could maybe run it on a smaller power supply. >

Re: [atlas] DNS over TCP problems?

On 2017/03/21 19:10 , Stephane Bortzmeyer wrote: > On Tue, Mar 21, 2017 at 05:57:15PM +0100, > Philip Homburg <philip.homb...@ripe.net> wrote > a message of 16 lines which said: > >> The patch is simply to delete the offending line and, if all goes well, >> wil

Re: [atlas] Failing probe, all lights blink

Hi Phillip, On 2017/03/07 0:41 , Phillip Remaker wrote: > A V3 probe, when powered on, lights the power light, and then blinks all > other lights for about a second every few seconds. Forever. If it does this without the USB stick then it is very likely that the probe is bricked. That can happen

Re: [atlas] DNS over TCP problems?

Hi Stephane, On 2017/03/21 17:25 , Stephane Bortzmeyer wrote: > According to DNSmon, there is indeed a problem since 14 March: > > https://atlas.ripe.net/dnsmon/group/fr.?dnsmon.session.color_range_pls=0-10-10-50-100=true=zone-servers=fr.=undefined=1488974400=1490112000=false=both=true

Re: [atlas] Link aggregation for anchors?

On 2017/07/20 7:44 , Tore Anderson wrote: > I'd rather you spent that time implementing LLDP support, come to think > of it. (That would be useful on the non-Anchor probes as well.) I have a ticket open for LLDP on regular probes. Though no time frame is assigned when it should be done. I assume

Re: [atlas] Many timeout-failures for DNS over TCP

On 2017/05/09 10:03 , Davey Song(宋林健) wrote: > I setup measurements for DNS queries over both TCP and UDP. I found the > timeout and failures of TCP is far more than UDP. > DNS over TCP: https://atlas.ripe.net/measurements/8552847/#!probes Hi, Unfortunately, due to a bug, DNS over

Re: [atlas] Probe does not request IPv4 address via DHCP

On 2017/06/23 16:34 , Stanish Stanishev wrote: > Thank you for the details. > Do I need to assist you somehow for finding the reason, why the automatic way > for providing the probe with literal did not happen ? Thanks for the offer. We already found the reason and this situation should now be

Re: [atlas] TLS tests with login.live.com

On 2017/05/29 14:02 , Stephane Bortzmeyer wrote: >> My guess is that the measurement code sends something the other side >> doesn't like and then the server responds with something the Atlas >> code doesn't understand. > > Any way to debug it in more detail? I guess the first step would be look

Re: [atlas] TLS tests with login.live.com

On 2017/05/29 13:53 , Stephane Bortzmeyer wrote: > On Mon, May 29, 2017 at 01:41:45PM +0200, > Stephane Bortzmeyer wrote > a message of 5 lines which said: > >> TLS tests from the Atlas probes work for me, for every server... *but* >> login.live.com, for which I always get

Re: [atlas] Probe does not request IPv4 address via DHCP

On 2017/06/13 14:07 , Stanish Stanishev wrote: > Ah, Thank you so much for the support. > May I ask you to share what did you do in order to make the probe connect > again to the Atlas ? Normally the probe receives the name of a controller to connect to. If the probe doesn't have access to DNS

Re: [atlas] Can Atlas probe handle Truncated response ?

On 2017/09/12 17:19 , Stephane Bortzmeyer wrote: > I don't think tou can ask for several tests. (Source: > ) There is a retry option hidden somewhere in the docs. "[dns] retry (integer): Number of times to retry," Philip

Re: [atlas] Recent TLS supported by probes?

Hi Stephane, On 2017/11/13 10:10 , Stephane Bortzmeyer wrote: > I cannot get the certificate for > (measurement #10174881): "alert" is "{u'description': 40, u'level': > 2}". > > It works with other, more "mainstream", HTTPS sites (see #10174883). I > suspect

Re: [atlas] Probe disconnects every 2 hours

Hi, Maybe you can mention your probe ID. That makes it easier to figure out what is going on. Philip

Re: [atlas] Effect of "Resolve on Probe"-option

On 2017/12/03 17:36 , Stephane Bortzmeyer wrote: > Atlas rejects 'use_probe_resolver': False if you did not specify a > target: > > Status 400, reason > "{"error":{"status":400,"errors":[{"source":{"pointer":"/definitions/0"},"detail":"`target` > cannot be null if `use_probe_resolver` is not >

Re: [atlas] Probe disconnects every 2 hours

On 2017/12/20 20:41 , Daniel AJ Sokolov wrote: > It is 1118. Your probe seems to reboot every two hours. V1 probes suffer from memory fragmentation, so when the ssh connection breaks, they often reboot. However I cannot find anything related to that in the logs. A reboot can be caused by a power

Re: [atlas] Running a probe behind a NAT66

On 2018/06/11 20:42 , Roman Mamedov wrote: > I fully expect that you didn't account for such a setup in the controller > infrastructure or possibly various "local IP is valid" checks and whatnot, but > why this used to work fine before? Has there been any change on your side in > April that would

Re: [atlas] IPv4 leading zeroes and weird interface behaviour

On 2017/10/25 23:16 , Peter J. Holzer wrote: > Possibly gethostbyname in the libc, but I haven't tested that. At least > interpreting numbers with leading zeroes as octal is traditional on > unix-like OSs (I probably first noticed that on Ultrix around 1990). I > don't know why anyone thought this

Re: [atlas] False positives on SSL check?

Hi Ruben, On 2018/01/31 13:46 , Ruben Herold wrote: > I tried to monitor on of our services running on https://login.afterbuy.de. > I configured an SSL check like (Meassure ID #11090260). All probes response > with: > > Error: timeout reading hello > > But the service is online and

Re: [atlas] DNS measurement using the Probe's resolvers

On 2018/07/06 22:30 , Rami Al-Dalky wrote: > I have a question about using the probe's list of resolvers when > creating a DNS measurement. It is unclear to me whether the probe would > send the query to all resolvers at the same time or not! Also, does the > probe send the query to all resolvers

Re: [atlas] TLS error when the certificate is expired?

On 2018/04/15 15:33 , Stephane Bortzmeyer wrote: > I'm reasonably certain that it has been possible to use 'sslcert' > measurements even when the certificate is expired. > > Today, I try to use 'sslcert' with trigger-happy.eu and it fails: > > "alert": { > "description": 40, >

Re: [atlas] Probe firmware source code

On 2019/01/13 16:41 , Evgeniy S. wrote: > thank you for helping I overlooked that information on website and > Github repository.  > > Btw, I see some discrepancy there (which can be improved): > 1) commit to Gihub repository - last was Jun 14, 2018; > 2) listed firmware (last 4790 from Jun 27

Re: [atlas] Long response times using one-off measurements with old probes

On 2018/12/14 15:03 , Moritz Muller wrote: > Some small additional delays have been documented before on the RIPE Atlas > website and in research papers [1, 2], but the big delay with one off > measurements was new to me. > > Also to others? Is our assumption correct that the scheduler is the

Re: [atlas] shared fate for my two probes

On 2018/11/16 22:16 , Jay Borkenhagen wrote: > probe 11171 2018-11-16 14:42:28 UTC. > probe 11203 2018-11-16 14:42:33 UTC. Both probes lost all internet connectivity for a couple of hours. I have no idea what happened but Atlas traceroutes stop at hop 1 (and don't even reach the local router).

Re: [atlas] shared fate for my two probes

On 2018/11/19 17:53 , Jay Borkenhagen wrote: > Philip Homburg writes: > > On 2018/11/16 22:16 , Jay Borkenhagen wrote: > > > > > probe 11171 2018-11-16 14:42:28 UTC. > > > probe 11203 2018-11-16 14:42:33 UTC. > > > > Both probes lost all i

Re: [atlas] EDNS Client Subnet

On 2019/01/28 14:33 , Rami Al-Dalky wrote: > When I tried to create a DNS measurement, I found that the only way to > send DNS query with option is to set default_client_subnet to True. > However, by setting this option, a DNS query will be sent with 0.0.0.0/0 > as client

[atlas] Issue with RIPE Atlas HTTP measurements

We recently discovered an issue with RIPE Atlas HTTP measurements. In trying to fix an issue that caused the HTTP body size to be reported incorrectly, we inadvertently introduced a bug that prevents the measurement from working under certain conditions. This bug affects firmware release 4940 and

Re: [atlas] Probe not coming online anymore after firmware upgrade

On 2019/03/21 16:41 , Annika Wickert wrote: > I bought a new USB Stick for this probe as the old one was tagged as > readonly etc.. > https://atlas.ripe.net/probes/23913/ > > But for some reason it is not coming online at all . > > Any idea what could be the issue? I also see no network traffic at

Re: [atlas] New on RIPE Labs: RIPE Atlas Probes: Delays in Distribution

On 2019/02/08 13:45 , Micha Bailey wrote: > Interesting. This seems like a much higher power device. What are the > actual power requirements? So far my probe has been powered from the USB > port on the router, and I’m concerned that this may make the > installation of future probes more

Re: [atlas] Probe v1 disconnecting every 2 hours

On 2019/01/30 19:49 , Cornelius Keck wrote: > I'm wondering, in case the probe continues to have issues, is there a > way to get a replacement? Yes, you can always ask for a replacement. We are still quite a bit behind in shipping probes because the transition from v3 to v4 probes was quite a bit

[atlas] Bug in DNS client subnet measurement

Hi, We got a bug report that using the DNS client subnet option in a measurement results in a form error. It turns out that probe firmware version 4940 will send a malformed DNS query. Code cleanup related to other changes fixes this issue in the upcoming firmware. We expect to release the new

Re: [atlas] DNS-over-TLS and DNS-over-HTTPS measurement

On 2019/04/08 17:04 , Petr Špaček wrote: > Anyway, are there plans for supporting DNS-over-HTTPS? Hi Petr, A couple of years ago we created a policy regarding HTTP measurements on RIPE Atlas. The concern was that probe hosts located in certain countries could get into trouble should their probes

[atlas] Measurement result issues for some RIPE Atlas anchors

In April, we started investigating a strange traceroute result reported by one of the RIPE Atlas anchors. The conclusion of our investigation is that the probe upgrade process for the v3 anchor firmware has been leaving old measurement daemons running as well as starting new ones. This means that

Re: [atlas] Feature Request to consider: DNS response IP header

On 2019/05/30 15:22 , Ponikierski, Grzegorz wrote: > Can be useful to estimate proximity between probe and DNS and to detect > nasty middle boxes. To limit overhead on Atlas side, IP header can be > provided as raw data to decode on end-user side. As far as I know there is no option provided by

Re: [atlas] Probe off-line for 6 days due to bad firmware signature

On 2019/06/24 17:54 , Novak Jirka wrote: > My probe is connected to my network infrastracture again, but not > connected to RIPE ATLAS infrastracture > > Could you help me now? Your probe is now fully connected. Philip

Re: [atlas] Probe off-line for 6 days due to bad firmware signature

On 2019/06/19 18:38 , Novak Jirka wrote: > my probe 22424 is off-line due to bad firmware signature error. > I try to boot it without USB stick many times, then i change the USB > stick (replace the old one with new one), but it doesnt solve my problem. > Could you help me? Hi, A bad firmware

Re: [atlas] DNS RTT over TCP: twice as long than UDP?

On 2019/07/05 14:33 , Giovane Moura wrote: > https://atlas.ripe.net/results/maps/root-server-performance/ > > By definition, however, RTT is "the length of time it takes for a > signal to be sent plus the length of time it takes for an > acknowledgement of that signal to be received."[2]. So if

Re: [atlas] All our atlas probes have reverted to DHCP

On 2019/04/17 8:52 , Sebastian Wiesinger wrote: > all of our four atlas probes have reverted from their fixed network > configuration to DHCP which is a shame because there is no DHCP at > their present locations. Also this not the first time it happend. Can > someone explain why this happens and

Re: [atlas] DNS issue with Atlas or with the ISP?

On 2019/09/09 9:39 , Stephane Bortzmeyer wrote: > So, people have tested, and confirm that 1) this ISP advertises > link-local address via RA 2) it works with all DNS clients, but the > RIPE Atlas probes. Any idea? I just tried a bare link local address with dig on FreeBSD and it failed. For some

Re: [atlas] RIPE Atlas Software Probes

On 2020/02/12 12:42 , Philip Homburg wrote: > On 2020/02/12 12:03 , Paul Eagles wrote: > >> fatal: reference is not a tree: 0615d3803b7b68cf85f959957b433f1c9fe2f3e6 >> Unable to checkout '0615d3803b7b68cf85f959957b433f1c9fe2f3e6' in submodule >> path 'probe-busy

Re: [atlas] RIPE Atlas Software Probes

On 2020/02/12 12:03 , Paul Eagles wrote: > fatal: reference is not a tree: 0615d3803b7b68cf85f959957b433f1c9fe2f3e6 > Unable to checkout '0615d3803b7b68cf85f959957b433f1c9fe2f3e6' in submodule > path 'probe-busybox' > [pauleagles@dns2 ~]$ Weird. It seems that the two repos are out of sync. I'll

[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

Re: [atlas] RIPE Atlas Software Probes

On 2020/02/12 11:11 , Borja Marcos wrote: > I am wondering, is the RIPE Atlas probe software fully Linux centric or can > it run > on other modern *IX derviatives? The sort answer is yes, it is fully Linux centric. The longer answer is that the code consists of two parts. One part is a

Re: [atlas] RIPE Atlas Software Probes

On 2020/03/04 11:14 , Enrico Ardizzoni wrote: > This is the "prerm" script ( a little bit overkill :) ) I'm not an expert in debian packaging. Does the prerm get executed during an upgrade? What I remember is that upgrading the debian package works, but maybe I remember wrong. Philip

Re: [atlas] RIPE Atlas Software Probes

On 2020/03/04 11:14 , Enrico Ardizzoni wrote: > This is the "prerm" script ( a little bit overkill :) ) I pushed v5010.3 which fixes the prerm script. Unfortuantely, during an upgrade it runs the old script, so upgrading to 5010-3 will still remove the keys. Philip

Re: [atlas] RIPE Atlas Software Probes

On 2020/02/16 16:23 , Jacques Lavignotte wrote: > *Connection & Traffic* is firmly showing *No data available for Probe # > 1000165 for this time period* since start. > > Do I have something to do more ? Hi, There are two issues: The first is that by default, the software probe does not report

Re: [atlas] check dns64/nat64 behavior ?

On 2020/02/21 14:50 , Thomas Schäfer wrote: > Am 21.02.20 um 14:38 schrieb Thomas Schäfer: >> Hi, >> >> is there a simple way to check the reachability of IPv6 targets by >> probes behind NAT64? > > IPv4 targets of course. On NAT64, an IPv4 address is accessed over IPv6. You do need to disable

Re: [atlas] RIPE Atlas Software Probes

On 2020/02/14 10:50 , Jaap Akkerhuis wrote: > When the software probe projects started I offered to make a FreeBSD > port version. The developers said that that was a good idea and > they would come back to me. A FreeBSD port would be nice, but may be a significant amount of work. Philip

Re: [atlas] Software probes offline since updating to 5010-3

On 2020/03/11 13:54 , Paul Eagles wrote: > About an hour ago I updated my 4 software probes (1000136, 1000137, > 1000149 & 1000177) to 5010-3 from 5010-1 and they’re all still showing > as offline.  For each probe I went through and updated the keys within a > minute or so of the installation

[atlas] New on RIPE Labs: What’s the Deal with IPv6 Link-Local Addresses?

-with-ipv6-link-local-addresses We think this will be an interesting read for network operators and others who are using RIPE Atlas measurement data or are interested in IPv6. Kind regards, Philip Homburg RIPE NCC

[atlas] Broken traffic graphs in latest firmware (5010)

Hi, A change in the RIPE Atlas probe code to make reporting traffic statistics optional in software probes (and disabled by default) has the unfortunate side-effect that reporting of traffic statistics is now disabled on Version 3 and Version 4 hardware probes, as well as all anchors. This change

Re: [atlas] Setting the DNS AD bit

On 2020/04/15 8:58 , Stephane Bortzmeyer wrote: > It seems there is currently no way to set the AD bit in DNS queries? > (Through the API, we can only control RD, CD and DO bits.) Hi Stephane, That sounds like a useful addition. I'll put it on the list of things to implement. Philip

Re: [atlas] Software probe using port 8080

On 2020/03/13 13:48 , Paul Eagles wrote: > Is there any way to change the ports that the software probes use?  Port > 8080 is used by the probe which conflicts with another piece of software > I wanted to use. Unfortunately, that is not possible at the moment. I'll look into making this more

Re: [atlas] status-check redirects to itself?

On 2020/04/29 19:58 , Stephane Bortzmeyer wrote: > Since today, status-check seems to redirect to itself? > > % curl -v > https://atlas.ripe.net/api/v2/measurements/2060427/status-check\?permitted_total_alerts=3 > < Location: >

Re: [atlas] Probe 2177 disconnected since Tuesday

On 2020/03/20 11:38 , Werner Wiethege wrote: > I didn't see any ARP requests. So I order a new probe? Yes, that's best. Philip

Re: [atlas] Probe 2177 disconnected since Tuesday

On 2020/03/20 11:14 , Werner Wiethege wrote: > No change. The orange light flickers when the switch handles > broadcasts. The orange light is just ethernet traffic. If the probe never transmits anything then the probe is probably broken. Because the probe has static address configuration, it

Re: [atlas] Feature request DNS DoH measurement

On 2020/05/20 22:00 , Yang Yu wrote: > As DoH is getting more adoption, it would be interesting to have DoH > query support on Atlas. With support added as an additional protocol > for DNS measurement (currently TCP/UDP), most measurement > creation/result parsing settings can be reused. >From a

Re: [atlas] Feature request DNS DoH measurement

On 2020/05/23 8:35 , Dave . wrote: > Would it be possible for your servers to first verify whether a DOH > address is really a DNS before running actual atlas tests? If you can do > it from an IP address that also hosts a web page that explains the > purpose of the test, anyone investigating

Re: [atlas] RIPE Atlas Software Probes and Ubuntu 20.04 / glibc 2.31

Hi Bernd, On 2020/05/24 13:04 , Bernd Strehhuber wrote: > with newer Linux Dists / glibc Versions (tested on Ubuntu 20.04 LTS) > stime() has been deprecated and replaced with clock_settime(). > Busybox got the following commit back in 11/2019: > >

Re: [atlas] probe offline/lock up

On 2020/07/05 19:55 , Bryan Fields wrote: > Is this normal or is there a problem with my probe? I've never really taken > this close of a look before, I'm unsure if it has an issue or if this is > normal. Do you see any ARP request coming from the probe? It seems that the probe cannot reach

Re: [atlas] RIPE Atlas Software Probes and Ubuntu 20.04 / glibc 2.31

On 2020/05/24 13:04 , Bernd Strehhuber wrote: > with newer Linux Dists / glibc Versions (tested on Ubuntu 20.04 LTS) > stime() has been deprecated and replaced with clock_settime(). > Busybox got the following commit back in 11/2019: > >

Re: [atlas] dead v1 probe

On 2020/06/03 21:08 , Wilfried Wöber wrote: > As I do not have a static machine there, just a laptop which goes with me > onto the road, my Q is: what is the cheapest / recommended / smallest piece > of hardware which can support a software probe? Any pointers for more info? The debian version of

Re: [atlas] dead v1 probe

On 2020/06/02 20:28 , Gert Doering wrote: > have there been software updates for v1 probes recently? I've heard > about a few v1 probes that have died "just last week" - mine among > them (#461), fell off the net with "Firewall Problems Suspected", > but it's no longer even ARPing properly (=

Re: [atlas] DoH / DoT test in Atlas Probes

On 2020/10/29 15:28 , Imre Tuskes wrote: > Hello, > Is there any plan to measure DNS over HTTPs (or TLS). > We are interested in the performance of this kind of service. > Regards, Imre   DNS over TLS is available today. DNS over HTTPS require new code, in particular because HTTPS should be

Re: [atlas] Automating software probe creation?

On 2021/01/02 8:25 , Steve Gibbard wrote: As far as I can tell from the documentation, it looks like the probes are identified by the encryption keys in /var/atlas-probe/etc/probe-key* . If creating new probes from an image, is it sufficient to make each probe generate its own encryption

Re: [atlas] atlas probe down : ID 35603

On 2021/01/29 14:34 , MAYER Hans wrote: But when I go to https://atlas.ripe.net/probes/35603/   I see it is offline. The web page says „no flash drive“ and „trying to connect“. On the page https://atlas.ripe.net/probes/35603/#tab-network at the bottom it

Re: [atlas] atlas probe down : ID 35603

On 2021/02/03 11:53 , MAYER Hans wrote: many thanks for your response. This I didn’t see, even if it is listed several times. So will I try a third USB stick. Is there a recommended size ? Is 64 GB too big ? And what if this will not help too ? Due to covid-19 I am working from home most of the

Re: [atlas] Getting RRSIG records when do bit is set

On 2021/07/06 16:18 , pravicha wrote: The measurement ID is 31426231. I query for DNSKEY records, have the do bit set in this and yet don’t get back the RRSIGs. Hi, DNSSEC OK flag is false in this measurement. See https://atlas.ripe.net/measurements/31426231/#general and then 'DNS Specific

Re: [atlas] Getting RRSIG records when do bit is set

On 2021/07/06 17:21 , pravicha wrote: This is another measurement, which has the do bit set, 31426253. This one does indeed have the DO flag set. Where it goes wrong is that Atlas DNS measurements default to a UDP buffer size of 512 octets. The result that comes back is truncated. In

  1   2   >