[atlas] Probe reported as disconnected but is actually online

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
>