[Wireshark-dev] No error when plugin failed to load

2014-11-27 Thread Maarten Bezemer
Hello, I am developing a plugin (dissector) for wireshark and I got stuck at some point. My plugin was (after a change) not loading for some reason, but I did not get any message about this (or the actual reason). After delving in the wireshark code I stumbled upon wsutil/plugins.c This piece of

[Wireshark-dev] New dissector between existing protocols

2014-11-27 Thread Juan Jose Martin Carrascosa
Hi all! I have to implement a new dissector that goes between TCP and RTPS. The name is not decided yet so let's call it XXX. I wonder, what is the best way to proceed here: 1) Currently, RTPS is already registered with UDP and TCP. Register it also with XXX. I don't know what steps do I need to

Re: [Wireshark-dev] No error when plugin failed to load

2014-11-27 Thread Alexis La Goutte
On Thu, Nov 27, 2014 at 11:58 AM, Maarten Bezemer maarten.beze...@gmail.com wrote: Hello, I am developing a plugin (dissector) for wireshark and I got stuck at some point. My plugin was (after a change) not loading for some reason, but I did not get any message about this (or the actual

Re: [Wireshark-dev] New dissector between existing protocols

2014-11-27 Thread Juan Jose Martin Carrascosa
Hi again, I have been reading some source code (UDP), and I have found the following: 1) When the dissection is completed, we call decode_udp_ports. 2) Within this function, we get a subset of the tvb with next_tvb = tvb_new_subset(tvb, offset, len, reported_len); 3) We provide that subset to

Re: [Wireshark-dev] New dissector between existing protocols

2014-11-27 Thread Anders Broman
Hi, “Next dissector” in TCP and UDP dissectors is by default determined by first looking at the port numbers and calling …try_port to see if a dissector is registered for that source or destination port if that fails it continues With the heuristic tables and finally calls the data dissector if

Re: [Wireshark-dev] New dissector between existing protocols

2014-11-27 Thread Juan Jose Martin Carrascosa
Hi Anders, Many thanks for your reply. My protocol carries a magic word at the beginning and may go in whatever port. So, it has to be heuristic. Right? The protocols stack would be: IP - TCP - My protocol - RTPS I will take into account to include the preference to turn the heuristic off.

Re: [Wireshark-dev] New dissector between existing protocols

2014-11-27 Thread Anders Broman
Hi, You probably want to register it for ports to be able to do “decode as” and having a port(range) preference AND a heuristic gives you all possibilities… Regards Anders From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Juan Jose Martin

[Wireshark-dev] Is this a bug in the ipv6 dissector?

2014-11-27 Thread 蓝常珍
In the function dissect_ipv6 of the ipv6 dissector(packet-ipv6.c),the ip6_hdr struct is allocated on the stack,then it's address is passed to tap_queue_packet.I notice that the other dissectors do not look like this. The code snippet of the dissect_ipv6 function,from dev-version 1.99.0: static

Re: [Wireshark-dev] Is this a bug in the ipv6 dissector?

2014-11-27 Thread Alexis La Goutte
Hi, On Thu, Nov 27, 2014 at 4:13 AM, 蓝常珍 lanc...@gmail.com wrote: In the function dissect_ipv6 of the ipv6 dissector(packet-ipv6.c),the ip6_hdr struct is allocated on the stack,then it's address is passed to tap_queue_packet.I notice that the other dissectors do not look like this. The code

Re: [Wireshark-dev] Is this a bug in the ipv6 dissector?

2014-11-27 Thread Evan Huus
On Thu, Nov 27, 2014 at 10:21 AM, Alexis La Goutte alexis.lagou...@gmail.com wrote: Hi, On Thu, Nov 27, 2014 at 4:13 AM, 蓝常珍 lanc...@gmail.com wrote: In the function dissect_ipv6 of the ipv6 dissector(packet-ipv6.c),the ip6_hdr struct is allocated on the stack,then it's address is passed to