[atlas] Re: Probe v3 id #22785 - BADMD-APP

>After sitting there for a long time with an USB drive the probe returned >to live, it has been online for the past 7 hours and 30 minutes. > >Is it possible that this was somehow related to some server side issue? >I'm seeing other similar reports from at least one other probe. This typically h

Re: [atlas] Invalid JSON because of DNS TXT records

Hi Stephane, On 2015/05/15 6:50 , Stephane Bortzmeyer wrote: > The DNS, as we know, is a jungle. People put anything in their TXT > records, even control characters. > > Atlas faithfully returns this content in the JSON files (see > measurement #2004707). Then they are no longer legal JSON (RFC 7

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 i

Re: [atlas] Probe question - Issue

On 2015/06/23 14:06 , Daniel Karrenberg wrote: > Ah, nobody tells me anything anymore around here ;-). > So does this mean you can no longer just change the USB stick anymore > like you used to? This behavior is unchanged since the v3 probes were first introduced. Assuming no static network confi

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 configuration

[atlas] Upcoming change to DNS IN/TXT query result

Hi, This is to inform you about a change in a future release of the RIPE Atlas firmware that changes how 'IN TXT' records get decoded in DNS measurements. Currently, the JSON generated by the probe for TXT query looks like this: { "fw" : -1 , "time" : 1436282373 , "lts" : -1 , "name" : "stereo.hq

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 p

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] [UDM] Consistency in the timeout parameter

On 2015/07/31 12:10 , Stephane Bortzmeyer wrote: >> Do you have a specific use case? > > Yes, today, tools.ietf.org has a DNS problem and the majority of the > probes do not send back an answer in time (those who do return > SERVFAIL). I wanted to increase the timeout. I also noticed some issue w

Re: [atlas] Your RIPE Atlas Probe (ID: 17523) is not connected to our network

Hi Joachim, On 2015/08/04 19:15 , Joachim Tingvold wrote: > Having some issues getting my probe to work in an v6-only environment. > > Doing only SLAAC (and no v4) made it unable to connect (which makes > kinda sense). Made it connect temporarily via v4 so that I could set > static v6-address and

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

Hi Wilfried, On 2015/08/06 12:44 , Wilfried Woeber wrote: > Is there any intelligence available about the percentage (or type) of > responders > answering with the "correct" camel case? I'm running measurement 1666409 which asks for 'WwW.rIpE.nEt.'. In addition it sets the DO flag. Looking at a

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

On 2015/08/06 14:43 , Fearghas Mckay wrote: > Is there a process to tell probe owners that they have issues like that ? For the DNS issue, we have a system tag 'Resolver Mangles Case'. But that depends on the probe host looking at the probe page. It is not clear when and how often we should mail

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

On 2015/08/06 16:56 , Colin Johnston wrote: > would be great to have this info, happy to help to debug problems with dns > connectivity if my isp is affected as well on mass scale, i hope not :) You should be able to get a list of probes that mangle case in DNS from the probe archive API. https:/

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

Hi Wilfried, Quick mental counting suggests that there are 3 different options: 1) if resolve-on-probe is not set, the target is resolved by the Atlas backend and the probe only gets the IP address. The (glibc) stub resolver on CentOS does not do any case mangling. 2) if resolve-on-probe is set th

Re: [atlas] Friday's events on RIPE Atlas

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2015/09/23 10:22 , Gert Doering wrote: > I have always understood that if you need "more resources than > your credits allowed", you could talk to the atlas team, explain > your needs, and find a solution - so it seems this is what was > done, as

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 > https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-

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 >> U

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 tr

Re: [atlas] ntp built-in measurements?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2015/11/03 11:55 , Bajpai, Vaibhav wrote: > I do see your NTP measurements, but I suppose these are UDMs > provisioned by your user account, no? — I somehow had the > impression that the NTP measurements would also be running on my > probe as buil

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 have

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

On 2015/11/10 13:36 , Colin Johnston wrote: > After having lived and still work in a Solaris physical metal land, I took > onboard the virtual machine world for a webservice/emailservice. > The virtual world is cheaper in long run. > However does require a vm/ov image. > > I think it is important

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 manag

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 t

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 bu

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] Measurements delete and ping issue

On 2015/11/30 15:42 , Andrea Consadori wrote: > Another issue i see, if i create a ping measurement (id 3034899 > ) under probes i see RTT > column unreachable for every raw... but the public ip is pingable form > everywhere.. Hi Andrea, Just commenti

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 p

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 w

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 10:11 , Willem Toorop wrote: > And sending arbitrary EDNS0 options? Have you ever considered that too? > Is it on the todo list too? Hi Willem, Just about all EDNS0 options take parameters. It is not part of the model to allow users to inject arbitrary binary data. Though if there

Re: [atlas] Support for arbitrary DNS queries

On 2015/12/10 13:33 , Jared Mauch wrote: > client-subnet? :) I can add an option to send 0/0 as the client subnet :-)

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] Availability report accuracy

On 2016/01/02 18:27 , Lorenzo Colitti wrote: > mostly out of curiosity: what sort of accuracy are the numbers in the > monthly availability report? For example: the report says that my probe > was "connected" 99.95% of the time (down for 20 seconds) in December. > > What does that mean? That the S

Re: [atlas] Availability report accuracy

On 2016/01/02 18:57 , Gerhard Joch wrote: > I want to jump into this topic too, but before a Happy New Year to > everybody. > > Was wondering too, for December my probe got an total availability of > only 98.17% - and which is in fact not true. I'm on a VDSL line 50 mbit > from German Telekom, and

Re: [atlas] What is 'iwantbcp38compliancetesting' user tag?

On 2016/01/09 16:30 , Geert Jan de Groot wrote: > On Sat, 9 Jan 2016 16:06:26 +0100 Stephane Bortzmeyer wrote: >> Geert said it was *his* probe so I assume he did not set the tag. > > I set the tag because it was listed as user tag; it was not a field > whose name I created myself. It wasn't ther

Re: [atlas] integrity checks for the Atlas software?

On 2016/01/12 12:48 , Wilfried Woeber wrote: > While thinking about options or mechanisms to make virtual probes > "tamper-proof" > I had this question coming up: > > Is the probe software capable to "verify" (check-sum or digital sig) the > bootstrap > kit and then, during run-time, verify that

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] 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] 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 is

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

On 2016/03/23 19:25 , gboonie wrote: > A powercycle did not help. I did a reboot without USB stick and formated > it in my laptop. Then plugged it back and after some minutes it started > working again. > > Some googeling showed that the stick can be replaced by a 4GB stick but > the one that it c

Re: [atlas] USB drive

Hi Michael, > but on further inspections do not contain a valid magic number in their > superblocks, so they are effectively unformatted. I would therefore suspect > that they are not being used by the probe. > > Now the question: > What is the correct layout supposed to look like (primary/sec

Re: [atlas] Flow-id of built-in traceroute measurement

Hi, On 2016/04/05 20:53 , Wenqin SHAO wrote: > I have some questions concerning the flow-id of built-in traceroute > measurements and are seeking for your help. > > As many of you may have already noticed, the flow-id of the built-in > traceroute measurement periodically varies form 0 to 15, in

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] Local network checks

On 2016/04/11 13:49 , Alison Wheeler wrote: > Sadly, there was nothing in there to indicate a problem, other than no > records: > > 74.125.47.144 2016-04-07 18:57:44 A 0h 1m > 74.125.47.140 2016-04-07 18:57:44 0h 1m > 2a00:1450:400c:c08::116 2016-

Re: [atlas] Local network checks

On 2016/04/11 14:39 , Gert Doering wrote: > While that is an improvement, actually having diagnostic info in the > *mails* sent (especially about "we're having USB troubles, so better bring > a fresh USB stick with you before you drive out to the probe site!") would > be even better. > > The reaso

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

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 and

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. Someth

Re: [atlas] probe congestion?

On 2016/05/11 13:13 , Paul Vlaar wrote: > This seems like a bug to me. The time between scheduling one-off > measurements using the same probe is of influence on the RTT? How can I > trust the RTT at all now? What if others are using the same probe at the > same time? Statistically speaking the pr

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

On 2016/05/20 14:37 , Michael Ionescu wrote: > If the main reason for the drive is to cache data during unavailability > of the command and control center, this may not be worth the effort. No, the probe actually runs from the USB stick. The internal 4MB flash is just enough to initialize the USB

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] USB drive more harmful than helpful?

On 2016/05/21 21:32 , Hank Nussbacher wrote: > On 20/05/2016 22:08, Phillip Remaker wrote: >> I don't suppose RIPE buys enough USB sticks to get to talk to >> engineers at SanDISK? >> > Sandisk R&D is located in Israel: > http://www.globes.co.il/en/article-sandisk-acquisition-affects-650-israeli-em

Re: [atlas] sometimes no RTT?

Hi, On 2016/07/08 11:38 , Antranig Vartanian wrote: > I'm new to RIPE Atlas, and right now using it for educational purposes > :)) lately I've seen that some of my traceroute measurements do not have > RTT. although it's not completely ignored by the hop (I get the data > like from, size, ttl), bu

Re: [atlas] sometimes no RTT?

On 2016/07/08 12:07 , Antranig Vartanian wrote: > sure! Probe ID: 938. Hop: 12 I uploaded that probe's json part - > https://antranigv.am/misc/result_prb_id_938.json :) Hi, There is a 'late' field. Basically that means that the packet arrived after the traceroute code already timed out. The curre

Re: [atlas] sometimes no RTT?

On 2016/07/08 14:19 , Alex Saroyan wrote: > I am a bit confused, is that "late reply from the probe" or it is "late > reply from router - basically timed out reply" ? > Should it be treated like packet loss ? It is replies received by the probe. So it is usually from routers, but it could be from

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

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

complete analysis: https://labs.ripe.net/Members/philip_homburg/further-analysis-of-ripe-atlas-version-3-probe?pk_campaign=atlas&pk_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 th

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 G

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] 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] 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 probe

Re: [atlas] probe offline - troubleshooting requested

On 2016/10/18 7:46 , Andre Heinrichs wrote: > Any ideas what I could try to get the probe reconnected? > > Just to be complete: Here are the last lines of the SOS history: > 62.109.121.35 2016-10-18 05:43:27 A 3h 59m > 62.109.121.35 2016-10-18 05:43:27 3h 59m The best thing to try is to refl

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. > W

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: 72.52

Re: [atlas] Testing DNS-over-TLS support?

Hi Stephane, On 2017/03/01 1:13 , Stephane Bortzmeyer wrote: > DNS-over-TLS (RFC 7858) is important for privacy but, today, few DNS > resolvers support it. It would be interesting to measure if this is > changing, but the probes do not seem to be able to query their > resolver with TLS over port 8

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] Failing probe, all lights blink

On 2017/03/07 11:06 , Phillip Remaker wrote: > Are there any steps I can take to unbrick? Not officially. There are ways to open up the probe and reflash it without losing key material, but it is very tricky. Better to send the old one back and ask for a new one. Philip

Re: [atlas] Fwd: [mat-wg] Atlas: DNS TCP Errors

Hi John, On 2017/03/14 14:49 , John wrote: > feature request, when preforming DNS queries over TCP would it be > possible for the probe to differentiate between a timeout and a TCP > Reset. Currently the result just records the following when it gets a > reset[1]. > > `error.timeout: 5000` I'll

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&dnsmon.session.exclude-errors=true&dnsmon.type=zone-servers&dnsmon.zone=fr.&dnsm

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 wrote > a message of 16 lines which said: > >> The patch is simply to delete the offending line and, if all goes well, >> will be rolled out on the anch

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] 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 timeouts (it works w

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 a

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

Hi, On 2017/06/08 16:39 , Stanish Stanishev wrote: > So I decided to do a traffic capture of the uplink port where the probe is > connected to. According to the capture the probe does not send DHCP requests. > It sends only IPv6 traffic - Multicast Listener reports and Neighbor > solicitation.

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

On 2017/06/12 13:55 , Stanish Stanishev wrote: > Note: The router assigns recursive DNS servers (2001:4860:4860:: > 2001:4860:4860::8844) via ICMP6 Option 25 in Router Advertisement messages. > I have also tried to assign DNS servers via the RIPE Probe Management Web > Interface but no diff

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

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 co

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 t

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] 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] 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 th

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] ULA detected by probe?

Hi Jordi, On 2017/12/02 10:41 , JORDI PALET MARTINEZ wrote: > And > Addresses fd3f:4830:fd21:0:220:4aff:febf:ffaf/64 > 2001:…. I'm not aware of any case where an Atlas probe created an IPv6 ULA out of thin air. Addresses are either statically configured or derived from a prefix

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] 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] 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 reachable.

Re: [atlas] False positives on SSL check?

On 2018/02/01 20:59 , Ruben Herold wrote: > thx for your help. I found this about signature_algorithms: > > https://support.citrix.com/article/CTX205578 > > seems this is the same here. > Hope this helps fixing it on the probes. I can confirm that it works with the signature_algorithms extensio

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, > "le

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

On 2018/04/23 12:20 , Stephane Bortzmeyer wrote: > The strange thing is that sometimes, it depends on the probe. For > instance, in #12283468, most probes succeeded but some got "{'level': > 2, 'description': 40}". It is not a firewall issue since otherwise we > would get a different message. It do

Re: [atlas] Firmware version 4660

Hi, > I am using data  collected by RIPE Atlas probes, I found data with a> > firmware /*4660*/, but I can't find definition of the structure related> to this firmware here . For 4660 you need Section 7: https://atlas.ripe.net/docs/data_struct/#v4610 I

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 b

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 i

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] 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 cu

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

On 2018/12/17 11:46 , Moritz Muller wrote: > Not sure if I understood you right. > So you think that it doesn’t have anything to do with the probes themselves, > but the round trip time is actually that long? No. The extra time is caused by the measurement code. The actual round trip time is only

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 201

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 subnet.

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

  1   2   >