On Tue, Mar 17, 2015 at 06:48:14PM +0100,
Daniel Quinn <[email protected]> wrote
a message of 14 lines which said:
> Unfortunately, the issue of rejecting should-be-valid prefixes was
> not as simple a problem and that's going to take a little longer to
> fix. We have a few people tasked now with fixing this. It's a
> known problem with how we handle comparing IPs to prefixes in our
> database and we hope to have that working in production tomorrow as
> well -- though it may take a smidge longer than that.
Apparently, it is not yet fixed? For:
{'definitions': [{'target': '2001:4b98:dc2:45:216:3eff:fe4b:8c5b',
'af': 6, 'packets': 3, 'type': 'ping', 'is_oneoff': True,
'description': 'Ping 2001:4b98:dc2:45:216:3eff:fe4b:8c5b from prefix
2000::/3'}], 'probes': [{'requested': 10, 'type': 'prefix', 'value':
'2000::/3'}]}
I get:
Status 400, reason "{"error":{"message":"__all__: Your selected
prefix is not covered by our network.","code":104}}"
But 2000::/3 is the entire IPv6 space currently allocated, all the
Atlas probes are certainly in it.
