Not getting collisions

[Guest_imported]

Sniffer pro 3.0
Nai's xircom nic
using Nai's driver

monitoring Hub not switch
collision light on hub coming on.
Netware monitor\lan wan stats\nic\collisions incrementing

Any ideas why I'm not seeing the errors on my sniffer
I tried using a different hub,
reinstalling the sniffer
updating the nic driver

Thanks in advance

 

[fortunat]

On my webpage (

http://www.thetechfirm.com),

go to the "Tips, Tricks and Bugs section".

Go to:
Tip - Collision detection in Sniffer - October 22, 2000

That may help.

 

[rdsecure]

The xircom drivers must be uninstalled before you install the NAI nic drivers in ver 3.x or later.....some pcs have the autodetection of your nics and will not allow for the change....you will not see any errors unless the NAI drive is installed......

 

[Guest_imported]

Part 1:
I tried multiple methods, of installing the nic
1 uninstalling the nic then doing a fresh install of sniffer 3.00.05, You get prompted to install nai's driver before the reboot. I choose yes then am prompted to reboot.

The nic gets detected when you reboot after the sniffer install and the nic driver reports the driver's origin being nai. no user intervention at all.

I also tried updating the drivers on the nic to the ones supplied in the program files\nai\sniffer\drivers\xircom directory.
Part II:
I still get No collisions or for that matter ANY errors at all.
In reference to the sniffer the tip you have in the October section This seems to refer to me seeing other errors but not collisions . I am seeing NO errors at all on my sniffer. no runts or crc errors nothing?

The tecfirm pages are great. They use your saying in PMG class about the "if you don't design your network your network will design itself. I added your page to my favorites links.

Thanks a bunch
Okee Dokee

 

[fortunat]

Here's a copy of what I have posted on my site (

http://www.thetechfirm.com).

Tip - Collision detection in Sniffer - October 22, 2000
Andy Lail ..Thanks Andy.

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.