[atlas] Probe reported as disconnected but is actually online

surely a fsck via the mini operating system, of the affected flash drive file system should able to be attempted remotely before reinstall of new image ?

Colin

> On 4 Aug 2016, at 13:08, Boris Fersing <ripe at fersing.eu> wrote:
> 
> 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
>