Wireshark · Ethereal-dev: Re: [Ethereal-dev] netxray.c patches

["Bill Meier" <wmeier@xxxxxxxxxxx>]

patch for netxray.c
patch for wtap-int.h

Note: This patch *supercedes* a previous (apparently not applied) 
netxray.c patch.
[http://www.ethereal.com/lists/ethereal-dev/200508/msg00639.html] .

(A fix for a newly found problem has been added to the patch).

(If the correct procedure is to submit this additional fix 
separately please let me know).

1. [netxray.c] Timezone defined as gint16;

2. [netxray.c] Comment revisions

   > That would make sense - the new header definition is the better one, 
   > so the comments should refer to it.

   Done


3. [netxray.c] Precision 

   > ...hence my XXX comment. An alternative might be "if (timeunit >= 1e7)", 
   > for example.

   OK - Let's do that ...

4. [wtap-int.h, netxray.c] 

   Fix case wherein Ethereal reads frames from a netxray capture file twice. 
   This happened if the capture file is "short" (truncated) exactly on a frame boundary
   causing netxray.c to 'wrap' and (re)read frames from the beginning of the file.
   (Sniffer files that I've seen are sometimes truncated: i.e. shorter than the 'end-offset'
    specified in the file header).

Bill Meier


[netxray.c]

92c92
< 	guint16 timezone_hrs;	/* timezone hours [at least for version 2...];	*/
---
> 	gint16 timezone_hrs;	/* timezone hours [at least for version 2.2..];	*/
93a94
> 				/*  negative values = east of UTC:		*/
94a96
> 				/* [Does not appear to be adjusted for DST ]	*/
564a567
> 		 * XXX - Seems reasonable to use nanosecs only if TPS >= 10M
566c569
< 		if (timeunit > 1e6)
---
> 		if (timeunit >= 1e7)
607,617c610,616
< 				 * In the Cisco HDLC capture, hdr.xxc[22:26]
< 				 * is 0x02 0x00 0x01 0x00 0x06, but it's
< 				 * 0x00 0x00 0x00 0x00 0x00 in the Frame
< 				 * Relay capture.  Also, hdr.xxc[30:31]
< 				 * is 0xff 0xff in the Cisco HDLC capture
< 				 * and 0x00 0x00 in the Frame Relay capture,
< 				 * and hdr.xxc[46:47] is 0xff 0xff in the
< 				 * Cisco HDLC capture and 0x05 0x00 in the
< 				 * Frame Relay capture.
< 				 *  [XXX: xxc[46:47] appear to be Timezone]
< 				 *  [Does 0xff 0xff mean "time zone unknown?]
---
> 				 * [Bytes in each capture:
> 				 * Cisco HDLC:  hdr.xxx_x60[06:10]: 0x02 0x00 0x01 0x00 0x06
> 				 * Frame Relay: hdr.xxx_x60[06:10]  0x00 0x00 0x00 0x00 0x00
> 
> 				 * Cisco HDLC:  hdr.xxx_x60[14:15]: 0xff 0xff
> 				 * Frame Relay: hdr.xxx_x60[14:15]: 0x00 0x00
> 				 * ]
740c739
< 		 * 0x01 in xxb[4].  No captures I've seen with a network
---
> 		 * 0x01 in xxx_x40[4].  No captures I've seen with a network
744c743
< 		 * and with 0x01 in xxb[4], *without* FCSes in the
---
> 		 * and with 0x01 in xxx_x40[4], *without* FCSes in the
746c745
< 		 * not as simple as "xxb[4] = 0x01 means the 4 bytes at
---
> 		 * not as simple as "xxx_x40[4] = 0x01 means the 4 bytes at
748,749c747,748
< 		 * 802.11 capture with an xxb[4] value of 0x01 with junk
< 		 * rather than an FCS at the end of the frame, so xxb[4]
---
> 		 * 802.11 capture with an xxx_x40[4] value of 0x01 with junk
> 		 * rather than an FCS at the end of the frame, so xxx_x40[4]
753c752,753
< 		 * There don't seem to be any other values in xxb or xxc
---
> 		 * There don't seem to be any other values in any of the
> 		 * xxx_x5..., xxx_x6...., xxx_x7.... fields
771,773c771,777
< 	 * there's sometimes crud after it. */
< 	wth->capture.netxray->wrapped = FALSE;
< 	wth->capture.netxray->end_offset = pletohl(&hdr.end_offset);
---
> 	 * there's sometimes crud after it.
> 	 * XXX: Remember 'start_offset' to help testing for 'short file' at EOF
> 	 */
> 	wth->capture.netxray->wrapped      = FALSE;
> 	wth->capture.netxray->nframes      = pletohl(&hdr.nframes);
> 	wth->capture.netxray->start_offset = pletohl(&hdr.start_offset);
> 	wth->capture.netxray->end_offset   = pletohl(&hdr.end_offset);
816c820,844
< 		/* We're at EOF.  Wrap? */
---
> 		/* We're at EOF.  Wrap?
> 		 * XXX: Need to handle 'short file' cases
> 		 *      (Distributed Sniffer seems to have a 
> 		 *	 certain small propensity to generate 'short' files
> 		 *       i.e. [many] bytes are missing from the end of the file)
> 		 *   case 1: start_offset < end_offset 
> 		 *           wrap will read already read packets again;
> 		 *           so: error with "short file"
> 		 *   case 2: start_offset > end_offset ("circular" file)
> 		 *           wrap will mean there's a gap (missing packets).
> 		 *	     However, I don't see a good way to identify this
> 		 *           case so we'll just have to allow the wrap.
> 		 *           (Maybe there can be an error message after all
> 		 *            packets are read since there'll be less packets than
> 		 *            specified in the file header).
> 		 * Note that these cases occur *only* if a 'short' eof occurs exactly 
> 		 * at the expected beginning of a frame header record; If there is a
> 		 * partial frame header (or partial frame data) record, then the
> 		 * netxray_read... functions will detect the short record.
> 		 */
> 		if (wth->capture.netxray->start_offset < wth->capture.netxray->end_offset) {
> 			*err = WTAP_ERR_SHORT_READ;
> 			return FALSE;
> 		}
> 		



[wtap-int.h]

107c107,109
< 	int		end_offset;
---
> 	guint32		nframes;
> 	long		start_offset;
> 	long		end_offset;