marko
> To: wireshark-dev
> Sent: Sat, Jul 2, 2016 5:19 pm
> Subject: Re: [Wireshark-dev] Adding dynamic fields to tree from dissector
>
> On Tue, Jun 21, 2016 at 1:27 PM, ma...@kevac.org wrote:
> > I can indeed figure out all possible fields and their types because I
> &
] Adding dynamic fields to tree from dissector
On Tue, Jun 21, 2016 at 1:27 PM, ma...@kevac.org wrote:
> I can indeed figure out all possible fields and their types because I
> have a protocol in some binary format selected by wireshark user
> through settings.
I have tried to implement this
On Tue, Jun 21, 2016 at 1:27 PM, ma...@kevac.org wrote:
> I can indeed figure out all possible fields and their types because I
> have a protocol in some binary format selected by wireshark user
> through settings.
I have tried to implement this and found out that all dissectors
register their fi
On Sat, Jun 18, 2016 at 5:14 PM, ma...@kevac.org wrote:
> Hi.
>
> I have read Developer Manual, README.dissector and looked into few
> examples, but could not find an answer to my question.
>
I am sorry that I am answering to my own message instead of your
replies. Somehow I did not received answ
names/filters for all of the fields.
-----Original Message-
From: marko
To: wireshark-dev
Sent: Sat, Jun 18, 2016 11:58 am
Subject: [Wireshark-dev] Adding dynamic fields to tree from dissector
Hi.
I have read Developer Manual, README.dissector and looked into few
examples, but could not
Hi,
Yes indeed, we try to make sure that the most important feature (the filtering)
works as well as possible, which is undermined by using the add_text() API.
What you are saying is that there is no way to know how the message looks like
until you’ve received it. That’s not unusual. But are y
Hi.
I have read Developer Manual, README.dissector and looked into few
examples, but could not find an answer to my question.
I have a dissector for a custom protocol, that is basically 4 bytes
length, 4 bytes msg_id and rest is packed protocol buffers message.
I am unpacking this protocol buffe
