Re: [Wireshark-dev] Couldn't load module / undefined symbol:
On Thu, 06 Oct 2011 10:11:23 -0400, Jeff Morriss jeff.morriss...@gmail.com wrote: Marcel Haas wrote: On Thu, 06 Oct 2011 09:10:38 -0400, Jeff Morriss jeff.morriss...@gmail.com wrote: Marcel Haas wrote: Hey, I have a new problem. Some of u still remember that im writing my own function and include it to wireshark/epan file folder. i built it in with autogen configure and make. Now i want to include my functions to my dissector plugin. #include epan/list_mh.h and inculde my function NeuesListenElement Built my plugin new too. No Errors but if i start wireshark now i get an error : Couldn't load module /home/marcel/Downloads/wireshark-1.6.1/plugins/nos/.libs/nos.so: /home/marcel/Downloads/wireshark-1.6.1/plugins/nos/.libs/nos.so: undefined symbol: NeuesListenElement Why it doesnt know my function ? If you put new functions in libwireshark you must add their names to epan/libwireshark.def so that the symbols get exported. (Previously this file was used only on Windows, but it is now also used to control *NIX symbol exports.) ___ 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 Ok thx, but can i put my function to .def after make or have i to run make again. The epan/libwireshark.sym will be generated after make. Have to appear my function there too ? cause say dont .. Running 'make' again will rebuild the .sym file (based on the contents of the .def file). ___ 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 Thx again Jeff.. now its totally included u save me again ;) ___ 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] Send info to plugin
Hello, Is there any way to send some information to a plugin dissector from the wireshark GUI interface? For instance using a wireshark menu to set some variable that will be accessible from the plugin. Or maybe it is possible to add a menu from the plugin? Thanks Fabien ___ 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] Send info to plugin
Hi, Can't you do what you want through preferences possibly with a UAT table? GUI code is not suppposed to live in plugins. With the new UIManager code in trunk it is possible To add items to the menubar. There's absolutly no guatrantee that that API is stable and I'm Not sure if it would work from a plugin, there is no ducumentation on it either. Regards Anders -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of fa...@freesurf.fr Sent: den 7 oktober 2011 10:20 To: wireshark-dev@wireshark.org Subject: [Wireshark-dev] Send info to plugin Hello, Is there any way to send some information to a plugin dissector from the wireshark GUI interface? For instance using a wireshark menu to set some variable that will be accessible from the plugin. Or maybe it is possible to add a menu from the plugin? Thanks Fabien ___ 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] Send info to plugin
On Oct 7, 2011, at 1:19 AM, fa...@freesurf.fr wrote: Is there any way to send some information to a plugin dissector from the wireshark GUI interface? What sort of information? For instance using a wireshark menu to set some variable that will be accessible from the plugin. As Anders suggested, you *can* give it global information through a preference setting. We should probably also add a notion of conversations available to dissectors at multiple layers (a notion more general than the current address-and-port-endpoint-pair notion, that can include multiple address layers, circuits for protocols that have a virtual circuit ID of some sort, and conversations at layers above the transport layer), and per-conversation settings as well, with Wireshark offering a GUI to let you select a conversation and set one or more of a set of dissector-specified parameters. Or maybe it is possible to add a menu from the plugin? A menu item to do what? ___ 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] Send info to plugin
On Oct 7, 2011, at 1:19 AM, fa...@freesurf.fr wrote: Is there any way to send some information to a plugin dissector from the wireshark GUI interface? What sort of information? Typically a filename + Directory where the the plugin dissector would write some statistic information. For instance using a wireshark menu to set some variable that will be accessible from the plugin. As Anders suggested, you *can* give it global information through a preference setting. We should probably also add a notion of conversations available to dissectors at multiple layers (a notion more general than the current address-and-port-endpoint-pair notion, that can include multiple address layers, circuits for protocols that have a virtual circuit ID of some sort, and conversations at layers above the transport layer), and per-conversation settings as well, with Wireshark offering a GUI to let you select a conversation and set one or more of a set of dissector-specified parameters. Or maybe it is possible to add a menu from the plugin? A menu item to do what? I imagine a menu that would open a popup asking to enter the filename + directory. ___ 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] Decompress Data
And i have the next problem. Damn wireshark kick my ass :) I have some packets witch are compress witz zlib. I want to uncompress them. I read the dev-guid about transformed data but i dont have a clue. I were testing some stuff but with no good result. Can someone help me with that ? thx and regards Marcel ___ 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] Decompress Data
2011/10/7 Marcel Haas inf...@fh-worms.de: And i have the next problem. Damn wireshark kick my ass :) I have some packets witch are compress witz zlib. I want to uncompress them. I read the dev-guid about transformed data but i dont have a clue. I were testing some stuff but with no good result. Can someone help me with that ? It is simple. 1) You have to know the size of decompressed data, e.g. in buffer_size variable. 2) Alloc the buffer of needed size for it using e.g. se_alloc, e.g. you have pointer to alloced buffer called buffer_ptr. 3) Decompress you data into that buffer. 4) call child_tvb = tvb_new_child_real_data(current_tvb, buffer_ptr, buffer_size, buffer_size); 5) call add_new_data_source(pinfo, child_tvb, Decompressed Data); 6*) Optionally you can dissect child_tvb as any usual TVB. In the GUI you'll get the decompressed data into another tab called Decompressed Data or any other name you provide in step 5. -- Max ___ 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] Decompress Data
On Fri, 7 Oct 2011 13:51:13 +0400, Max Dmitrichenko dmitr...@gmail.com wrote: 2011/10/7 Marcel Haas inf...@fh-worms.de: And i have the next problem. Damn wireshark kick my ass :) I have some packets witch are compress witz zlib. I want to uncompress them. I read the dev-guid about transformed data but i dont have a clue. I were testing some stuff but with no good result. Can someone help me with that ? It is simple. 1) You have to know the size of decompressed data, e.g. in buffer_size variable. 2) Alloc the buffer of needed size for it using e.g. se_alloc, e.g. you have pointer to alloced buffer called buffer_ptr. 3) Decompress you data into that buffer. 4) call child_tvb = tvb_new_child_real_data(current_tvb, buffer_ptr, buffer_size, buffer_size); 5) call add_new_data_source(pinfo, child_tvb, Decompressed Data); 6*) Optionally you can dissect child_tvb as any usual TVB. In the GUI you'll get the decompressed data into another tab called Decompressed Data or any other name you provide in step 5. -- Max ___ 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 hmm i dont get it at all .. my code looks like this : guint8 *buff; tvbuff_t *compress_tvb; int captured_size; captured_size=tvb_length_remaining(tvb, offset2); //I think that what u mean by 1 buff= g_malloc(captured_size); // step 2 ? compress_tvb=tvb_new_real_data(buff,captured_size,captured_size);// step 4 ? tvb_set_free_cb(compress_tvb,g_free); // step 4 ? tvb_set_child_real_data_tvbuff(tvb,compress_tvb); // step 4 ? add_new_data_source(pinfo,compress_tvb,Decompressed TVB); //step 5 ___ 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] Decompress Data
I have a example from my plugin if it may help: unsigned char Ip_Buffer[2000]; /* Get the buffer bytes to decompress */ tvb_memcpy(tvb, Ip_Buffer, (*bitoffset)/8,lgpdubit/8); /* * Decompress it: * Decompressed buffer is output in Op_Buffer, * size of the decompressed buffer (in bit in this case) in SizeInBits */ */ rc = decompress(Ip_Buffer, lgpdubit - ((8-bitnb) % 8), (Op_Buffer), O_SizeInBits); /* Now re-setup the tvb buffer to have the new data */ next_tvb = tvb_new_real_data(Op_Buffer, O_SizeInBits/8, O_SizeInBits/8); tvb_set_child_real_data_tvbuff(tvb, next_tvb); add_new_data_source(pInfoG, next_tvb, Decompressed Data); /* From here dissect next_tvb from offset 0 */ On Fri, 7 Oct 2011 13:51:13 +0400, Max Dmitrichenko dmitr...@gmail.com wrote: 2011/10/7 Marcel Haas inf...@fh-worms.de: And i have the next problem. Damn wireshark kick my ass :) I have some packets witch are compress witz zlib. I want to uncompress them. I read the dev-guid about transformed data but i dont have a clue. I were testing some stuff but with no good result. Can someone help me with that ? It is simple. 1) You have to know the size of decompressed data, e.g. in buffer_size variable. 2) Alloc the buffer of needed size for it using e.g. se_alloc, e.g. you have pointer to alloced buffer called buffer_ptr. 3) Decompress you data into that buffer. 4) call child_tvb = tvb_new_child_real_data(current_tvb, buffer_ptr, buffer_size, buffer_size); 5) call add_new_data_source(pinfo, child_tvb, Decompressed Data); 6*) Optionally you can dissect child_tvb as any usual TVB. In the GUI you'll get the decompressed data into another tab called Decompressed Data or any other name you provide in step 5. -- Max ___ 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 hmm i dont get it at all .. my code looks like this : guint8 *buff; tvbuff_t *compress_tvb; int captured_size; captured_size=tvb_length_remaining(tvb, offset2); //I think that what u mean by 1 buff= g_malloc(captured_size); // step 2 ? compress_tvb=tvb_new_real_data(buff,captured_size,captured_size);// step 4 ? tvb_set_free_cb(compress_tvb,g_free); // step 4 ? tvb_set_child_real_data_tvbuff(tvb,compress_tvb); // step 4 ? add_new_data_source(pinfo,compress_tvb,Decompressed TVB); //step 5 ___ 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] Decompress Data
On Fri, 7 Oct 2011 13:21:15 +0200, fa...@freesurf.fr wrote: I have a example from my plugin if it may help: unsigned char Ip_Buffer[2000]; /* Get the buffer bytes to decompress */ tvb_memcpy(tvb, Ip_Buffer, (*bitoffset)/8,lgpdubit/8); /* * Decompress it: * Decompressed buffer is output in Op_Buffer, * size of the decompressed buffer (in bit in this case) in SizeInBits */ */ rc = decompress(Ip_Buffer, lgpdubit - ((8-bitnb) % 8), (Op_Buffer), O_SizeInBits); /* Now re-setup the tvb buffer to have the new data */ next_tvb = tvb_new_real_data(Op_Buffer, O_SizeInBits/8, O_SizeInBits/8); tvb_set_child_real_data_tvbuff(tvb, next_tvb); add_new_data_source(pInfoG, next_tvb, Decompressed Data); /* From here dissect next_tvb from offset 0 */ Where u get the decompress function and what type does rc have .. ? On Fri, 7 Oct 2011 13:51:13 +0400, Max Dmitrichenko dmitr...@gmail.com wrote: 2011/10/7 Marcel Haas inf...@fh-worms.de: And i have the next problem. Damn wireshark kick my ass :) I have some packets witch are compress witz zlib. I want to uncompress them. I read the dev-guid about transformed data but i dont have a clue. I were testing some stuff but with no good result. Can someone help me with that ? It is simple. 1) You have to know the size of decompressed data, e.g. in buffer_size variable. 2) Alloc the buffer of needed size for it using e.g. se_alloc, e.g. you have pointer to alloced buffer called buffer_ptr. 3) Decompress you data into that buffer. 4) call child_tvb = tvb_new_child_real_data(current_tvb, buffer_ptr, buffer_size, buffer_size); 5) call add_new_data_source(pinfo, child_tvb, Decompressed Data); 6*) Optionally you can dissect child_tvb as any usual TVB. In the GUI you'll get the decompressed data into another tab called Decompressed Data or any other name you provide in step 5. -- Max ___ 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 hmm i dont get it at all .. my code looks like this : guint8 *buff; tvbuff_t *compress_tvb; int captured_size; captured_size=tvb_length_remaining(tvb, offset2); //I think that what u mean by 1 buff= g_malloc(captured_size); // step 2 ? compress_tvb=tvb_new_real_data(buff,captured_size,captured_size);// step 4 ? tvb_set_free_cb(compress_tvb,g_free); // step 4 ? tvb_set_child_real_data_tvbuff(tvb,compress_tvb); // step 4 ? add_new_data_source(pinfo,compress_tvb,Decompressed TVB); //step 5 ___ 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] Send info to plugin
Thus wrote Guy Harris (g...@alum.mit.edu): We should probably also add a notion of conversations available to dissectors at multiple layers (a notion more general than the current address-and-port-endpoint-pair notion, that can include multiple address layers, circuits for protocols that have a virtual circuit ID of some sort, and conversations at layers above the transport layer) that would definitely be helpful. As far as I can see, DVB-CI is an example that does not fit into the current mechanism very well. CI is not based on tcp/ip, a ci session looks like open_session_request(resource_id) session_opened(newly assigned session number) payload transfer(session_number, payload data) ... close session(session_number) For now, how would you create a conversation from this? I've been playing with a new port_type PT_DVBCI_SESSION_NUMBER and set both source and destination port to the session number. Does that make sense or is there a better approach? Thanks, Martin ___ 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] Global conversation
Thus wrote Guy Harris (g...@alum.mit.edu): We should probably also add a notion of conversations available to dissectors at multiple layers (a notion more general than the current address-and-port-endpoint-pair notion, that can include multiple address layers, circuits for protocols that have a virtual circuit ID of some sort, and conversations at layers above the transport layer) that would definitely be helpful. As far as I can see, DVB-CI is an example that does not fit into the current mechanism very well. CI is not based on tcp/ip, a ci session looks like open_session_request(resource_id) session_opened(newly assigned session number) payload transfer(session_number, payload data) ... close session(session_number) For now, how would you create a conversation from this? I've been playing with a new port_type PT_DVBCI_SESSION_NUMBER and set both source and destination port to the session number. Does that make sense or is there a better approach? Thanks, Martin I've been contemplating the idea of making it possible to filter a call in the Telco world that could involve A multitude of protocols for example SIP, DIAMETER, H248, ISUP, BICC and a number of Mobile protocols. I suppose this is What mate tries to do. Perhaps it could be done if we had a Global conversation to which you cold add a List of per protocol conversations. One problem is to make it generic enough and in this particular scenario the subscriber number or similar would be the thing gluing the conversations together and that would only be Available in some messages. Another problem is when to create the global conversation e.g. what is the start. Thoughts? Regards Anders ___ 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] [Wireshark-commits] rev 38304: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-snmp.c
Gerald Combs wrote: On 10/4/11 1:11 PM, Jeff Morriss wrote: Balint Reczey wrote: Let's make Python a requirement now. I fully support the idea of not keeping generated files in SVN and in the release tarball. I know it's been a while, but... Any other thoughts/votes on this topic? It's fine with me. One downside with this is that it takes (at least on my not-that-old home PC) about 3.5 minutes to build all the ASN.1 dissectors (time make -C asn1). Since the ASN.1 dissectors are all in subdirectories (and each subdir has only one target) the build does not parallelize (make -j X) well. It probably could be made more parallel through some ugliness (making what is currently a recursive build non-recursive). Thoughts? ___ 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 38304: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-snmp.c
On 10/07/2011 04:07 PM, Jeff Morriss wrote: Gerald Combs wrote: On 10/4/11 1:11 PM, Jeff Morriss wrote: Balint Reczey wrote: Let's make Python a requirement now. I fully support the idea of not keeping generated files in SVN and in the release tarball. I know it's been a while, but... Any other thoughts/votes on this topic? It's fine with me. One downside with this is that it takes (at least on my not-that-old home PC) about 3.5 minutes to build all the ASN.1 dissectors (time make -C asn1). Since the ASN.1 dissectors are all in subdirectories (and each subdir has only one target) the build does not parallelize (make -j X) well. It probably could be made more parallel through some ugliness (making what is currently a recursive build non-recursive). Thoughts? We can make it parallel without converting them non-recursive. I'm in for improving the parallelism. Cheers, Balint ___ 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 38304: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-snmp.c
Balint Reczey wrote: On 10/07/2011 04:07 PM, Jeff Morriss wrote: Gerald Combs wrote: On 10/4/11 1:11 PM, Jeff Morriss wrote: Balint Reczey wrote: Let's make Python a requirement now. I fully support the idea of not keeping generated files in SVN and in the release tarball. I know it's been a while, but... Any other thoughts/votes on this topic? It's fine with me. One downside with this is that it takes (at least on my not-that-old home PC) about 3.5 minutes to build all the ASN.1 dissectors (time make -C asn1). Since the ASN.1 dissectors are all in subdirectories (and each subdir has only one target) the build does not parallelize (make -j X) well. It probably could be made more parallel through some ugliness (making what is currently a recursive build non-recursive). Thoughts? We can make it parallel without converting them non-recursive. I'm in for improving the parallelism. How? (At the moment I'm looking only at automake, but I suppose eventually Windows and CMake must be considered.) ___ 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] Global conversation
On Fri, Oct 07, 2011 at 02:51:35PM +0200, Anders Broman wrote: Perhaps it could be done if we had a Global conversation to which you cold add a List of per protocol conversations. We could create a new set of conversation functions, such as: global_conversation_new() global_find_conversation() global_conversation_add_proto_data() (Although using global makes them a bit long) One problem is to make it generic enough and in this particular scenario the subscriber number or similar would be the thing gluing the conversations together and that would only be Available in some messages. Another problem is when to create the global conversation e.g. what is the start. Using a unique piece of information, such as the phone number, would allow each dissector that is capable of working with that global conversation to look up if it has already been created. Perhaps two pieces of informatino would be needed: a type of information and the information, e.g. PHONE_NUMBER and +111 or something more generic like passing a string phone-number and then the number itself. It sounds like a good idea, but would just need a few decisions to be made first. ___ 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] Decompress Data
On Fri, Oct 07, 2011 at 11:31:24AM +0200, Marcel Haas wrote: I have some packets witch are compress witz zlib. I want to uncompress them. Take a look at the tvb_uncompress() or tvb_child_uncompress() functions in epan/tvbuff.c. An example of tvb_child_uncompress() is in the HTTP dissector, epan/dissectors/packet-http.c. ___ 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] Global conversation
-Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Stephen Fisher Sent: 07 October 2011 16:32 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Global conversation On Fri, Oct 07, 2011 at 02:51:35PM +0200, Anders Broman wrote: Perhaps it could be done if we had a Global conversation to which you cold add a List of per protocol conversations. We could create a new set of conversation functions, such as: global_conversation_new() global_find_conversation() global_conversation_add_proto_data() (Although using global makes them a bit long) One problem is to make it generic enough and in this particular scenario the subscriber number or similar would be the thing gluing the conversations together and that would only be Available in some messages. Another problem is when to create the global conversation e.g. what is the start. Using a unique piece of information, such as the phone number, would allow each dissector that is capable of working with that global Conversation to look up if it has already been created. Perhaps two pieces of informatino would be needed: a type of information and the information, e.g. PHONE_NUMBER and +111 or something more generic like passing a string phone-number and then the number itself. It sounds like a good idea, but would just need a few decisions to be made first. I think that it should be a bit more flexible: * Have conversations per protocol, with 1 or more identifier keys. * When a new identifier is observed, if it can be associated with an existing conversation which was created with a different key, then add the new key to the existing conversation, otherwise create a new conversation with the new key. * Allow conversations to be associated with conversations in other protocols. The set of associated conversations becomes the global conversation, but is flexible in terms of the sequence of build-up of supporting protocols. * A dissector can use a protocol/key pair to find a potentially associated conversion already existing in another protocol. * A dissector can access the set of keys for any protocol in an associated conversation This message contains confidential information and may be privileged. If you are not the intended recipient, please notify the sender and delete the message immediately. ip.access Ltd, registration number 3400157, Building 2020, Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom ___ 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] Global conversation
Mike Morrin skrev 2011-10-07 17:48: -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Stephen Fisher Sent: 07 October 2011 16:32 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Global conversation On Fri, Oct 07, 2011 at 02:51:35PM +0200, Anders Broman wrote: Perhaps it could be done if we had a Global conversation to which you cold add a List of per protocol conversations. We could create a new set of conversation functions, such as: global_conversation_new() global_find_conversation() global_conversation_add_proto_data() (Although using global makes them a bit long) One problem is to make it generic enough and in this particular scenario the subscriber number or similar would be the thing gluing the conversations together and that would only be Available in some messages. Another problem is when to create the global conversation e.g. what is the start. Using a unique piece of information, such as the phone number, would allow each dissector that is capable of working with that global Conversation to look up if it has already been created. Perhaps two pieces of informatino would be needed: a type of information and the information, e.g. PHONE_NUMBER and +111 or something more generic like passing a string phone-number and then the number itself. It sounds like a good idea, but would just need a few decisions to be made first. I think that it should be a bit more flexible: * Have conversations per protocol, with 1 or more identifier keys. * When a new identifier is observed, if it can be associated with an existing conversation which was created with a different key, then add the new key to the existing conversation, otherwise create a new conversation with the new key. * Allow conversations to be associated with conversations in other protocols. The set of associated conversations becomes the global conversation, but is flexible in terms of the sequence of build-up of supporting protocols. * A dissector can use a protocol/key pair to find a potentially associated conversion already existing in another protocol. * A dissector can access the set of keys for any protocol in an associated conversation Something like that is what I was thinking about. /Anders This message contains confidential information and may be privileged. If you are not the intended recipient, please notify the sender and delete the message immediately. ip.access Ltd, registration number 3400157, Building 2020, Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom ___ Sent via:Wireshark-dev mailing listwireshark-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] [Wireshark-commits] rev 38304: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-snmp.c
On 10/07/2011 04:26 PM, Jeff Morriss wrote: Balint Reczey wrote: On 10/07/2011 04:07 PM, Jeff Morriss wrote: Gerald Combs wrote: On 10/4/11 1:11 PM, Jeff Morriss wrote: Balint Reczey wrote: Let's make Python a requirement now. I fully support the idea of not keeping generated files in SVN and in the release tarball. I know it's been a while, but... Any other thoughts/votes on this topic? It's fine with me. One downside with this is that it takes (at least on my not-that-old home PC) about 3.5 minutes to build all the ASN.1 dissectors (time make -C asn1). Since the ASN.1 dissectors are all in subdirectories (and each subdir has only one target) the build does not parallelize (make -j X) well. It probably could be made more parallel through some ugliness (making what is currently a recursive build non-recursive). Thoughts? We can make it parallel without converting them non-recursive. I'm in for improving the parallelism. How? (At the moment I'm looking only at automake, but I suppose eventually Windows and CMake must be considered.) I was thinking about using build-stamps and inter-directory dependencies without implementing a full non-recursive make system, but I have to investigate the current situation to be sure. In the meantime maybe we could simply speed up the asn2wrs script, but I haven't done any profiling on it yet. Right now I'm getting errors even with -j1. :-( Cheers, Balint ___ 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 38304: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-snmp.c
Balint Reczey wrote: On 10/07/2011 04:26 PM, Jeff Morriss wrote: Balint Reczey wrote: On 10/07/2011 04:07 PM, Jeff Morriss wrote: Gerald Combs wrote: On 10/4/11 1:11 PM, Jeff Morriss wrote: Balint Reczey wrote: Let's make Python a requirement now. I fully support the idea of not keeping generated files in SVN and in the release tarball. I know it's been a while, but... Any other thoughts/votes on this topic? It's fine with me. One downside with this is that it takes (at least on my not-that-old home PC) about 3.5 minutes to build all the ASN.1 dissectors (time make -C asn1). Since the ASN.1 dissectors are all in subdirectories (and each subdir has only one target) the build does not parallelize (make -j X) well. It probably could be made more parallel through some ugliness (making what is currently a recursive build non-recursive). Thoughts? We can make it parallel without converting them non-recursive. I'm in for improving the parallelism. How? (At the moment I'm looking only at automake, but I suppose eventually Windows and CMake must be considered.) I was thinking about using build-stamps and inter-directory dependencies without implementing a full non-recursive make system, but I have to investigate the current situation to be sure. In the meantime maybe we could simply speed up the asn2wrs script, but I haven't done any profiling on it yet. Right now I'm getting errors even with -j1. :-( I have it working except for asn1/x721 which, well, doesn't actually have a dissector in it yet (need to find a way to make it do nothing for make all). I can check in my changes--thus far just cleanup and putting the asn1 dissectors straight into epan/dissectors/ tonight or this weekend. (I think the changes I made will port over easily to Windows/nmake.) ___ 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] updated patch file for bug 5531
Based on the current discussion about the use of the format field for proto_tree_add_item(), I have once again revised the patch file for Bug 5531 ( https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5531 ). It has gotten a lot of votes and was originally submitted over nine months ago. Is there something else I should do to help get this in the main build? Ed ___ 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] Wireshnork - A snort plugin for Wireshark - Volunteers needed
Hi Folks. This year the Honeynet Project[1] mentored 12 projects for the Google Summer of Code[2]. Project #8's goal was to extend Wireshark and add it some forensics security analysis plugins. WireShnork[3] plugin allows applying Snort IDS[4] rules and signatures against pcap files in Wireshark. This allows analysts to automatically colorise packets that match a particular Snort IDS signature. I'm looking for volunteers to help going on developing this plugin and improving its features. Don't hesitate to contact me if you are interested. PS: testers would also help, by the way. [1] http://www.honeynet.org [2] http://www.google-melange.com/gsoc/homepage/google/gsoc2011 [3] http://www.honeynet.org/gsoc/slot8, http://www.honeynet.org/node/716 [4] http://www.snort.org -- Guillaume - ___ 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] Correct and efficient way of displaying bit fields?
I'm struggling for some time now with displaying bitfields, I'm sure there
must be something I'm overlooking, or it's just a bit difficult to do in
Wireshark.
I have a 32bit, little endian field, which I'd like to parse the bits (as
set/not set):
Example:
05 00 00 00
1 0 0 0 Feature A - set
0 0 0 0 ... Feature B - not set
0 0 1 0 ... Feature C - Set
1. Do I really have to create a hf_xxx for each? And use something like
proto_tree_add_bits_item() ? I was hoping to do it in a single
proto_tree_add_xxx() and pass it a single HF that would hold a VALS(...)
which will describe all the attributes.
2. How do I take into consideration the endianess?
Best I could do so far, it works but it's ugly and not maintainable, is:
proto_tree_add_bits_item(tree, hf_common_cap_auth_select, tvb, (offset * 8)
+ 7, 1, ENC_NA);
proto_tree_add_bits_item(tree, hf_common_cap_auth_spice, tvb, (offset * 8) +
6, 1, ENC_NA);
proto_tree_add_bits_item(tree, hf_common_cap_auth_sasl, tvb, (offset * 8) +
5, 4, ENC_NA);
...
{ hf_common_cap_auth_select,
{ Auth Selection, spice.common_cap_auth_select,
FT_BOOLEAN, 32, TFS(tfs_set_notset), 0,
NULL, HFILL }
},
{ hf_common_cap_auth_spice,
{ Auth Spice, spice.common_cap_auth_spice,
FT_BOOLEAN, 32, TFS(tfs_set_notset), 0,
NULL, HFILL }
},
{ hf_common_cap_auth_sasl,
{ Auth SASL, spice.common_cap_auth_sasl,
FT_BOOLEAN, 32, TFS(tfs_set_notset), 0,
NULL, HFILL }
},
If I look at how it's done in packet-tcp.c, then it's again quite a bit of
manual labour, this time with proto_tree_add_boolean() - per each single
bit!
Is there a better way?
TIA,
Y.
___
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
