I have a couple of QoS Round Trip sensors. Occasionally the sensor will fail with the error: "Could not open UDP Port xxx. Please make sure this port is not in use. (code: PE091)" Restarting both probes does not help. The only workaround I found is to change the port each time it happens and it fixed the sensor for a while until it happens again.
The ports I'm using are completely random and not used by any other service, also it works for several days fine before it fails.
PRTG version 15.1.15.2022
Article Comments
I have changed the ports to have a gap and it still happens. Now 2 our of 3 are failed with this error.
Apr, 2015 - Permalink
I created a normal (One way) QoS sensor as well. So far it is not having an issues. I just had 2 of the sensors fail again right now. I also have a 3rd round trip sensor that is not having the issue.
May, 2015 - Permalink
Weird. Did you already check our python solution for QoS RTT? It works better in some environments sometimes than the remote probe implementation. Note that you might need CygWin in order to run it on Windows.
May, 2015 - Permalink
I'm seeing something similar. I just created this sensor, and it worked for a few minutes, and then stopped with "Could not open UDP Port 50010. Please make sure this port is not in use. (code: PE091)" This is the only QoS probe we have in our environment, and i dont want to use the python reflector.
Screen grabs http://screencast.com/t/cOdRz1xySCO http://screencast.com/t/ILWVSczTEJBt
PRTG 15.2.17.2636 (local probe)
Jun, 2015 - Permalink
We probably found a bug in the behavior of QoS sensors that could cause this.
I'll keep you posted.
Jun, 2015 - Permalink
Any update on this bug? I'm seeing the same issue - qosreflector script running on a remote Raspberry Pi.
Sep, 2015 - Permalink
Can you check if there's any broadcast traffic on the ports you're using for the QoS sensors? That was the issue a customer was facing. Aside from that, the latest stable includes some fixes in the QoS - Probe connection code.
Sep, 2015 - Permalink
We need a bit more info here. What have you tried so far? Port diversity, checked for broadcasts arriving at the hosts?
Jul, 2016 - Permalink
I too am having this issue as recently as today. I was running 16.3 and I am upgrading to 16.4 now. Thanks
Oct, 2016 - Permalink
Same as for the others, we'll need more information here. What's your port range, any broadcast traffic in those networks, how many QoS sensors, etc. :)
Oct, 2016 - Permalink
Hi Diego,
If you provide me with more information regarding the issue (port range, any broadcast traffic in those networks, how many QoS sensors, etc.), then I can possibly help you with the issue :)
Kind regards,
Stephan Linke, Tech Support Team
Mar, 2018 - Permalink
Has this been resolved? It's been 3 years since this discussion opened and I am still having the same problem.
Feb, 2019 - Permalink
I am still having this and still fixing by changing the port. I have a suspicion that this is a firewall problem. There could be a stale session on the firewall that prevents the traffic from passing. I did not fully confirm that yet.
Yuval
Mar, 2019 - Permalink
Hi there,
As mentioned by my colleague Stephan Linke we need more information regarding the issue (port range, any broadcast traffic in those networks, how many QoS sensors, etc.). With this we may be able to help you. You can also open a case by writing a mail at support@paessler.com.
Kind regards,
Birk Guttmann, Tech Support Team
Mar, 2019 - Permalink
What ports are the sensors using exactly? They need to have a gap between them, like this: 5000, 5050, 5100, etc. Is that the case?
Apr, 2015 - Permalink