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