Install Network Monitor
Color Filters in Network Monitor are a simple way to make frames stick out in a trace. Dealing with large traces often makes it difficult to see important information. The sea of data represented by network traffic becomes a difficult backdrop to catch errors that occur. This blog will focus on creating color filters to make these types of errors stick out.
For this blog, I concentrate on the protocols above the transport layer: Kerberos, LDAP, SMB and HTTP. I could have dove into TCP or ICMP as well, but those types of errors are in a different class. For instance TCP resets, don’t always indicate a problem. But this should give you a good background to understand how to create color filters to flag errors for other protocols you work with.
We’ll start with the simplest filter. When we flag an error in Kerberos, we use a structure called “KrbError”. So we’ll simply filter on any frame which has this structure created. We can do this by using the name of the structure as our filter.
For LDAP, we need to look at frames where the LDAPResult is not zero. But due to an engine quirk, we can’t just search for frames where the Result code is not zero. Instead we’ll search for frames that have a ResultCode, and where the description string does not have success in it.
(!LDAPResult.ToString.contains("Success") && LDAPResult.ResultCode)
I also want to flag Abandon Request for LDAP, since these may also be an indication that something went awry. The following filter catches these.
HTTP return’s a status code that’s 400 or larger when an error occurs. But one problem is this value is a string. For this filter, we will use the StringToNumber plug-in and convert to a number first so we can use our mathematical operators.
http.Response.StatusCode.StringToNumber >= 400
SMB has an NTStatus code that is set when an error occurs. The only modification we are going to do here is ignore one specific error. This is because SMB will return an error STATUS_MORE_PROCESSING_REQUIRED (22) when SMB expects more frames with the rest of the data. This isn’t exactly an error, so my filter ignores that specific value.
smb.NTStatus.Code != 0 AND smb.NTStatus.Code != 22
Now that we’ve determined the various things we want to flag, now it’s time to create the color filter. Just go to the Filter menu and open the Color Filter dialog. Simply click on Add and paste the following.
(smb.NTStatus.Code != 0 AND smb.NTStatus.Code != 22)
(http.Response.StatusCode.StringToNumber >= 400)
Then choose an appropriate color, I chose red, and exit. Now any problem frames that match our filter will show up as red. Color filters are global to NM3.1, so any new instance of NM3 or any new traces you open will use this new color filter automatically.
You could continue to do this for every protocol you work with. Sometime trying to find the proper filter is the trick, so hopefully these examples will help you understand different ways of doing this.
Note that HTTP 401/407 happens during normal authentication sequences as well. I'm not sure how you would filter "real" access denied responses though, since they could look the same like initial "authentication required" responses, with the difference kept only in the client's head.
This is a good point. There may be other error messages that don't always indicate a real problem. But hopefully this can give you a starting point to locate problems.
You could create another filter to capture these types of errors and color them Yellow or some other color.
I use this for NFS (v3 and v4 - didn't bother with v2):
(rpc.programversion == 3 && !(nfs.nfsstat3 == 0) && (rpc.msgtyp == 1) && nfs && !(nfs.procedure_v3 == 0)) || (nfs && rpc.programversion == 4 && !(nfs.procedure_v4 == 0) && (nfs.nfsstat4 != 0) && (rpc.msgtyp == 1))
how to know more about those child tag which http.xx.xx.xx having ?
Intellisense will help a little bit, though HTTP is different. If you type "http." in the filter window you will see suggestions for the types of filters you can type.
You can also infer the filter element by looking at the tree struction in the details. For the most part for HTTP, you have htttp.request. and http.response.. For each of these there are fields that you can find in the description or infer from the name of the field. One trick is that a dash "-" is not a legal char, so you'll have to remove it when you write your filter.