2

I have an application that relies on port 63000 for communicating with other devices over the network.

Some while ago this app stopped working on the PC.

I tried all sorts of firewall configs, ON/OFF etc but no effect.

Today I noticed that even without the application running, WireShark reported the following every 2 seconds:

No  Time    Source       Destination Ptrcl Length Info
272 10.1529 192.168.1.46 239.0.0.1   UDP   157    Source port: 49181  Destination port: 63000

I think whatever is responsible for this might be the cause of the issue with this other application.

The problem is the port mentioned (49181 and 63000) are only showing up in WireShark.

I cannot see anything in Windows Reseurce Monitor, nor with netstat.

Questions:

  1. How can I identify what is responsible for this data packet?
  2. Is this a WireShark red herring? I think not because it is the only thing I have found that could explain my issue with the other application.
1
  • look into the packets to see whether there is any clear text information in there to give you a clue as to what these packets are. Also, are you sure that no components of your application are running? Something on your machine is broadcasting to a port specified as used by that application. Also, does your application use TCP:63000 or UDP:63000? And does it use broadcast? – Xalorous Oct 7 '16 at 14:47
1

The IP address 239.0.0.1 is a multicast address which is broadcasted on your network for Multicast purposes such as joining a multicast session.

Multicast IP addresses are class-D addresses that fall within two ranges: 224.0.0.0 through 239.255.255.255

For intranet use, it is recommended that you use IPv4 addresses in the range 239...*. Port numbers can range between 1 and 65535

To answer your question:

1) How can I identify what is responsible for this data packet?

Looking at the WireShark output, you can see the source address which is 192.168.1.46. This is the device where it came from.

2) Is this a WireShark red herring? I think not because it is the only thing I have found that could explain my issue with the other application.

No, you are not seeing this on your server because it isn't a service that is hosted on your server, so there is no interface that is listening for this particular IP range or destination port.

I don't think this is your root cause for the application not working. If your application service is listening on port 63000, it would simply reject the connection coming from the device that is broadcasting the multicast session. Also, this is using UDP protocol, and your application might be using TCP which would not be related directly.

If you think that this device is the root cause, find out what 192.168.1.46 and do some investigation in regards to multicasting.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.