retrieve our SVN revision in releases.
Use make-version.pl to set all version information. Be more explicit
about the tasks it performs:
- Fetching the SVN revision which corresponds to our code. The
revision can be fetched via "svn info", "git svn info", SubWCRev",
config.nmake, or by prodding .svn.
- Setting the version numbers (the "major.minor.micro" triplet).
- Setting the release information (revision/build number, local build
identifier)
Remove the "is_release" configuration option and dist-hook target.
When run with a "--set-*" option or no options make sure we leave a
valid svnversion.h behind.
svn path=/trunk/; revision=39891
pcap. Add a "-P" capture option which tries to use pcap instead of
pcap-ng ("-P" seemed to be the best option but we may want to use a
different letter).
Update the documentation and release notes.
svn path=/trunk/; revision=37696
The Locator/ID Separation Protocol [1] is being standardized within the IETF,
and it is nearing RFC status (pending security review). I have been maintaining
a dissector patch for about a year, see [2]. Feedback received indicates that,
among others, it is widely used by the developers of a large router vendor,
without issues.
In January I submitted the dissector for data plane packets as bug #5602, which
was committed as r35615. The patch attached to this bug adds support for
dissection of control plane packets.
[1] http://tools.ietf.org/html/draft-ietf-lisp
[2] http://lisp.ccaba.upc.edu/wireshark/
svn path=/trunk/; revision=36845
Patch to add a new dissector for Realm Specific IP (RSIP) as defined by
RFC 3102, RFC 3103, and RFC 3104.
This is a very basic dissector. It could be extended to do addtional RSIP
protocol violation testing. The dissector is written such that it should be
easy to add later.
svn path=/trunk/; revision=35653
The patch I am attaching here is for dissecting LISP data packets.
From me:
Minor cleanups.
Showing the reserved field.
Adding to all makefiles and release notes.
svn path=/trunk/; revision=35615
This patch adds a new '-S' option to editcap that will rewrite timestamps of
packets to insure that the new capture file is in strict chronological order.
This option's primary use case is to fixup the occasional timestamps that have
a negative delta time relative to previous packet.
This feature is related to (but does not depend on) capinfos enhancement
submitted in bug #4315 which helps identify tracefiles with "out-of-order"
packets.
svn path=/trunk/; revision=33042
This patch adds a new '-o' option to capinfos (enabled by default) to report if
the packets within a particular capture file are in strict chronological time
order or not.
svn path=/trunk/; revision=33041
Gerald Combs