would have filled in had it not failed. (Thanks and a tip of the Hatlo
hat to the Clang static analyzer for complaining about this.)
svn path=/trunk/; revision=42306
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
native file formats, so try them first.
Move eyesdn_open() to the section for open routines for file formats
that have a magic number - EyeSDN traces all start with "EyeSDN".
svn path=/trunk/; revision=42250
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
wtap_dump_fdopen_ng() and add a dummy IDB to be able to write pcapng files.
Solves https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6969
mergecap: Can't open or create <FILENAME>: Internal error.
We might want to add a SHB comment from mergecap giving the merged filenames or something like that, Merging of pcapng files
is a different issue, idealy we should probably start using several SHB:s in that case.
svn path=/trunk/; revision=42230
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
Unable to display the correct IEEE802.11 MCS data rates due to header definition
The problem is due to the ieee_802_11_phdr.data_rate is defined as guint8,
since this variable is counting number of 0.5Mbps units, any datarates which is
higher than 255Mbps would get wrapped up. In the above example, only the lower
8bit value will be put into the ieee_802_11_phdr which is 0x04 and result in
the incorrect 2Mbps display.
There are 802.11n WLAN product is capable to transmit @450Mbps, we should fix
this data_rate from guint8 to guint16.
#BACKPORT
svn path=/trunk/; revision=42123
return the right error code and information string.
InfoVista bought Accellent Group, and, at least according to the
InfoVista Web site, it's "5View", not "5Views".
svn path=/trunk/; revision=42119
Add a new WTAP_ENCAP_BACNET_MS_TP_WITH_PHDR encapsulation type, for use
by the EyeSDN file reader; unlike the pcap-encapsulated MS/TP, it
includes a direction indicator. Don't treat WTAP_ENCAP_BACNET_MS_TP as
if it has a direction indicator, as it doesn't; instead, do that for
WTAP_ENCAP_BACNET_MS_TP_WITH_PHDR.
Add some missing entries to encap_table_base for WTAP_ENCAP_ values that
didn't get entries added.
svn path=/trunk/; revision=41969
or other information; WTAP_ENCAP_MTP2_WITH_PHDR is for MTP2 *with* such
a pseudo-header. Use WTAP_ENCAP_MTP2_WITH_PHDR for the EyeSDN captures,
and don't assume there's a pseudo-header if you have WTAP_ENCAP_MTP2.
svn path=/trunk/; revision=41962
from makefiles (and thus from the buildbot).
The intention is to be able to tell when a human is running the tool so we
can provide more code-review guidance.
As a starter, enable the "too many proto_tree_add_text() calls" check when
a human is running the tool.
svn path=/trunk/; revision=41943
Guy Harris