From tapio.sokura at iki.fi Wed Oct 4 05:10:28 2017 From: tapio.sokura at iki.fi (Tapio Sokura) Date: Wed, 4 Oct 2017 06:10:28 +0300 Subject: [atlas] ipv6 ping to root name servers failing? Message-ID: Hello, I noticed a few days ago from the built-in probe graphs that ipv6 pings started to fail to the a-root name server instance serving the probe I host. Now also the j-root serving the probe is dropping pings. Some other instances of the same root servers at the moment are still answering pings. If it is intentional that root name servers are starting to drop pings, something should probably be done to the built-in probe measurements/graphs. Does someone know more about this, will all roots be dropping pings in the future or is this just a Verisign thing (a and j operator)? Tapio From c.estelmann at gmx.net Wed Oct 4 09:19:46 2017 From: c.estelmann at gmx.net (Estelmann, Christian) Date: Wed, 4 Oct 2017 09:19:46 +0200 Subject: [atlas] ipv6 ping to root name servers failing? In-Reply-To: References: Message-ID: Hi, it is not only for your probe / connection / ISP. See the result map of the measurement [1]. In Germany the probes from AS3320 (DTAG / Deutsche Telekom) and AS31334 (Kabel Deutschland / Vodafone) are not able to reach the destination*. Maybe same uplink provider? Greetings, Christian *I took some of the black dots randomly from the map [1] https://atlas.ripe.net/measurements/2009/#!map > Gesendet: Mittwoch, 04. Oktober 2017 um 05:10 Uhr > Von: "Tapio Sokura" > An: ripe-atlas at ripe.net > Betreff: [atlas] ipv6 ping to root name servers failing? > > Hello, > > I noticed a few days ago from the built-in probe graphs that ipv6 pings > started to fail to the a-root name server instance serving the probe I > host. Now also the j-root serving the probe is dropping pings. Some > other instances of the same root servers at the moment are still > answering pings. > > If it is intentional that root name servers are starting to drop pings, > something should probably be done to the built-in probe > measurements/graphs. Does someone know more about this, will all roots > be dropping pings in the future or is this just a Verisign thing (a and > j operator)? > > Tapio > > From colinj at mx5.org.uk Thu Oct 5 14:38:32 2017 From: colinj at mx5.org.uk (Colin Johnston) Date: Thu, 5 Oct 2017 13:38:32 +0100 Subject: [atlas] Charity IT Pulse :) one more sleep till Bytenight Action for Children 2017 References: Message-ID: > > Dear all, one more sleep until ByteNight events across the UK on Friday night. > Please donate if you can electronically > > > See mydonate page linked to Byte Night https://mydonate.bt.com/fundraisers/colinjohnston1 > > For more information go to www.bytenight.org.uk or to donate Text Byte17 and the amount to 70070. > > In just 1 days time, on Friday 6 October, I am spending one night sleeping rough for Byte Night. Byte Night works to support some of the 83,000 young people who are homeless in the UK. One in four young people who are homeless have been diagnosed with mental health issues and one in five will have self-harmed due to their situation at home. ?10 could provide an hour?s support with a mental health practitioner for 1 young people to help them get through their issues. Action for Children has supported many young people to a safe and happy future. Unfortunately, so many more still need our help. You can help support young people across the UK by generously donating to my page > > > > Yours > > Colin Johnston > > Colin Johnston > IT Support Senior Professional, Core IT Infrastructure > BT Technology Service & Operations? | Tel: 01313001324? | MyProfile? | colin.johnstone at bt.com? | http://fixit.bt.com/ > > BT Group plc Registered office: 81 Newgate Street London EC1A 7AJ. Registered in England and Wales no. 4190816 This electronic message contains information from BT Group plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please delete it and notify me immediately by telephone or email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 49619 bytes Desc: not available URL: From ripe-ncc at vanderzwan.org Sun Oct 8 11:45:28 2017 From: ripe-ncc at vanderzwan.org (RIPE) Date: Sun, 8 Oct 2017 11:45:28 +0200 Subject: [atlas] Probe disconnects Message-ID: <3CB798AB-623C-42DF-A630-982BA23FFF66@vanderzwan.org> Hi, I have a probe ( #22583 ) at home connected via my DSL link, for IPv6 connectivity I use a Hurricane Electric ( tunnelbroker.net ) /48 tunnel. I noticed on the monthly report that my probe is showing lots of short ( 1-2 min) disconnects. But it only seems to happen when the connection address in the probe?s network tab is the IPv6 address. In that case the IPv4 Connection address is empty. If it?s showing the IPv4 the probe stays connected for days ( until the DSL link really disconnects). Is there a way to get the probe to ignore the IPv6 for connection status ? Or to mark it as disconnected when both iPv4 and IPv6 are disconnected ? Best regards, Paul van der Zwan From jterbeest at ripe.net Mon Oct 9 12:01:36 2017 From: jterbeest at ripe.net (Johan ter Beest) Date: Mon, 9 Oct 2017 12:01:36 +0200 Subject: [atlas] Probe disconnects In-Reply-To: <3CB798AB-623C-42DF-A630-982BA23FFF66@vanderzwan.org> References: <3CB798AB-623C-42DF-A630-982BA23FFF66@vanderzwan.org> Message-ID: Hi Paul, On 08/10/2017 11:45, RIPE wrote: > Hi, > I have a probe ( #22583 ) at home connected via my DSL link, for IPv6 connectivity I use a Hurricane Electric ( tunnelbroker.net ) /48 tunnel. > > I noticed on the monthly report that my probe is showing lots of short ( 1-2 min) disconnects. > > But it only seems to happen when the connection address in the probe?s network tab is the IPv6 address. > In that case the IPv4 Connection address is empty. > > If it?s showing the IPv4 the probe stays connected for days ( until the DSL link really disconnects). > Is there a way to get the probe to ignore the IPv6 for connection status ? > Or to mark it as disconnected when both iPv4 and IPv6 are disconnected ? You can restrict the probe to connect only on IPv4 if you want by checking the box in the network settings for IPv4: https://atlas.ripe.net/probes/22583/#tab-network This will make sure the probe only connects to our infrastructure using IPv4 but the probe will still be available for IPv6 measurements. Hope this helps, Kind regards, Johan ter Beest RIPE Atlas Team > > > > Best regards, > Paul van der Zwan > > > > From ripe-ncc at vanderzwan.org Mon Oct 9 12:20:33 2017 From: ripe-ncc at vanderzwan.org (Paul van der Zwan) Date: Mon, 9 Oct 2017 12:20:33 +0200 Subject: [atlas] Probe disconnects In-Reply-To: References: <3CB798AB-623C-42DF-A630-982BA23FFF66@vanderzwan.org> Message-ID: <6AA080C3-07A6-4B71-90CE-21904DC6A095@vanderzwan.org> Hi Johan, I had a look on my probe?s page but I cannot find a check box anywhere. Only things I see are the dhcp/static address selection options. Regards Paul Sent from my mobile phone > On 9 Oct 2017, at 12:01, Johan ter Beest wrote: > > Hi Paul, > > >> On 08/10/2017 11:45, RIPE wrote: >> Hi, >> I have a probe ( #22583 ) at home connected via my DSL link, for IPv6 connectivity I use a Hurricane Electric ( tunnelbroker.net ) /48 tunnel. >> >> I noticed on the monthly report that my probe is showing lots of short ( 1-2 min) disconnects. >> >> But it only seems to happen when the connection address in the probe?s network tab is the IPv6 address. >> In that case the IPv4 Connection address is empty. >> >> If it?s showing the IPv4 the probe stays connected for days ( until the DSL link really disconnects). >> Is there a way to get the probe to ignore the IPv6 for connection status ? >> Or to mark it as disconnected when both iPv4 and IPv6 are disconnected ? > > You can restrict the probe to connect only on IPv4 if you want by checking the box in the network settings for IPv4: > https://atlas.ripe.net/probes/22583/#tab-network > > This will make sure the probe only connects to our infrastructure using IPv4 but the probe will still be available for IPv6 measurements. > > Hope this helps, > > Kind regards, > > Johan ter Beest > RIPE Atlas Team > > >> >> >> >> Best regards, >> Paul van der Zwan >> >> >> >> > > From andre.brioso at gmail.com Mon Oct 9 15:29:32 2017 From: andre.brioso at gmail.com (Andre Kakoo Brioso) Date: Mon, 9 Oct 2017 14:29:32 +0100 Subject: [atlas] Plan to Implement RIPE Atlas WiFi Measurements In-Reply-To: References: <56FBBCF3.5010606@ripe.net> Message-ID: Hi Robert, I have probe #21580 at Universidade Lisboa with good eduroam coverage. If you want, we can give you some logging and other information from our wireless infrastructure. Best Regards, Andr? Kakoo Brioso On 30 August 2017 at 08:32, Robert Kisteleki wrote: > Hi, > > The wifi measurements are technically possible, and can measure eduroam > as planned. You can find these in the UI. > > We only have a handful of probes "upgraded" to support them, since we're > still looking at their behavior. We have the mans to opt more probes in, > so if you have a probe in eduroam vicinity and would like to help > testing the feature, please let us know by writing to atlas at rtipe.net > > Regards, > Robert > > > On 2017-08-29 22:44, Anurag Bhatia wrote: > > Hello > > > > > > Very interesting information and since this email is old. Can you share > > latest updates around it? > > > > On Wed, Mar 30, 2016 at 5:18 PM, Robert Kisteleki > > wrote: > > > > Dear colleagues, > > > > We wanted to update the community and let you know that we plan to > start > > work on the proposed experiment with WiFi measurements in mid-2016. > > As we > > communicated in a recent RIPE Labs article, we will work with G?ANT > as a > > test partner to learn more about the operational effects of > > introducing WiFi > > measurements to the RIPE Atlas system, in addition to the benefits we > > believe this could provide for the entire RIPE Atlas community. > > Please see > > the article for more details if you are interested: > > > > https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe- > atlas-wifi-measurements-part-2 > > ripe-atlas-wifi-measurements-part-2> > > > > We will continue to update you once we?ve begun work on this plan, > > and we > > welcome your comments in the meantime. > > > > Regards, > > > > Robert Kisteleki > > RIPE NCC > > > > > > > > > > -- > > > > > > Anurag Bhatia > > anuragbhatia.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baptiste.jonglez at imag.fr Fri Oct 13 19:19:30 2017 From: baptiste.jonglez at imag.fr (Baptiste Jonglez) Date: Fri, 13 Oct 2017 19:19:30 +0200 Subject: [atlas] What is the meaning of 127.0.0.1 as probe resolver? Message-ID: <20171013171930.2eaox2ybr2yj4bbh@imag.fr> Hi, While looking at the result of built-in DNS measurements that use the probe resolvers, I noticed that a significant fraction of probes have "127.0.0.1" as a resolver. And the results are strange: performance is really bad, for instance measurement 30002 gives a median resolution time of 300 ms for these probes! What could be the meaning of this? It almost looks like a recursive resolver with no cache at all is running on the probes themselves. I was looking at this measurement: https://atlas.ripe.net/measurements/30002/ And here are some example probes that exhibit this "127.0.0.1" symptom: 6001, 6087, 6162, 6235, 6308. Any reasonable explanation is welcome! Thanks, Baptiste -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From anandb at ripe.net Fri Oct 13 20:21:38 2017 From: anandb at ripe.net (Anand Buddhdev) Date: Fri, 13 Oct 2017 20:21:38 +0200 Subject: [atlas] What is the meaning of 127.0.0.1 as probe resolver? In-Reply-To: <20171013171930.2eaox2ybr2yj4bbh@imag.fr> References: <20171013171930.2eaox2ybr2yj4bbh@imag.fr> Message-ID: <25230611-554c-7776-47bb-f49fad8cc9df@ripe.net> On 13/10/2017 19:19, Baptiste Jonglez wrote: Hi Baptiste, > While looking at the result of built-in DNS measurements that use the > probe resolvers, I noticed that a significant fraction of probes have > "127.0.0.1" as a resolver. And the results are strange: performance is > really bad, for instance measurement 30002 gives a median resolution time > of 300 ms for these probes! > > What could be the meaning of this? It almost looks like a recursive > resolver with no cache at all is running on the probes themselves. > > I was looking at this measurement: https://atlas.ripe.net/measurements/30002/ > > And here are some example probes that exhibit this "127.0.0.1" symptom: > 6001, 6087, 6162, 6235, 6308. All these probes are actually RIPE Atlas anchors. They all run a caching recursive resolver, which can, and often is, used to perform DNS lookups for measurements running on these anchors. The high latency in resolution could be for any number of reasons, so I can't immediately it. Regards, Anand Buddhdev RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 898 bytes Desc: OpenPGP digital signature URL: From bortzmeyer at nic.fr Sat Oct 14 09:11:04 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 14 Oct 2017 09:11:04 +0200 Subject: [atlas] Problem in status checks? Message-ID: <20171014071104.fv5hunrydu4gdb5a@sources.org> Error 500 when trying to retrieve status checks: % curl -v 'https://atlas.ripe.net/api/v2/measurements/2060427/status-check?permitted_total_alerts=3' ... > GET /api/v2/measurements/2060427/status-check?permitted_total_alerts=3 HTTP/1.1 > Host: atlas.ripe.net > User-Agent: curl/7.52.1 > Accept: */* > < HTTP/1.1 500 Internal Server Error < Server: nginx/1.10.2 < Date: Sat, 14 Oct 2017 07:09:10 GMT < Content-Type: text/html; charset=utf-8 < Content-Length: 38403 < Connection: keep-alive < Vary: Accept-Encoding, Cookie < X-Frame-Options: SAMEORIGIN < Strict-Transport-Security: max-age=15768000 From camin at ripe.net Sat Oct 14 10:03:43 2017 From: camin at ripe.net (Chris Amin) Date: Sat, 14 Oct 2017 10:03:43 +0200 Subject: [atlas] Problem in status checks? In-Reply-To: <20171014071104.fv5hunrydu4gdb5a@sources.org> References: <20171014071104.fv5hunrydu4gdb5a@sources.org> Message-ID: <03a569d7-9a07-330e-1e48-36ad7c2d30ca@ripe.net> Hi Stephane, We are currently experiencing some problems with one of our backends which is affecting various API endpoints, including status checks. We are looking into the root cause now. Regards, Chris On 14/10/2017 09:11, Stephane Bortzmeyer wrote: > Error 500 when trying to retrieve status checks: > > % curl -v 'https://atlas.ripe.net/api/v2/measurements/2060427/status-check?permitted_total_alerts=3' > ... >> GET /api/v2/measurements/2060427/status-check?permitted_total_alerts=3 HTTP/1.1 >> Host: atlas.ripe.net >> User-Agent: curl/7.52.1 >> Accept: */* >> > > < HTTP/1.1 500 Internal Server Error > < Server: nginx/1.10.2 > < Date: Sat, 14 Oct 2017 07:09:10 GMT > < Content-Type: text/html; charset=utf-8 > < Content-Length: 38403 > < Connection: keep-alive > < Vary: Accept-Encoding, Cookie > < X-Frame-Options: SAMEORIGIN > < Strict-Transport-Security: max-age=15768000 > > From baptiste.jonglez at imag.fr Mon Oct 16 10:48:02 2017 From: baptiste.jonglez at imag.fr (Baptiste Jonglez) Date: Mon, 16 Oct 2017 10:48:02 +0200 Subject: [atlas] What is the meaning of 127.0.0.1 as probe resolver? In-Reply-To: <25230611-554c-7776-47bb-f49fad8cc9df@ripe.net> References: <20171013171930.2eaox2ybr2yj4bbh@imag.fr> <25230611-554c-7776-47bb-f49fad8cc9df@ripe.net> Message-ID: <20171016084802.klaslsho4yiodxe7@imag.fr> On Fri, Oct 13, 2017 at 08:21:38PM +0200, Anand Buddhdev wrote: > On 13/10/2017 19:19, Baptiste Jonglez wrote: > > Hi Baptiste, > > > While looking at the result of built-in DNS measurements that use the > > probe resolvers, I noticed that a significant fraction of probes have > > "127.0.0.1" as a resolver. And the results are strange: performance is > > really bad, for instance measurement 30002 gives a median resolution time > > of 300 ms for these probes! > > > > What could be the meaning of this? It almost looks like a recursive > > resolver with no cache at all is running on the probes themselves. > > > > I was looking at this measurement: https://atlas.ripe.net/measurements/30002/ > > > > And here are some example probes that exhibit this "127.0.0.1" symptom: > > 6001, 6087, 6162, 6235, 6308. > > All these probes are actually RIPE Atlas anchors. They all run a caching > recursive resolver, which can, and often is, used to perform DNS lookups > for measurements running on these anchors. Indeed, this is quite obvious now that you point it out. In the dataset I am using (measurement 30002), there are 287 "probes" using 127.0.0.1 as resolver, which roughly matches the current number of anchors (290). > The high latency in resolution could be for any number of reasons, so I > can't immediately it. In case you are interested, I have attached a plot of query latency over one week of DNS measurements, showing the behaviour across the different address types of the resolvers (global, RFC1918, RFC6598 shared addresses, and loopback). As you can see, the loopback resolver used by Atlas anchors has an incredibly bad latency! Baptiste -------------- next part -------------- A non-text attachment was scrubbed... Name: atlas-delay-classification-30002.png Type: image/png Size: 298860 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mir at ripe.net Tue Oct 17 16:34:56 2017 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 17 Oct 2017 16:34:56 +0200 Subject: [atlas] New on RIPE Labs: Insights from RIPE Atlas Probe Disconnections Message-ID: <28a33543-6882-09ad-75c8-6424c299e3e4@ripe.net> Dear colleagues, There are all kinds of reasons why RIPE Atlas probes might become disconnected. So, even though we'd like all probes to be connected all the time, disconnects can also tell us a useful story. Please find this new article by Emile Aben on RIPE Labs exploring what insights we can gain from RIPE Atlas probe disconnections: https://labs.ripe.net/Members/emileaben/insights-from-ripe-atlas-probe-disconnections Kind regards, Mirjam Kuhne RIPE NCC From gboonie at gmail.com Wed Oct 18 13:08:44 2017 From: gboonie at gmail.com (Dave) Date: Wed, 18 Oct 2017 13:08:44 +0200 Subject: [atlas] status is confusing Message-ID: <59e73636.c3a7500a.cf81b.f5cb@mx.google.com> Hi, The status page of one of my probes says: I?ve been bitten a few times by misinterpreting this. Could these 2 things be put on separate lines? This does suggest the probe is up but only when you missed the red colour and didn?t get the meaning of the icon. Also, when you read the mail it may be hours later than when it was sent. So keep in mind that a receiver?s probe could be back online in the meantime. Often a mail will be checked on the mobile. The status on a small screen must be clear too. I?ll restart the probe and modem and it will work again but I would have done that on day 1 if the message was more clear. Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 45B0D42D170D4326A379EAE53937F921.png Type: image/png Size: 3146 bytes Desc: not available URL: From mir at ripe.net Fri Oct 20 13:02:44 2017 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 20 Oct 2017 13:02:44 +0200 Subject: [atlas] New on RIPE Labs: RIPE Atlas Probes as IoT Devices In-Reply-To: <6efe315f-66f1-1dbc-9a40-5e2e715f5ae3@ripe.net> References: <6efe315f-66f1-1dbc-9a40-5e2e715f5ae3@ripe.net> Message-ID: <4feabe27-a926-feec-a975-0bceb2f722f0@ripe.net> Dear colleagues, As a follow-up to the presentation Robert Kisteleki gave during the IoT Roundtable Meeting in September [1], we have published a RIPE Labs article describing RIPE Atlas probes as IoT devices and some initial design decisions that we thought were important for such an infrastructure: https://labs.ripe.net/Members/kistel/ripe-atlas-probes-as-iot-devices Kind regards, Mirjam Kuhne RIPE NCC [1] https://www.ripe.net/participate/meetings/roundtable/september-2017/ripe-iot-roundtable-meeting-21-september-2017/agenda From eduardo.duarte at dns.pt Wed Oct 25 14:03:15 2017 From: eduardo.duarte at dns.pt (Eduardo Duarte) Date: Wed, 25 Oct 2017 13:03:15 +0100 Subject: [atlas] Why did I get "Over the limit on number of results"? Message-ID: <9f719cf6-3938-a5ef-63ae-1b0758dd86b2@dns.pt> Hello, I schedule some measurements to run during today but I got an error on some of them. The error is "Over the limit on number of results". I have enough credits to run all the measures so I don't understand this message. Thank you and best regards, -- Eduardo Duarte Gest?o e Desenvolvimento de Projetos l Project Development Management ? *DNS.PT* Rua Latino Coelho, n.? 13, 5.? piso | 1050-132 Lisboa | Portugal Tel: (+351) 211 308 200??Fax: (+351) 211 312 720 dns.pt | dnssec.pt | 3em1.pt | facebook.com/dns.pt | pt.linkedin.com/in/dnspt ? Aviso de Confidencialidade/Disclaimer: Este e-mail foi escrito de acordo com o novo acordo ortogr?fico. Esta mensagem ? exclusivamente destinada ao seu destinat?rio, podendo conter informa??o CONFIDENCIAL, cuja divulga??o est? expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via devendo apagar o seu conte?do de imediato. This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail and delete it immediately. [ Antes de imprimir esta mensagem pense no ambiente. Before printing this message, think about environment ] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4634 bytes Desc: S/MIME Cryptographic Signature URL: From w.b.devries at utwente.nl Wed Oct 25 14:16:30 2017 From: w.b.devries at utwente.nl (Wouter de Vries) Date: Wed, 25 Oct 2017 14:16:30 +0200 Subject: [atlas] Why did I get "Over the limit on number of results"? In-Reply-To: <9f719cf6-3938-a5ef-63ae-1b0758dd86b2@dns.pt> References: <9f719cf6-3938-a5ef-63ae-1b0758dd86b2@dns.pt> Message-ID: <20171025121630.GL2018@wfstore.localdomain> Hi Eduardo, There are also limits on the number of results that you generate per day, called the "Daily measurement result flow". This could be what you are describing. The limits are shown at https://atlas.ripe.net/atlas/user/ Best, Wouter On Wed, Oct 25, 2017 at 01:03:15PM +0100, Eduardo Duarte wrote: > Hello, > > I schedule some measurements to run during today but I got an error on > some of them. The error is "Over the limit on number of results". > I have enough credits to run all the measures so I don't understand this > message. > > Thank you and best regards, > -- > Eduardo Duarte > Gest?o e Desenvolvimento de Projetos l Project Development Management > ? > *DNS.PT* > Rua Latino Coelho, n.? 13, 5.? piso | 1050-132 Lisboa | Portugal > Tel: (+351) 211 308 200??Fax: (+351) 211 312 720 > dns.pt | dnssec.pt | 3em1.pt > | facebook.com/dns.pt > | pt.linkedin.com/in/dnspt > > > ? > Aviso de Confidencialidade/Disclaimer: > Este e-mail foi escrito de acordo com o novo acordo ortogr?fico. > Esta mensagem ? exclusivamente destinada ao seu destinat?rio, podendo > conter informa??o CONFIDENCIAL, cuja divulga??o est? expressamente > vedada nos termos da lei. Caso tenha recepcionado indevidamente esta > mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta > via devendo apagar o seu conte?do de imediato. This message is intended > exclusively for its addressee. It may contain CONFIDENTIAL information > protected by law. If this message has been received by error, please > notify us via e-mail and delete it immediately. > [ Antes de imprimir esta mensagem pense no ambiente. Before printing > this message, think about environment ] From robert at ripe.net Wed Oct 25 14:46:51 2017 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 25 Oct 2017 14:46:51 +0200 Subject: [atlas] Why did I get "Over the limit on number of results"? In-Reply-To: <20171025121630.GL2018@wfstore.localdomain> References: <9f719cf6-3938-a5ef-63ae-1b0758dd86b2@dns.pt> <20171025121630.GL2018@wfstore.localdomain> Message-ID: <4ca04caf-72bb-6cec-0dd8-34a0a4a0a29d@ripe.net> Hi, On 2017-10-25 14:16, Wouter de Vries wrote: > Hi Eduardo, > > There are also limits on the number of results that you generate per > day, called the "Daily measurement result flow". This could be what you > are describing. > > The limits are shown at https://atlas.ripe.net/atlas/user/ > > Best, > > Wouter Indeed that page describes the limits for a particular user. There's more documentation available at https://atlas.ripe.net/docs/udm/#rate-limits. Let me perhaps explain a bit more of the motivation. We started off with putting hard limits, besides other things, on: a) the number of concurrent measurements a user can b) the number of probes that can be involved in a single measurement c) the total amount of credits one can spend per day A year or two ago we introduced a "daily measurement result flow" (d), with the intention of that it can ultimately replace (a) and (b), perhaps even (c). The idea behind this is that from the resource use point of view it shoould not matter (*) if one runs 1 msm with 10000 probes or 100 measurements with 100 probes each -- what matters is the total output the user is requesting from the system. BTW (a), (b) and (c) are hard numbers, (d) is an estimate so even though it's more user-friendly, it's more difficult to maintain. We haven't reached the point where (d) is the ultimate limit; mostly because there *is* difference in the (*) part above, for internal reasons. Solving this is a long-ish process, but are making steps to get there. Hope this explains, Robert From dileo.1781694 at studenti.uniroma1.it Wed Oct 25 21:08:49 2017 From: dileo.1781694 at studenti.uniroma1.it (Antonio D) Date: Wed, 25 Oct 2017 21:08:49 +0200 Subject: [atlas] Segmentation fault (core dumped) Message-ID: I upgraded UBUNTU from 17.04 to 17.10 and I discovered that ripe-atlas-tools had disappeared. So I tried reinstalling it with "pop install ripe-atlas-tools", but the process crashed with the following error: Segmentation fault (core dumped) Can you help me solve the problem? Thank you Antonio Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From max.grobecker at ml.grobecker.info Wed Oct 25 22:45:42 2017 From: max.grobecker at ml.grobecker.info (Max Grobecker) Date: Wed, 25 Oct 2017 22:45:42 +0200 Subject: [atlas] IPv4 leading zeroes and weird interface behaviour Message-ID: <489767dd-7902-d08b-2858-8cb33e7ffee2@ml.grobecker.info> Hello, is there - by standard - a definition on how to represent an IPv4 address? I have (for example) the IP address "73.0.255.229", which can IMHO also be written as "073.000.255.229" as the leading zeroes are not giving any changes to the binary representation of this address. Am I right on this? But: When I lookup this IP address on https://stat.ripe.net/073.000.255.229 the first octet is internally getting swapped to "59". This can be explained, if you take "073" as an octal value and convert it to a decimal value. It is definitely a octal-to-decimal conversion thing, as for example also the value "010" is getting replaced by "8" and so on. Now I'm puzzled: Of course, writing IPv4 octets with leading zeroes is not very common. But: Is it officially prohibited or discouraged? This weird conversion also happens inside the "geoiplookup" tool by MaxMind and I'm not sure if I'm going to be the moron in this story or if I found the same bug inside multiple softwares at once ;-) Thanks and greetings from Wuppertal Max -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From remaker at gmail.com Wed Oct 25 22:54:46 2017 From: remaker at gmail.com (Phillip Remaker) Date: Wed, 25 Oct 2017 13:54:46 -0700 Subject: [atlas] IPv4 leading zeroes and weird interface behaviour In-Reply-To: <489767dd-7902-d08b-2858-8cb33e7ffee2@ml.grobecker.info> References: <489767dd-7902-d08b-2858-8cb33e7ffee2@ml.grobecker.info> Message-ID: Historically, C uses a 0 to precede an octal number, 0x to precede a decimal, and 0b for binary. Leading zeroes are otherwise stripped in numerical representation. Since 0x is not accepted, I'd call it a bug and request that the numbers always get treated as decimal, regardless of leading zeros. There's probably some downstream library making the anachronistic assumption. On Wed, Oct 25, 2017 at 1:45 PM, Max Grobecker < max.grobecker at ml.grobecker.info> wrote: > Hello, > > is there - by standard - a definition on how to represent an IPv4 address? > > I have (for example) the IP address "73.0.255.229", which can IMHO also be > written as "073.000.255.229" as the leading zeroes > are not giving any changes to the binary representation of this address. > Am I right on this? > > But: When I lookup this IP address on https://stat.ripe.net/073.000. > 255.229 the first octet is internally getting swapped to "59". > This can be explained, if you take "073" as an octal value and convert it > to a decimal value. > It is definitely a octal-to-decimal conversion thing, as for example also > the value "010" is getting replaced by "8" and so on. > > Now I'm puzzled: Of course, writing IPv4 octets with leading zeroes is not > very common. > But: Is it officially prohibited or discouraged? > > This weird conversion also happens inside the "geoiplookup" tool by > MaxMind and I'm not sure if I'm going to be the moron in this story > or if I found the same bug inside multiple softwares at once ;-) > > > Thanks and greetings from Wuppertal > Max > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Wed Oct 25 23:05:27 2017 From: nick at inex.ie (Nick Hilliard) Date: Wed, 25 Oct 2017 22:05:27 +0100 Subject: [atlas] IPv4 leading zeroes and weird interface behaviour In-Reply-To: <489767dd-7902-d08b-2858-8cb33e7ffee2@ml.grobecker.info> References: <489767dd-7902-d08b-2858-8cb33e7ffee2@ml.grobecker.info> Message-ID: <59F0FC97.70804@inex.ie> Max Grobecker wrote: > Now I'm puzzled: Of course, writing IPv4 octets with leading zeroes is not very common. > But: Is it officially prohibited or discouraged? It was never defined in the rfcs, but by rfc convention, leading zeros should probably be interpreted as decimal (e.g. rfc790). The problem is, inet_aton() interprets leading zeros as octal, and on any operating system which uses the bsd socket library, the address may get converted into octal, or may not, depending on whether the program is using inet_aton(), which assumes octal if there are leading zeros, or getaddrinfo(), which will interpret as decimal in all cases, because POSIX was a bit more careful about the definition. In other words, you have no idea a priori what someone else's code will do, so unless you're ok about your output being interpreted as random garbage, you should avoid zero-padding at all costs. Nick From rm at romanrm.net Wed Oct 25 22:59:44 2017 From: rm at romanrm.net (Roman Mamedov) Date: Thu, 26 Oct 2017 01:59:44 +0500 Subject: [atlas] IPv4 leading zeroes and weird interface behaviour In-Reply-To: <489767dd-7902-d08b-2858-8cb33e7ffee2@ml.grobecker.info> References: <489767dd-7902-d08b-2858-8cb33e7ffee2@ml.grobecker.info> Message-ID: <20171026015944.4322a15d@natsu> On Wed, 25 Oct 2017 22:45:42 +0200 Max Grobecker wrote: > But: When I lookup this IP address on https://stat.ripe.net/073.000.255.229 the first octet is internally getting swapped to "59". > This can be explained, if you take "073" as an octal value and convert it to a decimal value. > It is definitely a octal-to-decimal conversion thing, as for example also the value "010" is getting replaced by "8" and so on. > > Now I'm puzzled: Of course, writing IPv4 octets with leading zeroes is not very common. > But: Is it officially prohibited or discouraged? > > This weird conversion also happens inside the "geoiplookup" tool by MaxMind and I'm not sure if I'm going to be the moron in this story > or if I found the same bug inside multiple softwares at once ;-) There are many ways to write an IP address, and yes, leading zeroes mean the octal form. Even basic utilities like "ping" use this conversion: $ ping 010.020.030.040 PING 010.020.030.040 (8.16.24.32) 56(84) bytes of data. ^C --- 010.020.030.040 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms Another way is to give a full 32-bit number as integer: $ ping 728374928 PING 728374928 (43.106.30.144) 56(84) bytes of data. ^C --- 728374928 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1015ms Or you can skip zeroes (almost like in IPv6): $ ping 10.9 PING 10.9 (10.0.0.9) 56(84) bytes of data. ^C --- 10.9 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1015ms So what you found is not a bug, but a common behavior. I'm sure all of this is described in great detail in some 40 year old RFC. -- With respect, Roman From hsalgado at nic.cl Wed Oct 25 23:06:26 2017 From: hsalgado at nic.cl (Hugo =?iso-8859-1?Q?Salgado-Hern=E1ndez?=) Date: Wed, 25 Oct 2017 18:06:26 -0300 Subject: [atlas] IPv4 leading zeroes and weird interface behaviour In-Reply-To: References: <489767dd-7902-d08b-2858-8cb33e7ffee2@ml.grobecker.info> Message-ID: <20171025210626.GA21807@nic.cl> It was warned before on this IETF draft, but it was never published: Hugo On 13:54 25/10, Phillip Remaker wrote: > Historically, C uses a 0 to precede an octal number, 0x to precede a > decimal, and 0b for binary. Leading zeroes are otherwise stripped in > numerical representation. > > Since 0x is not accepted, I'd call it a bug and request that the numbers > always get treated as decimal, regardless of leading zeros. > > There's probably some downstream library making the anachronistic > assumption. > > On Wed, Oct 25, 2017 at 1:45 PM, Max Grobecker < > max.grobecker at ml.grobecker.info> wrote: > > > Hello, > > > > is there - by standard - a definition on how to represent an IPv4 address? > > > > I have (for example) the IP address "73.0.255.229", which can IMHO also be > > written as "073.000.255.229" as the leading zeroes > > are not giving any changes to the binary representation of this address. > > Am I right on this? > > > > But: When I lookup this IP address on https://stat.ripe.net/073.000. > > 255.229 the first octet is internally getting swapped to "59". > > This can be explained, if you take "073" as an octal value and convert it > > to a decimal value. > > It is definitely a octal-to-decimal conversion thing, as for example also > > the value "010" is getting replaced by "8" and so on. > > > > Now I'm puzzled: Of course, writing IPv4 octets with leading zeroes is not > > very common. > > But: Is it officially prohibited or discouraged? > > > > This weird conversion also happens inside the "geoiplookup" tool by > > MaxMind and I'm not sure if I'm going to be the moron in this story > > or if I found the same bug inside multiple softwares at once ;-) > > > > > > Thanks and greetings from Wuppertal > > Max > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From vnaumov at ripe.net Thu Oct 26 10:37:35 2017 From: vnaumov at ripe.net (Viktor Naumov) Date: Thu, 26 Oct 2017 10:37:35 +0200 Subject: [atlas] Segmentation fault (core dumped) In-Reply-To: References: Message-ID: <4613afbc-7f17-d9dc-cdbc-b8dec01331eb@ripe.net> Hi Antonio, try? "pip install ripe-atlas-tools" wbr /vty On 10/25/17 9:08 PM, Antonio D wrote: > I upgraded UBUNTU from 17.04 to 17.10 and I discovered that ripe-atlas-tools had disappeared. So I tried reinstalling it with "pop install ripe-atlas-tools", but the process crashed with the following error: Segmentation fault (core dumped) > Can you help me solve the problem? > Thank you > Antonio > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > From hjp at hjp.at Wed Oct 25 23:16:47 2017 From: hjp at hjp.at (Peter J. Holzer) Date: Wed, 25 Oct 2017 23:16:47 +0200 Subject: [atlas] IPv4 leading zeroes and weird interface behaviour In-Reply-To: References: <489767dd-7902-d08b-2858-8cb33e7ffee2@ml.grobecker.info> Message-ID: <20171025211647.54auczrfexslnn53@hjp.at> On 2017-10-25 13:54:46 -0700, Phillip Remaker wrote: > Historically, C uses a 0 to precede an octal number, 0x to precede a decimal, > and 0b for binary. 0b for binary is not C. It is used by some other languages, though (e.g. Perl). > Since 0x is not accepted, That depends on the tool: % ping 0x8f.0x82.0x10.0x8 PING 0x8f.0x82.0x10.0x8 (143.130.16.8) 56(84) bytes of data. 64 bytes from 143.130.16.8: icmp_seq=1 ttl=55 time=8.37 ms 64 bytes from 143.130.16.8: icmp_seq=2 ttl=55 time=8.26 ms ... % ping -V ping utility, iputils-s20161105 > There's probably some downstream library making the anachronistic assumption. 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 was a good idea. I wouldn't expect anyone to rely on it, but apparently nobody dares to get rid of that "feature". hp -- _ | Peter J. Holzer | we build much bigger, better disasters now |_|_) | | because we have much more sophisticated | | | hjp at hjp.at | management tools. __/ | http://www.hjp.at/ | -- Ross Anderson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From philip.homburg at ripe.net Fri Oct 27 11:08:19 2017 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 27 Oct 2017 11:08:19 +0200 Subject: [atlas] IPv4 leading zeroes and weird interface behaviour In-Reply-To: <20171025211647.54auczrfexslnn53@hjp.at> References: <489767dd-7902-d08b-2858-8cb33e7ffee2@ml.grobecker.info> <20171025211647.54auczrfexslnn53@hjp.at> Message-ID: <48f3ded5-0fc8-e022-9e0f-756e7751783e@ripe.net> 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 was a good idea. I wouldn't expect > anyone to rely on it, but apparently nobody dares to get rid of that > "feature". Technically it is C feature. If you call, for example, strtol with the third argument (base) equal to 0, then it will parse numbers just like a C compiler. In many contexts is is convenient if you can just type a hex number by prefixing the number with 0x. Unfortunately, this use of strtol is so common, that it gets used even in a context where it doesn't make sense, such as parsing an IPv4 address. However, the way IPv4 addresses are parsed is completely weird. This is from the inet_aton manual page: Values specified using the `.' notation take one of the following forms: a.b.c.d a.b.c a.b a When four parts are specified, each is interpreted as a byte of data and assigned, from left to right, to the four bytes of an Internet address. Note that when an Internet address is viewed as a 32-bit integer quantity on the VAX the bytes referred to above appear as ``d.c.b.a''. That is, VAX bytes are ordered from right to left. When a three part address is specified, the last part is interpreted as a 16-bit quantity and placed in the right-most two bytes of the network address. This makes the three part address format convenient for speci- fying Class B network addresses as ``128.net.host''. When a two part address is supplied, the last part is interpreted as a 24-bit quantity and placed in the right most three bytes of the network address. This makes the two part address format convenient for specify- ing Class A network addresses as ``net.host''. When only one part is given, the value is stored directly in the network address without any byte rearrangement. All numbers supplied as ``parts'' in a `.' notation may be decimal, octal, or hexadecimal, as specified in the C language (i.e., a leading 0x or 0X implies hexadecimal; otherwise, a leading 0 implies octal; other- wise, the number is interpreted as decimal). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From christian.teuschel at ripe.net Mon Oct 30 12:01:09 2017 From: christian.teuschel at ripe.net (Christian Teuschel) Date: Mon, 30 Oct 2017 12:01:09 +0100 Subject: [atlas] IPv4 leading zeroes and weird interface behaviour In-Reply-To: <489767dd-7902-d08b-2858-8cb33e7ffee2@ml.grobecker.info> References: <489767dd-7902-d08b-2858-8cb33e7ffee2@ml.grobecker.info> Message-ID: <3dbe56b9-fe65-9f3d-ccb2-170de09b7e0b@ripe.net> Hi Max, On RIPEstat having leading zeros in the octets is a very uncommon query pattern but since this behaviour is an inconsistency in the parsing for prefixes and IP addresses, it has been changed so that leading zeros are ignored. This change affects IP addresses and IP ranges. Hth, Christian On 25/10/2017 22:45, Max Grobecker wrote: > Hello, > > is there - by standard - a definition on how to represent an IPv4 address? > > I have (for example) the IP address "73.0.255.229", which can IMHO also be written as "073.000.255.229" as the leading zeroes > are not giving any changes to the binary representation of this address. Am I right on this? > > But: When I lookup this IP address on https://stat.ripe.net/073.000.255.229 the first octet is internally getting swapped to "59". > This can be explained, if you take "073" as an octal value and convert it to a decimal value. > It is definitely a octal-to-decimal conversion thing, as for example also the value "010" is getting replaced by "8" and so on. > > Now I'm puzzled: Of course, writing IPv4 octets with leading zeroes is not very common. > But: Is it officially prohibited or discouraged? > > This weird conversion also happens inside the "geoiplookup" tool by MaxMind and I'm not sure if I'm going to be the moron in this story > or if I found the same bug inside multiple softwares at once ;-) > > > Thanks and greetings from Wuppertal > Max >