It is supported in asn2eth and PER decoder but as I remember it is not supported in BER
decoder.
But we should still discern between extension and invalid packet.
Tim wrote:
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.