Login

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

QoS sensor randomly fails with code PE091 (port is in use)

Votes:

0

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

pe091 qos-roundtrip sensor

Created on Apr 26, 2015 7:35:54 AM

19 Replies

Votes:

0

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?

Created on Apr 28, 2015 11:46:35 AM by Stephan Linke [Paessler Support]

Last change on Apr 28, 2015 11:53:10 AM by Stephan Linke [Paessler Support]

Votes:

0

It is currently using ports: 20670, 50009, 50002

Created on Apr 28, 2015 2:14:46 PM

Votes:

0

I have changed the ports to have a gap and it still happens. Now 2 our of 3 are failed with this error.

Created on Apr 29, 2015 9:04:40 AM

Votes:

0

Can you check if the normal QoS sensors work properly for a while?

Created on Apr 29, 2015 1:41:00 PM by Stephan Linke [Paessler Support]

Votes:

0

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.

Created on May 6, 2015 8:25:10 AM

Votes:

0

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.

Created on May 6, 2015 9:28:22 AM by Stephan Linke [Paessler Support]

Votes:

0

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)

Created on Jun 10, 2015 6:53:03 PM

Votes:

0

We probably found a bug in the behavior of QoS sensors that could cause this.
I'll keep you posted.

Created on Jun 11, 2015 6:32:20 AM by Stephan Linke [Paessler Support]

Votes:

0

Any update on this bug? I'm seeing the same issue - qosreflector script running on a remote Raspberry Pi.

Created on Sep 1, 2015 5:33:27 PM

Votes:

0

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.

Created on Sep 1, 2015 5:46:55 PM by Stephan Linke [Paessler Support]

Votes:

0

Hello, I have the same issue. How can we fix that?

Created on Jul 22, 2016 1:02:22 PM

Votes:

0

We need a bit more info here. What have you tried so far? Port diversity, checked for broadcasts arriving at the hosts?

Created on Jul 25, 2016 6:46:52 AM by Stephan Linke [Paessler Support]

Last change on Jul 25, 2016 6:47:11 AM by Stephan Linke [Paessler Support]

Votes:

0

I too am having this issue as recently as today. I was running 16.3 and I am upgrading to 16.4 now. Thanks

Created on Oct 26, 2016 9:31:36 PM

Votes:

0

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

Created on Oct 27, 2016 12:35:32 PM by Stephan Linke [Paessler Support]

Votes:

0

Same problem here, on 18.1.38.11934

Is there any solution?

Thanks

Created on Mar 16, 2018 1:26:55 PM

Votes:

0

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

Created on Mar 19, 2018 9:28:54 AM by Stephan Linke [Paessler Support]

Votes:

0

Has this been resolved? It's been 3 years since this discussion opened and I am still having the same problem.

Created on Feb 28, 2019 4:31:44 PM

Votes:

0

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

Created on Mar 1, 2019 11:59:19 AM

Votes:

0

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 [email protected].

Kind regards,
Birk Guttmann, Tech Support Team

Created on Mar 5, 2019 12:53:30 PM by Birk Guttmann [Paessler Support]

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.