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@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@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-prob...
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