Commit Graph

146 Commits

Author SHA1 Message Date
Jakub Zawadzki 78631020b8 Add wtap_pseudo_header union to wtap_pkthdr structure.
Use pkthdr instead of pseudo_header as argument for dissecting.

svn path=/trunk/; revision=45601
2012-10-16 21:50:57 +00:00
Jeff Morriss 3551a86c36 We always HAVE_CONFIG_H so don't bother checking whether we have it or not.
svn path=/trunk/; revision=45015
2012-09-20 01:29:52 +00:00
Guy Harris b459c468a3 Set the 802.11 "already decrypted" flag to FALSE for file formats other
than Network Instruments Observer files, as we don't know whether they
are already decrypted.

svn path=/trunk/; revision=43796
2012-07-18 22:48:18 +00:00
Jakub Zawadzki bf81b42e1e Update Free Software Foundation address.
(COPYING will be updated in next commit)

svn path=/trunk/; revision=43536
2012-06-28 22:56:06 +00:00
Guy Harris 33bb54a945 file_seek() used to be a wrapper around fseek() or gzseek(), both of
which could use lseek() and were thus expensive due to system call
overhead.  To avoid making a system call for every packet on a
sequential read, we maintained a data_offset field in the wtap structure
for sequential reads.

It's now a routine that just returns information from the FILE_T data
structure, so it's cheap.  Use it, rather than maintaining the data_offset
field.

Readers for some file formats need to maintain file offset themselves;
have them do so in their private data structures.

svn path=/trunk/; revision=42423
2012-05-04 16:56:18 +00:00
Anders Broman be31ffaeb0 Get the Windows build going again. The Netxray "fix" cast to guint8 may not be OK.
svn path=/trunk/; revision=42125
2012-04-18 08:15:32 +00:00
Guy Harris b6ff142f60 Add a presence flag field to the packet information structure filled in
by Wiretap, to indicate whether certain fields in that structure
actually have data in them.

Use the "time stamp present" flag to omit showing time stamp information
for packets (and "packets") that don't have time stamps; don't bother
working very hard to "fake" a time stamp for data files.

Use the "interface ID present" flag to omit the interface ID for packets
that don't have an interface ID.

We don't use the "captured length, separate from packet length, present"
flag to omit the captured length; that flag might be present but equal
to the packet length, and if you want to know if a packet was cut short
by a snapshot length, comparing the values would be the way to do that.

More work is needed to have wiretap/pcapng.c properly report the flags,
e.g. reporting no time stamp being present for a Simple Packet Block.

svn path=/trunk/; revision=41185
2012-02-25 23:24:34 +00:00
Guy Harris e9fc1b72aa Use guint8 rather than guchar for raw octets and pointers to arrays of
same.

Add to wiretap/pcap-common.c a routine to fill in the pseudo-header for
ATM (by looking at the VPI, VCI, and packet data, and guessing) and
Ethernet (setting the FCS length appropriately).  Use it for both pcap
and pcap-ng files.

svn path=/trunk/; revision=38840
2011-09-01 09:43:10 +00:00
Bill Meier 4e782042de #include <stdlib.h> not needed;
use consistent indentation.

svn path=/trunk/; revision=36921
2011-04-28 01:07:43 +00:00
Guy Harris 6cbf6ce16c Add a new WTAP_ERR_DECOMPRESS error, and use that for errors discovered
by the gunzipping code.  Have it also supply a err_info string, and
report it.  Have file_error() supply an err_info string.

Put "the file" - or, for WTAP_ERR_DECOMPRESS, "the compressed file", to
suggest a decompression error - into the rawshark and tshark errors,
along the lines of what other programs print.

Fix a case in the Netscaler code where we weren't fetching the error
code on a read failure.

svn path=/trunk/; revision=36748
2011-04-21 09:41:52 +00:00
Guy Harris 2b8ebd389b "This file format can't be written to a pipe" and "this file format
can't be saved in compress form" are both equivalent to "this file file
format requires seeking when writing it".  Change the "can compress"
Boolean in the file format table to "writing requires seeking", give all
the entries the proper value, and do the checks for attempting to write
a file format to a pipe or write it in compressed format to common code.

This means we don't need to pass the "can't seek" flag to the dump open
routines.

svn path=/trunk/; revision=36575
2011-04-12 00:44:44 +00:00
Guy Harris 4c93827e34 From Jakub Zawadzki:
file_read(buf, bsize, count, file) macro is compilant with fread
function and takes elements count+ size of each element, however to make
it compilant with gzread() it always returns number of bytes.

In wiretap file_read() this is not really used, file_read is called
either with bsize set to 1 or count to 1.

Attached patch remove bsize argument from macro.

svn path=/trunk/; revision=36491
2011-04-06 06:51:19 +00:00
Bill Meier 0d7508cf8e From Robert Bullen: ... code is not incrementing wtap_dumper.bytes_dumped.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5666

Fro me: use 4 -space indentation (not tab) to match surrounding code lines.

svn path=/trunk/; revision=36074
2011-02-25 20:33:43 +00:00
Guy Harris 414dadf6ba Add a note.
svn path=/trunk/; revision=33741
2010-08-08 23:32:40 +00:00
Guy Harris 194cfe2d2f Don't use fwrite directly when writing a dump file; call it through
wtap_dump_file_write().  Replace various wrappers around fwrite() with
wtap_dump_file_write(), or at least make the wrappers call
wtap_dump_file_write().

svn path=/trunk/; revision=33116
2010-06-06 22:19:30 +00:00
Guy Harris 17392a865a Move the definitions of all the private data structures out of
wtap-int.h, and change the unions of pointers to those private data
structures into just void *'s.

Have the generic wtap close routine free up the private data, rather
than the type-specific close routine, just as the wtap_dumper close
routine does for its private data.  Get rid of close routines that don't
do anything any more.

svn path=/trunk/; revision=32015
2010-02-26 07:59:54 +00:00
Bill Meier 72ef03e60a [Trivial] Constify a few things
svn path=/trunk/; revision=28144
2009-04-24 12:16:01 +00:00
Guy Harris ad33ca6c2f Clean up some 64-bit issues.
svn path=/trunk/; revision=28117
2009-04-22 03:07:37 +00:00
Bill Meier 11042d0dd1 Fix a typo in a comment
svn path=/trunk/; revision=27164
2009-01-06 13:31:28 +00:00
Bill Meier f281fabf7f Oops: Revert SVN #27152: There weren't actually any memory leaks ...
svn path=/trunk/; revision=27155
2009-01-04 16:28:48 +00:00
Bill Meier e8cc3f500a Fix a few minor memory leaks...
svn path=/trunk/; revision=27152
2009-01-04 15:44:28 +00:00
Guy Harris c193066114 At least some LAPB Windows Sniffer captures have 4 bytes of extra stuff
at the ends of packets.

svn path=/trunk/; revision=22540
2007-08-17 20:04:31 +00:00
Bill Meier 68cdbd4e65 Note invalidity of realtick for
captypes ETH_CAPTYPE_OTHERPOD2 and
ETH_CAPTYPE_GIGPOD2 in comments for
the associated TpS tables.

svn path=/trunk/; revision=22074
2007-06-11 15:50:03 +00:00
Guy Harris ef511c0bbc Note realtick's invalidity for ETH_CAPTYPE_OTHERPOD in the comment for
TpS_otherpod[].  Ask about its validity for ETH_CAPTYPE_OTHERPOD2 and
ETH_CAPTYPE_GIGPOD2.

svn path=/trunk/; revision=22016
2007-05-31 05:51:15 +00:00
Guy Harris aa3ac312b2 My comment is redundant with Bill's more-detailed comment; remove it.
svn path=/trunk/; revision=22015
2007-05-31 05:46:45 +00:00
Bill Meier e88e33d5e2 Update Comments
svn path=/trunk/; revision=22005
2007-05-30 15:32:31 +00:00
Guy Harris 70a9743831 Update a comment.
svn path=/trunk/; revision=21998
2007-05-30 00:36:32 +00:00
Guy Harris cba6441fa4 Give more detail on a captype of 6 for an Ethernet capture.
svn path=/trunk/; revision=21997
2007-05-29 23:35:45 +00:00
Guy Harris acde0f9f8a It's pretty clear that hdr.captype's interpretation depends on the
network type; there's no "presumably" about it.

Suggest that "realtick" might have the right time stamp in other cases
(if not, a comment should explicitly indicate that, so that in all cases
where we either know that realtick is wrong or have a lot of evidence to
show that it's right, we note that fact).

svn path=/trunk/; revision=21996
2007-05-29 23:31:03 +00:00
Guy Harris f93cf6dd86 Update the big time unit comment to reflect Bill Meier's recent changes.
Fix some other comments.

Add a suggestion for why the realtick values might correlate with
packets having an FCS.

svn path=/trunk/; revision=21993
2007-05-29 22:52:42 +00:00
Bill Meier 0bf864bc32 (fix comment)
svn path=/trunk/; revision=21983
2007-05-29 14:27:42 +00:00
Bill Meier 3b12c867a2 Another sniffer timestamp display fix; addresses bug 866 and other reports.
(Also: change variable name to correctly reflect usage).

svn path=/trunk/; revision=21982
2007-05-29 14:20:54 +00:00
Guy Harris 235596a3c8 From Jeff Foster: add support for Cisco HDLC captures.
svn path=/trunk/; revision=21598
2007-04-26 20:06:06 +00:00
Ulf Lamping 59d6c8ea33 change all file offsets from long to gint64 so we can - theoretically - handle files > 2GB correct.
Please distclean Win32 builds!

svn path=/trunk/; revision=19814
2006-11-05 22:46:44 +00:00
Michael Tüxen 3ce4a70412 Use G_GINT64_CONSTANT to handle 64-bit constants in the code.
svn path=/trunk/; revision=19663
2006-10-23 17:12:48 +00:00
Bill Meier 798a4b8c77 fix 'save' to store hi-order 32 bits of time offset for each pkt; fixes bug 1168
svn path=/trunk/; revision=19622
2006-10-20 01:17:17 +00:00
Jaap Keuter b33cccd47f Sake Blok wrote....
I have taken a look at the trace myself and calculated the TpS to be 
20000000.0 for this particular trace. If I also discard the start_timestamp
like it has been done for other versions of the netxray format, then I get 
the proper results.

svn path=/trunk/; revision=17869
2006-04-15 19:00:42 +00:00
Luis Ontanon 9ed9299e17 Remove an entire horde of off-by-one errors pointed out by Coverity's CID: 83
(Coverity finds just one at a time...)


svn path=/trunk/; revision=17580
2006-03-11 11:48:35 +00:00
Luis Ontanon 83296ec679 Another off by one error found by coverity (CID 83), using > instead of >= when comparing index against array size.
svn path=/trunk/; revision=17521
2006-03-08 10:20:09 +00:00
Jaap Keuter ca4000cbaf The attached patch to fix bug 663 allows Ethereal to read Windows
Sniffer V2 format capture files with captyp=5, timeunit=0.
The ticks_per_sec for this case apparently is 1e6.

Bill Meier

svn path=/trunk/; revision=17019
2006-01-12 15:02:25 +00:00
Guy Harris 90ce35c64e From Bill Meier:
define "timezone" as "gint16", as it can be positive (west of
	UTC) or negative (east of UTC);

	update comments to refer to the new names for structure members;

	say the precision of the time stamps is 1 nanosecond only if the
	ticks per second is > 10 million;

	fix the handling of files truncated exactly on a frame boundary.

svn path=/trunk/; revision=15739
2005-09-09 08:40:58 +00:00
Guy Harris 88c5c6c0d8 Get rid of the old file header definition.
Set the time stamp resolution based on whether the number of ticks per
second is > 1 million or not.

svn path=/trunk/; revision=15606
2005-08-29 01:18:27 +00:00
Guy Harris 394582573d From Bill Meier:
1. Use the new (good work!) 'nanosec' precision only for gig pods;
2. Rework 'struct netxray_hdr' to make it (somewhat) easier
   to maintain and revise:
   a. Declare known hdr fields such as 'captype' instead
      of using offsets in 'xxx placeholder' fields.
   d. Define 'unknown' hdr fields using placeholder names
      based upon hex-offset in the netxray header record.
      (This isn't perfect, but I hope it will make things 
       more manageable).
3. Update hdr field info (based upon examination of various
   capture files):
   a. Define a hdr field which appears to be 'time-zone' 
      [offset in hours from UTC] for the machine doing
      the capture.
      (Maybe this field can eventually be used for Ethereal
       to display the (local) time as it was at the time
       of the capture).
   b. Describe certain hdr fields as being "file offsets"
      (altho the exact use is still unclear).

Update some comments.

svn path=/trunk/; revision=15603
2005-08-28 23:11:53 +00:00
Ulf Lamping 723c80ea90 timestamp display precision:
- automatic adjustment depending on file format
- manual adjustment through menu items

save the setting in the recent file

svn path=/trunk/; revision=15534
2005-08-25 21:29:54 +00:00
Ulf Lamping 6f43fbb2f0 EVERYTHING IN THE BUILDBOT IS GOING TO BE RED!!! Sorry!
I've done more than a day to change the timestamp resolution from microseconds to nanoseconds. As I really don't want to loose those changes, I'm going to check in the changes I've done so far. Hopefully someone else will give me a helping hand with the things left ...

What's done: I've changed the timestamp resolution from usec to nsec in almost any place in the sources. I've changed parts of the implementation in nstime.s/.h and a lot of places elsewhere.

As I don't understand the editcap source (well, I'm maybe just too tired right now), hopefully someone else might be able to fix this soon.

Doing all those changes, we get native nanosecond timestamp resolution in Ethereal. After fixing all the remaining issues, I'll take a look how to display this in a convenient way...

As I've also changed the wiretap timestamp resolution from usec to nsec we might want to change the wiretap version number...

svn path=/trunk/; revision=15520
2005-08-24 21:31:56 +00:00
Guy Harris d5891d9623 Try yet another scheme for handling time stamps; realtick isn't always
correct.

svn path=/trunk/; revision=15404
2005-08-18 09:47:00 +00:00
Jörg Mayer adddb9819b Chris Lydick: Support for Sniffer 2.003 files.
Modified to match the current codebase.


svn path=/trunk/; revision=14832
2005-07-02 15:40:49 +00:00
Guy Harris f28456dd84 Note that the WAN_CAPTYPE value of 4 can correspond to Cisco HDLC
traffic as well as Frame Relay traffic, and give some information about
the cruft found in the xxc field of the header for one CHDLC and one FR
capture.

svn path=/trunk/; revision=14659
2005-06-16 08:10:13 +00:00
Guy Harris e4a550c538 Add some notes about stuff discovered by Ken Mann.
svn path=/trunk/; revision=13194
2005-01-29 10:48:16 +00:00
Guy Harris c3240e1ccb Note that the low-order bit of hdr->hdr_2_x.xxx[8] appears to be a "bad
FCS" bit for 802.11, just as it appears to be for Ethernet, and give
more details on the 4 bytes of junk at the end of the packet (i.e., that
we haven't yet seen an 802.11 capture where it's an FCS rather than just
junk).

svn path=/trunk/; revision=13028
2005-01-14 09:47:22 +00:00