I am not sure about this, the history of ASN.1 has definitions that
include the "..." clause, which basically means add anything required
for future expansions in here.
I not sure if the asn.1 compiler supports this, I need to have a look,
but the practice of companies extending asn.1 definitions is common
place. In the case where an unexpected Octet string is found we should
report the problem then skip the item, and continue dissecting.
Tim
-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Tomas Kukosa
Sent: 22 September 2005 06:46
To: ronnie sahlberg; Ethereal development
Subject: Re: [Ethereal-dev] Should the BER dissector throw an exception
ona tag mismatch?
I agree.
And the wrong packet will be more visible.
BTW do we have any any exception like "Invalid packet"?
ronnie sahlberg wrote:
> i think it would be valid to throw an exception right there when the
> tag
> is wrong.
>
> even it the length is correct it is more than likely something is
> pretty broken anyway so it is unlikely in my opinion that any attempts
> to try to skip to the next token and continue would work.
>
>
>
>
> On 9/22/05, Guy Harris <gharris@xxxxxxxxx <mailto:gharris@xxxxxxxxx>>
> wrote:
>
> Currently, the BER dissector will put a "BER Error" item into the
> protocol
> tree if it is attempting to dissect an item of a particular type
but the
> tag on the item says it has another type. It returns an offset
that
> runs
> past the end of the item after that.
>
> This means that, for example, callers to
dissect_ber_octet_string() who
> pass it a tvbuff_t ** have to check whether the tvbuff_t *
returned is
> null, which it will be if the item didn't have a tag appropriate
to an
> octet string. I've checked in a bunch of changes to add checks
for
> that.
>
> Should we, for any or all of the cases where a "BER Error" item is
> currently put into the protocol tree, be throwing an exception and
> giving
> up on dissection? One could argue that, if the tag is wrong but
the
> length is correct, *not* throwing an exception lets us try
> dissecting more
> of the packet.
>
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev