Ethereal-dev: Re: [Ethereal-dev] ETHEREAL bug in handling TR1 file format

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 26 Jun 2003 11:10:04 -0700
On Thu, Jun 26, 2003 at 01:32:44AM +0200, Rostislav Letos wrote:
> I know the old LANalyzer included FCS bytes here, but according to
> official TR1 file format documentation, this variable should keep length
> of stored packet data.

Perhaps Novell considered the FCS to be stored packet data.

> TR1 files generated by our NETMON for NetWare can be easily handled by
> LANalyzer or Sniffer, but not by your ETHEREAL.

Then presumably either

	1) there's no way to determine whether, in a LANalyzer token
	   ring capture, the frames include the FCS or not, in which
	   case either LANalyzer will treat the FCS as data (which would
	   happen if it read a LANalyzer-format capture that included
	   the FCS, and it assumed that the FCS *isn't* included) or
	   will treat the last 4 bytes of the frame data as an FCS
	   (which would happen if it read a LANalyzer-format capture
	   that *didn't* include the FCS, and it assumed the FCS *is*
	   included)

or

	2) there's some way to determine whether, in a LANalyzer
	   capture, Token Ring frames have an FCS at the end or not.