Making Things Work Better, One Bit At A Time

Network General

TIPS

When using SnifferPro Wireless, you are in “RFMON” mode which doesn't allow you to capture packets while performing regular network functions (ie, ping). If you've captured some packets via wireless and need access to the network to copy a file, print or access the Internet, simply log off your Wireless Sniffer Portable. To do so, just go to File and Log off.

Looking for Cisco 2900, 3548, 4000 and HP procurve SWC files for Switch Monitor?  Click here 

If you  ever want to revert back to your factory default DSS passwords, go to the c:\config directory and copy PWDS.DFT over PWDS.CFG

While in the detail screen (middle) pane, right click on a decoded protocol value (ie IP - Identifier) and select 'Find Frame' from the pull down menu.  Then select the 'Data' tab and you'll notice that the Sniffer automagically filled in the offset and data values.

A few notes, this only seems to work when selecting a Byte value. In other words, you can not do this with bit level specifics.  Make sure you highlight the value you wish to work with before right clicking.

If you  capture SNMP packets they are not displayed in the Application Object Screen, but is noted in the Matrix/Host -> Detail Screen.

Open a trace file.  If you compare the Expert Global Object and the Statistics, you will notice that the number of packets are the same, but the total bytes are different.  If you do the math, you'll realize that the difference its exactly 4 bytes per frame.  That damn CRC again....  If you want the total including the CRC use the Statistics tab.

If you go to Display and exclude all protocols except for IP, it works fine.  Then when you go to File->Print->File the out output still displays the highest layer.

Want to save that trace file and have it take up less space?  Just change the extension to CAZ and you'll see that this file takes approximately 11% less space.

If you ever check the Objects->Stations and see an ip address with no frames transmitted or received, it might be how Network General creates its IP objects.  If you check your trace, you'll see that the Sniffer takes ARP packets  to create these IP address objects.

Try this.
Start a Capture and Open up the Capture Panel.
Now maximize the Expert Capture window and go to Window and select the Capture Panel, titled 'Capture'. You'll notice that the capture panel is now 'full screen'. If you  Restore this capture window, the expert capture panel is not in full window mode.
Basically you can not have the Expert Capture window in full screen and the Capture Panel in a 'windowed' mode.

When trying to capture DHCP, people are often stymied as to how to filter it out since Sniffer Portable does not have a DHCP advanced predefined filter.  Don't filter on the source MAC since some DHCP responses are addressed to broadcast.  Instead go to Capture Filter-> Define Capture Filter, IP-> UDP -> Bootp.  There you go.

Open Explorer and Sniffer Portable open at the same time.  Now you can drag and drop cap files from Explorer directly into the Sniffer application.

To count a soft collision, the Sniffer must receive a valid preamble and a valid start frame delimiter. This is true for all normal Ethernet cards. If there isn't a preamble or start frame delimiter, it is impossible for us to receive a frame and it is impossible to look for a soft collision without a frame. But, this is also true for almost all of our competitors and true for all RMON products that I know of.

Most competitors will count a collision for any frame that is 60 bytes or less, and has a CRC error. Thus, all CRC errors for frames 60 bytes or shorter are considered collisions. CRC errors in frames longer than 60 bytes are considered just normal CRC errors. In fact, you can show this with the Sniffer Traffic Generator. Load a single frame into the buffer from a trace file, and delete bytes from the end until the frame is 60 bytes long. Use Frame Edit under Display to set this frame as a CRC error. Now, use Buffer Mode Traffic Generation to continuously generate this frame. The Sniffer will transmit that one frame with a bad CRC. Products like the Azure analyzer will count tons of  collisions, even though the Sniffer is the only generator on the wire.

We decided to add one additional test to decide about a collision. Some of our engineers at NGC worked on Ethernet chipsets in the past. To our knowledge, all Ethernet chipsets send a pattern of alternating
one's and zero's as the "JAM" signal. Technically, according to the 802.3 spec, there is no defined JAM signal. The spec just says that the
transmitting station must continue to transmit at least one "slot time"
(which is 60 bytes), and then must guarantee that the frame has a CRC
error.

So, in theory, a board could just continue to transmit the frame data and then put a bad CRC on the frame. But, in reality, our engineers know that almost everyone that produced an Ethernet chipset will send a pattern of alternating one's and zeros. They will also put alternating one's and zero's into the CRC bits. The Sniffer soft collision detection looks for either AAAA or 5555 to be in the last 16 bits of the CRC field. If we do not see either AAAA or 5555, then we call the frame just a normal CRC error. If we do see AAAA or 5555 in the last 16 bits of the CRC, and the board reports that the frame has a bad CRC, then we call it a collision. So, if you run the same Sniffer traffic generator test, and receive the data using both an Azure analyzer and a Sniffer notebook, the Azure will mistakenly count collisions, while the Sniffer will count them as CRC errors.

The only way for a Sniffer to count collisions is if the last 16 bits of the CRC pattern is either 5555 or AAAA. For you technical junkies, this does create one hole. If a frame is really just a CRC error, and if the frame data along with the error happens to create a CRC that ends in either AAAA or 5555, then the Sniffer will "mistakenly" count a true CRC error as a collision. But this "mistake" can only happen in 2 out of 65,535 chances.

Also, the card MUST report a frame as a CRC error before we do a
"collision" test. So it is impossible for us to count a good frame as a collision even if the good frame ends in either format. (5555 or AAAA.) By the way, in the next release of the Sniffer we may change the counters to better detect "late collisions". We could enhance our soft collision detection to only count collisions if the frame is 60 bytes or shorter. If the frame is longer than 60 bytes, and there is a CRC error, and the CRC ends with 5555 or AAAA, then it is probably a late collision. We are thinking about making this a separate counter, to help quickly detect late collisions. We may even add a specific "late collision" counter to the screen.

Helpful when troubleshooting 'ICMP Destination Unreachable (Fragmentation Needed, but DF set'.
When decoding ICMP messages regarding "Destination Unreachable, Fragmentation needed and DF set", go to the hexidecimal value after the ICMP checksum and before the copy of the original header.  There you will find a two byte field that represents the segment size that the client should attempt to use.

When in the Expert Screen go to objects, stations and move the Attribute column over to the far left and select the Object button. Here you will see what services are on various stations.

To find packets with physical errors perform a search [Alt+F3] for BAD. To find packets with IP or other checksum errors perform a search [Alt+F3] for should.

When you stop a trace file and want to report from the Expert System, Select the Export to HTML button [the web with an arrow]. For added customization, take your logo and name it nalogo.gif and overwrite the nalogo.gif file with your own logo.

By default Sniffer Portable uses approximately 28- 32 MBs of memory. You can greatly reduce this requirement by selecting exactly which topologies you work with. For example, if you are not working on any WAN trace files, you can free up to 9 MB of memoy by changing the Analyze column to NO. Even though you can not do this same procedure with ATM, you can lower the maximum number of objects to 11.

Good old NDIS. By default most Vendors NDIS drivers will not pass packets with CRC errors to the application. This is were Network General comes in and asks you to buy a specific NIC card that they have modified the NDIS for. Unfortunately, you can not use the Traffic Generator to send out a packet smaller than 60 bytes. If you intentionally try to send out an existing packet with a CRC error or smaller, you will notice that the packet will be padded or have the CRC corrected.

Pick a protocol any protocol.... You can add some of your legacy protocols by selecting Tools, Options and adding the TCP/UDP port number or IPX socket number.  *This only applies to monitor reports.

Reporting note. When using the History Samples go to the Detailed View icon and you will notice a sample period value. This is the amount of time for the entire report represented as hours:minutes;seconds . Each sample period equals a hour of total reporting time. So if you have a 1 second polling interval, you can only record an hour of information. So plan how long of a report you need and calculate the interval. [i.e. 10 hours would require a 10 second polling interval.]. If this isn't good enough for your needs, consider using the Database option for Data collection or the wrap options.

How To

Bugs

When capturing tagged packets, Sniffer will decode them correctly, but incorrectly mark them as 'Oversized'.

When decoding GVRP, Sniffer Portable misreports that the 'FRAME is too short'.

I accidentally hit the End key while 'printing to file' and my PC took approximately 10 times longer to create the text file.  Watch those fingers or you'll be watching that printer counter.

When printing to a file, you'll find that the trace file has been broken up into 2 lines of text per frame.  A real pain when trying to perform advanced reporting with any third party application.  CSV format doesn't help either. If you import this into Excel, sort by Frame Number.

If you have ISO/Ungerman Bass packets on your network, Sniffer incorrectly labels these packets as having a BAD CRC.
To find out if your packets fall into this category, check if the SAP addresses are FE or FA.

If you use the Newfoundland Time Zone you'll notice that the packet time stamp is a half hour ahead of your PC clock. 

Try this.. - Open any trace file.
- Go to Display -Display Setup.
- Pick the Summary Display tab.
- Uncheck all the Optional Fields.
- From the Decode Summary Pane, move your mouse to the end of the Summary Column as if to resize the Column.
- When your cursor changes to the "Double Arrow", double click.
- You will notice some fields return to the screen, but none are selected in the Optional Fields section.
- To fix this, you have to check any Optional Field and click OK.
- Then Uncheck them all again and click OK..

Go to Display -> Display Setup -> Summary Display -> Exclude Protocols and select ALL.
It seems that you need at least one protocol selected to make this work properly.

Maybe 'All' should warn you us about that.

The information on this page is provided free of charge with the ultimate goal of improving SnifferPro.  

Since we are not directly funded or commissioned by any vendor to provide this, or any information on our website, let us know if you see any inaccuracies. 

Please respect our copyright policies