Uploaded image for project: 'VOLTHA'
  1. VOLTHA
  2. VOL-3769

omci-lib-go inconsistencies when accepting attributeMask with error codes in response

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Low
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: VOLTHA v2.7
    • Component/s: openomci
    • Labels:
      None
    • Environment:

      manual lab/offline testing

      Description

      "Problem came to surface by accident: omcilib does not accept following getResponse:

      035e290a0101000001FFFC000000000000000000000000000000000000000000000000000000000000000028

      More elaborate investigation showed that the problem is in the used attributeMask 0xFFFC in connection with the indicated response error 0x01. More tests showed, that attributeMask values up to 0xFF00 are accepted while the next failing value is 0xFF80.

      From that one can assume that the omcilib parses the number of attribute values to verifiy if they could fit into one getResponse message. But even that is not quite accurate, as the GetResponse message content may only include 25 bytes (and not 29 bytes as possibly assumed here for the ONU2-G response).

      But anyway in my point of interpreting the attribute mask for some of the error codes - like her 0x01 - is not relevant, even though that's a bit left in the grey zone of the standard. In my point of view the attribute mask is only to be considered for error codes 0x03 and 0x09, for all other it is irrelevant and should not be further checked.

      So - out of this consideration two verifications/changes should be taken into account for the omci-lib:

      1.) acceptance of getResponse attributeMask concerning the maximum length should allow for maximum 25 bytes.

      2.) getResponse messages with error codes should validate the attributeMask only for error codes 0x03 and 0x09 (and maybe, but also not necessarily, for 'success' messages [error code 0])

       

       

        Attachments

        # Subject Branch Project Status CR V

          Activity

            People

            Assignee:
            chipboling Chip Boling (Inactive)
            Reporter:
            michaelpag Michael Pagenkopf
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Gerrit Reviews

                There are no open Gerrit changes