knowledge of particular types of plugins. Instead, let particular types
of plugins register with the common plugin code, giving a name and a
routine to recognize that type of plugin.
In particular applications, only process the relevant plugin types.
Add a Makefile.common to the codecs directory.
svn path=/trunk/; revision=53710
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
Lastly, try to improve the documentation a bit concerning chopping and provide another example depicting 2 separate chopping regions. *Maybe* this is clearer?
One more example here for posterity: Given the following 75 byte packet, there
are 8 different ways to chop the 2 regions marked as 10 and 20 in a single pass:
<--------------------------- 75 ---------------------------->
+---+-------+-----------+---------------+-------------------+
| 5 | 10 | 15 | 20 | 25 |
+---+-------+-----------+---------------+-------------------+
1) editcap -C 5:10 -C -25:-20 in.pcap out.pcap
2) editcap -C 5:10 -C 50:-20 in.pcap out.pcap
3) editcap -C -70:10 -C -25:-20 in.pcap out.pcap
4) editcap -C -70:10 -C 50:-20 in.pcap out.pcap
5) editcap -C 30:20 -C -60:-10 in.pcap out.pcap
6) editcap -C 30:20 -C 15:-10 in.pcap out.pcap
7) editcap -C -45:20 -C -60:-10 in.pcap out.pcap
8) editcap -C -45:20 -C 15:-10 in.pcap out.pcap
svn path=/trunk/; revision=51886
Given the following example, it's now possible to chop the 10 bytes depicted from the 100 byte packet 4 different ways and achieve the exact same results:
<-------- 100 --------> Methods:
1) editcap -C 20:10 in.pcap out.pcap
+------+----+---------+ 2) editcap -C -80:10 in.pcap out.pcap
| 20 | 10 | 70 | 3) editcap -C -70:-10 in.pcap out.pcap
+------+----+---------+ 4) editcap -C 30:-10 in.pcap out.pcap
svn path=/trunk/; revision=51854
there and moving it avoids having to recompile the file for use in editcap
and mergecap (which don't link against libwireshark).
svn path=/trunk/; revision=50650
Before:
user0 - USER 0
user1 - USER 1
user10 - USER 10
user11 - USER 11
user12 - USER 12
user13 - USER 13
user14 - USER 14
user15 - USER 15
user2 - USER 2
user3 - USER 3
user4 - USER 4
user5 - USER 5
user6 - USER 6
user7 - USER 7
user8 - USER 8
user9 - USER 9
After:
user0 - USER 0
user1 - USER 1
user2 - USER 2
user3 - USER 3
user4 - USER 4
user5 - USER 5
user6 - USER 6
user7 - USER 7
user8 - USER 8
user9 - USER 9
user10 - USER 10
user11 - USER 11
user12 - USER 12
user13 - USER 13
user14 - USER 14
user15 - USER 15
svn path=/trunk/; revision=50482
[PATCH 1/2] Revert "Try to fix the "LNK4217: locally defined symbol"
warnings.
This reverts commit r48158.
[PATCH 2/2] Employ small hack in editcap to link with a few objects from
libwireshark properly
From me:
Add the ability to reset symbol exports via ws_symbol_export.h's include
guard and do so in capinfos.c and editcap.c. We include ws_symbol_export.h
in over 200 files so it didn't seem to make sense to remove its include
guard entirely.
svn path=/trunk/; revision=48170
is running" mutex. Have the NSIS installer check for this mutex and ask
the user to close Wireshark if it's found. While not perfect this makes
the WinSparkle update process much less annoying.
svn path=/trunk/; revision=47758
Cast away some implicit 64-bit-to-32-bit conversion errors due to use of
sizeof.
Cast away some implicit 64-bit-to-32-bit conversion errors due to use of
strtol() and strtoul().
Change some data types to avoid those implicit conversion warnings.
When assigning a constant to a float, make sure the constant isn't a
double, by appending "f" to the constant.
Constify a bunch of variables, parameters, and return values to
eliminate warnings due to strings being given const qualifiers. Cast
away those warnings in some cases where an API we don't control forces
us to do so.
Enable a bunch of additional warnings by default. Note why at least
some of the other warnings aren't enabled.
randpkt.c and text2pcap.c are used to build programs, so they don't need
to be in EXTRA_DIST.
If the user specifies --enable-warnings-as-errors, add -Werror *even if
the user specified --enable-extra-gcc-flags; assume they know what
they're doing and are willing to have the compile fail due to the extra
GCC warnings being treated as errors.
svn path=/trunk/; revision=46748
Using g_fprintf() fails (crashes) on Windows because the Windows GLib DLL
is linked with (depends upon) MSVCRT while editcap is linked with
(depends upon) MSVCR90.
IOW: "You can't do that ... (on Windows)"
See https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6695 (Comment 2)
for some additional information.
svn path=/trunk/; revision=41168
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
type" when writing out a capture file (i.e., writing a
per-packet-encapsulation capture to a file type that supports it but
doesn't support one of the packet's encapsulations), report the packet
number and, when doing this in a merge operation, report the file from
which it came.
When reporting "sorry, that file can't be written to a file of that
type, period", show the file type rather than the input file link-layer
type that causes the problem. (We could show both. We could be
*really* ambitious and iterate through all possible file types and show
the ones that will or at least might work....)
file_write_error_message() is documented as handling only UNIX-style
errnos, and libwireshark should be usable without libwiretap, so leave
it up to its callers to handle Wiretap errors such as
WTAP_ERR_SHORT_WRITE.
Clean up indentation.
svn path=/trunk/; revision=39949
getopt() can/should normally be found in unistd.h, so:
- When testing for getopt(), define that we HAVE_GETOPT instead of
HAVE_GETOPT_H (to avoid confusion).
- Don't attempt to include getopt.h: not all OS's have it (for example,
Solaris 9 does not).
- (All the places which need getopt already include unistd.h (if we have it).)
If this breaks things on some OS, we might need (a real) HAVE_GETOPT_H check.
svn path=/trunk/; revision=38437
Bill Meier