> The assert in proto.c happens if length == -1. Note the comment:
>
> if (length == -1) {
> /*
> * For FT_NONE or FT_PROTOCOL fields, this means "set the
> * length to what remains in the tvbuff"; the assumption
> * is that the length can only be determined by dissection,
> * so we set it to that value so that, if we throw an
> * exception while dissecting, it has what is probably the
> * right value.
> *
> * It's not valid for any other type of field.
> */
> g_assert(hfinfo->type == FT_PROTOCOL ||
> hfinfo->type == FT_NONE);
> length = tvb_length_remaining(tvb, start);
> }
>
> tvb_length_remaining() is returning -1. Here's the comment describing
> tvb_length_remaining() in epan/tvbuff.h:
>
> /* Computes bytes to end of buffer, from offset (which can be
> negative,
> * to indicate bytes from end of buffer). Function returns -1 to
> * indicate that offset is out of bounds. No exception is thrown. */
> extern gint tvb_length_remaining(tvbuff_t*, gint offset);
>
> If your string (hf_tns_connect_data) really is supposed to continue to
> the end of the tvbuff, but the tvbuff has no more data, then an
> exception needs to be thrown. The question becomes, should we
> have a version of tvb_length_remaining() that can throw
> an exception, or should the dissector check the return value of
> tvb_length_remaining() and throw the exception. Probably the former.
>
> Do you concur?
Seems to make sense to me... Wonder why that is occurring though.
This is used in a bunch of places in the tns dissector - the offset in frame to certain data is a field in the frame. Odd that it either is dissecting incorrectly, or that something is wrong with the frame data. Will have to look into it a bit further.
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@xxxxxxx
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
