Guy Harris wrote:
> Bob Doolittle wrote:
>
>
>> alp_dgram_tree = proto_item_add_subtree(ti, ett_alp_dgram);
>>
>
> ett_alp_dgram - and ett_alp_commonr - aren't -1, right?
Right. They were both initialized in the proto_register_* routines
by calling proto_register_subtree_array(). I'
Bob Doolittle wrote:
> alp_dgram_tree = proto_item_add_subtree(ti, ett_alp_dgram);
ett_alp_dgram - and ett_alp_commonr - aren't -1, right?
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wiresha
Charles Lepple wrote:
> I don't know when it's NULL while the GUI is up, but I gather the
> intent was for cases like when tshark is displaying only the one-line
> summary, and not the full tree.
The intent is for all cases where a protocol tree isn't needed.
This includes:
1) tshark, w
On 4/4/07, Bob Doolittle <[EMAIL PROTECTED]> wrote:
> Guy Harris wrote:
> > So the "tree" argument to the subdissector is non-null?
> >
>
> Yes it is. Under what circumstances is it NULL, by the way? I'm
> mimic'ing the
> appropriate tests/structure but don't understand why yet...
I don't know w
Guy Harris wrote:
> What's the code in the subdissector that adds the top-level entry for
> the protocol?
Sorry - I just realized you asked for the subdissector code, and I sent
the dissector code for the top-level protocol. At least you can check that
I'm calling dissector_try_port properly...
Guy Harris wrote:
> On Apr 3, 2007, at 4:53 PM, Bob Doolittle wrote:
>
>
>> Thanks. My subdissector is now being called, and is updating the List
>> window
>> properly. But for some odd reason the sub-protocol isn't appearing
>> in the
>> Details window tree, and I'm handling it identically
On Apr 3, 2007, at 4:53 PM, Bob Doolittle wrote:
> Thanks. My subdissector is now being called, and is updating the List
> window
> properly. But for some odd reason the sub-protocol isn't appearing
> in the
> Details window tree, and I'm handling it identically to how I handled
> the parent
Guy Harris wrote:
> Bob Doolittle wrote:
>
>
>> Looking at packet.c, it appears that the type of the HF name
>> I'm passing as the first arg doesn't map to an acceptable type,
>> but in fact I've declared that field with type FT_UINT8,
>> which should be fine. Another possibility is that the
>>
Bob Doolittle wrote:
> Looking at packet.c, it appears that the type of the HF name
> I'm passing as the first arg doesn't map to an acceptable type,
> but in fact I've declared that field with type FT_UINT8,
> which should be fine. Another possibility is that the
> fields haven't been registered
Hi,
I've got a plugin dissector working for the top-level header of a
multi-layer protocol, and I need to add the subdissectors for the
subsequent layers.
I've tried doing this as separate plugins, and in a single plugin
with multiple registered dissectors. However, whenever I
call add_dissector
10 matches
Mail list logo
