Conversations in Network Monitor 3.0 – Cable Talk
Conversations for network protocols have been around for ages. But protocol analyzers have not been built to take advantage of them in the way NM3 does. Using the conversation tree and filters that reference conversations, make NM3 a powerful ally when trying to narrow down traffic.
It's important to note that conversations are disabled by default in NM3. This is because conversations tend to eat up memory and we wanted to be able to capture for long periods of time. You can turn on conversations from the start page or in options.
What is a Conversation with regards to networking?
In layman terms, a conversation is simply a communication stream, normally between two machines. When you call and talk to your friend on the phone, the stuff you talk about is your conversation. With networking protocols, it is much the same thing, but as with everything else in computers there are more levels of complexity.
When two machines talk to each other with a specific protocol, there is often a set of parameters that each frame has in common. Normally there is a value or values that are associated with that connection. When you look at that protocol in any frame, you should be able to determine what other frames are related by looking for the same values.
The most familiar type of conversation is the one TCP sets up when it creates its communication stream. When you computer talks to another using TCP, the first thing it does is negotiate which ports to use. This source/destination port pair defines what the conversation is for these two machines.
Conversations are Hierarchical!
Now one catch is that the source/dest port pair for TCP is specific to the pair of machines that are talking. So you may find other frames with the same source/dest port pairs, but these are not part of the same TCP Conversation. So it's important to understand that conversations can be hierarchical. The TCP source/dest pair is also dependant on the IP source/dest addresses.
So for a pair of machines, defined by their source/dest IP address, there may be many TCP conversations. And then on top of TCP, there may be multiple NBT, SMB, HTTP or other types of conversations.
Conversations not limited to connection oriented protocols
Certain protocols like UDP or ARP are called connectionless. They don't guarantee delivery of a packet and have no sense of sequence numbers. But this doesn't mean that they can't be associated in a conversation. For UDP we can use the port numbers to group those frames together. For ARP we associated the sender/target address and combine those frames into a single conversation. The only thing we need for a conversation is some basic set of parameters that we can match to say one frame is related to another.
Mommy, where do conversations come from?
When a parser is written, you have the option to define conversations for that parser. In fact you could define multiple conversations for the same parser. I won't go into all the details, but basically you tell the engine what parameters to use to correlate like packets. You can build the conversation based on the parent, or base them solely on parameters in the current frame. When you build them on the parent, you get the hierarchical nature I'm talking about above.
How can I use conversations to troubleshoot problems?
In Network Monitor 3.0, when you click on a node in the conversation tree, it automatically filters and shows you only traffic pertaining to that conversation. So for instance, if you click on an IPv4 node that is equivalent to Conversation ID 5, a filter of "Conversation.IPv4.Id == 5" is enabled. This doesn't change the display filter physically, but implicitly applies this filter so you only see that traffic displayed.
You are of course free to filter further by applying a display filter. If you right click the node in the tree and select "Copy Conversation Filter to Clipboard", you can see what filter is being applied. This will require you paste the clipboard text somewhere so you can see it. This is an easy way to add this permanently to your display filter.
This is basically part of the same kind of functionality Wireshark users know as "follow the stream". The difference though is that you can follow TCP, IPv4 and many other types of streams.
Since the conversation tree is hierarchical you can quickly see the traffic flowing between two IPv4 nodes. So if you know the machine you are interested in, you can see all traffic by clicking on the node. Further more you can drill down into each TCP conversation below it.
By the way, you'll notice the ConvID in my display that you may not have in yours. I'll explain more on this later.
So you can continue to drill down until you find the traffic you'd like to example more closely. Different protocols have different levels of information. For example you can see SMB broken down by file name followed by the SMB File ID.
In this example, you can see that HTTP traffic will list the initial HTTP command and URL. This makes it easy to find web traffic in question.
Certain parser features depend on conversations
Conversations have a purpose other than grouping frames. Today they are also used to hold state information that may be useful to other frames in the conversation. For instance, TCP keeps track of sequence numbers so it can detect retransmits and lost segments. This is done in the conversation so that you don't get collisions with duplicate sequence numbers on different ports.
Info on the ConvID = lines in My Display
Until we get some easy way to associate displayed frames with the conversation tree, I added some NPL code to display this info. This is fairly simple to add if you want the same functionality. Here's an example of how I did it for IPv4.NPL. The same thing applies to any conversation.
In NPL we create the description by calling ConversationDescription. So below you can see I simple add in the property ConvID when the conversation description for IPv4 is created.
Post.Conversation.ConversationDescription = FormatString("(%s - %s) ConvID = %d", Source, Destination,ConvID)
The Future of Conversations
Conversations are new and over time will evolve and change. There are already requests to associate the current frame with the node in the tree. Others have suggested we provide a way to filter the tree to only show relevant information. We are also hoping to someday to show specific processes and break out the traffic specific to each process.
Comments
Anonymous
January 01, 2003
This is not some existential trip or search for life's meaning. Rather this refers to a feature protocolAnonymous
January 01, 2003
The comment has been removed