'Re: [ooh323c-devel] BUG: decoding an extension with a NULL type'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ooh323c-devel
Subject:    Re: [ooh323c-devel] BUG: decoding an extension with a NULL type
From:       "Vishal Phirke" <vphirke () obj-sys ! com>
Date:       2005-08-01 15:38:55
Message-ID: 00ad01c596c8$51ee3b40$4e00000a () D6XKKF11
[Download RAW message or body]

Doru,

It does that to flag that the OpenType has been identified as NULL Type. For
unknown types, if required in future, we can create a list and provide it to
the application for further processing.

Regards,
Vishal Phirke
----- Original Message ----- 
From: "Doru Petrescu" <pdoru-h323@kappa.ro>
To: "Vishal Phirke" <vphirke@obj-sys.com>
Cc: <ooh323c-devel@lists.sourceforge.net>
Sent: Monday, August 01, 2005 2:43 AM
Subject: Re: [ooh323c-devel] BUG: decoding an extension with a NULL type


> I see it does like this:
>
>                   case 12:
>                      if(openType.numocts == 0) openType.numocts = 1;
>                      pvalue->m.supportsAltGKPresent = 1;
>
>                      invokeStartElement (pctxt, "supportsAltGK", -1);
>
>                      /* NULL */
>                      invokeNullValue (pctxt);
>
>                      invokeEndElement (pctxt, "supportsAltGK", -1);
>                      break;
>
>
>
> why do you need to make numocts=1 ? i dont think anybody use that value
> anyway... maybe in invoke***element() ?
>
>
> anyway, I tested the decoding of a NULL type and it works OK. BUG fixed.
>
> Beste regards,
> D.
>
>
>
> On Wed, 2005-07-27 at 04:03, Vishal Phirke wrote:
> > Hi Doru,
> >
> > I have added support to handle NULLs encoded as zero length elements.
Can
> > you test it and let me know if it works fine for you. I will close the
bug
> > entry after your testing.
> >
> > To get the latest code from CVS
> >  >cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ooh323c login
> > CVS PASSWD:<ENTER>
> > >cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ooh323c co
ooh323c
> >
> > Regards,
> > Vishal Phirke
> > Objective Systems Inc.
> >
> > ----- Original Message ----- 
> > From: "Doru Petrescu" <pdoru-php-upm@kappa.ro>
> > To: "Vishal Phirke" <phirke@gmail.com>
> > Cc: <ooh323c-devel@lists.sourceforge.net>
> > Sent: Friday, July 22, 2005 9:06 AM
> > Subject: Re: [ooh323c-devel] BUG: decoding an extension with a NULL type
> >
> >
> > > openh323 can decode my test correctly. also etherreal decodes it too.
> > > this is why i said it is a bug.
> > >
> > > my apologies if this is an ambiguity in the standard, but I think the
> > > decoder should handle it both ways.
> > >
> > > I think you can safely and easily cover both cases. just allow for the
> > > fact that the NULL type can have a zero-size encoding. i looked at the
> > > code I dont think it will affect anything else.
> > >
> > > D.
> > >
> > >
> > >
> > > On Fri, 2005-07-22 at 18:58, Vishal Phirke wrote:
> > > > Hi Doru,
> > > >
> > > > Thanks for testing. I believe that what we are doing is correct as
per
> > > > standards.The NULL here is an extension element, therefore, the NULL
> > > > element must be encoded as an open type as opposed to an ordinary
> > > > NULL.  An open type encoding must have a length field that must be
at
> > > > least 1 followed by the data field.  Therefore the encoding of the
> > > > NULL
> > > > in this case must be 01 00 instead of just 00.
> > > >
> > > > However, we may need to provide a kludge to handle this case,
because it
> > > > is a common error and could prevent interop.  As far as I know,
> > > > OpenH323 had this problem and it was brought to their atteintion,
but
> > > > we are not sure whether it was fixed.
> > > >
> > > > Here's the link to that discussion:
> > > > http://www.openh323.org/pipermail/openh323/2003-November/064267.html
> > > >
> > > >
> > > > Regards,
> > > > Vishal
> > > >
> > > >
> > > > On 22 Jul 2005 03:06:45 +0300, Doru Petrescu
<pdoru-php-upm@kappa.ro>
> > wrote:
> > > > >
> > > > >
> > > > > Hi everybody,
> > > > >
> > > > > I've been playing with the ooH323 library for a while, and found a
> > > > > problem with v.0.5.2.  I just checked and the sources look the
same in
> > > > > version 0.7.1, so the problem is not yet fixed.
> > > > >
> > > > >
> > > > > the problem is that it with the ASN1 decoder functions that will
fail
> > to
> > > > > decode an EXTENDED entry if it is of type NULL.
> > > > >
> > > > > an example is a GK GRQ packet containing field 'supportsAltGK'
> > > > >
> > > > > for v0.7.1 check file H323-MESSAGESDec.c line 16615 inside
> > > > > function asn1PD_H225GatekeeperRequest():
> > > > >
> > > > >      for (i = 0; i < bitcnt; i++) {
> > > > >          DECODEBIT (&lctxt, &optbit);
> > > > >
> > > > >          if (optbit) {
> > > > >              ......
> > > > >             if (i < 10 && openType.numocts > 0) {  /// ***BUG****
> > > > >
> > > > >
> > > > >
> > > > > notice the last line. if the size of the element is ZERO it will
not
> > > > > decode it. and because a NULL type is encoded in exactly ZERO bits
and
> > > > > ZERO bytes, the decoder will not decode it.
> > > > >
> > > > > This is a problem with your ASN1 decoder-generator. and not with
the
> > > > > h323 stack. but this might generate problems in the stack if it
fails
> > to
> > > > > detect options present in the received data packets.
> > > > >
> > > > > I think you need to decode the NULLs separatedly from the rest of
the
> > > > > fields because of this.
> > > > >
> > > > > OR
> > > > >
> > > > > even better, remove the 'numocts > 0' constraint and let each
sub-type
> > > > > deal with a zero-size buffer how it see fits: NULLs will be OK,
all
> > > > > others will complain becuase I think it would be an invalid case
> > anyway.
> > > > >
> > > > >
> > > > > the encoder works correctly because it is written in a different
way.
> > > > > you might consider re-writing the decoder in the same style as the
> > > > > encoder and remove the for/switch algorithm with a succession of
> > > > > if (field_is_present) { .... deocde it ... }
> > > > >
> > > > >
> > > > > please send replies to me too, as I am not subscribed to the list.
> > > > >
> > > > > Also, I am tring to build a set of ASN1 test cases for a software
I am
> > > > > writing, and I was wondering if anyone has some data packets and
the
> > > > > known (and verified) good decoding for them. I am looking for a
set of
> > > > > tests that covers all the posible cases in ASN1 and H323.
> > > > > It was during the development of such a test case that I realized
that
> > > > > different libraries give different results for the same pair of
bits.
> > > > > and this is how I found the bug.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > >
> > > > > Best regards,
> > > > > Doru Petrescu
> > > > > Senior Software Engineer
> > > > > Astral Telecom Bucuresti
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
> > > > > from IBM. Find simple to follow Roadmaps, straightforward
articles,
> > > > > informative Webcasts and more! Get everything you need to get up
to
> > > > > speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > > > > _______________________________________________
> > > > > ooh323c-devel mailing list
> > > > > ooh323c-devel@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/ooh323c-devel
> > > > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > > informative Webcasts and more! Get everything you need to get up to
> > > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > > _______________________________________________
> > > ooh323c-devel mailing list
> > > ooh323c-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/ooh323c-devel
> > >
> > >
> > >
> >
> >
>
>
>




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
ooh323c-devel mailing list
ooh323c-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ooh323c-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic