[atlas] (not) disconnected probes

Hi Viktor,

Thanks, I have learnt something, I didn't know about that Sanatorium 
controller. Still I am amazed that these probes are doing that at the 
exact same time, are all the probes tagged "Resolves AAAA/A Correctly" 
at the same time?

Thanks,
Romain

On 3/11/20 8:50 PM, Viktor Naumov wrote:
> Hi Romain,
> 
> I was wrong, the probe diagnostics works correctly. The probes seem 
> facing local DNS misconfiguration (cannot resolve controller) or not 
> allowed to connect to other controllers but Sanatorium. Such probes 
> connect to Sanatorium controller by IP address. When a probe is 
> connected to Sanatorium controller and tagged as "Resolves AAAA/A 
> Correctly" it gets kicked from Sanatorium to a normal controller which 
> it cannot connect due to mentioned reasons it gets into loop of 
> disconnects.
> 
> I also cannot exclude the probe USB flash corruption since it can lead 
> to weird probe behavior.
> 
> wbr
> /vty
> 
> On 3/11/20 9:32 AM, Viktor Naumov wrote:
>> Hi Romain,
>>
>> I'm checking what the problem can be. Art first glance it looks like a 
>> false positive in the probe diagnostics system. It causes probe 
>> redirect to the "Sanatorium" controller and connection flips.
>>
>> I will be back to you.
>>
>> wbr
>> /vty
>>
>> On 3/11/20 6:04 AM, Romain Fontugne wrote:
>>> Hi,
>>>
>>> I found that the following probes are reported disconnected for 
>>> several hours a day, more or less at the same time, but all their 
>>> built-in measurements are there and seem normal:
>>>
>>> https://atlas.ripe.net/probes/32639/#!tab-network
>>> https://atlas.ripe.net/probes/28818/#!tab-network
>>> https://atlas.ripe.net/probes/19107/#!tab-network
>>> https://atlas.ripe.net/probes/14831/#!tab-network
>>> https://atlas.ripe.net/probes/11982/#!tab-network
>>>
>>> These probes are in different ISPs and locations in Japan.
>>> Any idea why this is happening? something funky on the controllers side?
>>>
>>> Thanks,
>>> Romain
>>>
>>
>>
>