New protocol: epl v1
Hi,
in addition to the recently submitted dissector for the EPL v2 protocol,
this is the dissector for the first version of the EPL protocol.
Best Regards,
David
svn path=/trunk/; revision=19125
new protocol: veritas low latency transport
---
Attached is a patch file that adds a new dissector for the LLT protocol
(Veritas Low Level Transport, used for server clustering). They use
ethertype 0xCAFE even though it isn't assigned to them :(. There are
other fields and possibly other message types directly between servers
it does not yet dissect as no one outside of Veritas knows what they
are. This dissector understands the one people will run across most -
multiple servers broadcasting these heartbeats all over the place. I
figured out these fields through many Internet searches.
I will add the protocol to the Wiki after it is committed.
Thanks,
Steve
svn path=/trunk/; revision=18944
I have developed a plugin for Pro-MPEG FEC packets over RTP (see
previous posts on ethereal-dev). I have added a page and example capture
file to the Wiki (http://wiki.wireshark.org/2dParityFEC). The source and
Windows makefile for the plugin are attached. Unfortunately I do not
have access to other systems so this plugin has been tested on Windows
only.
The attached version of my plug-in has only had the copyright header
added.
I will translate this into a proper dissector rather than a plug-in as
requested, but this may take a little time as I have a lot of other
things
to do at the moment.
Me:
Convert into a normal dissector
Reorder / reformat code a bit
Added Marks name to the top of the file.
svn path=/trunk/; revision=18908
Hi,
The attached file should fix the following two bugs in the AJP dissector.
1) The dissector doesn't know about CPING/CPONG
2) The dissector misinterprets multiple requests in one connection if a
prior request has a Body request part.
svn path=/trunk/; revision=18780
this dissector will not yet detect when ppp is passed over the rfcomm link
but the old code to detect and deescapt the ppp data is still in the dissector, though ifdeffed out to serve as inspiration when ppp over rfcomm captures are made available.
the only captures i have with rfcomm are for raw serial communications so they dont contain any ppp frames. :-(
svn path=/trunk/; revision=18221
library. If that's not done, it leaves to ethereal or other binaries
using it the job of linking adns within them. This behaviour is
unreliable and breaks when using the --as-needed flag for GNU ld
(version 2.16 or better 2.17).
svn path=/trunk/; revision=17969
I have developed an external plugin to enable ssl decryption in
ethereal.
Me
- Remove unnecessary $Id$ from acinclude.m4
- Added packet-ssl-utils.h to Makefile.common
- Fixed a few warnings
TODO
- Lots of warning fixes (see separate mail)
- Reformat function headers to read like the others do
(return value<newline>function-name...)
- Test on Windows platform
- Review the patch to packet-ssl.c and new files packet-ssl-utils.[hc]
svn path=/trunk/; revision=17156
epan/dissectors/ncp2222.py - Fixes the NCP group values for all NCP's. Also fixes some additional return values and cleanup.
gtk/ncp_stat.c - Fixes the NCP group values for SRT.
gtk/service_response_time_table.c:
The SRT is broken if you hit the reload button or apply a filter. The table isn't cleared so each item in the list is duplicated and the second entries remain with initial values. This patch clears the GTK_CLIST so that the redundant entries no longer appear.
svn path=/trunk/; revision=17139
After investigating the time-sequence graphs (Stevens and tcptrace) produced
using an FTP capture file supplied by Eduardo Segura
(see http://www.ethereal.com/lists/ethereal-users/200512/msg00153.html )
I've identified several problems in tcp_trace.c.
The problems mostly involve incorrect determination of the lower/upper
sequence number bounds (for the Y axis) in certain cases (e.g. having to do
with 'partial' conversations).
I've reworked the '...get_bounds' code to handle cases such as:
1. out of order data segments (e.g.: the first segment in a captured
conversation has a higher sequence number than a later segment);
2. 'ack' sequence numbers for initial ack segments in a conversation lower
than the sequence numbers of the initial data segments;
3. maximum 'ack + win' sequence number in a conversation greater than the
max data sequence number;
4. Stevens graph: only use data segment sequence numbers when
determining bounds;
5. TCP RST packet without 'ack' flag: do not try to use the 'ack' seq num from
the packet in this case. (This was the specific cause of the originally reported
problem).
I've also reworked the tcptrace display code slightly to properly handle
the initial ack packet of a sequence;
As an example of the some of the fixes the Ethereal tcptrace style graph
of the following conversation fragment will now be similar to the graph
produced by Tcptrace.
data: seq 10000 len 100
data: seq 10100 len 200
ack: ack 5000 win 6000
ack: ack 5400 win 5600
svn path=/trunk/; revision=16874
> Two patch files are attached adding UDP-Lite dissection to the UDP
> dissector. Wiki page is available at the normal location, including
> sample captures courtesy of Gerrit Renker of the University of
> Aberdeen Electronics Research Group. The patch has been tested with
> both the sample captures and Fuzz test.
And add Marc Petit-Huguenin to AUTHORS
svn path=/trunk/; revision=16801
New protocol : CIGI (with minor updates to make it heuristic)
Hi,
This patch is for a CIGI dissector (complete versions 2 and 3). It has
been [fuzz] tested on GNU/Linux using the Ethereal 0.10.13 codebase.
However, the patch here is against the svn repository.
More information about CIGI can be found at http://cigi.sourceforge.net/
Kyle Harms
svn path=/trunk/; revision=16681
New protocol : STANAG 5066
I changed it from being a plugin to a builtin dissector
and also changed a couple of small bugs
svn path=/trunk/; revision=16390
