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
in little-endian byte order, as that's what the dissector expects. Add
a pletohl() macro for that purpose.
Fix comments (the Veriwave code is *not* writing data to a file!) and
clean up indentation.
svn path=/trunk/; revision=42255
global variables into a structure that's attached to the wtap_t as
private data, and make all the per-*packet* global variables local
variables.
svn path=/trunk/; revision=42251
we know we had a real problem with the file. If we just get a short
read, return 0, as it means the file is probably not a VWR file.
If we get an invalid message length when reading packets (rather than
when looking for the FPGA version), return WTAP_ERR_BAD_FILE and an
"Invalid message record length" indication, not a generic fallback
"can't read the file" error.
For file_tell() errors, fetch the error code with file_error().
For file_seek() errors, use the error file_seek returned.
svn path=/trunk/; revision=42249
From Tom Cook and Tom Alexander.
1. A VWR encapsulation that reads VeriWave capture files (*.vwr)
generated from
WaveTest test hardware
2. Dissectors that display the VeriWave tap headers (both 802.11 and
Ethernet)
3. A dissector for the WaveAgent protocol. The WaveAgent dissector is
heuristic and parses the WaveAgent packet (a UDP payload).
The WaveAgent dissector has been Fuzz tested.
The VWR ENCAP and dissectors have been used extensively by VeriWave
customers in a special version of WireSark compiled by VeriWave.
svn path=/trunk/; revision=42155
Guy Harris