Santa’s Bag was Full

Santa’s Bag was Full

  • Comments 20
  • Likes

The Elves are working furiously on the next version of Network Monitor 3.2. But it seems that NM3.2 won’t be under the tree for Christmas for this season. In a few more months, however, we will have a new Beta available for public consumption. And you can’t blame Santa, his bag already stuffed with Xboxes and such. Room in his bag should be reserved for children’s gifts you know. So you will have something under the tree for Christmas we will give you a sneak preview of the new things we are working on.

Stocking Stuffers

The first thing you’ll notice with NM3.2 is that the UI has been tweaked a bit. We moved around some items to make them more visible like Reassembly and Find. We’ve, err I mean the Elves, created a Most Recently Used list on the Start Page to make opening previous captures a quick operation. We uncluttered the tool bar to get rid of some of the lesser used items. And we are still envision more changes for NM3.2, like single line filter boxes to go along with our multi-line filters, as well as a way to get rid of windows you don’t use as often. This streamed line UI should give you more real-estate and make discoverability of some lesser used, but powerful, features more prominent.

All I Want is to Open LibPCap/WinPCap Files

And now you’ll be able to with NM3.2. One of the advantages of the NM3 capture file format is that we can store data from multiple network interfaces in the same file. But that makes it impossible to save as a LibPCap format, with out splitting the traffic. But why should we limit you from opening LibPCap files? Now when you open a LibPCap file, we convert it in memory to our format and display it just like any other capture file. I’m sure this will please more than a few folks. At this point you can save it as a NM3 capture file if you wish.

Finding a Conversation in the Tree

No, not some lame version of the "12 Days of Christmas".  And I'm not referencing the Christmas tree, but rather the NM3 conversation tree. The conversation tree is very helpful for quickly narrowing down traffic, but I’m sure you have had more than one occasion to locate the current frame in the tree. A exciting new feature we now have is the ability to right click a frame and highlight that conversation in the tree. This in turn filters the traffic based on that conversation. The cool thing this is this is not limited to TCP conversations. You can filter on any conversation as displayed by the Conv ID column, like all traffic for that machine-to-machine conversation or just HTTP level traffic.

The Big Gifts

I’ve noticed that some kids will often save the biggest gifts for last. I guess the assumption is that the larger the gift the grander the surprise. Of course, you occasionally get the big box stuffed with socks and underwear from Grandma. No such disappointment here.

NM Application Interface

We get asked about Experts all the time. The availability of the API is a giant step in that direction. While it’s much more than just a way to create experts, it allows a simple programming interface to query and access data fields using our parsing engine. This means you can create applications where only your imagination is the limit. Not only can you look into the packet data, you can also control the NM capturing engine. So you can design programs to stop/start captures based on whatever events you have.

Let me give you an example of the applications I’ve already tinkered with. Perhaps at some point when the API is released, we can also release some of these examples.

TopUsers – Lists traffic based on IPv4, IPv6, MacAddresses, and show columns for bytes sent, frames sent, etc. Simply click on a column header to sort and find out who is the chattiest user on your network.

EventCap - Lets you capture data until a certain Event error appears in the Event Log. This gives you a simple way to capture traffic leading up to a failure logged in the Event Log.  Basically a one step version of the blog I wrote on this subject: (http://blogs.technet.com/netmon/archive/2007/02/22/eventmon-stopping-a-capture-based-on-an-eventlog-event.aspx)

FiltCap – Lets you query capture data using a simple SQL like command and export that data as a CSV (Comma Delimited File). No longer are you trapped by the limitations of what the UI can do. You can use your favorite tool to graph and analyze trace data.

Process Tracking

I’m often trouble shooting traffic from a specific application. I want to know why Internet Explorer isn’t working properly. Process tracking is a way to show data based on the application that is sending it. Our final design will create new Nodes in the conversation tree that show each process that is running and then allow you to filter on only that traffic when you click on that Node.

We’ll even save that data from the capturing machine so that given you’ve taken the trace with NM3.2, you’ll have all the data necessary to see the processes that were running at the time the capture was taken. Imagine how much faster you’ll be able to narrow down a specific problem with this new feature!

Now How Much Would You Pay…

While we are not done adding features, these are the major ones we have so far. We plan to release a Beta in the early part of next year (we think April time frame). And while we haven’t been able to add every feature people have asked for, and there’s been a bunch of them, we are hoping this next version has a little of everything for everyone.

Happy Holidays from the Network Monitor Team

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • PingBack from http://geeklectures.info/2007/12/28/santa%e2%80%99s-bag-was-full/

  • Thank you - I look forward to NM 3.2.

    The "extensibility" part of this parser is awesome - very powerful. Using the ParserLanguage.doc and the NPLs provided I wrote a parser for a proprietary protocol that is reasonably complicated. I am writing a Primer kind of a doc - if anyone wants - pl send me an email.

    It would be very helpful (with 3.2) to be able to

    - create short cuts (or macros) to launch a Protocol parser on a piece of data.

    - change font size and type

    Wish you all a wonderful 2008!

  • Hi Abhijit,

    I can't find your email address ...

    My address is jpmasseria(at)yahoo(dot)com

    I'm interested in reading your document.

    Thank you,

    John

  • Changing Font size is on our list (has been for a while).  I'm not certain when we will implement this feature.

    As for short cuts to launch a protocol parser, I'll have to add this one for consideration.  It sounds like an interesting idea.  You can highlight a portion of the hex details and decode as any protocol you want, but it sounds like you want to automate this a bit.

  • Here are some ideas that would be useful to testers and admins:

    (1) some sample scripting that would log message to an event log when a filter's criteria is exceeded.

    (2)a /q switch to install NM3 or nmcap remotely. Or just description of a process to install nmcap remotely so it could be run with psexec.

    (3) some integration with Powershell SQL queries.

  • #1 Will be possible with the API.  You'll be able programmatical filter capture data and then log an event or what ever you want when any criteria is met/exceeded.

    #2 Is possible today.  You can use the /quiet switch to install NM3.  You should be able to run with PSExec or using Scheduler.

    #3 This is another job that the API could handle, though I've not looked at Powershell integration to understand for sure how straight forward it would be.  But the filtcap application I mentioned does something similar.

  • Hello,

    The protocol I am parsing is shown below

    Protocol A

    {

      Preamble P;

      Header h1;

      header h2;

      Payload P[n]

    }

    Premable is fixed size, whereas the Header is variable size. I am able to parse Protocol A and get it displayed properly. I modified TCP.npl to load this parser as required.

    At the top level, I show a field from the Preamble. (Top level ==  before expanding in the Network Monitor- at Frame Summary). I am unable to show  a field from h2. The field from Preamble is being shown using LookAhead, but I am not able to get the LookAhead working with accessing the field in h2. I am not able to resolve with the variable size of h1 and h2. Any comments / pointers you may have is very helpful.

    Thanks a lot

  • Hello,

    The protocol I am parsing is shown below

    Protocol A

    {

      Preamble P;

      Header h1;

      header h2;

      Payload P[n]

    }

    Premable is fixed size, whereas the Header is variable size. I am able to parse Protocol A and get it displayed properly. I modified TCP.npl to load this parser as required.

    At the top level, I show a field from the Preamble. (Top level ==  before expanding in the Network Monitor- at Frame Summary). I am unable to show  a field from h2. The field from Preamble is being shown using LookAhead, but I am not able to get the LookAhead working with accessing the field in h2. I am not able to resolve with the variable size of h1 and h2. Any comments / pointers you may have is very helpful.

    Thanks a lot

  • I think I need more clarification on what you are asking.  Are you trying to reference a field from h2 in P?

    Can you send me the code for Header and Preamble to help me understand better what you are referencing?

    Thanks,

    Paul

  • Thank you for the prompt response

    > Are you trying to reference a field from h2 in P?

    yes that is correct

    > Can you send me the code ...

    Here are the relevant portions

    <BEGIN>

    Struct aaHeader

    {

      aaPE h1;

      aaPE h2 = FormatString("%s", GetCommandType(

                     AsciiString(h2.Value, 0,                      h2.ValueLen)));

    }

    Struct aaMessage

    {

          aaPreamble pre;

          aaHeader hdrSet;

    }

    Protocol Avalanche = FormatString("TotalLength=%d ", UINT32(FrameData, offset))

    {

          // we *Lookahead* to decide if we have received h.abort

          // Message header- h.mid(18 byte) and h.cmd(19 bytes) are mandatory,

          // whereas h.abort is optional

          switch ( UINT32(FrameData, offset + 4))

          {

                 case 36:

                 case 37:

                      aaMessage Message =

                               FormatString("%s", GetCommandType(

                                       AsciiString(

                                            Message.hdrSet.h2.Value,

                                            0,

                                            Message.hdrSet.h2.ValueLen)));

         default:

              avaAbortMessage AbortMessage;

          }

          ///////////////////////

          // Message Payload   //

          ///////////////////////

          while options[FrameData[offset] != 0xFF]

          {

                :

    <END>

    I am trying to display the h2.Value along with "Total Length".

    Thanks again!

  • I would love to see a sortable column (I know, I know).  Lex from MSFT told me not to ask, but it would be swell if I could sort by such.  

    I'm pretty stoked!  I've slowly been converting the network guys away from the *cough cough* other popular product.  

    I've noticed a problem where I'm only seeing one side of a conversation when using NLB also.  With the *cough cough* other product, I can do a trace on each interface and get all the traffic, but in NM, I have to disable NLB in order to recreate and see all the traffic.

  • Abhijit, you may be running into an issue where structs with the same name get overwritten, but let's narrow down this further by finding some very simple NPL.  One trick is that NPL doesn't have really do much, and we can simplify the whole thing down to follow.  Creating an Sparser.npl with only this will build and you can view traces with it.

    number byte

    {

    size = 1;

    DisplayFormat = FormatString("%d", this);

    }

    struct aaPe

    {

    byte val;

    byte len;

    }

    struct aaHeader

    {

    aaPe h1;

    aaPe h2;

    }

    protocol frame

    {

    aaHeader header = FormatString("h1.val = %d h2.val = %d", header.h1.val, header.h2.val);

    }

    So the problem that this example exposes is that since h1 and h2 are both of the same type.  The engine only remembers the last instance, so the aaHeader will show h1.val and v2.val as the same value.  We can work around this problem by using properties, but first lets determine if this is the issue you are running into.

    Can you confirm that this is the problem you are seeing?

    Thanks,

    Paul

  • Gazanga, sorting is on our list, but there are some difficulties with this.  Currently we only resolve those frames which are currently in view.  So to sort on a column would require we parse each frame summary and then sort.  This could be a lengthy process, and also would require a way to keep different frame orders in memory.  While this is all possible, we haven't had enough of a justification to do this.  It would be nice to understand your requirements here as there may be better options here.

    As for the NDR issue, I will have to investigate this futher.  It's possible this is due to how our driver works.  I would appriciate if you could file a bug on this on our http://connect.microsoft.com site under the Network Monitor 3 project.

    Thanks,

    Paul

  • Hello Paul,

    Thank you - yes you guessed it correct.

    h1.val and h2.val show the same value

    Abhijit

  • Hello Paul,

    Here is the modified portions of the npl that you pasted earlier

    If there is a better way to do it - please let me know. Initially I started with AddToProperty - I could not get it to work - so I went this way.

    struct aaHeader

    {

    [ Property.val1 = h1.val]

    aaPe1 h1;

    [Property.val2 = h2.val]

    aaPe1 h2;

    }

    protocol avaFrame= FormatString("1 h1.val = %d h2.val = %d", Property.val1, Property.val2)

    {

    aaHeader header = FormatString("2 h1.val = %d h2.val = %d", header.h1.val, header.h2.val);

    }

    the string that starts with 2 displays incorrect values, whereas string that starts with 1 shows the correct values.

    Thank you