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
The attached patch extends the mpeg2 ts format detection to take into account
that trailing bytes might be added to each packet.
Once it finds no sync after 188 bytes, it checks an additional 40 bytes for the
next sync byte and adjusts the packet size accordingly.
Only the 188 bytes of the actual ts packet are passed on to wiretap, the
trailer is omitted.
svn path=/trunk/; revision=41863
if they're not. Also report an error for zero-length names.
Handle multiple names per IP address - the pcap-NG spec says "one or
more zero-terminated strings containing the DNS entries for that
address."
Use a Buffer to hold NRB records, so there's no maximum size (well,
there is a maximum size, because the record length is 16 bits, but let's
not allocate 64KiB on the stack if we don't have to).
svn path=/trunk/; revision=41332
and should not contain the extension in the default_file_extension
member - that's why the name starts with "additional".
svn path=/trunk/; revision=41293
pcap_read_simple_packet_block(), not in pcap_read() - the way the fields
are filled in differs between simple and non-simple packet blocks.
Clean up white space.
svn path=/trunk/; revision=41284
clickable to open an edit window.
- Add checks for NULL pointers.
Help with a different color LED possibly with Jeff's (c) in it apreceated.
Should the LED be placed elsewhere or the whole thing done differently?
svn path=/trunk/; revision=41242
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
That means we don't need to do the block length check in
pcapng_read_block(); each block type reader, including the one for
unknown block types, does a check that's as stringent as that block
length check or more stringent, which means any block whose length is
less than the minimum will fail with the same error in both cases.
Fix the message for a too-short NRB.
svn path=/trunk/; revision=41152
1) contain the block length fields and block type field;
2) contain that plus the fixed-length portion of the block;
3) for blocks that have a variable-length portion other than the
options, contain that variable-length portion.
Fixes a crash we're seeing with a bad pcap-NG file in the Wireshark
menagerie (7799-lastPacketWithoutComment.pcapng - the last packet's
block length is 128, but it claims to have 98 bytes of packet data,
which requires a 132-byte block).
Clean up white space (use 8-space tabs).
svn path=/trunk/; revision=41143
block, which could be the case even in a *valid* file (consider a file
with an SHB, an NRB, an IDB, and a packet block, in that order); even if
there's no IDB before the first packet block, that should be reported to
the user as "interface N not less than interface count M", to more
precisely indicate the problem.
(Yes, the loop should probably keep going until it finds a packet block,
not just a non-IDB block.)
svn path=/trunk/; revision=41132
you provide NULL when you call it via wtap_dump_open.
This does not make the buildbots happy, but at least
tshark doesn't crash anymore.
svn path=/trunk/; revision=41111
so if we later get a short read, we have to return -1 and set *err to
WTAP_ERR_SHORT_READ. Otherwise, we'll try other file types and, if none
of them match, we'll try to close the wtap structure, which crashes.
svn path=/trunk/; revision=41102
the details of what in particular is unsupported; report it in TShark
and Wireshark.
Handle WTAP_ERR_RANDOM_OPEN_PIPE in TShark.
Handle WTAP_ERR_COMPRESSION_NOT_SUPPORTED in TShark, and have its error
message in Wireshark not speak of gzip, in case we support compressed
output in other formats in the future.
If we see a second section header block in a pcap-NG file, don't report
it as "the file is corrupted", report it as "the file uses a feature we
don't support", as that's the case - and don't free up the interface
data array, as the file remains open, and Wireshark might still try to
access the packets we were able to read.
svn path=/trunk/; revision=41041
For WTAP_ENCAP_ERF files if we find an Extension and/or Multi-Channel header,
ensure that the size of the full pseudoheader is smaller than the packet size
to avoid an underflow and subsequent attempt to allocate a rather large amount
of memory.
svn path=/trunk/; revision=41008
This is POC we may want to have more efficient use of the frame data
structure etc. But this allows for work to be done on the GUI to actually add comments.
svn path=/trunk/; revision=40969
encapsulation value and returns a GArray containing all the file types
that could be used to save a file of that file type and that
encapsulation value (which could be WTAP_ENCAP_PER_PACKET), with the
input file type first if that can be used and pcap or pcap-ng first if
not and if one of them can be used, and with pcap and pcap-ng clustered
together if they're among the file types that can be used.
Use that routine for the GTK+ file save dialog.
svn path=/trunk/; revision=40685
Fix an out-of-array-bounds warning from OpenBSD's compiler. (Note: this is
actually a false positive since adequate memory is allocated.)
From me: some additional code simplification.
svn path=/trunk/; revision=40680
a field that gives the default extension for the file type,
*without* a leading "." (i.e., just the extension, not the "."
that separates it from the rest of the file name), which is NULL
if there are no known extensions;
a field that gives a semicolon-separated list of *other*
extensions, without "*." or ".", which is NULL if there are no
known extensions or there are no known extensions other than the
default.
Rename wtap_file_extension_default_string() to
wtap_default_file_extension() (matches the name of the field).
svn path=/trunk/; revision=40678
extensions at all.
For file types that are plain text and that don't already have
extensions, add "txt" as the extension.
svn path=/trunk/; revision=40657
GSList of extensions for a file type, including extensions for the
compressed versions of those file types that we can read.
svn path=/trunk/; revision=40623
select only files of that type; you might as well use "All Files (*.*)"
for that.
The default suffix is a suffix, not a pattern, so it shouldn't be
"*.{something}".
We only use the patterns on Windows, where file names are
case-insensitive, so there's no point in capital letters in suffixes.
svn path=/trunk/; revision=40621
Wireshark distribution, give us code to read it. If somebody wants it
in their private version of Wireshark, they can manage that themselves.
(We should support plugins for file types at some point; I think we
already have support for Lua file readers.)
svn path=/trunk/; revision=40620
directly to k12text_set_pseudo_header(), so that it's passed the right
encapsulation for seek-and-read as well as for read. Fixes the
"malformed frames when reading some K12 text files" problem for which
we're using bug 6735.
svn path=/trunk/; revision=40508
Move pcap-NG right after standard pcap in the list of file types, so
that it shows up early in the list of output file types in the "Save
As..." dialog box (if, that is, it's supported; if not, neither is pcap,
as they use the same link-layer header type values).
svn path=/trunk/; revision=40493
WTAP_ENCAP_ARCNET_LINUX; update various tables mapping Wiretap
encapsulations to file-type encapsulations. Get rid of some trailing
"sorry, that's not supported" entries while we're at it.
svn path=/trunk/; revision=40274
> WTAP_MAX_PACKET_SIZE, either that should be caught above the
per-file-type layer in Wiretap or should be handled by the caller.
We've recently fixed at least one problem with reported lengths > 2^31 -
1 (by clamping the length to 2^31 - 1), so let's just remove the check
from the pcap-NG reader, to squelch some complaints we're getting from
the buildbot (bug 6673 and its duplicates).
(The pcap reader uses it to cope with some of the botched libpcap
formats that changed the per-packet header without changing the magic
number; I'll look at trying to preserve those heuristics while still
allowing reported lengths > WTAP_MAX_PACKET_SIZE.)
svn path=/trunk/; revision=40207
form of corruption/bogosity in a file, including in a file header as
well as in records in the file. Change the error message
wtap_strerror() returns for it to reflect that.
Use it for some file header problems for which it wasn't already being
used - WTAP_ERR_UNSUPPORTED shouldn't be used for that, it should only
be used for files that we have no reason to believe are invalid but that
have a version number we don't know about or some other
non-link-layer-encapsulation-type value we don't know about.
svn path=/trunk/; revision=40175
