Skip to main content

MIB Implementation within RI Stack

  4 posts   Feedicon  
Replies: 3 - Last Post: September 24, 2012 20:14
by: dominaf
showing 1 - 4 of 4
Posted: September 21, 2012 19:09 by dominaf

First, allow me to put this into the proper context, as previous posts were wrongly interpreted. This has nothing to do with the PC Platform, or any specific platform for that matter. And actually, in this case we are the platform -- we are writing the porting layer between the RI Stack and our platform.

Is there a document that indicates which OC-STB-HOST-MIB objects the RI Stack itself will be implementing?

There are some MIBs that, upon examination of the RI Stack source, we see RI has implemented (though there are bugs with some as noted at the bottom of this post).

There are other OC-STB-HOST-MIB objects that we believe would be impossible to implement within the platform, or even within our porting layer and therefore need to be implemented within the RI Stack itself. The problem is, they're not there. We need confirmation that the RI Stack will be implementing these MIBs:

  • ocStbHostSoftwareOCAPVersion -- Only RI knows this
  • ocStbHostBootStatus -- Only RI knows this level of detail (e.g. inProgressAwaitingMonitorApp)
  • ocStbHostJVMLiveObjects -- Only RI knows this
  • ocStbHostJVMDeadObjects -- Only RI knows this
  • ocStbHostSoftwareApplicationInfoSigLastNetworkVersionRead -- Only RI knows this.
  • ocStbHostSoftwareApplicationInfoSigVersionInUse -- Only RI knows this
  • ocStbHostPowerStatus (I could see this in either RI Stack or MPEOS, so which is it?)
  • ocStbHostCardMfgId (should come from RI – part of Application_Info_Cnf)
  • ocStbHostCardVersion (should come from RI – part of Application_Info_Cnf)
  • ocStbHostCardSerialNumber (should come from RI – part of Application_Info_Cnf)
  • ocStbHostCardMacAddress (should come from RI – part of Application_Info_Cnf)

You can ignore the ocStbEasMessage* objects Susmita asked about. They belong in the RI Stack, and are already there. (The info isn't available below that.)

Additionally, we do not fully understand the intent behind the MIBs under the ocStbHostSystemLogging branch, and as such we are not clear at what level they are expected to be implemented. This branch includes the following MIBs:

  • ocStbHostSystemLoggingControlReset
  • ocStbHostSystemLoggingSize
  • ocStbHostSystemLoggingLevelContro
  • ocStbHostSystemLoggingEventTable (multiple columns: EventTimeStamp, EventMessage)

According to the MIB spec: -- The Host System Logging table. -- -- This table is used as an event logging table shared by the system -- and applications. Note that network-related events are still -- recorded in the ocStbHostSystemLoggingEventTable. The Host adds an -- event by adding a conceptual row to the end of the table; -- Once the table 'fills' by reaching -- ocStbHostSystemLoggingSize, adding a new event causes the oldest -- conceptual row to be removed.

But what is "the system"? Is this the RI Stack plus any apps? Or does "the system" include the porting layer and platform all the way down to the lowest layer of drivers? If it includes the platform, that would be imposing a lot on the platform. I suspect this is supposed to apply only to the RI Stack (and above), but am not certain, so please confirm that the RI Stack will implement these ocStbHostSystemLogging MIBs.

Finally, here are the MIBs that are already implemented in the RI Stack, with bugs as noted:

ocStbHostSoftwareApplicationInfoTable (multiple columns: NameString, VersionNumber, Status, OrganizationId, ApplicationId)

            BUGS:
  • There is but one application (WATCHTV), yet it repeats that app's information 5 times (rows 1..5)
  • There are two undocumented columns(.8 and .9) responding (data we get is integer 220 for .8 and zero-length octet string for .9)
    • Looking at code, .8 is reporting app priority, but that's not in the latest published MIB spec.
    • Looking at code, .9 is returning the download server IP, but that's not in the latest published MIB spec.

ocStbHostSoftwareApplicationInfoSigLastReceivedTime

ocStbHostSoftwareApplicationInfoSigLastReadStatus

ocStbHostUserSettingsPreferedLanguage

            BUG: Returns zero-length string.

ocStbHostCCAppInfoTable (multiple Columns: Index, Type, Name, Version, Page)

            BUGS:
            - When queried via GetNext (walk), always returns "No Such Name".
            - When queried directly (get), responds, but all columns responses are null.
            - Logging indicates "ERROR diagnostics.MIBManagerImpl - MIB notifyOidValueRequest InvocationTargetException: java.lang.reflect.InvocationTargetException"

ocStbHostCfrSpecificationIssue

            BUG: Returns "TBD" (Per spec, should return a string in the format of "OC-SP-HOST2.1-CFR-I13-110204"

ocStbHostMibSpecificationIssue

            BUG: Returns "I10", which isn't very meaningful. (Per spec, should return a string in the format of "OC-STB-HOST-MIB-I14-120531"

ocStbHostPatTimeoutCount

ocStbHostPmtTimeoutCount

ocStbHostOobCarouselTimeoutCount

ocStbHostInbandCarouselTimeoutCount

ocStbHostJVMHeapSize

            BUG: Returns value in bytes, but spec units is kilobytes.

ocStbHostJVMAvailHeap

            BUG: Returns value in bytes, but spec units is kilobytes.
Posted: September 21, 2012 23:57 by dominaf
Correction: Ignore the bugs listed above for the ocStbHostCCAppInfoTable MIBs. That was an oops on my part.

HOWEVER, the RI stack has incorrectly implemented the ocStbHostCCAppInfoPage MIB (column of table). The MIB is reporting the internal URL of the first page of MMI:
case 5:
    // ocStbHostCCAppInfoPage
    snmpValue = new SNMPValueOctetString(appObj.[b]getURL()[/b]);
    break;

As a result, the MIB is reporting simply something like this "CableCARD///apps/CaApp.html"

Per the MIB spec, it should be querying all the MMI pages for that app (querying the first URL, and then traversing the pages querying all others), returning all of the HTML as a table of 1 column and N rows where N is the number of individual pages queried as traversing through the URLs and getting the HTML pages. From the spec, describing that OID:

All HTML data for this application. If a 'page' as reported from the Card contains links, the links shall be traversed, and all HTML from each page traversed shall be included in a single, valid HTML string (with per-page start/end HTML and BODY tags removed). The resulting HTML SHOULD be structured as an HTML table consisting of one column, with one row for each 'page' from the Card. If the full HTML from the application (all pages concatenated) will not fit within the SNMP buffer, text indicating this SHALL follow the table; otherwise nothing except the close BODY and HTML tags SHOULD follow the table.



ALSO, the ocStbEasMessageStateCode, ocStbEasMessageCountyCode and ocStbEasMessageCountySubdivisionCode MIBs have a bug. They are not handling the case where the EA Location GF is not supported. In such a case, the MIB spec says they should return values of zero. Currently, they are returning null (zero length).

Something is also very squirrely regarding how GetNext requests are handled in the RI. In the case where the above EAS MIBs are returning null (zero length), a direct GET on the OIDs indeed returns the zero-length data, but a MIB walk (GetNext) starting at the ocStbHostEasCodes branch ends up returning ocStbHostEasCodes.0 with a value of 0, and a MIB walk beginning one level further up, at ocStbHostEasObjects, results in three responses -- all invalid OIDs -- during the walk: ocStbEasCodes.0 with value zero, ocStbEasObjects.2.0 with value zero, and ocStbEasObjects.3.0 with value zero.

In fact, when the EA Location GF is supported and there is valid data to return, the GET requests work properly and return the values expected, but mib walks still behave strange were a walk beginning at ocStbHostEasCodes first returns a value of zero for the bad OID of ocStbHostEasCodes.0, followed by the right values for the right OIDs. A walk beginning further up at ocStbHostEasObjects does the same thing, but follows those with ocStbHostEasObjects.2.0 and ocStbHostEasObjects.3.0, both with values of zero.

Very odd behavior.
Posted: September 24, 2012 16:06 by smaynard
Please enter these types of discoveries as issues so they may be tracked properly and the work will get assigned accordingly.
Posted: September 24, 2012 20:14 by dominaf
We can do that for the bugs I've found with the MIBs, but what about my questions:

  • Is there a document that indicates which OC-STB-HOST-MIB objects the RI Stack itself will be implementing?
  • We need confirmation that the RI Stack will be implementing these MIBs (as listed above).


And regarding the ocStbHostSystemLogging MIBs:
  • what is "the system"?
  • Is this the RI Stack plus any apps?
  • Or does "the system" include the porting layer and platform all the way down to the lowest layer of drivers?

If it includes the platform, that would be imposing a lot on the platform. I suspect this is supposed to apply only to the RI Stack (and above), but am not certain, so please confirm that the RI Stack will implement these ocStbHostSystemLogging MIBs.

Replies: 3 - Last Post: September 24, 2012 20:14
by: dominaf
 
 
Close
loading
Please Confirm
Close