On 03/07/2018 07:39, Guy Harris wrote:
On Jul 2, 2018, at 10:34 PM, Mike Morrin wrote:
One idea I had was to NOT give the aggregated packets real packet numbers (in
the traditional sense), but give them sub-packet numbers which are displayed as
x.y where x is the aggregation packet where th
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 s
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 n
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 sco
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 wmem_file_sco
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 d
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 fr
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 para
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 fr
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 anot
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 in
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.
Hi
I work with sctp pcaps very often and I have always found that Wireshark
doesn't handle them in a practical way
The far biggest issue is the display filter logic
As a workaround, I have to externally pre-process the traces and "de-chunk"
the sctp packets: when every sctp packet contains only o
All,
I talked to Roland, Peter and Graham at SF about this, but I didn't get the
answer I wanted, so I figured I'd give it a try to implement:)
I'd like to automatically stop a live capture after some specific thing is
seen in a packet - using either a BPF style filter or a display filter. I
thin
On Tue, Jul 3, 2018 at 2:42 AM, Jakub Zawadzki
wrote:
> Hello,
>
> W dniu 2018-07-02 22:33, Jeff Morriss napisał(a):
>
>> It's an idea that's been tossed around since at least 2006[1]. Someone
>> (Jakub?) had played around with it but eventually gave up; unfortunately I
>> can't find the referen
This discussion was also voiced by Evan Huus back in 2015. For some reason,
I cannot find the original email, but here is the gist of it:
> I've been thinking about this and trying to come up with a way to
gracefully (and backwards-compatibly) add this
> information to our existing data-structures
16 matches
Mail list logo
