On Fri, Feb 6, 2015 at 7:52 AM, Michal Labedzki
wrote:
> One more hint: if push patch as draft then add reviewer, because draft
> is invisible for anyone (expect author and reviewers)
>
> Alternative command(s) to send to gerrit:
> git push origin HEAD:refs/drafts/master
> git push origin HEAD:re
One more hint: if push patch as draft then add reviewer, because draft
is invisible for anyone (expect author and reviewers)
Alternative command(s) to send to gerrit:
git push origin HEAD:refs/drafts/master
git push origin HEAD:refs/publish/master
By the way: I vote for adding expert info. Someti
Please just upload it Gerrit - it's much easier to review there. You
can upload it as a draft (pass the -D flag to git-review) if you want
to avoid cluttering up the main review list yet.
On Thu, Feb 5, 2015 at 11:49 AM, Dario Lombardo
wrote:
> Evan,
> please find attached a patch that implements
Evan,
please find attached a patch that implements what I was trying to do. I'd
like to share it here with you and other devels in order to understand if
it goes in the right direction and maybe to open discussions on it. If it
seems good, I'll move it to gerrit for code review.
To test it, simply
On Thu, Feb 5, 2015 at 1:19 PM, Evan Huus wrote:
> I believe g_log and friends go to standard out, but maybe not on all
> platforms. An expert info under conditional compilation would probably
> be enough though, I hadn't thought of that.
>
Another question. I've found a promising point to put t
I believe g_log and friends go to standard out, but maybe not on all
platforms. An expert info under conditional compilation would probably
be enough though, I hadn't thought of that.
On Thu, Feb 5, 2015 at 5:49 AM, Dario Lombardo
wrote:
> On Wed, Feb 4, 2015 at 7:28 PM, Evan Huus wrote:
>>
>> I
On Wed, Feb 4, 2015 at 7:28 PM, Evan Huus wrote:
> I suppose you could add a an expert info, but I think that might be
> overkill, most users probably don't care that much.
Expert infos could be added under conditional compilation. If enabled it
would allow to filter packets that has expert inf
I suppose you could add a an expert info, but I think that might be
overkill, most users probably don't care that much. You could just log
it, or dissect it as data, or...
On Wed, Feb 4, 2015 at 11:58 AM, Dario Lombardo
wrote:
> On Wed, Feb 4, 2015 at 5:25 PM, Evan Huus wrote:
>>
>> I think you
On Wed, Feb 4, 2015 at 5:25 PM, Evan Huus wrote:
> I think you will need to add a function very similar to
> proto_find_field_from_offset that makes use of
> proto_tree_traverse_pre_order and tracks which bytes have been "seen"
> as the traversal proceeds.
>
And how the output could be shown to
I think you will need to add a function very similar to
proto_find_field_from_offset that makes use of
proto_tree_traverse_pre_order and tracks which bytes have been "seen"
as the traversal proceeds.
On Wed, Feb 4, 2015 at 11:22 AM, Dario Lombardo
wrote:
> On Wed, Feb 4, 2015 at 3:52 PM, Evan Huu
On Wed, Feb 4, 2015 at 3:52 PM, Evan Huus wrote:
>
> As a side note, I would expect that method to be *very* slow, since it
> traverses the entire tree for every byte of the packet. Traversing the
> tree once and maintaining a set of covered/uncovered ranges would be
> much more efficient.
>
I c
I'm not sure why it would work differently in the two places if those
print statements are the same. In general I would expect the
requirements for that method to be:
- *after* full dissection is finished
- dissection must have been run with the full tree enabled (as when
selecting a packet in the
Hi Evan
This looks promising. Where can I use this call?
If I run it from within a dissector
packet-hpfeeds.c:344 (just an example... for purpose of testing)
for (i = 0; i < len; i++) {
fi = proto_find_field_from_offset(tree, i, tvb);
g_print("TEST1 %p %d %p => %p\
That's a possibility (I have to take a look at the dissectors you both
mentioned, and I didn't it yet), but what I was looking for was a more
general way to do that. If the dissector itself has to make this checks, it
means that all dissectors code must be patched. If we find a way to do that
after
I use expert info about undecoded thing in Bluetooth dissectors.
In proto.h:
/** The data is undecoded, the protocol dissection is incomplete here,
usually PI_WARN severity */
#define PI_UNDECODED0x0500
But I use it with PI_NOTE, because I treat PI_WARN more like a "bug"
rather th
There is some dissector (like ICMPv6, IEEE 802.11 or CAPWAP...)
where there is already expert info about undecoded code...
On Tue, Feb 3, 2015 at 6:15 PM, Evan Huus wrote:
> As far as I know this is not currently available, but it would
> probably be fairly useful and easy. You just need to ite
As far as I know this is not currently available, but it would
probably be fairly useful and easy. You just need to iterate the proto
tree and keep track of which byte ranges are claimed/unclaimed.
proto_find_field_from_offset does something related to this (it is
used for matching bytes to fields
Hi list
I was wondering if there is a comfortable way to find out undissected bytes
in packets. This would be useful to find incomplete dissectors.
Any hint?
Thanks!
Dario.
___
Sent via:Wireshark-dev mailing list
Archives:
18 matches
Mail list logo
