Re: [Wireshark-dev] [PATCH] Decode Bluetooth HS 4-way handshake over 802.11 media
Hi Joerg, On Mon, Aug 06, 2012 at 05:37:35PM +0200, Joerg Mayer wrote: Hello, can you please open a bug at bugs.wireshark.org and attach the patch there? https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7633 Does your patch distinguish between an 802.3/LLC/SNAP encapsulated frame of length 3 and Ethertype 3? Sorry did not get what you mean here. Best regards Andrei Emeltchenko ___ 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] [Wireshark-commits] rev 44480: /trunk/ui/gtk/ /trunk/ui/gtk/: CMakeLists.txt
On Tue, Aug 14, 2012 at 12:21:55AM +, ger...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=44480 User: gerald Date: 2012/08/13 05:21 PM Log: Comment out -DGDK_DISABLE_DEPRECATED to match configure.in. Directory: /trunk/ui/gtk/ ChangesPath Action +1 -1 CMakeLists.txtModified I really think the patch should be the other way round - it should be enabled in configure.in as well. Otherwise this option is just a waste of storage and should be removed completely. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ 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] g_convert_with_iconv as ep_ or se_ function
Would it be possible to make g_convert_with_iconv an ep_ or se_ type function or is there something obvious I'm missing if I turned this into an official enhancement request in bugzilla? Could/Would this be related to Wireshark providing better UTF8 support?___ 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] [Wireshark-commits] rev 44480: /trunk/ui/gtk/ /trunk/ui/gtk/: CMakeLists.txt
On 8/14/12 4:30 AM, Joerg Mayer wrote: On Tue, Aug 14, 2012 at 12:21:55AM +, ger...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=44480 User: gerald Date: 2012/08/13 05:21 PM Log: Comment out -DGDK_DISABLE_DEPRECATED to match configure.in. Directory: /trunk/ui/gtk/ ChangesPath Action +1 -1 CMakeLists.txtModified I really think the patch should be the other way round - it should be enabled in configure.in as well. Otherwise this option is just a waste of storage and should be removed completely. It probably should be enabled but right now it breaks compilation with GTK 2.22 and 2.24: ui/gtk/rlc_lte_graph.c: In function ‘create_drawing_area’: ui/gtk/rlc_lte_graph.c:503: warning: implicit declaration of function ‘gdk_gc_new’ ui/gtk/rlc_lte_graph.c:503: warning: assignment makes pointer from integer without a cast ui/gtk/rlc_lte_graph.c:504: warning: implicit declaration of function ‘gdk_gc_set_function’ ui/gtk/rlc_lte_graph.c:519: warning: implicit declaration of function ‘gdk_gc_set_foreground’ ___ 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] g_convert_with_iconv as ep_ or se_ function
On Aug 14, 2012, at 7:17 AM, mman...@netscape.net wrote: Would it be possible to make g_convert_with_iconv an ep_ or se_ type function All the protocol string encodings we intend to handle should be given ENC_ values in epan/proto.h and given implementations in tvb_get_ephemeral_string_enc() and tvb_get_ephemeral_stringz_enc(), which would let you get a UTF-8 ep_ string based on a packet string with any of those encodings, and would let proto_tree_add_item() support all of those encodings. Whether that's implemented *internally to tvb_get_ephemeral_string_enc() and tvb_get_ephemeral_stringz_enc()* with g_convert_to_iconv() or something else is another matter. ___ 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] [Wireshark-commits] rev 44485: /trunk/epan/ /trunk/epan/: libwireshark.def
On Aug 14, 2012, at 4:24 AM, grah...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=44485 User: grahamb Date: 2012/08/14 04:24 AM Log: Added proto_tree_free to the libwireshark expoert definitions for use in plugins What plugin would have a need for it? Freeing the protocol tree filled up by a dissection done elsewhere would be considered a bit impolite, as it might pull the tree out from under somebody using it. If the plugin has done its own top-level dissection (which seems a bit odd - dissectors shouldn't be doing that, taps shouldn't need to do that as the tapping should be doing the dissection for it, file format plugins are at a level below libwireshark and shouldn't even know what a protocol tree *is*, and codecs are orthogonal to dissection), it should have done it with the epan_ APIs and thus should free it with a call to epan_dissect_cleanup() or epan_dissect_free(). ___ 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] [Wireshark-commits] rev 44485: /trunk/epan/ /trunk/epan/: libwireshark.def
-Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev- boun...@wireshark.org] On Behalf Of Guy Harris Sent: 14 August 2012 17:27 To: wireshark-dev@wireshark.org Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 44485: /trunk/epan/ /trunk/epan/: libwireshark.def On Aug 14, 2012, at 4:24 AM, grah...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=44485 User: grahamb Date: 2012/08/14 04:24 AM Log: Added proto_tree_free to the libwireshark expoert definitions for use in plugins What plugin would have a need for it? Freeing the protocol tree filled up by a dissection done elsewhere would be considered a bit impolite, as it might pull the tree out from under somebody using it. If the plugin has done its own top-level dissection (which seems a bit odd - dissectors shouldn't be doing that, taps shouldn't need to do that as the tapping should be doing the dissection for it, file format plugins are at a level below libwireshark and shouldn't even know what a protocol tree *is*, and codecs are orthogonal to dissection), it should have done it with the epan_ APIs and thus should free it with a call to epan_dissect_cleanup() or epan_dissect_free(). I did wonder, but someone asked for it. Easily removed if we think that having it there will get folks into trouble. ___ 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] [Wireshark-commits] rev 44485: /trunk/epan/ /trunk/epan/: libwireshark.def
On Aug 14, 2012, at 9:32 AM, Graham Bloice wrote: I did wonder, but someone asked for it. OK, I've asked him in his ask.wireshark.org question why he wants to do that. ___ 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] [Wireshark-commits] rev 44496, 44491, 44490, 44488
I did some grepping and converted a bunch of g_ calls to use ep_ and se_ memory. The only true memory leaks were in rev 44491, the rest just had potential (or philosophically shouldn't be using g_ calls), mostly through possible exception handling. Because of this, I'm only scheduling rev 44491 for backporting. If someone feels strongly about the others, feel free to schedule them.___ 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] [PATCH] Decode Bluetooth HS 4-way handshake over 802.11 media
On Aug 14, 2012, at 12:49 AM, Andrei Emeltchenko wrote: Hi Joerg, On Mon, Aug 06, 2012 at 05:37:35PM +0200, Joerg Mayer wrote: Hello, can you please open a bug at bugs.wireshark.org and attach the patch there? https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7633 Does your patch distinguish between an 802.3/LLC/SNAP encapsulated frame of length 3 and Ethertype 3? Sorry did not get what you mean here. As per my comment in the bug: 0x0003 is not an Ethernet type, so the EAPOL dissector should *NOT* be registered in the ethertype table with a value of 0x0003. (Nothing less than 0x0600 can be a valid Ethernet type; see section 3.2.6 Length/Type field of IEEE Std 802.3-2008, for example. Values in the type/length field of an Ethernet packet that are less than or equal to 0x05DC - 1500 - are *length* values, not *type* values, so if an Ethernet packet had a value of 0x0003, it'd be a length value, hence the packet would be an 802.3/LLC-encapsulated frame with a length of 3.) Instead, it's a protocol ID in the space of SNAP protocol IDs for the OUI value 00:19:58, i.e. OUI_BLUETOOTH, so what you want to do is to: register a dissector table for the OUI value OUI_BLUETOOTH - for an example of how to do this, see proto_register_cisco_oui() in epan/dissectors/packet-cisco-oui.c; in that dissector table, register the EAPOL dissector in *THAT* dissector table with a protocol ID of 0x0003. ___ 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] Passing NULL to %s format specifiers
On Linux and most other operating systems I know of, passing a NULL to a %s format specifier is safe. On Solaris, as it turns out, it isn't [1]. The case in the filed bug is fairly trivial to fix, but I'm wondering if this is something that should be added to the Code Style / Portability section of README.developer? Alternatively, since I have no idea how many of these bugs we may have to fix, perhaps we should be wrapping all format strings somehow? Hopefully someone with some Solaris experience (or even a Solaris test box) could weigh in, since I have neither. Cheers, Evan [1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7634 ___ 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
