You’ve made some changes to your parsers and want to keep things organized. With the release of SSL.NPL, which we will also talk about today, it makes sense to understand how to work with parsers when you want to update or modify them. So I’d like to go over some strategies for keeping out of NPL H-E-double hockey sticks. If you are not familiar with this term, don’t worry, it is just a synonym for a type of file management night mare. It’s happened before, so we have learned some lessons and will attempt to help, but sometimes…some things…are in the user’s hands.
Where do I get it?
The SSL.NPL parser is available on our connect.microsoft.com site. http://Connect.microsoft.com is where we host our Netmon community. You can keep up to date, file bugs, and ask questions on our new forum (it’s still a newsgroup, but there’s now a web interface). From the connect.microsoft.com site, you should be able to get to the Network Monitor 3 project if you’ve already signed up. If not, just create a new account and then join the Network Monitor 3 project. Once you are on our site, you can click on the Downloads link on the left side. This will show you a list of files, one of which is the SSL.NPL parser.
Where do I stick it?
You could just plop the SSL.NPL file right on top of the old one in C:\program files\Microsoft Network Monitor 3\NPL, and things will work just fine potentially for the rest of you and your computer’s life. But there is a potential problem lurking.
In this case it’s the next update that may cause a problem. Not so much if we send out a new SSL.NPL, but more if you decide to change a parser yourself. It’s called forward integration, and it makes things complex. In this situation you have to figure out the difference you made and integrate into the new SSL parser, or vice versa if you prefer. Either way it’s an issue that not easy to resolve automatically and does require some user intervention.
But even in the replacing the SSL with new one, there are problems. On Vista, we should not be writing to the Program Files directory. So saving a file there using NM3 could end up shadowing it to some other directory (AppData\Local\VirtualStore\Program Files\Microsoft Network Monitor 3\NPL). So if you ever have a situation where you think you are updating the correct version of SSL.NPL in the NM3 editor, you may not be touching the invisible one. This has also caused problem in the past when trying to update from NM3.0. In any case we hope to address this for NM3.2.
Working with NPL Parser path
The solution is to store your NPLs in your own personal NPL directory using the Tools, Options dialog on the parsers tab. In NM3, you have the ability create a parser load order. This is a list of directories that are searched in order for each parser we encounter. When an NPL file includes another, we search each path in order and load the first NPL we encounter that matches. Even if the file is local to that NPL file, we still use the search order path.
We do create a personal NPL directory (documents\NM3\NPL), but it doesn’t automatically get added to your parser path. So it will search your local directory first and then each path listed in the options dialog in order (top to bottom). Add your local version first and then add the directory for versions of MS supplied files and finally add in the “C:\program files\Microsoft Network Monitor 3\NPL” directory so it searches that directory last. It won’t search the Program Files directory automatically once you add at least one directory in parser search path.
Once you’ve modified your path and added the new version of SSL.NPL, you’ll either need to restart NM3.1, or rebuild the parsers from the parser tab. Since we’ve already plugged a stub version of SSL into public build, no other modifications are need in the parsers to call the new SSL parser. In the case of a new parser, however, you would have to add this to sparser.npl.
This technique helps solve the problem by making sure you don’t clobber the original files. If we update a file, you can also check your local changes and forward integrate our changes in to your version. And if it’s Vista, we can make sure the versions of MS updates end up in an obvious place. Forward integration is a whole other topic, but there are difference tools which display file differences and make it easy to take changes from one file into another. But for simple changes this can be done by hand.
Improvements in NM3.2
There are things we can do in the future to make this more transparent to the user. And working more cooperatively with Vista is one of our goals for the next version. Fortunately this is not something most of us do all the time.
I was trying to write a new parser to reassemble some payloads. Do you have any good example on how to do it?
You can look at http.npl, tcp.npl or ipv4.npl for examples. Just look for PayloadStart, which is the callout that determines how to do reassembly.
You'll want to look at the documentation in the help directory on the parser langauge for all the details, but basically you can do reassembly with sequence numbers, a length, or by specifically tagging the first, middle and last fragments.
If you have further questions, please ask in the NPL Forum on our connect.microsoft.com support site.
We have decided to release an SMB2 parser for Network Monitor 3.1 (released July 07) to hold people over