Re: [Wireshark-dev] XML parsing
Ah, thanks Jeff; I understand now. I checked ( http://library.gnome.org/devel/glib/unstable/glib-Simple-XML-Subset-Parser.html) and it suggests it has been around since version 2.16... so I guess it is OK to use it. Thanks for your help! Abhik. On Sat, Mar 21, 2009 at 1:25 AM, Jeff Morriss jeff.morriss...@gmail.comwrote: Hi Abhik, Sorry, I guess I mean: what is the earliest version of glib that supports the APIs you're talking about? For Windows we don't have a problem because we distribute glib with Wireshark, but all other OS's rely on the currently-installed glib. configure.in currently enforces glib 2.4 . Increasing that may be OK but of course it means some number of people will have to go upgrade their glib (so doing it shouldn't be taken lightly). Regards, Jeff Abhik Sarkar wrote: Hi Jeff, I meant version of glib which is part of the current set of libraries used to build the SVN version (in particular wireshark-win32-libs). There are a few different ways of parsing XML used in various parts of WS, and I wanted to use an existing API without having to introduce a new dependency (but also without having to use any parser generators) and it seems to be possible using the mentioned functionality. Thanks, Abhik. On Thu, Mar 19, 2009 at 6:52 PM, Jeff Morriss jeff.morriss.ws http://jeff.morriss.ws@gmail.com http://gmail.com wrote: Abhik Sarkar wrote: Hi Everyone, This is a question specifically to the core developers. Would it be OK to use the GMarkupParser facility which is provided by the latest glib that is part of the required libraries for the development version? I want to use it to read XML configuration files for a generally available dissector. Define latest. (I looked through the GLIB documentation and their list of symbols new to each release and at least some of the markup functions have been around for a while.) ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org mailto:wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] XML parsing
Abhik Sarkar wrote: Ah, thanks Jeff; I understand now. I checked (http://library.gnome.org/devel/glib/unstable/glib-Simple-XML-Subset-Parser.html) and it suggests it has been around since version 2.16... so I guess it is OK to use it. Actually: configure.in requiring GTK to be 2.4 or greater means that Wireshark tries to support any version of GTK starting with 2.4. (Any code requiring a feature only available in later GTK versions is #ifdef'd to be compiled only if Wireshark is being built with that version or newer. In general, if this is done, alternative code should be provided which compiles and works with the earlier GTK version). So: if a function was implemented as of GTK 2.16, that means that any Wireshark build on a system with an earlier GTK version will fail trying to use that function. (Note that GTK 2.4 is [much] older than Gtk 2.16). For example: my fairly up-to-date Fedora 10 system has Gtk2 2.14.7 ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] XML parsing
Bill Meier wrote: Abhik Sarkar wrote: Ah, thanks Jeff; I understand now. I checked (http://library.gnome.org/devel/glib/unstable/glib-Simple-XML-Subset-Parser.html) and it suggests it has been around since version 2.16... so I guess it is OK to use it. Actually: configure.in requiring GTK to be 2.4 or greater means that Wireshark tries to support any version of GTK starting with 2.4. (Any code requiring a feature only available in later GTK versions is #ifdef'd to be compiled only if Wireshark is being built with that version or newer. In general, if this is done, alternative code should be provided which compiles and works with the earlier GTK version). So: if a function was implemented as of GTK 2.16, that means that any Wireshark build on a system with an earlier GTK version will fail trying to use that function. (Note that GTK 2.4 is [much] older than Gtk 2.16). For example: my fairly up-to-date Fedora 10 system has Gtk2 2.14.7 Ooops: We're talking Glib not Gtk in this case. The principle remains the same: Wireshark currently supports Glib versions starting with 2.4. ( ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Unable to Display Simple Protocol Tree
I've been trying to get dissector plugin that I'm coding to display
subtree information that it has parsed. I can get it to look through
the tvb buffer and extract the data, but I can't get it to display even
the top level protocol name beneath the UDP line. As a debugging aid, I
dropped in code lifted and slightly modified from the AMIN protocol
CodeProject web article (link:
http://www.codeproject.com/KB/IP/custom_dissector.aspx).
I macroed the code so that if macro AMIN is defined, the AMIN code runs.
Otherwise, my dissector runs. The AMIN code does display the protocol
name. With what looks like an identical proto_tree_add_item call, my
dissector won't display the protocol name.
I don't understand why the code doesn't work. I've stepped through it
in the debugger, and verified that the structure pointed to by the tree
has a new last_child as a result of the proto_tree_add_item call, and
its finfo element has reasonable looking contents that match what I
expected for this protocol. The tree's last_child appears to be changed
identically for the AMIN dissector (which works) and for my dissector
(which doesn't) when I flip the #define AMIN macro to #undef AMIN and
rebuild the plugin.
I've included a code snippet from the dissector below.
#ifndef AMIN
static void
dissect_x2d(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
static guint32 packetCounter = 0;
static proto_item* x2d_item = NULL;
proto_item* x2d_sub_item = NULL;
static proto_tree* x2d_tree = NULL;
static proto_tree* x2d_header_tree = NULL;
ParserNode* topClonePtr = 0;
ParseInfo* regPtr; /* To retain the result of the parse
operation */
guint32 ofst = 0; /* Tracks through tvb */
/* Debug only */
#ifdef DBG
if (bailoutPacket = ++packetCounter)
{
return;
}
#endif
/* Debug only */
if (check_col(pinfo-cinfo, COL_PROTOCOL))
{
col_set_str(pinfo-cinfo, COL_PROTOCOL, x2d);
}
/* Clear out stuff in the info column */
if (check_col(pinfo-cinfo,COL_INFO))
{
col_clear(pinfo-cinfo,COL_INFO);
}
if (tree)
{
x2d_item = proto_tree_add_item(tree, proto_x2d, tvb, 0,
-1, FALSE);
return;
}
I'd appreciate any help possible on this.
Steve Dix
407-399-5578, Fax 407-249-3599
steven.e@boeing.com
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] one possible way to speed up filtering
Hi Didier, Thank you for trying the patch :) and all the good comments given. I've attached a new patch to the wiki. Please see my detailed reply below. On Fri, Mar 20, 2009 at 6:30 AM, didier dgauthe...@magic.fr wrote: Hi, Le mercredi 18 mars 2009 à 23:05 +0800, yami a écrit : Thanks, I've written a page in Wiki: http://wiki.wireshark.org/Development/FastFiltering Nice work. - If compiled without NDEBUG defined I get a failed assert: epan/dfilter/wslimmat.c :1680 : fix_variables: v-assignment == v It seems like a 'bug' of gcc optimization. We can simply remove this assertion, see explanations below. The assertion fails, but the 'real' value of v-assignment and v are equal. I came to this conclusion by following experiments (is there any better way?): experiment 1. without NDEBUG defined, but using '-O0' to compile, not assertion failure occurs. experiment 2. no change to Makefile, simply add printf(v-assignment, v) to fix_pointer(), no assertion failure experiment 3. no change to Makefile, add following to fix_variables() after the assert line: if (v-assignment != v) printf(not hold v-assignment=%p, v=%p\n, v-assignment, v); else printf(hold v-assignment=%p, v=%p\n, v-assignment, v); The assertion fails (simply print, no abort), however output is: hold v-assignment=0x8070508, v=0x8070508 which just says the opposite. valgrind doesn't complain and it seems to work with NDEBUG but only for simple stuff ie udp dns, something like !(tcp.stream eq 1) !(tcp.stream eq 2) doesn't return the right result. ie: follow TCP stream, filter out this stream, follow TCP this stream, and so on. Does it work for you? This is a bug, I've fixed '!' (TEST_OP_NOT) part at least. I'll test the patch more. - stupid but Limmat uses the original BSD license which is incompatible with the GPL. Really? I've thought BSD license is looser than GPL (can you give me more details?). On the other hand, I find Wireshark code has already contains similar licenses (am I right?), for example, Menu - Help - About Wireshark - License - Part III has metioned some. - On the other hand if expressions are made incrementally via popup menus is a full SAT solver need? Perhaps you are right, but I'm not sure. However using a SAT solver (even if it is a simple one) is the most generalized way, which requires no special handling. And it is also a good example of how math is applied in real life :) Cons are 1. SAT solvers are complicated. (But we may use a simple algorithm) 2. Public available SAT solvers are mainly wrote by researchers, which may not have time to maintain the software. eg: Something like tcp.stream eq 1 -- H1 !(tcp.stream eq 1) -- !H1 -- H2 tcp.stream eq 2 -- H3 !(tcp.stream eq 1) !(tcp.stream eq 2) -- H2 !H3 may be good enough. Didier ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
