Hi

Thanks, but as I said it worked fine in 4.0.5 and I checked the Transport settings twice. I can tell by sniffer that RME (or credential verification) is trying SSH but then fails.

rgds

Mats

This error indicates a problem with the data returned from the TCP connection to port 22. You should enable ArchiveMgmt Service debugging under RME > Admin > System Preferences > Loglevel Settings, run a new archive sync operation, then check the dcmaservice.log for errors.

Of course, I'm assuming that before you upgraded to RME 4.0.6, you applied the Common Services 3.0.6 update. If not, you will need to apply the CS 3.0.6 update, then re-apply the RME 4.0.6 update.

FYI, I tested this locally after upgrading to CS 3.0.6 and RME 4.0.6, and I am not seeing any problems with SSH.

Hi

Thanks for responding quickly.

Yes i have confirmed CS 3.0.6 is ok installed.

Attached output in dcmaservice log after enabling debug. From what I can tell it first says "SSH is running on /10.69.77.1" and then shortly after a FATAL "could not detect protocols running on the device". I have to admit it is not my best skill to read theese debugs, please have a look to see if you can pinpoint the problem.

Btw

I reinstalled RME 4.0.5 on the testserver and synched config on the same 10.69.77.1 router without problem.

rgds

Mats

Looks like your installation is bad, or you have re-applied some old patches after installing RME 4.0.6. The NMSROOT/MDC/tomcat/webapps/rme/WEB-INF/classes/com/cisco/nm/rmeng/util/rmedaa/RMEDeviceContext.class looks bad. The line numbers in your log do not line up with the actual code, but they do on my server.

You might try reinstalling the RME 4.0.6 update. The MD5 checksum for the file above should be:

4d04e1ad1e29a206899c0853857b2fb4 RMEDeviceContext.class

Hi

I reinstalled 4.0.6 on the testserver (Windows 2003, as well as Prod server) no additional patches on the testserver only CS and RME. sych failed again.

The RMEDeviceContext.class got a different checksum on my system, but is the same on both servers as well as timestamp and bytesize.

But the culprit must be RMEDeviceContext.class, as I did an "ugly" test on the testserver and swaped it to 4.0.5 version and restarted, archivesynch is ok after that.

Fileinfo:

ab9c8b46e27a87719d01f66b8343f9da 2007-11-15 11:33 22 009 RMEDeviceContext.class

any idea ?

rgds

mats

I have a strong feeling the Windows RME 4.0.6 is broken. I assume you're testing on Windows?

Yes, and the "live one" is w2003 also.

It seems like using version 4.0.5 file is a temporary workaround to this problem. I have not noticed any other probs with RME yet, been focusing on this...

pls let me know what happens.

brgds

mats

I have confirmed the Windows update is bad. If you download the Solaris update, extract it, you will find an RMEDeviceContext.class. That is a good version. Simply replace your version with that one, restart dmgtd, and you'll be fine.

Hi

I get the same error with the solaris one on both servers, I verified checksum on the solaris file and that is the same as yours.

I suppose i can use v 4.0.5 until a fix is available, to avoid reinstalling RME on the Prod server.

rgds

mats

I see the problem. Please open a TAC service request, and have your engineer contact me for the patch.

Hi

I will do that. Thanks a lot for pointing out the problem so fast.

brgds

Mats

Was a patch made available for this problem or was a bugID assigned to it?