NMParsers Discussions Rss Feed

New Post: SCCP, MGCP and EIGRP (Cisco Protocols) not supported in Microsoft NetMon

cecijohn — Wed, 20 Mar 2013 16:32:11 GMT

Hey Paul,

Up until I found out about Microsoft Network Monitor, I was using another network packet capture/analyzer called Wireshark, which is also a free program. It is pretty much the Gold Standard when it comes to network packet capture analysis. What it does is that it allows you to choose which network interface(s) on your machine that you want to analyze packets and it will capture all of them. When you click on an individual packet in a trace, it separates all of layers according to the Internet/OSI model (i.e. Physical Layer, Data-Link Layer, Network Layer, Transport Layer, and Application Layer). It recognizes pretty much every known protocol in the market today, and if it detects it, you can add a filter to show only packets from that protocol. What's even more impressive for me as a VoIP specialist, is that it has a "VoIP Calls" option which allows you to view all VoIP calls that passed through the interface, and it will show a graph of the message and media transactions between all nodes involved.

However, There are a couple of flaws with Wireshark. They are:

1) Does not support all interfaces types on a Windows Machine, ie. VPN connections, Some IPv6 Tunnel Broker client interfaces

2) Choosing a network interface to capture is not always entirely clear as it shows it's Device ID rather than what is named in Windows Network Connections
For example: In Network Connections, one interface is named "Wireless Network Connection". In Wireshark, it's shown as "Microsoft: \Device\NPF_{4C968491-1244-4B63-916D-62EAD36268DE}". Message Analyzer (and NetMon) also did this, and I would like to see at least some kind of clear-cut correlation of the two.

3) You cannot separate traffic via the application that used it in Wireshark. For example: In Microsoft Network Monitor, with my VoIP Phone client program, I was able to see all transactions between the VoIP client and the VoIP server. This cannot be done in Wireshark, and I have not seen it in Message Analyzer. This is a feature that should have been passed over from Network Monitor to Message Analyzer, so please bring it back!

4) Packet capture sizes can become quite large over small periods of time and you may not even be able to open a capture that you made if it becomes too big.

Overall, if Wireshark addressed these issues, it would be perfect. In my opinion, if you can model the network analysis portion of Message Analyzer to mirror Wireshark while addressing all of Wiresharks short-comings as mentioned above, there's no question I would use Message Analyzer. But for now, I'll continue to use the combination of Wireshark and Network Monitor for my packet analysis needs! I'll say this though, Network Monitor was on the right track, it just lacked the protocol support (ie. Skinny, MGCP, EIGRP) and didn't have the graph options or VoIP call options.

I hope this helps. Let me know if you need any more opinions. I am glad to help!

Thanks,

John

New Post: SCCP, MGCP and EIGRP (Cisco Protocols) not supported in Microsoft NetMon

cecijohn — Wed, 20 Mar 2013 15:46:34 GMT

New Post: SCCP, MGCP and EIGRP (Cisco Protocols) not supported in Microsoft NetMon

cecijohn — Tue, 19 Mar 2013 22:36:07 GMT

New Post: SCCP, MGCP and EIGRP (Cisco Protocols) not supported in Microsoft NetMon

cecijohn — Tue, 19 Mar 2013 19:27:24 GMT

Hey Paul,

Other than Microsoft Network Monitor, I primarily use another network packet capture/analyzer called Wireshark, which is also a free program. It is pretty much the Gold Standard when it comes to network packet capture analysis. What it does is that it allows you to choose which network interface(s) on your machine that you want to analyze packets and it will capture all of them. When you click on an individual packet in a trace, it separates all of layers according to the Internet/OSI model (i.e. Physical Layer, Data-Link Layer, Network Layer, Transport Layer, and Application Layer). It recognizes pretty much every known protocol in the market today, and if it detects it, you can add a filter to show only packets from that protocol. What's even more impressive for me as a VoIP specialist, is that it has a "VoIP Calls" option which allows you to view all VoIP calls that passed through the interface, and it will show a graph of the message and media transactions between all nodes involved.

However, There are a couple of flaws with Wireshark. They are:

1) Does not support all interfaces types on a Windows Machine, ie. VPN connections, Some IPv6 Tunnel Broker client interfaces

2) Choosing a network interface to capture is not always entirely clear as it shows it's Device ID rather than what is named in Windows Network Connections
For example: In Network Connections, one interface is named "Wireless Network Connection". In Wireshark, it's shown as "Microsoft: \Device\NPF_{4C968491-1244-4B63-916D-62EAD36268DE}". Message Analyzer (and NetMon) also did this, and I would like to see at least some kind of clear-cut correlation of the two.

3) You cannot separate traffic via the application that used it in Wireshark. For example: In Microsoft Network Monitor, with my VoIP Phone client program, I was able to see all transactions between the VoIP client and the VoIP server. This cannot be done in Wireshark, and I have not seen it in Message Analyzer. This is a feature that should have been passed over from Network Monitor to Message Analyzer, so please bring it back!

4) Packet capture sizes can become quite large over small periods of time and you may not even be able to open a capture that you made if it becomes too big.

Overall, if Wireshark addressed these issues, it would be perfect. In my opinion, if you can model the network analysis portion of Message Analyzer to mirror Wireshark while addressing all of Wiresharks short-comings as mentioned above, there's no question I would use Message Analyzer. But for now, I'll continue to use the combination of Wireshark and Network Monitor for my packet analysis needs! I'll say this though, Network Monitor was on the right track, it just lacked the protocol support (ie. Skinny, MGCP, EIGRP) and didn't have the graph options or VoIP call options.

I hope this helps. Let me know if you need any more opinions. I am glad to help!

Thanks,

John

New Post: SCCP, MGCP and EIGRP (Cisco Protocols) not supported in Microsoft NetMon

PaulLong — Tue, 19 Mar 2013 16:13:40 GMT

Yes, thanks for the documentation pointers. That will help.

Regarding the Network Interface, it's certainly has changed. We now have Trace Scenarios because we are more than just a network sniffer, we can analyze many streams of data from different sources and formats. However, I see where we could make it easier to support the "Capture From Network Interface" scenario. At this point Link Layer captures all Network Interfaces by default. And you could take that as a start and create a scenario you would use most often and save it to the list. So perhaps that's a mitigation for now.

Regarding the previous capture and process info, we haven't implemented that yet. But it's on our radar and if we don't get it for v1, you won't have to wait too long for a refresh of some sort.

In terms of what you need to analyze this traffic, what do you use? Do you think that our visualizations could help? What types of diagnosis would help you see problems?

Thanks,

Paul

New Post: SCCP, MGCP and EIGRP (Cisco Protocols) not supported in Microsoft NetMon

cecijohn — Mon, 18 Mar 2013 16:12:52 GMT

Hey Paul,

Thanks for the reply Paul. The protocols SCCP and MGCP are pretty well known protocols in Cisco VoIP. For example, SCCP is used for Cisco IP phones to register with the Cisco Unified Communications Manager (CallManager) and analyzing the transactions between the two can help determine issues with registration. MGCP is also a call-processing protocol. EIGRP as you may know is a Routing protocol. Unfortunately I cannot find RFCs or detailed specifications for SCCP, but there are for EIGRP and MGCP. Here is all the info I can gather on them:

SCCP = Skinny Call Control Protocol (Usually just referred to as Skinny)
Runs over TCP, on port 2000
Note: This shouldn't be confused with the Signalling Connection Control Part from SS7 Signalling Stack
http://en.wikipedia.org/wiki/Skinny_Call_Control_Protocol
http://wiki.wireshark.org/SKINNY

EIGRP = Enhanced Interior Gateway Routing Protocol
RFC = http://tools.ietf.org/html/draft-savage-eigrp-00

MGCP = Media Gateway Control Protocol
RFC = http://www.ietf.org/rfc/rfc2705.txt

By the way, thanks for letting me know that Message Analyzer was the new NetMon. I installed it already, although it does look a bit more confusing than Network Monitor. For example, it's not clear how to choose which Network Interface I want to monitor because the names are not the same as the connection names. Also when I open up a previous capture, I cannot separate the traffic based on which application it was using. I hope these will be addressed in the final release.

Thanks!

John

New Post: SCCP, MGCP and EIGRP (Cisco Protocols) not supported in Microsoft NetMon

PaulLong — Mon, 18 Mar 2013 13:34:48 GMT

If you mean proprietary, there is no public documentation, then that would be a problem. And for Network Monitor, it's at the end of it's life as we are moving on to Message Analyzer (http://blogs.technet.com/MessageAnalyzer).

But I you know of detailed RFC or specification, we could put it on our list for Message Analyzer. Also perhaps you could add some justification here so we understand why it might be a priority for you. It would be nice to understand how you troubleshoot with these protocols and in what scenarios they are important for you.

Thanks,

Paul

New Post: SCCP, MGCP and EIGRP (Cisco Protocols) not supported in Microsoft NetMon

cecijohn — Fri, 15 Mar 2013 18:28:00 GMT

Hey Everyone,

I love using Microsoft NetMon, but I was wondering why it doesn't support Cisco proprietary protocols such as SCCP, MGCP, and EIGRP (Although EIGRP recently became Open Standard). I would love to see those added to the support of this program, but I'm not much of a coder :(.

Thanks!

John

New Post: Some questions about reassembly

PaulLong — Thu, 03 Jan 2013 15:59:15 GMT

For some protocols we've created a way to see only the relevant fragments (http://blogs.technet.com/b/netmon/archive/2010/11/04/reassembly-made-easier.aspx). Let me know if you need more details or if this doesn't solve your problem.

We don't have a way to do "Embedded Reassembly", as we call it. Though this is something that we do support in Message Analyzer if a beta product is an option for you. (http://blogs.technet.com/b/messageanalyzer/)

As for parsing TCP streams, we do have problems when the frames don't line up with the TCP boundaries. If this is what you are referring too, this is something we are addressing with Message Analyzer.

Thanks,

Paul

New Post: I cant install the newest version on Windows &.

Renee — Mon, 31 Dec 2012 18:59:04 GMT

I receive an error message in attempting to install it in 64bit win7:

Error reading from file C:\users\Renee\appdata\loca\temp\ixp000.tmp\netmon.msi verify that the file exists and that you can access it.

I can access it but I cannot install it.

Renee

New Post: Some questions about reassembly

JohnKare — Fri, 28 Dec 2012 06:43:25 GMT

Is there a way to show only the final defragmented frames of a specific protocol? It seems like that would be very easy to archive by using the reassembly engine for non-fragmented frames too.

Can you split up frames? I'm working a protocol where multiple messages are sent in a single TCP frame. I'd very much prefer a linear list of messages instead of having to inspect each frame to see if there's more.

And finally, can you parse TCP streams where the TCP frames has no relation to the payload's frames?

New Post: new raw IP driver

ugottrei — Sat, 17 Nov 2012 23:32:11 GMT

hi,

I'm developing an NDIS driver (raw IP one) for a new wireless technology which is an extension of wifi (to be more specific 802.11ad)

I would like to ask the following questions:

1. assuming that I can export management and control frames out from my driver up to the OS, how can I "connect" Network Monitor parsing tool to my driver?

Note: I don't want to save these frames in *.pcap format and open them offline... I want the same behavior as wifi driver i.e. have in the same capture file interleaved wifi management and control messages as well as IP packets. The problem is that my driver supports different set of API than std. wifi driver

2. I tried to open wifi capture from WireShark (can be downloaded from WireShark wiki web site) with Network Monitor but the Network Monitor tool was unable to identify the wifi packet. instead, I got the following error message from the parser: Unsupported Media Type.

in the PCAP header, the 'network' field (data link type) is set to 105 (LINKTYPE_IEEE802_11). could that be the problem?

Thanks,

Uri.

New Post: Parser for Hyper-V vmSwitch, Not exist EventID 55

MikeH2010 — Fri, 06 Jul 2012 15:02:32 GMT

Problem solved.

After downloading the current version from the source code section and using these files all the packets were identified.

I had to tweak a few unresolved datatypes. But in the end it worked.

I hope there will be a new version out real soon, so it is easier to work with.

New Post: Parser for Hyper-V vmSwitch, Not exist EventID 55

MikeH2010 — Fri, 06 Jul 2012 08:35:29 GMT

Hi!

I tried to capture data from a Microsoft Hyper-V V3 virtual switch. I used

netsh trace start scenario=InternetClient provider=Microsoft-Windows-Hyper-V-VmSwitch capture=yes capturetype=vmswitch

When I load the etl-file into network monitor and use the current parser version 3.4.2774, I cannot see the TCP traffic. Instead I see lots of NDIS packets like this:

3045 17:26:42 04.07.2012 3.5658375 NDISPacCap_MicrosoftWindowsNDISPacketCapture NDISPacCap_MicrosoftWindowsNDISPacketCapture:Not exist EventID {NDISPacCap_MicrosoftWindowsNDISPacketCapture:56, NetEvent:55}

I think the problem is the

Not exist EventID

Maybe I need a newer parser file for Windows 8 and Server 2012 captured packets?

Thanks

New Post: Bit fields from content in hexadecimal notation.

pf1957 — Wed, 13 Jun 2012 18:13:12 GMT

Never mind,

thanks for your time, pf

New Post: Parsing fragmented TCP stream

pf1957 — Wed, 13 Jun 2012 18:10:51 GMT

PaulLong wrote:

So your NPL code might look like this:
[RegisterBefore(...)]
[PayloadStart(NetworkDirection, 0, 0, 0, Property.MyProtLength, Property.IsFirst, 0, RssmblyIndStartBit + RssmblyIndLengthBit + RssmblySelfBit)]
Protocol MyProt
{
	[Property.MyProtLength]
	UINT16 Length;
	BLOB(Length) myblob;
}
So the trick is not to make Property.IsFirst follow the right pattern. The length isn't as important because I beleive it's ignored when IsFirst, is false. What makes this tricky is that we don't maintain state with properties as their scope is at the frame level. So now you have to create state using conversation properties and MultiValueState arrays.

Do you have any indication in your frame structure that can differentiate the first message from fragments?

Hi Paul.

great thanks for your help and illustrative explanation of Payload params. My implementation was the same as you recommend except: for continuous frames I din't reset Length param (this parameter has been set to random number from the start of continuous frame, because first packet has been determinated later).

First message indication I had implemeted already, so once I cleared Length param before continuous BLOB, it seems that my parser is able to parse reassembled frames (I don't have implemented parsing of long messages yet).

Once again, thank you very much for Your help,

P.S. It seems that length IS NOT IGNORED for continuous frames.

New Post: Bit fields from content in hexadecimal notation.

PaulLong — Wed, 13 Jun 2012 16:43:47 GMT

I'm not aware of any easier way to do this. Currently we only support using raw values from the frame as input into the parsing.

Paul

New Post: Parsing fragmented TCP stream

PaulLong — Wed, 13 Jun 2012 16:39:12 GMT

To answer your last question first, you don't get reassembly by default. You need to hit the reassembly button in the UI and then a new window opens up. This new window contains all the original data, plus the newly inserted frames. I have a video on the blog (http://blogs.technet.com/b/netmon/p/usagevideos.aspx), which might help understand how this works from the UI perspective.

To make sure we are on the same page with regards to how to implement reassembly for your case using IsFirst and a Length, let me show a small example of what the parameters for PayloadStart should look like over multiple frames. For example, say we have this data.

Frame 1: Length=100, Blob of 40 bytes

Frame 2: Blob of 40 bytes

Frame 3: Blob of 20 bytes

The params to PayloadStart for each frame would be:

Frame 1: PayloadStart(NetworkDirection, 0, 0, 0, Length, true, 0, RssmblyIndStartBit + RssmblyIndLengthBit + RssmblySelfBit)

Frame 2: PayloadStart(NetworkDirection, 0, 0, 0, 0, false, 0, RssmblyIndStartBit + RssmblyIndLengthBit + RssmblySelfBit)

Frame 3: PayloadStart(NetworkDirection, 0, 0, 0, 0, false, 0, RssmblyIndStartBit + RssmblyIndLengthBit + RssmblySelfBit)

So your NPL code might look like this:

[RegisterBefore(...)]
[PayloadStart(NetworkDirection, 0, 0, 0, Property.MyProtLength, Property.IsFirst, 0, RssmblyIndStartBit + RssmblyIndLengthBit + RssmblySelfBit)]
Protocol MyProt
{
	[Property.MyProtLength]
	UINT16 Length;
	BLOB(Length) myblob;
}

So the trick is not to make Property.IsFirst follow the right pattern. The length isn't as important because I beleive it's ignored when IsFirst, is false. What makes this tricky is that we don't maintain state with properties as their scope is at the frame level. So now you have to create state using conversation properties and MultiValueState arrays.

Do you have any indication in your frame structure that can differentiate the first message from fragments?

New Post: Bit fields from content in hexadecimal notation.

pf1957 — Wed, 13 Jun 2012 06:16:02 GMT

pf1957 wrote:

My current ugly implementation looks like this:
Struct SomeStruct = Local.Result
{
   ...
}

While debugging, I found that this does not work at all, here is the new iplementation, which works, but is still ugly:

Struct SomeStruct = Local.Result
{
	_struct
	{
		[Local.Byte = StringToNumber("0x"+ByteValue)]
		AsciiString(2) ByteValue;
		[Local.Result 
			= FormatString("0x%s = ",ByteValue)
			+ ((Local.Byte & 4)!=0 ? "b2:..." : "b2:...")
			+ " | "
			+ ((Local.Byte & 8)!=0 ? "b3:..." : "b3:...")
		]
		_struct {}
	}
}

New Post: Bit fields from content in hexadecimal notation.

pf1957 — Tue, 12 Jun 2012 20:39:49 GMT

Hi all,

is there a way to define bit fields e.g. if a byte content is written as two hexadecimal digits? Something like this:

AsciiString(2) ByteValue
{
    UINT8 b0:1 = ....;
    UINT8 b1:1 = ....;
    ....
}

I tried to define Local.Byte and use typecast, i.e.

[Local.Byte = StringToNumber("0x"+ByteValue)]
AsciiString(2) ByteValue
{
    UINT8(Local.Byte) b0:1 = .....;
    ....
}

but compiler does not accept such syntax.

My current ugly implementation looks like this:

Struct SomeStruct = Local.Result
{
    _struct
    {
	[Local.Result = ""]
	[Local.Separator = ""]
	[Local.Byte = StringToNumber("0x"+ByteValue)]
	[Local.Result = Local.Result + Local.Separator + (Local.Byte & 0x04)!=0 ? ....]
	[Local.Separator = " | "]
	[Local.Result = Local.Result + Local.Separator + (Local.Byte & 0x08)!=0 ? ....]
	[Local.Result = Local.Result + Local.Separator + (Local.Byte & 0x10)!=0 ? ....]
        ....
        AsciiString(2) ByteValue;
    }
}

Please, could somebody help me with such bit fields definition?

Thanks for any help, pf