Wireshark, Fragmented IP protocol, multicasting results?

I'm new to Wireshark, and still trying to learn how to interpret results.  What kind of traffic is this:
Source IP is from one of our servers, and is in a private range
Destination is a 239.x.x.x address, which I understand is multicast
Protocols are UDP source port 1048 destination port 850x, and IP with each listed as "Fragmented IP Protocol" and then some more info in (xxxx)
UDP is highlighted in light blue
IP is not highlighted and appears to be almost grayed out, real faint

This sever is used for our phone system, which is Altigen.

So what does the traffic mean, and why would our phone system be multicasting?

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Phone system could be attempting to discover other phone nodes on the same network.  VOIP?

Is the destination port always the same?  If so what is it?  850x is _nearly_ helpful. ;)
lloydr1lAuthor Commented:
No, we don't use VOIP.  No, the destination port is not always the same.  Usually 8501, 8502, or 8503 from what I can see.  So when I see an IP address beginning with 239, that means it's multicasting on our own network?  I'm confused about where this traffic is being sent to.
is the destination port always 850x, or does it go up higher than that?  Is the source port always the same?

What is the specific multicast address?
Webinar: Miercom Evaluates Wi-Fi Security

It's not just about Wi-Fi connectivity anymore. A wireless security breach can cost your business large amounts of time, trouble, and expense. Plus, hear first-hand from Miercom how WatchGuard's Wi-Fi security stacks up against the competition in our upcoming webinar!

lloydr1lAuthor Commented:
The destination is always 850x, and it appears the source port is always 1048.  The multicast address is typically   It seems I saw another one listed in a capture, but in reviewing some captures in order to answer your question, I only see this address.
Rats. From wikipedia:  "The range has been assigned by RFC 2365 as a locally administered address space with local or organizational scope"

So, it's not an industry standard multicast, which makes it a bit difficult to find.  Is there any readable text in the data portion of the packets?

Can you put the trace somewhere I can download it?
lloydr1lAuthor Commented:
So 239 traffic is not leaving the network then.  Nothing is readable in the data field; just a bunch of text and numbers.  By trace are you refering to the capture file?  If so, not sure I'm comfortable doing that.  
I seriously doubt that the 239 traffic is leaving your local LAN.  You can be sure by plugging your outbound router into a hub (not switch) and then plugging another cable from the hub into wherever your router was previously plugged into.  Then, plug your PC into the same hub and take the trace.  

In order to take the trace, It doesn't matter much if you get an IP address or not.  You can even put in your own mismatched static IP address if you like.  The important thing is to put your PC in a position to capture the traffic going out the router.  If you can do this with 2 PCs at the same time, one where you've already seen the 239 traffic, and one on the other side of your router, then that's an even better test.

I understand about being reluctant with the trace.  No worries.
lloydr1lAuthor Commented:
Putting it outside the router and seeing if anything in 239 shows up is a good idea.  I'll have to see if I can set that up.  As for why the phone system would be sending out multicast packets on our network?  I just had a thought, maybe someone can confirm this might be the traffic, we have people that have a supervisory program on their workstations that monitor the various phone system workgroups.  Could the multicast traffic be the same information being sent out to each of these programs on various pc's?
Absolutely.  That could very well be it.  

Did a little digging, here's what I found.  To show the list of multicast listeners on a WinXP PC, run the following command from a command prompt:
  netsh interface ip show joins

On mine, it showed, which is a fairly generic one.  It also showed, which I found to be associated with Universal Plug and Play discovery.

I'd bet that if you run this same netsh command on the supervisory workstations, you'll find them listening.  Let me know.  You've got me curious.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
lloydr1lAuthor Commented:
Bingo!  I ran the command on a workstation which had the supervisory program and one that did not.  With the program it displayed the exact IP address from the phone server, without the program just the address.  So that appears to be the mulitcast traffic in question.  So you got the points.  

Up for any more Wireshark questions?  How about this one (and if you want more points, I will gladly give them to you).  Wireshark automatically colors certain packets, and one of them is dark red for TCP RST.   So what is the purpose of the program automatically colorizing these packets and others?  Is there something I should be looking at when Wireshark highlights the TCP RST packets?

Thanks for your help so far.
I'm happy to help in any way I can.

The coloring rules (which can be edited to suit in the Wireshark preferences) are only for readability.  Though it might not seem like that at first, as certain packet traces (captures) can end up giving you a headache looking at the resultant colors.

RST packets can be indicative of a problem, but they can also be normal.  Here are two examples:

Problem:  You are trying to FTP to a server, but you get no response, that the connection was rejected or somesuch.  You take a trace, and see the following:
1) workstation sends SYN --> server on port 21
2) server sends back RST on port 21

This means that the TCP/IP stack on the server got the packet, saw that it had no listening services in port 21, and send you back a RST.  Your workstation receives the RST (reset) and resets the TCP connection.  The TCP/IP stack tells your FTP client that the connection was reset, and the application in turn sends you some error message to that effect.

Normal:  You're browsing the web with Internet Exploder or some other browser.  Every .html page that gets requested, as wellas every .gif, jpg etc all typically get requested with independent TCP connections.  Every connection that gets opened needs to get closed down too.  It can be closed with a "nice" ending, which takes several packets, optional timeouts, etc.  OR, it can be closed with a RST.  RSTs are faster ways to close the connection, but it makes for a bit of analytical noise when you're trying to look at a trace.

I hope that makes sense.  I also hope that you're finding that many things can be captured with Wireshark (or other tools) and you can learn a lot about how things work by looking at the capture.  A little practice and a little research can tell you basically what's happening much of the time.

lloydr1lAuthor Commented:
Thanks for the explanation.  I'll have to look at those instances of TCP RST and see what version I have, normal or problem.  I suspect I have the problematic kind.  Here's some background on why I am even looking at Wireshark.

This week our network connection started dropping out, but only very briefly.  If you were surfing the Internet, it might not even be noticed, but we have a VPN connection back to our corporate offices, over which we run a program that uses Telnet.  And people that happen to have that program or any other that uses the VPN connection to corporate, notice their applications freezing, and have to log back in.  And they are able to log right back in.

Up until this happens, one does not notice any slowness in the network, nor afterwards.  Bandwidth stays consistent.  Corporate has looked at it and says their connection is staying up with the firewall, so they say it is on our end.  I have talked to the ISP, but they see nothing on their circuits to cause the problem.

I have shut everything down 3 different times.  I've run a continuous ping out to the Internet while people lose connectivity, yet do not see myself losing any packets, and the times remain in the 50's and 60's on average.  I have observed the switches we have (5), and there does appear to be significant broadcasting going on, but then I'm not sure.  I'm not really sure how often all lights should flash, or if this just isn't background noise.  

While observing the switch, not one single connection seems overly loaded as if that workstation were doing something malicious.  Instead, traffic patterns are random as one would expect (although very busy).  

So finally, I decided to try Wireshark to see if I can find the source of all the traffic.  Yet in reading the results from multiple captures, I have yet to see one IP address on the network that isn't doing something that would be considered normal.  At least to my knowledge level.  I see what looks like normal web traffic, Telnet traffic, mail traffic, broadcasting, and before mentioned multicasting.

And again, when I see broadcasting, I'm not sure when enough is enough.  I don't see where someone is streaming music or video, and I don't see any obvious examples of spyware and such.  It seems though that the broadcasts are excessive, and I'm wondering if the problem isn't switch born, maybe a bad switch.

At any rate, a better understanding of Wireshark should help.  Now if I can only figure out how to use the I/O graph better, that might help.  Is there a way to use the graph to show a traffic breakdown by IP address?  
Here's another suggestion -- find a "server monitor" like netgong or isitup (google for them) and monitor the telnet port (port 23).  If it doesn't go down, then you might be seeing an application issue, not a network issue.

Those tools are not free, but they're cheap. I can't vouch for either of them, but I imagine either would work.

I've never used the I/O graphing before -- sorry on that one.

Some broadcasting is normal.  ARP, DHCP, etc all use broadcasting.  

Try R-clicking on a packet and creating filters based on a particular packet.  Look at the resulting filter that is typed out in the filter field.  Learning to use these filters will be a big help.  It also looks impressive to people looking over your shoulder when you say "Oh, I just started  using this last week."  <grin>

Have a great weekend!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Networking Protocols

From novice to tech pro — start learning today.