Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!decwrl!ucbvax!asmec.UUCP!andy
From: andy@asmec.UUCP (Andy Sykes)
Newsgroups: comp.protocols.iso.dev-environ
Subject: Bug in info2ppdu
Message-ID: <26d021d6.asmec@asmec.uucp>
Date: 20 Aug 90 17:45:58 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 45

We believe that we have uncovered a bug in the Presentation Layer
function info2ppdu when dealing with simply encoded User data.

The User data is passed into this function as an array of PEs.
Depending upon the type in the pdu->offset field after checking, the
User data is converted into a qbuf list using the info2qb function. For
simply encoded data this function is called once for each PE such
that the data therein is concatonated into a single qbuf. Fully
encoded data is built into a list of qbufs.

The bug relates to the fact the the qbuf is not set up correctly for
the simple encoded case. The qb_len feild is left with a value of
zero, and the qb_data pointer points to the end of the data held in
the qb_base character array due to the manner in which info2qb
operates. The qb_len field in the header stucture is correct,
however.

The upshot of all this is that simply encoded User Data is not
included in the encoded PPDU, as qb2prim specifically tests the qb_len
field.

A proposed solution is to insert the following just after the

        for (d = data, i = 0; i < ndata; i++)

processing loop which calls info2qb:-

        if (pdu->offset == type_PS_User__data_simple)
        {
                qb->qb_len = simple->qb_len;
                qb->qb_data = qb->qb_base;
        }

        return pdu;

This has worked successfully in our tests.


Best Regards
Andy Sykes

Andrew Sykes Micro-Electronics Consultants Ltd.
21 Willow Green, Needingworth, Cambridgeshire, PE17 3SW, UK
Tel/FAX: +44 (0) 480 69771              E-Mail: andy@asmec.uucp
                                        or ..mcsun!ukc!asmec!andy