LMS 3.1 Problem adding WISM module to CiscoWorks

[chris.mcgarrah]

I'm having a problem adding WISM modules to CiscoWorks. Here is the output from the failed archive management job:

*** Device Details for durhq1-cra-wr01 ***

Protocol ==> Unknown / Not Applicable

Selected Protocols with order ==> SSH,Telnet,TFTP

Execution Result:

CM0056 Config fetch failed for durhq1-cra-wr01 Cause: CM0204 Could not create DeviceContext for 4 Cause: CM0206 Could not get the config transport implementation for 10.72.1.20 Cause: CM0202 Could not access 10.72.1.20 via SNMP. Action: Check the Read Community string Action: Check if required device packages are available in RME. Action: Check if protocol is supported by device and required device package is installed.

I'm attaching sysinfo from WISM module. Thanks

[Joe Clarke]

You do not have the required package for this module. To manage the WiSM, you need Cat6000IOS package version 8.0. Go to Common Services > Software Center > Device Update, and download and install all available updates for Common Services and RME.

[chris.mcgarrah]

I've updated the device package, but am now getting a different message:

*** Device Details for durhq1-cra-wr01 ***

Protocol ==> Unknown / Not Applicable

Selected Protocols with order ==> SSH,Telnet,TFTP

Execution Result:

Unable to get results of job execution for device. Retry the job after increasing the job result wait time using the option:Resource Manager Essentials -> Admin -> Config Mgmt -> Archive Mgmt ->Fetch Settings

I increased the time as suggested in the message from 2 minutes to 3 minutes but still get the message.

The archive management job also took over 4 hours to fail.

Not sure if this is relevant but when I manually SSH into the WISM module, I first get a Login: prompt (no password) and then a User: prompt and then a Password: prompt.

[Joe Clarke]

Now you're seeing CSCsv95235. A patch for RME 4.2 is available by contacting TAC. However, the recommended fix is to upgrade to LMS 3.2.

[chris.mcgarrah]

I have your xdi.jar with checksum 326986eef9c9e46801a8623014ddd07e installed for another bug I ran into. I see in another posting that you rolled the fix for bug CSCsv95235 into that xdi.jar.

Could I be running into something else?

[Joe Clarke]

Yes, this could be another timing issue for which there is no fix in LMS 3.1. The issue is fixed in 3.2 by the addition of a cmdsvc.properties file in which one can change the various timeouts. If this is on Solaris, you could also be seeing a Solaris bug which causes hangs in processes using pkcs11 encryption. TAC can confirm the actual problem by getting a full thread dump when the archive operation has locked up.