NMParsers Issue Tracker Rss Feed

Created Issue: Fix some parsing issues (strict parser) [12846]

darkjames — Sun, 03 Mar 2013 23:12:46 GMT

Hi, I have been recently testing my NPL parser against NPL files found in https://nmparsers.svn.codeplex.com/svn/Develop_Branch/NPL, and I found some issues.

It's generally issues like: missing semicolon after field, or missing () around switch value, or not needed semicolon after switch declaration.

I know it's issue with my parser, and I should relax my grammar (btw. is there official NPL grammar published?), but I'd be happy if this patch gets accepted.

This patch was NOT tested with Windows Network Monitor.

Attaching patch against https://nmparsers.svn.codeplex.com/svn/Develop_Branch/NPL

Created Issue: NLB fix value for RemoveIPv6Count [12845]

darkjames — Sun, 03 Mar 2013 23:04:08 GMT

Hi, when testing my NLP parser I hit a error in Windows/nlb.npl ('.' before RemoveIPv6Count)

Funny thing that also in the same line, I found (probably) copy & paste bug, could you please review?

Attaching patch against https://nmparsers.svn.codeplex.com/svn/Develop_Branch/NPL
(not tested with Microsoft Network Monitor).

Closed Issue: Parser Submission: MS-WDSMA, MS-WDSMT, DHCP [10408]

rachelhu — Fri, 12 Oct 2012 10:05:44 GMT

Brief overview of WDS
----------------------------
Windows Deployment Services (WDS) enables Windows OS deployment on client machines over the network. To achieve this WDS uses standard network protocols (like PXE over DHCP, TFTP... etc) and a custom multicast protocol (Multicast Transport Protocol and Multicast Application Protocol). WDS is currently being used by various orgranizations along with Microsoft OEM and ODM partners.
 
Protocol Details (involving parser changes) -
-----------------------------------------------------
 
Multicast Transport Protocol -
 
The WDS Multicast Transport Protocol is a multiple clients/single server protocol. The protocol, in conjunction with the WDS Multicast Application Protocol, allows transmission of content to multiple clients using multicast UDP. The protocol provides the best effort mechanism for delivery of data to all clients. The protocol provides mechanisms to allow clients to join a multicast session at any.
Link - http://msdn.microsoft.com/en-us/library/dd646632(PROT.10).aspx
 
Multicast Application Protocol -
 
WDS Multicast Application Protocol is a single server, multiple client protocol. The protocol uses WDS Multicast Transport Protocol for transmission of content to multiple clients. The protocol relies on services provided by the WDS Multicast Transport Protocol to ensure all pieces of content are delivered to all clients in a multicast session. The protocol allows clients to join the multicast session at any point
Link - http://msdn.microsoft.com/en-gb/library/dd646562.aspx
 
PXE over DHCP - 
 
WDS uses some of the standard DHCP PXE options (eg. option 54 - ServerId, 252 - WPAD) along with option 250 for exchaning WDS specific options between client and the server. 
Looks like currently option 250 is being registered for something else and we will have to come up with a workaround so that option 250 can be used for WDS (if the DHCP packet is a PXE packet) or for what it is being used currently.
 
Justification for including these parsers - 
---------------------------------------------------
 
These parsers aid in debugging WDS issues to a great deal. Also, we have a strong case as most of the deployment MVPs ask for the inclusion of these parsers in NetMon.
Comments:

Commented Issue: Parser Submission: MS-WDSMA, MS-WDSMT, DHCP [10408]

LindaLu — Fri, 12 Oct 2012 09:24:10 GMT

Add wdsmt.npl and wdsma.npl, ChangeSet 82167 and 82160. These changes will include in Nov 2012 NM3.4 release build. "Downloads" page (<https://connect.microsoft.com/site216/Downloads/>).

Commented Issue: NetMon incompletely parses the RDPESC content of a RDPEFS packet [11955]

SteveRoss — Tue, 09 Oct 2012 15:09:54 GMT

I'm using:
 
 Network Monitor 3.4.2350 (dated 24 June 2010)
 the open-source parser package, version 3.4.2774.0001 (dated 19 Dec 2011)
 
This combination seems to incompletely parse the "RDPEFS:RDPDrDeviceIOCompletion" message. This same incomplete parsing occurs in all of the ":RDPDrDeviceIOCompletion" messages that I looked at using NetMon.
 
Here are the details with regard to parsing in the bowels of the Remote Desktop Protocol...
 
Section 2.2.1.5.5 (titled "Device Control Response (DR_CONTROL_RSP)") of the Microsoft document
"[MS-RDPEFS]: Remote Desktop Protocol: File System Virtual Channel Extension" (at <http://msdn.microsoft.com/en-us/library/cc241305(v=prot.10).aspx>) shows a "DeviceIoReply" field that NetMon successfully parses. 
 
However, NetMon seems to ignore the following two fields, namely, "OutputBufferLength" and "OutputBuffer (variable)". The attached ".cap" file is a single network packet. The RDP data is not compressed. It contains the above two fields, but NetMon doesn't parse them. It quits parsing after the "IoStatus" field.
 
The content that is in the "OutputBuffer (variable)" field in the attached file is the "EstablishContext_Return" structure found in section 2.2.3.2 of the [MS-RDPESC]: Remote Desktop Protocol: Smart Card Virtual Channel Extension document (at <http://msdn.microsoft.com/en-us/library/cc242596%28v=prot.10%29.aspx>).

Comments: ** Comment from web user: SteveRoss **

Linda,

Thank you. I've made some use of the new parser and it seems to work well.

-- Steve Ross

Closed Issue: Two default entries in RDPEVCapabilityTypeTable table [12145]

SandyYe — Mon, 08 Oct 2012 09:49:44 GMT

While testing my parser for NPL language I found that RDPEVCapabilityTypeTable has two default entries.
 
Attaching fix which merges these two entries into one.
 
(Patch wasn't tested with network monitor)
Comments:

Fixed

Commented Issue: Two default entries in RDPEVCapabilityTypeTable table [12145]

SandyYe — Mon, 08 Oct 2012 09:09:45 GMT

Thanks very much for reporting this bug to us.
It has been fixed it. Related change ID is 81970.
BTW, RDPEVCapabilityTypeTable has renamed to RDPEVTsmmCapabilitiesCapabilityTypeTable.

If you have any other concern, please feel free to contact us.

Commented Issue: NetMon incompletely parses the RDPESC content of a RDPEFS packet [11955]

LindaLu — Mon, 08 Oct 2012 02:07:00 GMT

You can get the Latest release build 03.04.2890.0001 from the "Downloads" page (<https://connect.microsoft.com/site216/Downloads/>).
PS: 120330-bug-not-parsing-completely1.cap and 120330-bug-not-parsing-completely2.cap are incomplete data, they will not be parsing successful.

Best Regards,
Linda

Commented Issue: NetMon incompletely parses the RDPESC content of a RDPEFS packet [11955]

SteveRoss — Mon, 01 Oct 2012 16:54:08 GMT

Linda,

Thanks for working on this issue. From where should I download the "Latest release build 03.04.2890.0001"? The parser version on the "Downloads" page (<http://nmparsers.codeplex.com/releases/view/79102>) is still at 3.4.2774.

Thanks,
-- Steve Ross

Closed Issue: NetMon incompletely parses the RDPESC content of a RDPEFS packet [11955]

rachelhu — Sat, 29 Sep 2012 03:10:06 GMT

I'm using:

Network Monitor 3.4.2350 (dated 24 June 2010)
the open-source parser package, version 3.4.2774.0001 (dated 19 Dec 2011)

This combination seems to incompletely parse the "RDPEFS:RDPDrDeviceIOCompletion" message. This same incomplete parsing occurs in all of the ":RDPDrDeviceIOCompletion" messages that I looked at using NetMon.

Here are the details with regard to parsing in the bowels of the Remote Desktop Protocol...

Section 2.2.1.5.5 (titled "Device Control Response (DR_CONTROL_RSP)") of the Microsoft document
"[MS-RDPEFS]: Remote Desktop Protocol: File System Virtual Channel Extension" (at <http://msdn.microsoft.com/en-us/library/cc241305(v=prot.10).aspx>) shows a "DeviceIoReply" field that NetMon successfully parses.

However, NetMon seems to ignore the following two fields, namely, "OutputBufferLength" and "OutputBuffer (variable)". The attached ".cap" file is a single network packet. The RDP data is not compressed. It contains the above two fields, but NetMon doesn't parse them. It quits parsing after the "IoStatus" field.

The content that is in the "OutputBuffer (variable)" field in the attached file is the "EstablishContext_Return" structure found in section 2.2.3.2 of the [MS-RDPESC]: Remote Desktop Protocol: Smart Card Virtual Channel Extension document (at <http://msdn.microsoft.com/en-us/library/cc242596%28v=prot.10%29.aspx>).
Comments:

Commented Issue: NetMon incompletely parses the RDPESC content of a RDPEFS packet [11955]

LindaLu — Sat, 29 Sep 2012 02:33:45 GMT

Thanks for reporting this bug to us, which has been fixed. The change ID is 76668 and the bug fixing has been inclued in Latest release build 03.04.2890.0001. If you have any question, please contact us. Thanks.

Closed Issue: installation fails with "processor type" not supported error [12222]

rachelhu — Tue, 28 Aug 2012 09:54:10 GMT

Hi.. newbie here.

I've successfully installed netmon 3.4 (and rebooted).

I'm trying to install NetworkMonitor_Parsers.msi (latest version) on my Windows 7 machine, and it immediately comes up with the following error:

"This installation type is not supported by this processor type"

I have an x86 processor and I've never encountered this error before (Pentium(R) dual-core CPU T4400 @2.2GHz).

Any clues?

Most appreciated.

Ronny
Comments:

It seems like that you didn't meet this issue again, so just close it but if you meet any issue please contact us. Thanks again.

Commented Issue: RDPBCGR Slow path input not parsed properly [12411]

Jessicawu — Tue, 28 Aug 2012 09:50:46 GMT

The current version of the parsers incorrectly parse slow path input PDU. It skips the numberEvents and pad2Octets fields, which cases all the other fields to be incorrect. The fix is very simple, and I would edit the code myself, but I don't know how to commit changes on CodePlex. In the rdpbcgr.npl file, replace:
case 28:
[Property.RDPBCGRPacketType = "TsInputEvent"]
RDPBCGRTsInputEvent TsInputEvent;
with
case 28:
[Property.RDPBCGRPacketType = "TsInputEvent"]
RDPBCGRTsInputPduData TsInputEvent;
I have tested this on my local copy and this one change fixes the issue.
Thanks!
Comments: ** Comment from web user: Jessicawu **

Please get the changeset 81160 to verfy the issue.Thanks!

Commented Issue: installation fails with "processor type" not supported error [12222]

Jessicawu — Tue, 28 Aug 2012 04:57:04 GMT

You can use the changeset 81160.

Closed Issue: RDPBCGR Slow path input not parsed properly [12411]

Jessicawu — Tue, 28 Aug 2012 04:19:17 GMT

Thanks for your reporting this issue, I have reslove the issue and you can get it in sep release.

Commented Issue: Parser Submission: MS-WDSMA, MS-WDSMT, DHCP [10408]

rachelhu — Wed, 15 Aug 2012 07:13:58 GMT

Brief overview of WDS
----------------------------
Windows Deployment Services (WDS) enables Windows OS deployment on client machines over the network. To achieve this WDS uses standard network protocols (like PXE over DHCP, TFTP... etc) and a custom multicast protocol (Multicast Transport Protocol and Multicast Application Protocol). WDS is currently being used by various orgranizations along with Microsoft OEM and ODM partners.

Protocol Details (involving parser changes) -
-----------------------------------------------------

Multicast Transport Protocol -

The WDS Multicast Transport Protocol is a multiple clients/single server protocol. The protocol, in conjunction with the WDS Multicast Application Protocol, allows transmission of content to multiple clients using multicast UDP. The protocol provides the best effort mechanism for delivery of data to all clients. The protocol provides mechanisms to allow clients to join a multicast session at any.
Link - http://msdn.microsoft.com/en-us/library/dd646632(PROT.10).aspx

Multicast Application Protocol -

WDS Multicast Application Protocol is a single server, multiple client protocol. The protocol uses WDS Multicast Transport Protocol for transmission of content to multiple clients. The protocol relies on services provided by the WDS Multicast Transport Protocol to ensure all pieces of content are delivered to all clients in a multicast session. The protocol allows clients to join the multicast session at any point
Link - http://msdn.microsoft.com/en-gb/library/dd646562.aspx

PXE over DHCP -

WDS uses some of the standard DHCP PXE options (eg. option 54 - ServerId, 252 - WPAD) along with option 250 for exchaning WDS specific options between client and the server.
Looks like currently option 250 is being registered for something else and we will have to come up with a workaround so that option 250 can be used for WDS (if the DHCP packet is a PXE packet) or for what it is being used currently.

Justification for including these parsers -
---------------------------------------------------

These parsers aid in debugging WDS issues to a great deal. Also, we have a strong case as most of the deployment MVPs ask for the inclusion of these parsers in NetMon.
Comments: ** Comment from web user: rachelhu **

Hi Vipai,

Thanks file the issue for us.
would you please help to share your three parsers for us, then we can integrate them to our branch. Your title write "Parser Submission". It seems like that there is no parser Submission to us.

Closed Issue: ProtocolWarning: Media Type not supported, please report to www.codeplex.com/nmparsers [11424]

rachelhu — Tue, 14 Aug 2012 01:43:07 GMT

This file opens in 'another network protocol analyzer', but not in NetMon.
It appears to be something small...

Tino
Comments:

Commented Issue: RDPBCGR Slow path input not parsed properly [12411]

felipet1326 — Mon, 30 Jul 2012 03:50:20 GMT

Thanks for replying so quickly. You're welcome. This issue is not related to Windows 8. It happens even when connecting to XP computers. Note that you would probably never see it in practice with mstsc.exe because these packets would be encrypted and/or compressed, but neither is required. Here is a capture containing two frames with valid input data. Open them with the current parsers, then try the change I recommended, and reopen it.
Sorry, this capture has lots of extra baggage, but if I only send you the relevant frames, it doesn't recognize it properly. Frames #131 and 118 among many others, demonstrate the issue.

Commented Issue: RDPBCGR Slow path input not parsed properly [12411]

rachelhu — Mon, 30 Jul 2012 01:59:02 GMT

Thanks for reporting this issue for us. We will do the win8 RDP series protocol alignment for parser during Nov. Then, do the public release. I think you can verify this issue that time.Would you mind to attach the capture you have related with this issue. Thanks a lot.

Created Issue: RDPBCGR Slow path input not parsed properly [12411]

felipet1326 — Sun, 29 Jul 2012 18:16:39 GMT