Re: BUG: decoding an extension with a NULL type
Doru Petrescu <pdoru-php-upm <at> kappa.ro>
2005-07-22 16:06:30 GMT
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 <at> 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 <at> 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