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
a new bit 0x00020000 is usde in the TGS-REQ packets and this results in a return of a PAC containing an unknown type 11 field.
the blob in the pac is 200 bytes and NDR encoded. its structure is obvious since it contains 2 conformant and varying arrays and three unique pointers.
enable decoding of this new KDCOptions bit and call it "constrained delegation"
svn path=/trunk/; revision=18857
libgcrypt, enable it in the Windows build.
In packet-ipsec.c:
- Remove non-constants from variable declaration initializations.
- Use ep_alloc() in a couple of places.
- Fix an off-by-one error.
- Reduce the number of SAs in the preferences from 4 to 2. 4 made the
preferences window absolutely enormous. This is probably the wrong
way to fix this.
- Fix up whitespace.
svn path=/trunk/; revision=18856
also change the name of one of the strings we keep around since it is more generic than just used for attributeassertions
svn path=/trunk/; revision=18841
Ulf Lamping