Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 1971 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 1971.

Report 1971 Actions

    Problem Report Number 1971
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Test Suite Deficiency (TSD)
    Problem Resolution ID TSD.X.0998
    Raised 1999-10-20 08:00
    Updated 2003-03-13 08:00
    Published 1999-11-09 08:00
    Product Standard Transport Service XTI
    Certification Program The Open Brand certification program
    Test Suite VST version 5.2.4
    Test Identification XTI.os/cots/T.accept 10
    Problem Summary TSDT4.036 slave system, file accept_s.c, line 554, function test10(): topic: "when preparing the rcvcall structure prior to a t_connect() call, the maximum length of the address buffer is not set" For data pass...
    Problem Text
    slave system, file accept_s.c, line 554, function test10():
    topic: "when preparing the rcvcall structure prior to a t_connect()
    call, the maximum length of the address buffer is not set"

    For data passed to the user, the MAXIMUM buffer length is to be
    specified while the CURRENT length is set on return. In this case,
    rcvcall->addr.maxlen is to be specified instead of rcvcall->addr.len,
    just as it is done for the user data buffer in the preceding lines of
    code.
    ==> rcvcall->addr.maxlen contains an arbitrary value which happens to
    be 1 in our case. Acc. to the text in the journal file this doesn't
    seem to be an intentional feature of this test case.
    As this value is definitely too small to hold any address information,
    t_connect() fails with t_errno set to TBUFOVFLW. As the function
    terminates prematurely, no option or user data information is copied to
    the rcvcall buffers.

    The XPG4 standard does in no way indicate how to deal with returning
    data after an error occurred. Though, in this particular case, one
    might argue that the user data are quite independent from the address
    information, in general, it doesn't seem to make sense to try and
    pass parts of the overall return information to the user in case of
    an error, as the application has no criteria to distiguish if any
    (or which) part of the returned information is reliable in a
    particular error case.
    >>>In our opinion, rcvcall->udata.len mustn't be evaluated in case of
    t_connect() terminating UNsuccessfully.<<<<

    For the "XNS, Issue5" standard, a chapter about using "struct netbuf"
    has been added which supports our point of view (see XNS5,7.4).

    PS: the user data are received correctly if the buffer overflow is
    avoided
    Test Output
    /tset/XTI.os/cots/accept/T.accept 10 Failed

    Test Description:
    If the implementation supports a connection-oriented transport service
    which supports data transmission with connect:
    When call->udata.len > 0 then a successful call to t_accept( fd,
    resfd, call ) sends the user data specified by call->udata to the
    caller.

    Test Strategy:
    VERIFY that the transport service is of type T_COTS or T_COTS_ORD
    SLAVE:
    SEND the info->connect value for the endpoint to the master using
    putsv_m()
    MASTER:
    OBTAIN an endpoint with qlen 1 in T_IDLE state using provsetup()
    RECEIVE the slave's info->connect value using getsv_s()
    SET test data length to an amount supported by both systems
    SEND the test data length to the slave using putsv_s()
    IF the master's info->connect is -2 :
    SKIP to next transport provider
    SLAVE:
    RECEIVE the test data length from the master using getsv_m()
    IF the test data length is zero:
    SKIP to next transport provider
    INITIATE a connection using t_connect()
    MASTER:
    WAIT for connect request using t_listen()
    ACCEPT connection using t_accept() with data in call->udata
    VERIFY that t_accept() returned zero
    SLAVE:
    VERIFY that t_connect() returned zero
    VERIFY that rcvcall->udata has the expected contents

    Test Information:

    Test Information From Slave:
    warning: t_connect() gave TBUFOVFLW on ISO CLASS 2 endpoint
    t_connect() on ISO CLASS 2 endpoint returned udata.len = 0, expected 32


    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    It is agreed that this is a test suite deficiency and a waiver is recommended.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Test Suite Deficiency (TSD)
    Review Conclusion
    This is an agreed Test Suite Deficiency.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority