We notice that FTP sensors switch from explicit to implicit mode when the sensor doesn't receive data or when the connection time-outs.
There is then made an log entry: Connection established using implicit mode.
We have 2 nodes for checking. This message applies for one of the two nodes, the other node stays using port 21 explicit mode. However the node isn't noted down in the message. When PRTG (or the single node) switches to implicit mode it uses port 990 instead of 21 and keeps using this until the sensor gets paused. So it doesn't seem to reset or detect that port 21 explicit mode becomes functional again. The only way to assure that port 990 isn't used is to choose "Do not use Transport-Level Security" bu this completely disables ssl.
This comes down to these requests:
FIX: Correct logging; noting down the Node that switched mode. IMPROVE: Detection that port 21 explicit is working again and switching back from explicit. ADD: Have the ability to configure the sensor to use implicit or explicit mode. As an alternative; force to always use the configured port.
The last one is the most important for us because it gives us to control how measurements are done and also makes them more predictable (or less unpredictable).
Article Comments
Hmm I don't think that is fully understood that these shortcomings of PRTG and FTP sensors is a serious production issue for us. Also, I invested quit some time in making this post so there is enough information to do something about this. Expecting to get at least a decent reply back. A short reply with only that this "workaround" won't get implemented isn't then very professional to my opinion.
So: 1. Could you please explain to me what is meant with a "workaround"? 2. What do the devs have to say about PRTG not honoring the configured port in the FTP sensor settings and just randomly using another port when switching modes?
Jan, 2016 - Permalink
Sorry for the late reply. Just so we're on the same page here - are you using the most recent PRTG version? Because this sounds like old behaviour of the FTP sensor...
Feb, 2016 - Permalink
We are currently at v16.1.21.1422+ Before that the most recent version of v15. Both are having the same issues.
Feb, 2016 - Permalink
Sorry that it took a while to get back on this. We talked about this in our development team and the problem itself originates in the sensor timing out. Is there a way for you to fix this? Because unfortunately, there is no easy way to fix this within the sensor as this is their "fallback" method. Other customers don't have any trouble with it so far (this feature is implemented since mid 2014).
Feb, 2016 - Permalink
Thanks for the request! I'll forward this to our developers and let you know what they said :)
Jan, 2016 - Permalink