So I'm looking at the value strings, and I'm wondering why we should
terminate them with {0, NULL} and what happens if one of the value pairs
needs to be {0, "a real string"} ?
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Joerg Mayer
Sent: Wednesday, May 30, 2007 10:42 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] DISSECTOR_ASSERT_NOT_REACHED in WLCCP decode...
On Wed, May 30, 2007 at 09:17:59AM -0400, Kevin A. Noll wrote:
> I've been compiling with the 0.99.5 tarball.
>
> I appreciate any suggestions anyone may have.
- Terminate all value strings with an entry of { 0, NULL },
wlccp_tlv_typeIDs, wlccp_aaa_msg_type_vs and others lack this.
- You do a
: proto_tree_add_item(wlccp_tree, hf_wlccp_requ_node_type tvb, offset, 2,
FALSE);
: offset += 2;
(16 bits)
but in the hf_ array the type is FT_UINT8
- hf_wlccp_status is defined as byte in hf_ and used as such in most places,
but there is 1 place where it is used with a length of 2.
- The following comment:
: next_tvb = tvb_new_subset(tvb, offset, -1, -1);
: call_dissector(eap_handle, next_tvb, pinfo, wlccp_eap_tree);
: This doesn't work. The EAP dissector expects to take over the entire
: packet dissection,
: when we are only passing it a portion of what it's looking for
indicates that you are a) reinventing the wheel because you b) used it in
slightly the wrong way:
if oyu pass -1, -1 to tvb_new_subset, then yes, it will use all the
remaining bytes. If you only pass the amount of bytes that you want the eap
dissector to use, then all should be fine (see packet-radius.c for an
example).
- Btw, the whitespace changes (added spaces and tabs at line ends) should
go.
> Please don't laugh at how bad my code looks :-)
The only stupid thing is not to not know, it would have been to not ask.
ok, I need to stop here for now. Probably I won't find the time to continue
until Saturday.
Ciao
Joerg
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev