New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


QoS sensor issue

Votes:

1

Your Vote:

Up

Down

When editing error limits on QoS sensors we have noticed that the sensor stops working and displays "Time-out No Packets received code PE062" and then it says the sensor has not received data for X number of minutes.

But the sensors have been working fine until we edited the error limits on RTT average and Jitter average.

any ideas why this might happen ?

Thanks

prtg qos traffic

Created on Mar 14, 2015 5:44:07 AM by  RaceIT (1) 1



Best Answer

Accepted Answer

Votes:

1

Your Vote:

Up

Down

Hi there,

I'm very much afraid I don't have an update for you at the moment. There are no plans on deprecating this sensor.

I kindly ask you to vote for this issue here in case you haven't done yet: https://kb.paessler.com/en/topic/82347-make-the-qos-sensor-work

Please note that for all feature requests, we developed a "formula" which enables us to estimate the best possible priorities. So we can make as many of our customers as possible happy, while using reasonable resources.

Please find our roadmap within the following link: https://www.paessler.com/prtg/roadmap

Thank you for your understanding!


Kind regards,
Andreas Günther
Tech Support, Paessler AG

[email protected]

Created on Jul 17, 2019 7:12:07 AM by  Andreas Günther [Paessler Support]



27 Replies

Votes:

0

Your Vote:

Up

Down

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.

Created on Mar 17, 2015 12:48:12 PM by  Jochen Greger [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Mar 19, 2015 5:25:16 PM by  RaceIT (1) 1



Votes:

0

Your Vote:

Up

Down

Dear RaceIT

You have two options:

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

Created on Mar 23, 2015 2:46:51 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Mar 24, 2015 10:24:05 AM by  RaceIT (1) 1



Votes:

0

Your Vote:

Up

Down

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 ...

Created on Jun 2, 2016 11:46:06 AM by  Sylvain Brucker (0) 2



Votes:

0

Your Vote:

Up

Down

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?

Created on Jun 2, 2016 12:29:14 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Aug 5, 2016 5:58:38 PM by  Dmitry Sherman (0) 1



Votes:

0

Your Vote:

Up

Down

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...

Created on Aug 5, 2016 6:15:20 PM by  Dmitry Sherman (0) 1



Votes:

0

Your Vote:

Up

Down

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,

Created on Aug 5, 2016 6:33:12 PM by  Dmitry Sherman (0) 1



Votes:

0

Your Vote:

Up

Down

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

Created on Aug 8, 2016 8:36:36 AM by  Felix Saure [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Thanks, Dan

Created on Sep 28, 2016 4:43:24 PM by  dnogu860 (0) 1



Votes:

0

Your Vote:

Up

Down

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

Created on Sep 29, 2016 1:14:44 PM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Thanks!

Created on Jan 10, 2017 3:02:32 PM by  dnogu860 (0) 1



Votes:

0

Your Vote:

Up

Down

Hi Dan,

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

Kind regards,

Erhard

Created on Jan 11, 2017 8:04:44 AM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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?

Created on Apr 26, 2017 4:37:53 PM by  MannyL (0) 1



Votes:

0

Your Vote:

Up

Down

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

Created on Apr 27, 2017 12:36:19 PM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Jul 14, 2017 10:30:50 AM by  PENO (0)



Votes:

0

Your Vote:

Up

Down

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

Created on Jul 14, 2017 1:09:02 PM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Jul 14, 2017 1:12:34 PM by  dnogu860 (0) 1



Votes:

0

Your Vote:

Up

Down

Dear dnogu860,

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

Kind regards,

Erhard

Created on Jul 17, 2017 10:47:39 AM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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...

Created on Sep 3, 2018 11:58:13 PM by  timau (0) 1



Votes:

0

Your Vote:

Up

Down

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

Created on Sep 4, 2018 1:56:08 PM by  Erhard Mikulik [Paessler Support]

Last change on Nov 7, 2018 7:12:36 AM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Nov 6, 2018 4:58:37 PM by  JasonP (24) 1



Votes:

1

Your Vote:

Up

Down

I didn't want it 'lost' in my last reply but I have created a 'Feature Request' here - https://kb.paessler.com/en/topic/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!

Created on Nov 6, 2018 5:19:10 PM by  JasonP (24) 1



Votes:

0

Your Vote:

Up

Down

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.

Created on Jun 20, 2019 8:51:37 AM by  Rille_lkp (0)



Votes:

0

Your Vote:

Up

Down

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?

Created on Jul 16, 2019 1:40:14 PM by  nocDan (0) 2



Accepted Answer

Votes:

1

Your Vote:

Up

Down

Hi there,

I'm very much afraid I don't have an update for you at the moment. There are no plans on deprecating this sensor.

I kindly ask you to vote for this issue here in case you haven't done yet: https://kb.paessler.com/en/topic/82347-make-the-qos-sensor-work

Please note that for all feature requests, we developed a "formula" which enables us to estimate the best possible priorities. So we can make as many of our customers as possible happy, while using reasonable resources.

Please find our roadmap within the following link: https://www.paessler.com/prtg/roadmap

Thank you for your understanding!


Kind regards,
Andreas Günther
Tech Support, Paessler AG

[email protected]

Created on Jul 17, 2019 7:12:07 AM by  Andreas Günther [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.