I had a play and saw that it is not reported at all, if I have time I
will fix this at the weekend.
Tim
-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Tomas Kukosa
Sent: 22 September 2005 08:04
To: tim@xxxxxxxxxxxxxxx; Ethereal development
Subject: Re: [Ethereal-dev] Should the BER dissector throw an exception
onatag mismatch?
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.
>>
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev