FWSM authentication error using RME

Answered Question
Feb 10th, 2009

During Config Archive, I'm encountering the following error when trying to connect using RME to a Cisco Catalyst 6513 FWSM.

"CM00139 Could not archive config, Cause: Action: Verify that device is managed and credentials are correct. Increase timeout value, if required."

I ran the credential verification using both the ssh protocol and the "SSH Enable Mode User Name and Password" check. It passes the protocol check, but fails with "Enable username credential missing." However, I do have the enable password set in device management/edit device credentials.



I have this problem too.
0 votes
Correct Answer by Joe Clarke about 7 years 8 months ago

So your problems with the FWSM fetch are now resolved?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Joe Clarke Tue, 02/10/2009 - 10:43

There is a problem entering enable mode. In order to fetch the config from an FWSM, RME must be able to enter enable mode, enter config mode, configure "no pager", then exit config mode. Can the credentials specified in DCR perform these steps? Try to perform those steps manually. what does the transaction look like?

Bruce Summers Tue, 02/10/2009 - 11:06

to answer the question about the credentials that are in DCR, yes...the account that i'm using is able to enter enable mode, config mode and then is able to make the change to "no pager"...

I'm not clear what you mean by "what does the transaction look like".


Joe Clarke Tue, 02/10/2009 - 11:18

From the LMS server, connect to the FWSM with SSH using the same credentials that are configured in DCR. Enter enable mode using the same enable password that is in DCR. Run the command "show pager". Then enter config mode, and configure "no pager". Then exit config mode. What does that transaction look like?

Bruce Summers Tue, 02/10/2009 - 11:23

login as:


Type help or '?' for a list of available commands.

FWSM> en

Password: ****

FWSM# sho pager

no pager


so, as you can see, from the LMS server, ssh to the FWSM is working...and works when you do the credentials check within RME...but, config arch is bombing on me...


Joe Clarke Tue, 02/10/2009 - 11:29

You missed a step. You need to go into configure mode, and type "no pager". Also, enable ArchiveMgmt Service debugging under RME > Admin > System Preferences > Application Loglevel Settings, perform another Sync Archive to this FWSM, and post the dcmaservice.log.

Bruce Summers Tue, 02/10/2009 - 12:43

sorry...i took from the show pager, that no pager was already set (from previously running the command). here is the output from the command:

fwsm> config t

fwsm(config)# no pager

fwsm(config)# exit

fwsm># sho pager

no pager

after setting debug mode, i ran the config arch again, and attached is the output fo the dcmaservice.log from that run...I didnt want to include it all (WAY too much)....

Joe Clarke Tue, 02/10/2009 - 18:35

The problem is in your use of privilege levels. RME is expecting enable level to be 15, but you are currently at privilege level 2. That said, you appear to be hitting a code path that should be impossible. What patches have you applied to LMS?

Bruce Summers Tue, 02/10/2009 - 18:49

"code path" not sure what you mean...I have applied no patches to LMS since installation. Im running LMS Portal 1.1.0, RME 4.2.0, CV 6.1.8, CM5.1.0, DFM 3.1.0

Joe Clarke Tue, 02/10/2009 - 18:53

Nevermind, I found the problem. I can provide a patch if you want to test it. You will need to open a TAC service request to get it.

Bruce Summers Tue, 02/10/2009 - 18:56

absolutely...I'll have to get approval before applying it, but give me the bug fix number and i'll vet it out thru my leadership and get the tac case submitted...is it an LMS issue or a firewall issue? that will point me to which way i need to submit the tac case...

thanks J

Joe Clarke Tue, 02/10/2009 - 19:28

I don't have a bug yet. I'll file the bug when I get confirmation that my fix is the right one. The problem is with the FWSM code in RME.

Joe Clarke Tue, 02/10/2009 - 19:43

Since you are the only one seeing the problem, and have the privilege level setup, yes.

Bruce Summers Tue, 02/10/2009 - 19:44

lol...roger...let me tell the boss...

if the privledge level were increased to 15, would we still be seeing this problem?

Bruce Summers Tue, 02/10/2009 - 20:24

roger...i'll get back with you directly...well, it will probably be in the a.m. Gotta confer with the boss...

Bruce Summers Wed, 02/11/2009 - 05:18

J, Also, when I started this thread, I said this is a 6513...My apologies, it is a CAT 6509...Hope that doesnt make a difference...


Bruce Summers Wed, 02/11/2009 - 14:52


I submitted the support request, but have gotten nothing back from those folks...

Shall we continue to wait, or can we proceed?

Joe Clarke Thu, 02/12/2009 - 10:50

Your engineer just contacted me, and I sent him the patch. Another customer has since received it, but I have not heard back on the results.

Bruce Summers Thu, 02/12/2009 - 14:02


I'm about to deploy the patch...I understand that what needs to be done is to drop the SharedDcmaSC.zip file into the following path:


No extraction has to be performed.

then restart the Daemon Manager.


Joe Clarke Thu, 02/12/2009 - 14:29

There is much more to it than that. Hopefully your engineer explained how to backup the original file and verify the MD5 checksum of the new file.

That said, the zip file does go into this directory, and it must not be extracted.

Bruce Summers Thu, 02/12/2009 - 14:35

Yes, I'm sorry...Yes, he said to backup the old file, also he sent a checksum MD5 number for verification and advised it must be RME 4.2

I've verified the MD5 checksum and have backed up the old file...

bout to drop and go

Joe Clarke Thu, 02/12/2009 - 14:37

The file must be backed up to SharedDcmaSC.zip.orig. The name is important. If the backup retains the .zip extension, then RME will load the old file, and override the patch.

Bruce Summers Thu, 02/12/2009 - 17:04


Deployed the patch...But, now RME is displaying error concerning no DB (error getting summary, no records found, etc..)

I've had this happen before, a bounce of the server cleared it, but of course thats extreme (and I've done it twice now)...

Joe Clarke Thu, 02/12/2009 - 17:32

This doesn't sound like a problem with the patch. It sounds more like a core daemon failed to start. Post the output of pdshow.

Bruce Summers Thu, 02/12/2009 - 18:10

I agree...it returned to normal...like i said, its done that to me before...Now, back to the "real" problem...deployed the patch, and when running the sync archive, get following error:

CM0056 Config fetch failed for Cause: CM0204 Could not create DeviceContext for 9 Cause: CM0206 Could not get the config transport implementation for Cause: CM0202 Could not access 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.

Of course, we know SNMP is indeed working...but, just for giggles, i did an SNMP walk...it worked...


Joe Clarke Thu, 02/12/2009 - 19:10

It sounds like there is a problem with the patch. Work with your engineer, and provide him the dcmaservice.log.

Bruce Summers Thu, 02/12/2009 - 19:24

done...not sure what his hours are...so, maybe tomorrow before you see anything...

thanks for the help...

Joe Clarke Fri, 02/13/2009 - 14:15

No. He sent me an email, but there were no logs. I asked him to get them.

Joe Clarke Fri, 02/13/2009 - 14:20

You reposted the patch to the SR, not the log. Send the dcmaservice.log to the SR.

Bruce Summers Fri, 02/13/2009 - 14:26

my apologies...i was out of the office this morning and asked a guy to send the zip file to him...i guess he grabbed the wrong -zip file...i zipped 3 logs for you to take a look at...wasnt sure which one you needed...i just sent them to Jose (SR).

Joe Clarke Fri, 02/13/2009 - 22:58

I looked through the logs, but it appears you have disabled ArchiveMgmt Service debugging, and last ran the FWSM sync before 2/12 19:02. You need to re-enable debugging, run a sync job, then capture the dcmaservice.log.

Bruce Summers Sat, 02/14/2009 - 05:51

Alright...Let me make sure I get this right this time.

You want me to drop the patch back in, turn on debugging, run the sync archive, then forward the dcmaservice.log...

I'll have it done directly...

Bruce Summers Sat, 02/14/2009 - 06:46

hope thats what you needed...i ran the sync arch with debugging on and the patch file you sent...forwarded the dcmaservice.log file to SR...

Bruce Summers Sat, 02/14/2009 - 15:18

I sent them to the SR this morning...not sure how they get "posted" for you to review, but shot them to em this morning...it was a 2mb file...pulled it after setting debug mode and running the sync arch with your bug fix in place...

Joe Clarke Sat, 02/14/2009 - 16:30

This could indicate patch corruption. What is the MD5 checksum of the patch as it is installed? Send your ConfigMgmtServer.log to the SR.

Bruce Summers Sat, 02/14/2009 - 18:14

MD5Checksum 683b50d4b3e1aed8bf868d33b993a25f

sent the confmgmtserver.log to SR and email-in...

Joe Clarke Sat, 02/14/2009 - 19:19

That's wrong. The correct checksum is fac5b624ba0755c08973e417425df4cb. The patch you resent to the SR has the correct checksum. Verify that you did not transfer this file using ASCII FTP transfers. Reinstall the SharedDcmaSC.zip which has the checksum of fac5b624ba0755c08973e417425df4cb, restart Daemon Manager, and repeat the tests.

Additionally, your ConfigMgmtServer.log did not make it to the SR.

Bruce Summers Sun, 02/15/2009 - 06:28


I messed up with that checksum...I had placed my setup back to the way it was originally, and when i ran the check sum checker, i ran it on the original sharedcmasc.zip file, not the one you sent...I ran the checker against your file, and it was correct. I set up using your patch, ran the config arch and it failed with the error I sent previously. I have forwarded the dcmaservice.log and the configmgmtservice.log to the SR CC: [email protected]. Not sure why that log didnt make it there previously...maybe our mail system stripped it...it was 5mb in size...i zipped these logs, should make it fine...

thanks for the continued assist...



This Discussion