Solved

Wireshark, Fragmented IP protocol, multicasting results?

Posted on 2007-03-29
13
8,362 Views
Last Modified: 2008-01-09
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?

0
Comment
Question by:lloydr1l
  • 7
  • 6
13 Comments
 
LVL 2

Expert Comment

by:jaredcall
ID: 18819481
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. ;)
0
 

Author Comment

by:lloydr1l
ID: 18819624
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.
0
 
LVL 2

Expert Comment

by:jaredcall
ID: 18819964
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?
0
 

Author Comment

by:lloydr1l
ID: 18820052
The destination is always 850x, and it appears the source port is always 1048.  The multicast address is typically 239.192.17.61.   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.
0
 
LVL 2

Expert Comment

by:jaredcall
ID: 18820103
Rats. From wikipedia:  "The 239.0.0.0/8 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?
0
 

Author Comment

by:lloydr1l
ID: 18820175
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.  
0
PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

 
LVL 2

Expert Comment

by:jaredcall
ID: 18821629
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.
0
 

Author Comment

by:lloydr1l
ID: 18822546
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?
0
 
LVL 2

Accepted Solution

by:
jaredcall earned 500 total points
ID: 18824024
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 224.0.0.1, which is a fairly generic one.  It also showed 239.255.255.250, 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.
0
 

Author Comment

by:lloydr1l
ID: 18824809
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 224.0.0.1 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.
0
 
LVL 2

Expert Comment

by:jaredcall
ID: 18825636
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.

Enjoy!
0
 

Author Comment

by:lloydr1l
ID: 18826232
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?  
0
 
LVL 2

Expert Comment

by:jaredcall
ID: 18826656
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!
0

Featured Post

6 Surprising Benefits of Threat Intelligence

All sorts of threat intelligence is available on the web. Intelligence you can learn from, and use to anticipate and prepare for future attacks.

Join & Write a Comment

I. Introduction There's an interesting discussion going on now in an Experts Exchange Group — Attachments with no extension (http://www.experts-exchange.com/discussions/210281/Attachments-with-no-extension.html). This reminded me of questions tha…
I previously wrote an article addressing the use of UBCD4WIN and SARDU. All are great, but I have always been an advocate of SARDU. Recently it was suggested that I go back and take a look at Easy2Boot in comparison.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

746 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now