Commit Graph

13 Commits

Author SHA1 Message Date
Guy Harris 8a8b883450 Set the svn:eol-style property on all text files to "native", so that
they have LF at the end of the line on UN*X and CR/LF on Windows;
hopefully this means that if a CR/LF version is checked in on Windows,
the CRs will be stripped so that they show up only when checked out on
Windows, not on UN*X.

svn path=/trunk/; revision=11400
2004-07-18 00:24:25 +00:00
Guy Harris ba72e955dc Have "wtap_read()" set "wth->phdr.pkt_encap" to "wth->file_encap",
rather than requiring individual capture file type handlers to do it
(unless they're doing per-packet encapsulation, in which case we check
to make sure they didn't *leave* it as WTAP_ENCAP_PER_PACKET).

svn path=/trunk/; revision=10290
2004-03-03 22:24:53 +00:00
Guy Harris 75d7c8727b Whether frames in an AiroPeek V9 802.11 capture have 4 bytes of 0 or an
FCS at the end appears to depend on the network subtype value.

svn path=/trunk/; revision=10001
2004-02-06 20:50:44 +00:00
Guy Harris 922c36ea57 A MediaSubType value of 1 also means 802.11. (Is that what indicates
whether there's an FCS or not?)

svn path=/trunk/; revision=9995
2004-02-06 05:23:46 +00:00
Guy Harris f23a8e64c0 Make sure a packet has one and only one length field, one and only one
timestamp lower field, and one and only one timestamp lower field.

svn path=/trunk/; revision=9994
2004-02-06 04:48:06 +00:00
Guy Harris 95ff961e2d The time stamps in *Peek V9 files appear to be in nanoseconds from the
Windows FILETIME epoch, i.e. midnight, January 1, 1601.

svn path=/trunk/; revision=9993
2004-02-06 04:27:19 +00:00
Guy Harris d5263942b5 Ethernet frames appear to have 4 bytes of 0 at the end, at least in the
captures I've seen.

svn path=/trunk/; revision=9991
2004-02-06 03:12:21 +00:00
Guy Harris 0875bf3afe V9 format appears to be used by some versions of EtherPeek, too.
The MediaType field seems to be 0 for the Ethernet captures; however,
the MediaSubType field is different.

The fields in the header are different - we can't use hard-coded offsets
for the fields, we have to process them as a sequence of tag/value
items.

Rename some routines to use the same naming convention as the V9 open
routine rather than the same convention as the V5/V6/V7 read and
seek/read routines.

svn path=/trunk/; revision=9990
2004-02-06 02:11:52 +00:00
Guy Harris 2528c053ce Supply a pseudo-header for all 802.11 packets; add an "fcs_len" field to
it, similar to the Ethernet pseudo-header's "fcs_len" field, and use it
in the 802.11 dissector.

svn path=/trunk/; revision=9884
2004-01-27 08:06:12 +00:00
Guy Harris d6cd61061e Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors.  Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.

Add messages for cases where those errors were returned without printing
an additional message.

Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.

Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument.  (That handles a lot of the work of putting the info
string into the error message.)

Make some variables in "ascend-grammar.y" static.

Check the return value of "erf_read_header()" in "erf_seek_read()".

Get rid of an unused #define in "i4btrace.c".

svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
Guy Harris 95f25d46c1 "strtoul()" returns a "long", not a "long long".
svn path=/trunk/; revision=9154
2003-12-03 19:47:36 +00:00
Guy Harris 98c4d5d030 Check for errors and EOF, and handle them appropriately; don't treat all
errors when reading the header as indications that the file isn't an
AiroPeek V9 file.

Put in comments nothing some additional checks we should do.

svn path=/trunk/; revision=9145
2003-12-02 20:27:14 +00:00
Guy Harris fe73d8e3b6 From Martijn Schipper: support for reading AiroPeek files in V9 capture
file format (AiroPeek 2.x).

svn path=/trunk/; revision=9144
2003-12-02 19:37:05 +00:00