[atlas] Probe reported as disconnected but is actually online

Hi Viktor,

I tried the flash drive reset procedure and now the probe is back online.

Thank you,
Boris


August 4 2016 2:47 AM, "Viktor Naumov" <vnaumov at ripe.net> wrote:
> Hi Boris,
> 
> The troubleshooting system sees that you have a number disconnects, sees connection to a
> registration server, but probe cannot make it to controller, therefore it thinks that there are
> possible firewall problems.
> 
> But if you say that you had a power outage it most probably looks like a file system corruption on
> the flash drive.
> Please try this
> https://labs.ripe.net/Members/philip_homburg/troubleshooting-ripe-atlas-probes-usb-sticks
> 
> wbr
> 
> /vty
> 
> On 8/4/16 12:17 AM, Boris Fersing wrote:
> 
>> Hi there,
>> 
>> Today I had a power failure at home and since then, my probe's state is "disconnected", but I
>> checked the network traffic and it looks like the probe is actually able to reach the internet and
>> is doing some DNS requests I don't know about:
>> 
>> U431.M<PROBES MAC>.sos.atlas.ripe.net
>> U980.M<PROBES MAC>.sos.atlas.ripe.net
>> U116.M<PROBES MAC>.sos.atlas.ripe.net
>> 
>> Do you know what those SOS requests mean? The SOS history on the atlas.ripe.net page doesn't show
>> any useful message.
>> 
>> The Status (beta) tab shows the following message:
>> 
>> =====
>> 
>> Firewall Problems Suspected
>> What does this mean?
>> Probes connect to the controlling infrastructure using SSH (via port 443). If our system detects
>> that the probe is successfully engaged in other kinds of activities, but these SSH connections
>> fail, then it's highly likely that these connections are somehow blocked or disturbed.
>> 
>> This could be because there's a firewall blocking these connections. Another reason could be that
>> there is a (transparent) proxy in the way that affects port 443 (usually HTTPS) connections, which
>> means the probe and its controller cannot mutually authenticate each other (because the proxy is
>> interfering).
>> 
>> How can I fix this?
>> Check whether you have a firewall or an aggressive NAT appliance preventing such connections. Also
>> check whether there's a transparent proxy on the path. Alternatively, you can try plugging in the
>> probe on a different network to confirm whether a firewall / proxy is really causing the problem.
>> 
>> =====
>> 
>> But since I don't know which host the probe is trying to connect to, I can't really test it and
>> tcpdump doesn't show any attempt to a port 443.
>> 
>> Thanks
>> Boris