Ethereal-dev: Re: [Ethereal-dev] Should the BER dissector throw an exception ona tag mismatch?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: Tomas Kukosa <tomas.kukosa@xxxxxxxxxxx>
Date: Thu, 22 Sep 2005 09:04:10 +0200
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.