(The dissector checks for it.)
Change-Id: Ic1456b263f3cbda2a630259a2b71b1f1015b5e3e
Reviewed-on: https://code.wireshark.org/review/21442
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Include the RF information length if there's RF information.
While we're at it:
Rename the variable holding the offset of the stats information from "j"
to "stats_offset", to make it clearer what it is.
Clean up whitespace.
Get rid of comments that no longer apply.
Improve the comment explaining the MPDU_OFF value for Series III.
Change-Id: I49e2926a80aa8bb11f87d97fdc628bcc9f1220e0
Reviewed-on: https://code.wireshark.org/review/21439
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add #defines for the remaining command types, based on some other
Get rid of the HEADER_IS_xxx #defines; they're the same for all
hardware, and the switch statement doesn't distinguish between different
hardware.
Set *IS_TX in the switch statement cases. While we're at it, set v_size
and *v_type in the default case; add a VT_UNKNOWN value for that case.
Change-Id: Ib17d1e435c99fcb746144b4735c160a5f22b7544
Reviewed-on: https://code.wireshark.org/review/21438
Reviewed-by: Guy Harris <guy@alum.mit.edu>
There aren't any "4 Management bytes for OCTO version FPGA" in that
header.
Change-Id: I57f673dad5bc10b888fae22c2fb1a45af57ff493
Reviewed-on: https://code.wireshark.org/review/21434
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Whitespace, remove now-irrelevant comments, add more comments, expand
some comments, make an if chain more straightforward.
Change-Id: I9772022247e2f0fdbfc676db9f0031bad7f8884d
Reviewed-on: https://code.wireshark.org/review/21423
Reviewed-by: Guy Harris <guy@alum.mit.edu>
You don't have to and the bitfield container with a mask and compare it
against the bit, you can just test the bit, which is a pretty standard C
idiom.
Change-Id: I87b3d84f802114199fb93357358412c623199ca2
Reviewed-on: https://code.wireshark.org/review/21422
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This makes stuff a bit clearer.
Also, add some comments, remove some redundant comments, fix some
comments, and use some #defines instead of hardcoded constants and
expressions.
And get rid of an unnecessary setting of *err to WTAP_ERR_SHORT_READ -
either it's a short read, in which case it was already set to
WTAP_ERR_SHORT_READ, or it's *not* a short read, in which case *err was
set to the appropriate error code, and we should leave it alone.
Change-Id: I657f505915854ac4a6b85e87b4021961b1a1c507
Reviewed-on: https://code.wireshark.org/review/21415
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It's only called if vwr->FPGA_VERSION is S2_W_FPGA, so any code that's
run only if it's *not* S2_W_FPGA is dead code. Remove it, for clarity.
While we're at it, add some new comments, fix some comments, and get rid
of an unused argument to vwr_read_s2_W_rec().
Change-Id: I3e4bd5d7a79f36d8354a0bbf875ee87eeaf60d43
Reviewed-on: https://code.wireshark.org/review/21414
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Attempt to make the various metadata headers, and the code that
constructs them, a bit clearer.
(Also, it's VeriWave; be consistent.)
Change-Id: I0bb7d70f547d492c4947ceb313888991f2d374f2
Reviewed-on: https://code.wireshark.org/review/21360
Reviewed-by: Guy Harris <guy@alum.mit.edu>
If the seek forward is just skipping record content that's not
(currently) interesting, use wtap_read_bytes() with a null buffer
pointer; it catches short "reads" and requires less seeking, so it may
work better when reading from a pipe.
Change-Id: Ifb07d20e0391a8ed97da85149d971b4e9ef093a8
Reviewed-on: https://code.wireshark.org/review/17976
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Allow file_read() to take a null pointer as a buffer argument; a null
argument means "do everything except copy the bytes from the file to the
user buffer". That means that wtap_read_bytes() and
wtap_read_bytes_or_eof() also support a null pointer as a buffer
argument.
Use wtap_read_bytes() with a null buffer argument rather than
file_skip() to skip forward over data.
This fixes some places where files were mis-identified as ERF files, as
the ERF open heuristics now get a short "read" error if they try to skip
over more bytes than exist in the file.
Change-Id: I4f73499d877c1f582e2bcf9b045034880cb09622
Reviewed-on: https://code.wireshark.org/review/17974
Reviewed-by: Guy Harris <guy@alum.mit.edu>
VS Code Analysis claims the arrays are too large and should be moved to help
Change-Id: I741ebe8cc73a108cb6e6d9ecbda37e2a4b6e1b4b
Reviewed-on: https://code.wireshark.org/review/16423
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
And note the cases where we don't have to check, as the length in the
file is 2 bytes long, and 65535 + the metadata length is <
WTAP_MAX_PACKET_SIZE.
Change-Id: I1e690eeee900b9aa7484dc0bd0c106dc38c77269
Reviewed-on: https://code.wireshark.org/review/15180
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The S1 code works similarly to the S2/S3 code, and has the same issue.
Change-Id: I288e30ccdf67d8a6daec8c8428c0f703e18ecc89
Reviewed-on: https://code.wireshark.org/review/14127
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The 1 is for the byte written with vht_ndp_flag; the 16 is for the PLCP
header. Separate them out; no change to the actual code (as any
compiler worth its salt would do constant folding).
Change-Id: I5e081c67e605203153270ed9a3f9e30b9e9b968c
Reviewed-on: https://code.wireshark.org/review/14125
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Commit v1.99.10rc0-316-gf28e23f added some additional room for the 16
byte PLCP header and 1 byte L1P. These are however not part of the
remaining data, only the header.
Bug: 11795
Change-Id: Ia6935d27366a07f818f147c9094a801429b049e2
Reviewed-on: https://code.wireshark.org/review/12240
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Bug: 11791
Change-Id: Ibaa2c16229c1b78818283ba5f954b09f3894dc60
Reviewed-on: https://code.wireshark.org/review/12270
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
No need to put them on the stack and initialize them at the beginning of
the routine.
Change-Id: Id6332be186660c881cf37290f70d03cc77ac66be
Reviewed-on: https://code.wireshark.org/review/12265
Reviewed-by: Guy Harris <guy@alum.mit.edu>
For unsigned x, x/8 is x >> 3, and x*8 is x << 3, so 8*(x/8) is the result
of shifting x right 3 bits and then left 3 bits, which is the same as
masking out the low-order 3 bits, and x - (8*x/8) is the result of
subtracting all but the low-order 3 bits from x, thus it's the lower 3
bits, so you can just mask it with 0x7. That means the result is in the
range 0 through 7, so as long as the array has 8 elements, you're OK; it
does, but explicitly declare it as such, to make it clearer that it is,
and to get compiler warnings if not all 8 elements are initialized.
Change-Id: Iff9c0626b9bdc012cca52e4160dda9e947315bc4
Reviewed-on: https://code.wireshark.org/review/12264
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Bug: 11789
Change-Id: Ieba9f32928b91be5d07b25bf54005155f7cc79f6
Reviewed-on: https://code.wireshark.org/review/12245
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
The packet data in some records has an FCS and in some records doesn't.
It appears that only the Series III packets do. Handle that.
Handle HT and VHT information supplied by Series III.
Get rid of an unused include while we're at it, and make the checks for
whether the protocol tree is being built a bit clearer, by testing the
tree pointer we'll actually be using. Make some style cleanups. Get
rid of some unused cruft.
Fix FPGA version checks.
This is based on Ixia's patches to an older version of Wireshark, but is
much cleaned up.
Bug: 11464
Change-Id: Ia341e6ffb1771cf38be812bf786f59b3250b7d5b
Reviewed-on: https://code.wireshark.org/review/10756
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The command byte values aren't FPGA-specific - if they were, the code
wouldn't have worked. Provide #defines for the main ones and check for
them, and use that to determine whether the packet is transmitted or
received.
Add a bunch of #defines, shuffle some defines to cluster related ones
together and separate unrelated ones, get rid of duplicate #defines
(where different FPGAs use the same value).
Fix some typoes.
Change-Id: Ic8adc589d7c36a4a91a81858de40c904743dd067
Reviewed-on: https://code.wireshark.org/review/9529
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Clean up some things we ran across while making those changes.
Change-Id: Ic0d8943d36e6e120d7af0a6148fad98015d1e83e
Reviewed-on: https://code.wireshark.org/review/4581
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Unlike the standard I/O routines, the code we introduced that supports
fast random seeking on gzipped files will always supply some specific
error code for read errors, so we don't need WTAP_ERR_CANT_READ.
Add WTAP_ERR_CANT_WRITE for writing, as we're still using the standard
I/O routines for that. Set errno to WTAP_ERR_CANT_WRITE before calling
fwrite() in wtap_dump_file_write(), so that it's used if fwrite() fails
without setting errno.
Change-Id: I6bf066a6838284a532737aa65fd0c9bb3639ad63
Reviewed-on: https://code.wireshark.org/review/4540
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add wtap_read_bytes(), which takes a FILE_T, a pointer, a byte count, an
error number pointer, and an error string pointer as arguments, and that
treats a short read of any sort, including a read that returns 0 bytes,
as a WTAP_ERR_SHORT_READ error, and that returns the error number and
string through its last two arguments.
Add wtap_read_bytes_or_eof(), which is similar, but that treats a read
that returns 0 bytes as an EOF, supplying an error number of 0 as an EOF
indication.
Use those in file readers; that simplifies the code and makes it less
likely that somebody will fail to supply the error number and error
string on a file read error.
Change-Id: Ia5dba2a6f81151e87b614461349d611cffc16210
Reviewed-on: https://code.wireshark.org/review/4512
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Pcap-ng files don't have a per-file time stamp resolution, they have a
per-interface time stamp resolution. Add new time stamp resolution
types of "unknown" and "per-packet", add the time stamp resolution to
struct wtap_pkthdr, have the libwiretap core initialize it to the
per-file time stamp resolution, and have pcap-ng do the same thing with
the resolution that it does with the packet encapsulation.
Get rid of the TS_PREC_AUTO_XXX values; just have TS_PREC_AUTO, which
means "use the packet's resolution to determine how many significant
digits to display". Rename all the WTAP_FILE_TSPREC_XXX values to
WTAP_TSPREC_XXX, as they're also used for per-packet values.
Change-Id: If9fd8f799b19836a5104aaa0870a951498886c69
Reviewed-on: https://code.wireshark.org/review/4349
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It was being checked against the wrong value, so some invalid records
passed the check.
Also, change one comparison (rec_size is in the range [0, 65535], even
though it's in an int, so we can safely cast it to guint) and fix the
metadata length value when reading Ethernet packets.
Bug: 10495
Change-Id: I2ce5c93fe50d836ec0accfcdef31654ba6b5b7c7
Reviewed-on: https://code.wireshark.org/review/4278
Reviewed-by: Guy Harris <guy@alum.mit.edu>
In particular, epan/wslua/lrexlib.c has its own buffer_ routines,
causing some linker warnings on some platforms, as reported in bug
10332.
(Not to be backported to 1.12, as that would change the API and ABI of
libwsutil and libwiretap. We should also make the buffer_ routines in
epan/wslua/lrexlib.c static, which should also address this problem, but
the name change avoids other potential namespace collisions.)
Change-Id: I1d42c7d1778c7e4c019deb2608d476c52001ce28
Reviewed-on: https://code.wireshark.org/review/3351
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Otherwise, if you link with both libwiretap and libfiletap, it's
anybody's guess which one you get. That means you're wasting memory
with two copies of its routines if they're identical, and means
surprising behavior if they're not (which showed up when I was debugging
a double-free crash - fixing libwiretap's buffer_free() didn't fix the
problem, because Wireshark happened to be calling libfiletap' unfixed
buffer_free()).
There's nothing *tap-specific about Buffers, anyway, so it really
belongs in wsutil.
Change-Id: I91537e46917e91277981f8f3365a2c0873152870
Reviewed-on: https://code.wireshark.org/review/3066
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add a "record type" field to "struct wtap_pkthdr"; currently, it can be
REC_TYPE_PACKET, for a record containing a packet, or
REC_TYPE_FILE_TYPE_SPECIFIC, for records containing file-type-specific
data.
Modify code that reads packets to be able to handle non-packet records,
even if that just means ignoring them.
Rename some routines to indicate that they handle more than just
packets.
We don't yet have any libwiretap code that supplies records other than
REC_TYPE_PACKET or that supporting writing records other than
REC_TYPE_PACKET, or any code to support plugins for handling
REC_TYPE_FILE_TYPE_SPECIFIC records; this is just the first step for bug
8590.
Change-Id: Idb40b78f17c2c3aea72031bcd252abf9bc11c813
Reviewed-on: https://code.wireshark.org/review/1773
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This reverts commit c0c480d08c.
A better way to do this is to have the record type be part of struct wtap_pkthdr; that keeps the metadata for the record together and requires fewer API changes. That is in-progress.
Change-Id: Ic558f163a48e2c6d0df7f55e81a35a5e24b53bc6
Reviewed-on: https://code.wireshark.org/review/1741
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This is the first step towards implementing the mechanisms requestd in
bug 8590; currently, we don't return any records other than packet
records from libwiretap, and just ignore non-packet records in the rest
of Wireshark, but this at least gets the ball rolling.
Change-Id: I34a45b54dd361f69fdad1a758d8ca4f42d67d574
Reviewed-on: https://code.wireshark.org/review/1736
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This reverts commit 1abeb277f5.
This isn't building, and looks as if it requires significant work to fix.
Change-Id: I622b1bb243e353e874883a302ab419532b7601f2
Reviewed-on: https://code.wireshark.org/review/1568
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Start of refactoring Wiretap and breaking structures down into "generally useful fields for dissection" and "capture specific". Since this in intended as a "base" for Wiretap and Filetap, the "wft" prefix is used for "common" functionality.
The "architectural" changes can be found in cfile.h, wtap.h, wtap-int.h and (new file) wftap-int.h. Most of the other (painstaking) changes were really just the result of compiling those new architecture changes.
bug:9607
Change-Id: Ife858a61760d7a8a03be073546c0e7e582cab2ae
Reviewed-on: https://code.wireshark.org/review/1485
Reviewed-by: Michael Mann <mmann78@netscape.net>
Leave it there, but commented out, just in case it *should* be used.
"#if 0" out the code that sets it.
Change-Id: I8802fc416030106d9d8421b0d7b8612597794bab
Reviewed-on: https://code.wireshark.org/review/867
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The "48 bits, in a weird byte order" is a variant of 64-bit
"Corey-endian", with the upper 16 bits of the result - which are in the
*middle* of the bytes of the number - ignored. Define a pcorey48tohll()
macro and use that, rather than the loop.
There are a bunch of #defines for offsets in the headers; use them
rather than magic constants.
Change-Id: Idfdc8a741278d71a5db47c067914c97615c3e02d
Reviewed-on: https://code.wireshark.org/review/864
Reviewed-by: Guy Harris <guy@alum.mit.edu>
And rename to #define for the stats block trailer length to indicate
that it's the length of the trailer, not the length of the stats block
in its entirety.
Change-Id: Iec82c971b32f2d3f4a604fe75a91633e1813ebd5
Reviewed-on: https://code.wireshark.org/review/701
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The #defines came from Radiotap, but this isn't Radiotap (I see no
presence bits here), and Radiotap has to handle stuff that this code
doesn't (such as, for example, Atheros Wi-Fi adapters that, annoyingly,
pad the space between the 802.11 header and the 802.11 payload when in
monitor mode, hence the "datapad" flag).
Change-Id: I87ca3539e0f9254ab94cc8897bdf69e4574f0525
Reviewed-on: https://code.wireshark.org/review/690
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Pull the packet data copying code into the routines that parse the rest
of the record data. Have those routines directly fill in the metadata
headers in the packet data, without bothering to fill in a structure
first.
As a result, those routines no longer can set phdr->caplen to a value
different from phdr->len, so don't set WTAP_HAS_CAP_LEN.
Have the existing sanity checking code cause the read to fail if the
checks fail, and add some additional sanity checking.
Use #defines for some offsets into the statistics header and trailer.
Change-Id: Ie936683b96888961d6e2598131cc0eb6146b37e9
Reviewed-on: https://code.wireshark.org/review/689
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Always include the length of the metadata headers, as we're always
copying them.
Do a straightforward check to make sure the data length is >= 4 before
subtracting out the FCS (which appears not to actually be an FCS; at
least in the captures I've seen, it looks like random junk).
Improve the comments for that code.
Get rid of some tabs, in favor of spaces, while we're at it, and make
the 3 sections of code where that's done more alike.
Change-Id: Ica338cd492ac535833933a8b7cd5191217c5ab5b
Reviewed-on: https://code.wireshark.org/review/685
Reviewed-by: Guy Harris <guy@alum.mit.edu>
In some cases, we know, based on the FPGA code, what vwr->STATS_LEN is,
so use that #define.
While we're at it, replace some hardcoded numbers that represent the
statistics trailer length with the appropriate #define.
Also, combine two identical case arms for Ethernet into one.
Change-Id: I0bdea8e5aab146094ad21fa7e67dca2913da688b
Reviewed-on: https://code.wireshark.org/review/672
Reviewed-by: Guy Harris <guy@alum.mit.edu>
vwr->STATS_LEN is the length of the statistics trailer at the end of the
packet, and it's the same for S2 and S3 versions of the WLAN card. It
should *not* be set to the length of the metadata headers that we
*generate and put in front of the packet data that we hand to our
callers*.
Get rid of a debugging message while we're at it.
Change-Id: I465b5ba4dedb88f1f401d34439b44b16a4bb01cc
Reviewed-on: https://code.wireshark.org/review/671
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The so-called "radiotap headers" bear no resemblance to actual
radiotap.org radiotap headers; there are no presence bits, for example.
Get rid of the words "radiotap" and "radio tap", get rid of #defines
that aren't used, get rid of duplicate definitions.
Change-Id: I0bb6abda5d13bf20810dc865a567f4ec51a38056
Reviewed-on: https://code.wireshark.org/review/670
Reviewed-by: Guy Harris <guy@alum.mit.edu>
In the S1 FPGA code, copy the "MPDU starts at 4 or 6" comment.
Get rid of misleading comment in the S2/S3 FPGA code; we're using the
MPDU_OFF field from the private data structure, so we're not calculating
*anything* at that point. Put in comments indicating what's being done
at the point where those calculations are actually done.
Change-Id: Ifda709a6b2aa7edad964f639086012c72c0a71fe
Reviewed-on: https://code.wireshark.org/review/668
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add a comment describing (some of) the record, while we're at it, and
update another comment to reflect reality.
Change-Id: Ia7f1432402b843b96983375c0e0842c030de0cee
Reviewed-on: https://code.wireshark.org/review/667
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Instead of throwing in 48 and 64 as numbers, use vwr->STATS_LEN to
indicate what the lengths are. Yeah, it has to be fetched at run time,
but big deal.
That also shows that, as we've already rejected records whose size is
less than vwr->STATS_LEN, we don't have to check for that, so eliminate
those checks.
Change-Id: Id4822b3e5a02abfffb2da96a50999e36548a4279
Reviewed-on: https://code.wireshark.org/review/663
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Fix presumed typo while we're at it.
Change-Id: Ic8ae6e6669e5c5fc618ec2516af98ba2390487ce
Reviewed-on: https://code.wireshark.org/review/660
Reviewed-by: Guy Harris <guy@alum.mit.edu>
(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
subtypes, e.g. Network Monitor version 1 and Network Monitor version 2
are separate "file types", even though they both come from Network
Monitor.
Rename various functions, #defines, and variables appropriately.
svn path=/trunk/; revision=53166
We read a two-byte length field and add a constant number of header
bytes to this length, so we could in theory be larger than guint16.
svn path=/trunk/; revision=52619
range check for array index
don't assign the result of pntohs() to a gint16
range check for the values stored in phdr.(cap)len
svn path=/trunk/; revision=52618
don't assign the output of pntoh24() to a gint16
unfortunately, vwr detection does not work reliably and many pdf files
are recognized as vwr - this commit should prevent wireshark from
crashing when it tries to load the USB 2.0 spec as pdf ;-)
svn path=/trunk/; revision=52599
and assign float constants, not double constants, to float variables.
Floating-point constants are double by default; you have to add "f" to
the end to make them float.
This squelches 64-bit-to-32-bit warnings.
svn path=/trunk/; revision=51289
This was the 4th patch, but also:
- use gmalloc0() to allocate vwr struct. Otherwise, valgrind says that
many of fields were still uninitialised when parse_s1_W_stats later
read them
- whitespace tidyup, got rid of remaining tabs and trailing whitespace
Did a fair bit of fuzz-testing without seeing any problems.
svn path=/trunk/; revision=51248
as the "where to put the packet data" argument.
This lets more of the libwiretap code be common between the read and
seek-read code paths, and also allows for more flexibility in the "fill
in the data" path - we can expand the buffer as needed in both cases.
svn path=/trunk/; revision=49949
Check that the record length we got out of the file is at least as big as
stats block trailer; if not, declare the file bad.
svn path=/trunk/; revision=49739
wtap_file_read_expected_bytes() from an open routine - open routines are
supposed to return -1 on error, 0 if the file doesn't appear to be a
file of the specified type, or 1 if the file does appear to be a file of
the specified type, but those macros will cause the caller to return
FALSE on errors (so that, even if there's an I/O error, it reports "the
file isn't a file of the specified type" rather than "we got an error
trying to read the file").
When doing reads in an open routine before we've concluded that the file
is probably of the right type, return 0, rather than -1, if we get
WTAP_ERR_SHORT_READ - if we don't have enough data to check whether a
file is of a given type, we should keep trying other types, not give up.
For reads done *after* we've concluded the file is probably of the right
type, if a read doesn't return the number of bytes we asked for, but
returns an error of 0, return WTAP_ERR_SHORT_READ - the file is
apparently cut short.
For NetMon and NetXRay/Windows Sniffer files, use a #define for the
magic number size, and use that for both magic numbers.
svn path=/trunk/; revision=46803
(read a record header) from failure (got an EOF or an error). Make it
just return a Boolean.
If it fails in vwr_read(), don't overwrite *err_info (yes,
vwr_read_rec_header() might have set *err_info, so don't lose - and
leak! - the value it returned) - trust vwr_read_rec_header(), or the
routines it calls, to have set it. (If there's a code path where that
doesn't happen, that code path needs to be fixed; the setting of
*err_info in vwr_read() should *not* be restored.)
Thanks to Evan Huus for finding a useless variable with cppcheck, and
reporting it in bug 7295, provoking me to look at this.
svn path=/trunk/; revision=42865
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
Guy Harris