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 GUI)
If those two are met I think it should work.
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.
On Wed, Feb 4, 2015 at 4:51 AM, Dario Lombardo
<dario.lombardo.ml@xxxxxxxxx> wrote:
> 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\n", tree, i, tvb, fi);
> }
>
> it always returns NULL.
>
> If I run it from the gtk gui
>
> packet-panes.c:369
>
> g_print("TEST2 %p %d %p => %p\n", tree, byte, tvb, finfo);
>
> it returns a (valid?) pointer.
>
> The 2 prints show the same values of pointer/offsets.
>
> Where should a "for" routine like the above could be added in the code so it
> shows every undissected byte in every dissector?
> Thanks.
> Dario.
>
> On Tue, Feb 3, 2015 at 6:15 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
>>
>> 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 in the UI) so it's probably a good
>> place to start.
>>
>> On Tue, Feb 3, 2015 at 12:08 PM, Dario Lombardo
>> <dario.lombardo.ml@xxxxxxxxx> wrote:
>> > 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 <wireshark-dev@xxxxxxxxxxxxx>
>> > Archives: http://www.wireshark.org/lists/wireshark-dev
>> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> >
>> > mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>
>> ___________________________________________________________________________
>> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives: http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>
>> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
>
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
