FTP of log files from IDSM

[jason.fletcher]

This message is for WARDWALK or anyone who can answer this. Because of the greyed out FTP option in CSPM I was given a workaround that involved manually editing the sapd.conf file. This was a little more than a year ago and I was able to get it working before. I have re-implemented this workaround again and am running into an issue. When I run a show errorfile sapd command on the sensor now I am getting the following:

01/09/2003 08:00:01UTC E Batch file error detected executing "c:/PROGRA~1/CISCOS~1/NETRAN~1/bin/sap/load_run.ftp.bat".

01/09/2003 08:00:01UTC E Error executing "c:/PROGRA~1/CISCOS~1/NETRAN~1/bin/sap/load_run.ftp.bat", returned 1.

If I remember correctly I got this before but it was fixed pretty simply....I can't remember what we changed though. WARDWALK, you still out there?

Jason Fletcher

[wardwalk]

Hi Jason, I'll check into it and see what I can find out.

Thanks, Ward.

[wardwalk]

Jason, did you try this workaround on an IDSM or an appliance sensor? (This workaround was intended for an IDSM because the workaround specified path names for sapd.conf that are only valid on an IDSM.)

Here's a link to a description of the workaround on the NetPro forum:

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40.ee85266/2#selected_message

[jason.fletcher]

Yep, using IDSM and that is the workaround that I implemented. I have double checked all the syntax to make sure I didn't fat finger anything and all looks exactly like the instructions say it should. Like I stated, I believe we ran into this about a year back and you had a solution....I believe it had something to do with the line containing the load_run.ftp.bat, but can't recall exactly.

Jason

[wardwalk]

I think the problem you're seeing now is not the same that you saw in Dec 2001. Rather, I think you're seeing a problem with connecting to the ftp server. (I just implemented the workaround and didn't encounter a problem.)

Please check the following:

-- username is correct

-- password is correct

-- ftp dest ip addr is correct

-- the switch configuration is correct for the IDSM. (Check that the command & control port/interface is in the proper VLAN). To verify connectivity, ping the ftp server from the IDSM CLI -- log into the IDSM, type "diag", type "ping ".

FYI. Here's a link to our original discussion on the NetPro forum. There, you can see that one of the problems we experienced then (Dec 2001) was that the load_run.ftp.bat file was incorrectly referenced (by me) as load_run.bat. I don't think that's the problem you're seeing now because the error message you reported above lists the filename correctly.

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.ee7672c

[jason.fletcher]

That must have been what I was thinking about. I will double check everything on the IDSM and make sure it is able to ping the FTP server. Thanks.

Jason

[jason.fletcher]

Darn, I just tried pinging the FTP server from the IDSM and it worked perfectly....I have made sure the account I am using is able to FTP to that server and write files to the directory also. So it doesn't seem to be a permission or a communication problem, any other ideas?

Jason

[wardwalk]

Via the IDSM CLI in the diagnostics sub-mode, what do you get when you execute "show errorfile sapx"?

The only thing that comes to mind is that the syntax of the ftp server's prompts are not understood by the IDSM ftp client. Have you used this ftp server before?

[jason.fletcher]

Alas, some info....taking a look at the sapx errorfile I found the following:

sapx:(log.200301040803,0,0)

get last error = 12014

Thu 01/09/2003

2:49a

FtpTransfer: log.200301040803

*Error: Bad target ID, user name, or password

12014 The request to connect and login to an FTP server could not be completed because the supplied password is incorrect.

This means that either the FTP server prompts aren't synching up with what the batch file is expecting or something because all the info is correct...I will investigate and see what is happening. I am going to try this with the FTP server we were initially using a year ago and see if that works.. Thanks for the help and I will post whatever I find so that it may help someone else in the future.

Jason

[jason.fletcher]

OK, I have checked and double-checked everything. All username and password information is correct because I can FTP to both FTP servers I am trying this on using that information. The FTP server we were initially using produces the same sapx error as in the above post, even though the FTP server configuration hasn't changed a bit and it worked just fine a year ago. Also, I implemented this on another of our IDSM's...also which worked fine a year ago....and it does the exact same thing. The IDSM's are currently running at 3.0(4)S20 if that helps at all. I can't recall what version they were at a year ago. I even reset them from the CatOS and still getting the same problem. Is it possible to view the contents of the batch file somewhere or to see if there is an old password or something that isn't being overwritten? I'm reaching for straws here because this should be working. Thanks for the help and any help you can continue to provide.

Jason Fletcher

[jason.fletcher]

I just completed updating CSPM to 2.3.3i S37 and the IDSM to 3.0(5)S35....still doesn't work.... According to the release notes for 3.0(5)S23 which I applied before the S35 sig update:

"Caveats Corrected in this Release

This defect has been fixed in this release: You cannot FTP log files off of the IDSM. (CSCdr78646)".

It also says we have the

"Ability to push its log files automatically to remote systems using FTP."

That's great, but the FTP option in CSPM is still greyed out and I can't find any doc on how to configure the FTP server to do this directly and there doesn't seem to be any new option in the config mode or anything. I have to get this working somehow as the CSPM database is way too unstable for my needs and the cvtnrlog utility that everyone seems to depend on so much constantly gives me headaches with Dr. Watson errors that require me to completely reinstall CSPM to fix. I can't even count the number of times I have had to restore the CSPM default database and lose all my events for that time frame. Something has changed with regards to this load_run.ftp.bat file and that is obvious. I have even had it try using an anonymous FTP account that doesn't care what the password is and it still gives me that password incorrect message in the sapx errorfile.

Jason

[wardwalk]

Hi Jason, sorry this isn't working for you. I haven't found where that DDTS issue you mentioned is referenced with the 3.0(5)S23, but it's not a new issue -- it was resolved some time ago. Further, I don't know of any issue regarding ftp'ing log files and I have been able to implement the workaround in our lab. So, I don't yet know why it's not working for you.

To ensure that all the IDSM files used for ftp'ing are proper, i.e. not corrupt, I'd like to replace them with known good scripts. Is there any way I can access your IDSM? Feel free to email me. wardwalk@cisco.com

[marcabal]

The DDTS mentioned was actually fixed back in the 3.0(1)S4 version (well over a year ago). The Release Notes were updated when 3.0(5)S23 was released, but the Tech Writer different differentiate which issues were fixed in 3.0(1), 3.0(2), 3.0(3), 3.0(4), or 3.0(5). So it looks like they were all fixed in the 3.0(5)S23 even though most were fixed well before that.

As for something else that may help:

If you have a network sniffer that can see the traffic between your IDSM and the Ftp Server, then attempt to sniff the connection. You will be able to see which username/password the IDSM is trying to use, and if the FTP Server is sending back an error.

Another thing to do would be to send a copy of your sapd.conf file directly to wardwalk@cisco.com. It is possible that you may have a small syntax error that is resulting in a bad reading of the password by sapd.