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" <[email protected]> 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
