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>
(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
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
for read and seek-read.
Clarify a comment. (wtap_open_offline() only rewinds the file before
calling each open routine; once one of those routines has decided the
file belongs to it, the seek offset belongs to it, so it needs to do all
the seeking necessary - files with a file header *don't* want a rewind,
they want to leave the seek offset positioned *past* the file header so
it can read the records that follow the file header.)
svn path=/trunk/; revision=49347