It would be nice to be able to set architecture and firmware version
criteria when selecting probes, making the results more consistent and
avoid unnecessary measurements in certain cases.
Yang
Hello,
In https://atlas.ripe.net/measurements/2928258, I did a UDP
traceroute. "edst":"193.0.0.228" from first hop and second hop somehow
showed up in the results after the last hop that responded to
traceroute, which should have been a reply to buil-in measurement to
tt01.ripe.net. And under maps
On Thu, Nov 12, 2015 at 10:41:03AM +0100,
Chris Amin wrote
a message of 75 lines which said:
> > For instance, probes 16659, 17072, 17620, 17854 use a resolver
> > which yields a REFUSED for any request and probe 19948, 20065 one
> > with systematic SERVFAIL.
...
> The above probes are mostly
Hi Stephane, all,
On 11-nov.-15 17:36, Stephane Bortzmeyer wrote:
[Is there a better way to record enhancement requests for Atlas? Atlas
has no public issue tracker, if I'm correct?]
You are correct, to some extent -- there is a manual processing involved
in the middle ;-)
It's good that yo
Hi Stephane,
On 11/11/2015 17:36, Stephane Bortzmeyer wrote:
> [Is there a better way to record enhancement requests for Atlas? Atlas
> has no public issue tracker, if I'm correct?]
You can also send requests to at...@ripe.net, where they will be
automatically added to our issue queue. There's no
> On 11 Nov 2015, at 17:36, Stephane Bortzmeyer wrote:
>
> [Is there a better way to record enhancement requests for Atlas? Atlas
> has no public issue tracker, if I'm correct?]
>
> It would be cool to have system (automatic) tags for DNS resolution
> because some probes are using broken DNS re
