QoS sensor issue

Hello,

Are all these sensors using the same target port? If yes, please change this, so that each QoS-Sensor uses a different port. Also, please make sure that now firewalls or similar are blocking the packets here.

All of the QoS sensors all use different ports. As they are remote probes they all via firewalls but they all these port and others for network management.

We use the remote probes on windows machines.

Would you suggest using the QoS Reflector on a Linux OS rather than a windows remote probe for QoS? If so do you have a user guide for the QoS Reflector.

Thanks

Dear RaceIT

You have two options:

• Use a remote probe as deflector
• Use our Python script instead

The Python solution requires Linux, and Python 2.7 or newer.

Thanks for the information. I will give the Linux based solution a go

Hi, i have exactly the same error. QoS sensors are working fine since many days or months, but without any reason, stop working. After 2 hours or two days, it works again...with no reason...

This sensor is very strange, yesterday, we plan a route switching between tow sites, the master link between the sites is a optical fiber, so the QoS sensor was 4ms latency... and when we switched on our backup MPLS DSL link (40ms latency), the QoS sensor had stay to 4ms !!!!

If someone have the answer ...

Dear Sylvain

In this case, please check with a tool like Wiresharks where the UDP packets are going.

About the non-working sensor, did the sensor work for a time without any issues, or did you have the issues from the beginning? In which sense is it not working, do you get a grey status, or a red status?

Same problem for me, it works for a couple of days and then stops with error: Timeout. No packets received. (code: PE062) I change the port and it works again. The problem happens when there is no charge performed, no middle way firewall/blocks, full way between probes observed, just happens randomly, I can also change the port and then change it back after 5 minutes and it will work too.

I suspect that some traceroute or temporary port used by other application as a source port on server or some other reason which denies it to be bounded.

Using QOS between 2 remote probes, Win 2008. Thanks.

further wireshark tests, changed port, message now: Could not open UDP Port 20017. Please make sure this port is not in use. (code: PE091)

wireshark on (x.x.x.x): 1253 6.394264 X.X.X.X Y.Y.Y.Y UDP 214 60845 ? 20017 Len=172

X.X.X.X - from this probe Y.Y.Y.Y - to this remote probe

later error changed to: Timeout. No packets received. (code: PE062) Indeed no packet received in wireshark...

now both new and old ports doesnt work, on the remote server I see this in netstat:

UDP 0.0.0.0:20017 *:*

UDP 0.0.0.0:20117 *:*

I see traffic arrives suddenly in wireshark,

Hello Dimitry,

We encountered similar issues in other customer installations. Since the code of the sensor is very complex and "historically grown", we will need to do a complete rewrite of the sensor. I'm sorry for being the bearer of bad news, but we will not be able to offer a quick solution for this issue.

Best regards, Felix

I understand this is a complete rewrite, but is there a target date/release for this feature to be fixed?

Thanks, Dan

Hi Dan,

Nothing new so far. It has been addressed internally for analysis, but other topics do have higher priorities at the moment I'm afraid.

Kind regards,

Erhard

Is there any chance any progress has been made over the past 6 months? Is there a targeted date to be fixed?

Thanks!

Hi Dan,

Still nothing new I'm afraid, there were too many other things on the roadmap that had higher priority.

Kind regards,

Erhard

I'd like to bump this one up on the priority list as well. This is one of the reasons we purchased PRTG, so it's a bit disappointing that we are having issues with this sensor. Any update on this one?

Hello MannyL,

I'm afraid it was recently decided to disregard the re-write of the sensor. The reason for this is the complexity of the sensor and the work required compared to the quite low usage rate of the sensor. Sorry to have no better news at the moment. I can only recommend to consider what's been recommended earlier about trying to use aforementioned approach with the Python script.

In case you haven't done so already, please send us a support bundle regarding the issues you're having with the QoS sensors to see if there's something else we can do.

Kind regards,

Erhard

Hi Erhard.

That was an odd decision made by Paessler, I think. We use PRTG heavily throughout our organization and I frequently install PRTG in customer networks. I agree that the QoS sensor may not have as frequent use as the others. However, it is by far one of the most powerful sensors PRTG offer when it comes to troubleshooting network reliability. I have used it many times to confirm or dismiss allegations of network problems. As of now I have the problems with the QoS Round Trip sensor stopping as others have mentioned here. I have found out that when the sensor stops (goes red), I just pause it for 5 minutes and it comes back and stay operational for anywhere between 2-7 hours. Please bump this issue once more.

Regards

Hi PENO,

Thank you for your feedback, we appreciate it. The issues you describe are -among others- the reason we initially wanted to have the QoS sensors rewritten, since the code base is quite old. As stated earlier, what "hinders" development to give this priority, is the rather low usage of the sensor, within a total of 200,000 installations worldwide in relation to the necessary development needed for the rewrite. We want as many users to benefit from each hour of development work as possible.

We keep an eye on it to see how demand changes to possibly prioritize it higher again, but so far this is the current state of affairs.

Kind regards,

Erhard

Erhard/PRTG-

If you have decided to abandon the re-write of the sensor and fixing it, then at what point will you stop listing it as a usable sensor? Both of these links specifically call out probe to probe tests. https://www.paessler.com/manuals/prtg/qos_quality_of_service_round_trip_sensor https://www.paessler.com/manuals/prtg/qos_quality_of_service_sensor

Dear dnogu860,

You're assuming that the sensor works for nobody, but this is not the case.

Kind regards,

Erhard

Hello I am also having exactly the same problem. When will a fix be available?

I have a single probe and a single 'local device' it randomly stops working (generally doesn't start up again)

If the 'sensor' is 'too hard' for you to re-wite at least write a Windows service that will perform the task. Installing python etc on a Windows server isn't a practical solution for a product we're paying $1,000 for.

Its very likely not many people are using it as it DOESNT WORK! fix it and they might start using it...

Hello timau,

I cannot really argue with what you say, I'm not that happy about the circumstances either to be honest. We recentrly introduced a new way of streamlining customer's wishes, please find here more about it. In case you need assistance in posting the request, please let me know, then I will do it for you.

Kind regards,

Erhard

I had the same problems and have been following this thread for a long time.

I have to agree that it is not acceptable to continue publishing a sensor that you know doesn't work properly. You say "You're assuming that the sensor works for nobody, but this is not the case" but how do you know?

This sensor takes quite a lot of work to set up and it was very disappointing to have to abandon it after installing it in multiple sites (we got sick of the false alerts when it repeatedly stopped working). I'm not sure how you measure a sensors true demand when many people will have just abandoned it because it doesn't work. I think you also miss the point that even if the demand is lower, it's value to people who use it is very high because it measures something that is very difficult to measure with other methods. I would put it in my top 10 sensors - if it worked.

There is also a more general point. My trust in PRTG has significantly reduced. For a company to continue to publish a sensor that they know is faulty shows that Paessler aren't interested in the quality of their product. It makes me wonder how reliable your other sensors are. I've used PRTG for eight years and used to enthusiastically recommend it. Now I rate it as 'OK' when people ask about it.

I didn't want it 'lost' in my last reply but I have created a 'Feature Request' here - https://helpdesk.paessler.com/en/support/solutions/articles/82347-make-the-qos-sensor-work

If you want this fixed please make sure you up vote it.

As I said, I'm not sure that popularity is the sole best way to select what to devote resources to as it doesn't account for the value of a sensor. Also it isn't really a feature request but a bug fix!

We also had this issue with constant false alarms where we had to pause the sensor for about 10 minutes after which it sometimes started working again or we had to pause it again for 10 minutes. When it worked, it would usually run for a day or 2. What we did was to switch to the QoS Reflector (which actually does work) but this presented another issue. We still want the probe to monitor other things on this server. When we perform maintenance or server is restarted, the probe takes the port the QoS Reflector is set to use (which means the QoS reflector doesn't start). This means that every time the server is restarted, we have to log on remotely, stop the probe, start the script and then start the probe.

This is a real shame. We love this sensor for it's usefulness and we we generally control routers & firewalls etc it's not too much hassle to set up for us. is this sensor likely to get depreciated if it won't be fixed?

I am posting only because we just "attempted" to use this sensor recently and we ran into the same kinds of issues that everyone else in this thread has experienced. We were hoping this would be a good way to monitor our WAN infrastructure to 24 remote sites, all 24 sites have their own PRTG servers. So in our case it is your software talking to your software. Initially, I configured this sensor on 2-3 sites where we were suspecting issues and it seemed to work fine (for a couple of days). Each remote probe was configured using a different port as described previously. NOTE: PRTG throws a warning and will not let you create this sensor if the port is already used (seemingly). So like a fool, I spent the time to deploy this sensor to all or our remote sites worked great for a couple of hours then every single sensor started failing, this was clearly a PRTG issue because all 24 of my sites did not drop off an lose connectivity all at once with the geographic dispersion that would be nearly impossible. At this point none of them work even using the pause trick others have talked about and or deleting and re-adding the sensor it doesn't work either. Anyways, for what it's worth (doesn't really seem like you care) but, it would be nice to be able to use this as I do believe it would be beneficial. I will say after the time it took to configure it for windows and it didn't work I'm not going to waste my time building a bunch of linux boxes to run a script that I suspect doesn't work any better.

Hello,

I asked our developers about the future of these sensors; they are currently discussing about what would be the next step (re-write, bug fixes, etc.).

We will let you know when we have more information about this matter.

Kind regards.

It's been over a couple of months now. Any update on this?

Hello Jason,

I'm afraid that I do not have more information regarding this matter, the QOS sensors are still planned to be discussed.

Regards.