Skip to main content

Diagnostics in RI

6 replies [Last post]
sus_tri
Offline
Joined: 2008-12-15
Points: 0

Is our understanding correct that not RI Stack, but the platform is responsible for implementation of the Cable Labs defined on-screen diagnostics?
-For the data that come from MIBs implemented within RI, the platform shall simply indicate that the values are not available while those MIBs are not responding (i.e. until such time as those MIBs are initialized by RI).?

-Also do you have a list or a document you can point us to, that will indicate what OCAP Mibs RI has implemented

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
smaynard
Offline
Joined: 2009-01-27
Points: 0

It's not clear what you mean by on-screen diagnostics from a Cable Labs perspective. Typically, on-screen diagnostics are generated and maintained by the platform vendor.

The PC-platform code that comes with the RI implements very few of the hundreds of MIB ObjIds that the platform host should implement. The Makefile in $PLATFORMROOT/src/snmp can be consulted for up-to-date supported MIBs. At the time of this response, the following have some minimal support:

MIB_OBJS = \
mib \
hrDeviceTable \
hrProcessorTable \
hrStorage \
hrStorageTable \
hrSWRunPerfTable \
hrSWRunTable \
ifTable \
ocHnNetConfig \
ocStbCardInfo \
ocStbHostAnalogVideoTable \
ocStbHostAVInterfaceTable \
ocStbHostCCMMI \
ocStbHostComponentVideoTable \
ocStbHostDeviceSoftwareBase \
ocStbHostDVIHDMIAvailableVideoFormatTable \
ocStbHostDVIHDMITable \
ocStbHostEasObjects \
ocStbHostFirmwareDownloadStatus \
ocStbHostHWIdentifiers \
ocStbHostIEEE1394ConnectedDevicesTable \
ocStbHostIEEE1394Table \
ocStbHostInBandTunerTable \
ocStbHostInfo \
ocStbHostMemoryInfo \
ocStbHostMpeg2ContentTable \
ocStbHostMpeg4ContentTable \
ocStbHostPower \
ocStbHostProgramStatusTable \
ocStbHostQpskObjects \
ocStbHostRebootInfo \
ocStbHostRFChannelOutTable \
ocStbHostSecuritySubSystem \
ocStbHostSPDIfTable \
ocStbHostSystemDriveInfoTable \
ocStbHostSystemHomeNetworkTable \
ocStbHostSystemLogging \
ocStbHostSystemLoggingEventEntry \
ocStbHostSystemLoggingEventTable \
ocStbHostSystemMemoryReportTable \
ocStbHostSystemTempTable \
ocStbHostUserSettings \
ocStbHostVc1ContentTable \
sysORTable \
system

sus_tri
Offline
Joined: 2008-12-15
Points: 0

Thanks for your response.
Based upon our examination of the RI code, it looks like the following MIBs have been implemented within the RI, with bugs as noted, and below those are MIBs we believe that the RI needs to implement, but hasn't:

IMPLEMENTED in RI:

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.

ocStbEasMessageStateCode " Also implemented in the platform, meaning there is a conflict! We need to resolve where this should be implemented! Is there a reason RI feels the platform shouldn't implement this?
ocStbEasMessageCountyCode " Also implemented in the platform, meaning there is a conflict! We need to resolve where this should be implemented! Is there a reason RI feels the platform shouldn't implement this?
ocStbEasMessageCountySubdivisionCode " Also implemented in the platform, meaning there is a conflict! We need to resolve where this should be implemented! Is there a reason RI feels the platform shouldn't implement this?

MISSING from RI:

We would expect the following MIBs to also be implemented within the RI. Where there is a disagreement, can you explain why the data that the MIBs report are considered as owned by the platform?

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)

This leaves one MIB branch " the ocStbHostSystemLogging branch " that we are unclear as to where it should be implemented. This branch includes the following MIBs:
ocStbHostSystemLoggingControlReset
ocStbHostSystemLoggingSize
ocStbHostSystemLoggingLevelControl
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 (specifically, the Java portion, or maybe MPE and up) plus any apps? Or does "the system" include the 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. We suspect this is supposed to apply only to the RI Stack, but am not certain, so what layer needs to implement these MIBs?

smaynard
Offline
Joined: 2009-01-27
Points: 0

The OCAPR-RI PC platform was never meant to completely implement all that a true host platform must. It should implement an example of each of the features for reference.

You can add your discoveries to an enhancement issue and the time required to satisfy your request will be estimated and potentially be added to the work queue. There was a request some years back for the code you mention to be contributed. Two companies made large contributions in this area. Maybe your company would like to contribute as well?

Best Regards,
Steve

dominaf
Offline
Joined: 2012-09-20
Points: 0

Please allow me to put this into context. Our question (I work with Susmita) 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 in Susmita's post above).

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.

dominaf
Offline
Joined: 2012-09-20
Points: 0

Hi. Susmita was posting for me -- we work together -- but I'll eliminate the middleman by posting directly...

Our questions had nothing to do with the PC platform -- nothing to do with any specific platform, though we our writing the porting layer to our (Cisco) platforms. The MIB questions we are asking are referring to RI Stack itself.

The RI stack implements some MIBs (with bugs as noted in Susmita's previous post). There are also other OC-STB-HOST MIBs that are required by the OCAP spec, and that must return data that we believe is known only to the RI stack (not our platform porting layer). We need confirmation that the RI 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)

(Ignore the portion of Susmita's question about the ocStbEasMessage(State/County/Subdivision)Code MIBs. Those must from from the RI, and the RI code is already implementing them.)

ALSO, I am very unclear about the ocStbHostSystemLogging branch's purpose and thus unclear as to which layer needs to implement it. This branch includes the following MIBs:

  • ocStbHostSystemLoggingControlReset
  • ocStbHostSystemLoggingSize
  • ocStbHostSystemLoggingLevelControl
  • 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 <strong>the system</strong>
   -- 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 (specifically, the Java portion, or maybe MPE and up) plus any apps? Or does "the system" include the 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, but am not certain, so what layer needs to implement these MIBs?

smaynard
Offline
Joined: 2009-01-27
Points: 0

We have received all of your requests on both forums. We will discuss internally to determine the next steps. This should be entered as a feature request in an issue so it is tracked properly. Your request for clarification of the logging table will be forwarded to the spec team...