On Thu, Jul 5, 2018 at 9:53 AM Guy Harris wrote:
>
> Is there some reason to forbid dissectors called by the dissector for the
> next protocol in the stack to fetch that data?
>
No. My concern was: if the stack is
IP/TCP/MYPROTO1/MYPROTO2/MYPROTO3
and myproto3 gives back some info, and
On Jul 5, 2018, at 12:34 AM, Dario Lombardo wrote:
> What about, instead, introducing a new field in pinfo? Something like "result
> from dissection of the next proto in the stack, reported to the previous"?
That's like a restricted-to-one-element version of the already-existing
What about, instead, introducing a new field in pinfo? Something like
"result from dissection of the next proto in the stack, reported to the
previous"? This could be a struct like
struct dissection_data {
guint dissection_data_type;
gchar dissection_data;
} dissection_data_t;
The called
On Jul 4, 2018, at 7:02 AM, Michael Mann via Wireshark-dev
wrote:
> Just because you can exchange data between dissectors this way, doesn't mean
> you should. I think it's more understandable if there are multiple
> layers/protocols between the setting of data and it's retrieval, but if you
On Jul 4, 2018, at 2:27 AM, Dario Lombardo wrote:
> On Tue, Jul 3, 2018 at 8:49 PM Guy Harris wrote:
>
>> Should we, instead, get rid of the scope arguments to those functions and,
>> instead, have separate functions, one of which serves the original purpose,
>> using file scope, and one of
Dario Lombardo
To: Developer support list for Wireshark
Sent: Wed, Jul 4, 2018 5:28 am
Subject: Re: [Wireshark-dev] Retrieving dissection result from another dissector
On Tue, Jul 3, 2018 at 8:49 PM Guy Harris wrote:
Should we, instead, get rid of the scope arguments to those function
On Tue, Jul 3, 2018 at 8:49 PM Guy Harris wrote:
>
> Should we, instead, get rid of the scope arguments to those functions and,
> instead, have separate functions, one of which serves the original purpose,
> using file scope, and one of which serves this new purpose, using
> pinfo->pool scope?
>
Den tis 3 juli 2018 21:28Guy Harris skrev:
> On Jul 3, 2018, at 12:01 PM, Pascal Quantin
> wrote:
>
> > As the scope is an explicit argument, I find it quite clear what's going
> on already.
>
> As the two functions are quite different in intent, I find it not entirely
> clear, merely from the
On Jul 3, 2018, at 12:01 PM, Pascal Quantin wrote:
> As the scope is an explicit argument, I find it quite clear what's going on
> already.
As the two functions are quite different in intent, I find it not entirely
clear, merely from the scope, what's going on.
> Personally I do not think a
Le mar. 3 juil. 2018 à 20:57, Richard Sharpe
a écrit :
> On Tue, Jul 3, 2018 at 11:48 AM, Guy Harris wrote:
> > On Jul 3, 2018, at 9:24 AM, Peter Wu wrote:
> >
> >> Another possibility is to use p_add_proto_data/p_get_proto_data with
> packet scope
> >
> > 1) Presumably you mean pinfo->pool
On Tue, Jul 3, 2018 at 11:48 AM, Guy Harris wrote:
> On Jul 3, 2018, at 9:24 AM, Peter Wu wrote:
>
>> Another possibility is to use p_add_proto_data/p_get_proto_data with packet
>> scope
>
> 1) Presumably you mean pinfo->pool scope - the only scopes p_add_proto_data()
> allows are
On Jul 3, 2018, at 9:24 AM, Peter Wu wrote:
> Another possibility is to use p_add_proto_data/p_get_proto_data with packet
> scope
1) Presumably you mean pinfo->pool scope - the only scopes p_add_proto_data()
allows are wmem_file_scope() and pinfo->pool.
2) The original purpose of per-packet
Hi Dario,
Another possibility is to use p_add_proto_data/p_get_proto_data with packet
scope with the protocol and id as chosen by the producer. That way you do not
have to change the data argument.
Kind regards,
Peter
https://lekensteyn.nl
(pardon my brevity, top-posting and formatting, sent
On Tue, Jul 3, 2018 at 8:21 AM, Pascal Quantin wrote:
> Hi Dario,
>
> Le mar. 3 juil. 2018 à 17:11, Dario Lombardo a écrit :
>>
>> Actually I'm using the blob to pass data from the caller to the called. I
>> guess it's a design flow to re-use this blob to have data back...
>
>
> Simply add a
Hi Dario,
Le mar. 3 juil. 2018 à 17:11, Dario Lombardo a écrit :
> Actually I'm using the blob to pass data from the caller to the called. I
> guess it's a design flow to re-use this blob to have data back...
>
Simply add a parameter to your structure that is used to retrieve the
output data
Actually I'm using the blob to pass data from the caller to the called. I
guess it's a design flow to re-use this blob to have data back...
On Tue, Jul 3, 2018 at 5:01 PM Richard Sharpe
wrote:
> On Tue, Jul 3, 2018 at 7:55 AM, Dario Lombardo wrote:
> > Hi
> > In my dissector I need to call
On Tue, Jul 3, 2018 at 7:55 AM, Dario Lombardo wrote:
> Hi
> In my dissector I need to call another dissector, and I'm using
> call_dissector_with_data(). I need to have back one result coming from the
> dissection (an integer) to use in the calling dissector.
> How can I do that?
You can pass
Hi
In my dissector I need to call another dissector, and I'm using
call_dissector_with_data(). I need to have back one result coming from the
dissection (an integer) to use in the calling dissector.
How can I do that?
Thanks
Dario.
--
Naima is online.
18 matches
Mail list logo
