A very tiny patch that corrects decoding of the Next Payload field in
the IKEv2 header. RFC 4306, Sec 3.2 says that a payload type of 0
means "No Next Payload" and not RESERVED. The patch just uses the
same string the dissector uses for IKEv1, namely, "NONE".
svn path=/trunk/; revision=18914
The enclosed patch updates the set of mime types for line oriented text
data per RFC 2046.
Me:
Remove application/postscript, as it may be binary.
svn path=/trunk/; revision=18913
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
- add a generic guid register to dissect UUID's (move this to a seperate file?)
- this enables us to set some known names for special UUID's
- use standard DCOM fields for IID and alike in remunk.c
- cleanup dcom_protseq_vals handling
- some FT_STRING to FT_GUID changes
svn path=/trunk/; revision=18904
protocol has a lot of preference items. Change the number of
configurable ESP SAs to 16 (in case someone needs do decrypt many
sessions in a single trace file). Fix up whitespace.
svn path=/trunk/; revision=18903
Attached is a patch to packet-http.c that calls a subdissector for
traffic flowing through a proxy via the HTTP CONNECT method. Most
protocols, especially SSL, can be tunneled through an HTTP proxy.
Wireshark currently says this traffic is "Continuation or non-HTTP
traffic" but this patch turns the payload over to the dissector for the
protocol being tunneled. This is similar to how the Socks dissector
works.
svn path=/trunk/; revision=18901
Please find attached a patch with updates to l2tpv3's l2_sublayer_vals
and pw_types_vals numbers (and pw type decoding).
The previous values belong to a different number space, "MPLS Pseudowire
Types Registry" in http://www.iana.org/assignments/pwe3-parameters, used
by LDP. The new values belong to the correct number space, "L2TPv3
Pseudowire Types" in http://www.iana.org/assignments/l2tp-parameters,
used by L2TPv3. Note that one is a 15-bit number while the other is a
16-bit number. So it's not really removing half of the values; even
though there are some numerical "matches" in the two registries, there
are differences (see for example 12 and 13, and some name changes). From
my knowledge the values not registered are also not used (and part of
the intention of the patch is that they are not misused); a fair
assumption is that it was a clerical error mis-assuming the two
protocols, LDP and L2TPv3, used the same space for "PW Types".
svn path=/trunk/; revision=18900
============================ Samba log start ============
svn: When specifying working copy paths, only one target may be given
============================ Samba log end ==============
svn path=/trunk/; revision=18898
change all accessor functions to be defines to the emem_tree_ functions.
now to create a tree with a different scope we only need to create a new
..._tree_create() function and set up the appropriate defines
(it was a mistake to call the functions se_tree_create and se_tree_create_non_persistent, they should be the other way around i.e. se_tree_create_persistent and se_tree_create )
svn path=/trunk/; revision=18895
teh tree management and to use trees with different storage scope without too much code duplication.
it would be useful with a tree that had indefinite storage instead of the emem functions which commonly have ep or se storage scope.
indefinite storage scope would be useful for example for managing a global and static set of well known guid to name mappings(not yet implemented) and also for
oid to name mappings.
svn path=/trunk/; revision=18886
Simply ignore the incoming values of -32000 by not calling gtk_window_move() / gtk_widget_set_uposition() in that case.
I don't know what the Unix GLib version will do in that case.
svn path=/trunk/; revision=18884
The real cause of this: There's a bug in GLib's snprintf implementation which crashes with the I64x format string and certain (negative?) values.
svn path=/trunk/; revision=18883
add a lot more PROFINET CBA dissection output based on these DCOM context information
still need some improvements, e.g. dissection uses a simple (slow) linear list search
changes are fuzz-tested
svn path=/trunk/; revision=18882
modernize the section on BPF (modern BSDs have BPF built in and clone
BPF devices, so no configuration should be necessary; we can add back
the old instructions if people using older BSDs run into problems), and
add information on making BPF devices available to non-root users.
svn path=/trunk/; revision=18880
I've attached a patch to the "wlan capture header" dissector to bring it
in line with the current frame format, and a proper URL to obtain said
format. Nothing major, just the addition of a couple of fields and
definitions. The dissector remains backwards-compatible with the older
format.
svn path=/trunk/; revision=18878
wireshark was located in /usr/X11R6/bin while dumpcap
int /usr/bin. That way wireshark couldn't find dumpcap.
Install wireshark in the same path as dumpcap and tshark.
svn path=/trunk/; revision=18874
I've just had a bug in one of our private dissectors which meant
that the handle passed to call_dissector was null. This seemed to give
varying behavior - on some Windows installations it hit wireshark's
in-built exception handling, and displayed that the dissector had an
error (correct), but on some installations it just crashed wireshark
(not helpful). I _think_ the difference was whether MSVC was installed
or not, but on a sample of only 3 machines.
Should call_dissector include explicit null handle checks, and if so,
should it:-
a) g_assert - the simple patch attached
b) fallback to doing a data decode (as disabled protocols do)
c) try to invoke the wireshark exception handling for the packet
Or is the correct answer none of the above - the exception handler
should already cope ?
svn path=/trunk/; revision=18869
provided by markdrago@mail.com.
Me: Patch template files instead and regenerate the dissector files.
Fix Makefiles to use the correct asn filenames.
svn path=/trunk/; revision=18866
Ronnie Sahlberg