keys to have _uint in their names, to match the routines that handle
dissector tables with string keys. (Using _port can confuse people into
thinking they're intended solely for use with TCP/UDP/etc. ports when,
in fact, they work better for things such as Ethernet types, where the
binding of particular values to particular protocols are a lot
stronger.)
svn path=/trunk/; revision=35224
the data source does not need to be allocated if (!tree).
Rev 30158 took the if (!tree) check out indicating that the check was invalid.
So: (since packet_add_new_data_source() now only calls add_new_data_source()),
remove packet_add_new_data_source().
svn path=/trunk/; revision=34717
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4422
From me: Fix a number of instances where the function prototype or
the function definition wasn't changed so there was a mismatch
thus causing Windows (but not gcc) compilation errors.
svn path=/trunk/; revision=32365
* Disable the TRY_TO_FAKE_THIS_ITEM optimization
* Use GString to store the protocols
We should only do this if the 'hf_frame_protocols' is referenced (unlikely)
svn path=/trunk/; revision=29733
1) The tvb + name (aka. data_source) is only used when the protocol tree is visible
The current implementation of add_new_data_source() doesn't take this into account and simply allocates a data_source regardless. This is what packet_add_new_data_source() tries to rectify.
A couple of dissectors have already been switched over to the new packet_add_new_data_source(). Many are still missing. Help appreciated!
svn path=/trunk/; revision=29427
This patch optimizes the data source name processing in add_new_data_source()
by delaying it. We now simply store the constant string and lazily compute the
name when needed. This gives a performance boost because we only need the name
if we have multiple data sources.
svn path=/trunk/; revision=29066
if compiled in and the env var WIRESHARK_DEBUG_EP_CANARY is set:
will check for canary integrity at every call to EP_CHECK_CANARY()
if corruption is found it exits pronting the prior location and the location in which corruption was found.
Hopefully it stops running while the corruptor is still in the stack.
see EP_CHECK_CANARY() calls in packet.c as an example.
svn path=/trunk/; revision=25927
Attached is a patch for:
- PW Associated Channel Header dissection as per RFC 4385
- PW MPLS Control Word dissection as per RFC 4385
- mpls subdissector table indexed by label value
- enhanced "what's past last mpls label?" heuristic
- Ethernet PW (w/o CW) support as per RFC 4448
svn path=/trunk/; revision=25730
move the case where pinfo->in_error_pkt is true in its own function:
- it's not the common case.
- it needs a TRY block. ==> slow volatile and big stack footprint.
- call_dissector_work is called a lot and recursively.
svn path=/trunk/; revision=23413
Adds a heur_dissector_delete() function to allow heuristic dissectors to be
dynamically disabled based upon, for example, preference settings.
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1697
svn path=/trunk/; revision=22463
Fix compilation failures when building wireshark-0.99.6-SVN-21916 on an
x86_64-unknown-linux-gnu target with gcc version 4.1.2 20070403 (Red Hat
4.1.2-8).
The failures fall into two categories:
(1) Casts between pointers and 32-bit integers without an intermediary cast
via 'long' or 'unsigned long'. This results in a compiler warning complaining
about casts between a pointer and an integer of a different size.
(2) Passing values to "%lld" or similar printf-style format options that the
compiler thinks are a different size. Such values need to be cast to 'long
long' or 'unsigned long long'.
svn path=/trunk/; revision=21975
--enable-extra-gcc-checks set.
If we turn on -pedantic, try turning on -Wno-long-long as well, so that
it's not *so* pedantic that it rejects the 64-bit integral data types
that we explicitly require.
Constify a bunch of stuff, and make some other changes, to get rid of
warnings.
Clean up some indentation.
svn path=/trunk/; revision=21526
- asn dissectors : libasndissectors.la
- pidl dissectors : libpidldissectors.la
- normal dissectors : libdissectors.la *and* libcleandissectors.la. I
separated it in two libraries temporarily. The source files used to build
libcleandissectors.la do not generate warning anymore and the -Werror is used
to compile them. If we patch a dissector and it doesn't generate warning
anymore, we have to move the filename dissector from DISSECTOR_SRC to
CLEAN_DISSECTOR_SRC in epan/dissectors/Makefile.common.
If you want to define specific cflags for one library type, let's say pidl, you
may define libpidldissectors_la_CFLAGS.
svn path=/trunk/; revision=21324
add sccp_info to struct _packet_info (Sorry but the way private_data works and the fact that TCAP uses it and BSSAP/RANAP can be tunnelled on GSMMAP over TCAP makes it impossible to avoid)
SCCP
- Have SCCP to have a TAP,
- Fix associations so that every message belongs to the association.
- Export message type values so that they can be used by a tap listener
RANAP
- Have RANAP information attached to the sccp_info
BSSAP + GSM_A
- Have DTAP, BSSMAP and BSSAP info attached to the sccp_info
svn path=/trunk/; revision=21076
use this field in the policy handle helper to indicate not only which frames the handle was opened/close in but also the name of the function that opened it.
eventually, when other pidl support infrastructure is developed it would be nice if this could be expanded to also contain the name of the object/handle opened.
svn path=/trunk/; revision=20895
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