Re: [Wireshark-dev] How to get calling dissector

[Shai Shapira]

I believe there's another possible approach here:
Register the dissector once with proto_register_protocol (as usual), which
assumed caller is TCP
register another dissection function (for SMP) using
create_dissector_handle_with_name called something like "smp.tds"
than look for this name when retrieving the dissector handle in the TDS
dissector

This means you should have 2 'entry point' functions to your dissector (usually
there's only one dissect_PROTO).
This way by writing different dissection/payload handling code in those two
functions you can react differently to different calling protocols (tcp
calls will trigger the first function, TDS will trigger the second etc)


2018-01-29 21:26 GMT+02:00 Uli Heilmeier :

> Thanks a lot Roland.
>
> Now that I know what to look for packet-sip.c gives a nice example.
>
> Cheers
> Uli
>
> Am 29.01.18 um 18:03 schrieb Roland Knall:
> > Short answer: packet_info->layers should get you the list of protocols
> called before yours. If you iterate, you should
> > see the other protocols before yours. In packet.c:754 you see the code
> adding to the list.
> >
> > Not sure though, how stable that interface is. It is pretty in-depth for
> span, so you should be save to use it, but not
> > sure, if it is official, or if there is another way.
> >
> > cheers
> > Roland
> >
> > On Sun, Jan 28, 2018 at 10:59 PM, Uli Heilmeier  > wrote:
> >
> > Hi all,
> >
> > TL,DR:
> > How does a dissector know which dissector called it?
> >
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=
> unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] PAD file contents

[Jaap Keuter]

Hi,

The published PAD file lists:


Linux,Linux Console,Linux Gnome,Linux GPL,Linux Open Source,Mac OS X,Unix,Win7 
x32,Win7 x64,WinServer,WinVista,WinVista x64,WinXP,Other


I think "WinVista,WinVista x64,WinXP” should be dropped from this list.

Also the screenshot is due for an overhaul:


https://www.wireshark.org/image/front_screen_full.png


It showing the good old GTK interface.

Thanks,
Jaap

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Philosophy question - avoiding g_alloc in dissectors?

[Craig Jackson]

I have a place in my dissector where g_strjoin would fit my needs exactly,
and make clean code. However, it calls g_alloc, which I am assuming is
heavier than the allocator used for wmem_packet_scope.

I see there's a wmem_strconcat, but that doesn't quite fit my needs. It
could but not as well.

The string isn't long (ITEM_LABEL_LENGTH max) and has up to three
components, so I could also write open code to put things into a buffer
allocated on the stack. They would then be copied into a wmem_packet_scope
allocated buffer.

I see three alternatives. Which is preferred?

1. Write my open code, finishing with wmem_strdup().
2. Use g_strjoin(), and then wmem_strdup the result.
3. Add a wmem_strjoin to wmem/wmem_strutl.[ch], modeled after
wmem_strconcat and g_strjoin.

I notice that g_strjoin is only used in dissectors/packet-rtps.c, and this
suggests to me that option (2) is to be avoided.

Many of the other places I see g_alloc/g_free used in dissectors have to do
with things like uats which are long-lived structures.

I'm thinking that (3) is the best, but I want confirmation from the more
experienced developers. Also, if I create wmwm_strjoin, should I fix
packet-rtps.c? I would have to way to test it unless there is an archive of
rtps captures.

Craig Jackson
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] How to get calling dissector

[Uli Heilmeier]

Thanks for your idea. It's exactly the way Michael did it with his improvement 
for my patch:
https://code.wireshark.org/review/#/c/25509/

Am 29.01.18 um 21:01 schrieb Shai Shapira:
> I believe there's another possible approach here:
> Register the dissector once with proto_register_protocol (as usual), which 
> assumed caller is TCP
> register another dissection function (for SMP) using  
> create_dissector_handle_with_name called something like "smp.tds" 
> than look for this name when retrieving the dissector handle in the TDS 
> dissector
> 
> This means you should have 2 'entry point' functions to your dissector 
> (usually there's only one dissect_PROTO).
> This way by writing different dissection/payload handling code in those two 
> functions you can react differently to
> different calling protocols (tcp calls will trigger the first function, TDS 
> will trigger the second etc)
> 
> 
> 2018-01-29 21:26 GMT+02:00 Uli Heilmeier  >:
> 
> Thanks a lot Roland.
> 
> Now that I know what to look for packet-sip.c gives a nice example.
> 
> Cheers
> Uli
> 
> Am 29.01.18 um 18:03 schrieb Roland Knall:
> > Short answer: packet_info->layers should get you the list of protocols 
> called before yours. If you iterate, you should
> > see the other protocols before yours. In packet.c:754 you see the code 
> adding to the list. 
> >
> > Not sure though, how stable that interface is. It is pretty in-depth 
> for span, so you should be save to use it, but not
> > sure, if it is official, or if there is another way.
> >
> > cheers
> > Roland
> >
> > On Sun, Jan 28, 2018 at 10:59 PM, Uli Heilmeier    >> wrote:
> >
> >     Hi all,
> >
> >     TL,DR:
> >     How does a dissector know which dissector called it?
> >
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe