It's surprising, that you can't manage probe remotelly when it isn't "connected" (even you can directly reach it on L3). Technically, probe runs on Linux, so you can have SSH daemon with restricted IP access running here (listenning daemon has minimal performance overhead) - by current "behavior" you simply loose any way to diagnose problem - and dependence of established tunnel is another layer, which can fail... As stated before - simple rebooting is just a *workaround* of any issue, not a solution (but it seems that's your basic recomendation). I think you should work on improvements on probe diagnostics in such cases - new hardware versions of probes seems to be more problematic compared to older probes, as I can see also on atlas mailing list. I remember, that I had to plug out/in USB flash as some step with probe before (also your recomended "solution"). Also on probe should run some kind of watchdog, which reboots probe in case of similar problem automatically - probably it doesn't run now... With regards, Daniel On 31.7.2014 17:31, Philip Homburg wrote:
Hi Daniel,
On Tue Jul 29 19:29:20 2014, danny@danysek.cz wrote:
What checks did you performed at your side before sending such email? You don't have any kind of "emenergency" probe management, like SSH shell access directly to the device? What do you see in *your* logs about affected probe before it was disconnected?
The mail gets sent when the is not connected for some time. Nothing more.
There are no open ports on the probes. The probe can only be controlled when it is connected.
There is some evidence in the logs that there was already something wrong with the probe when it disconnected. Most likely there is something wrong with the filesystem on the USB flash drive, but that is hard to say.
Philip