Network Management

Trying to backup network devices using IMC/TFTP.  IMC Ent. version 7.1 (E0303P10).

IDMA shows TFTPServer started and confirmed with "netstat" for UDP port 69.

No other TFTP server processes running.

All attempts to initiate TFTP backup of any resources via IMC results in "TFTP Server Not Started"

Contents of imccfgbakdm.2016-09-21 file show no TFTP activity, even after several IMC-initiated backup attempts:

2016-09-21 01:30:00.375 [WARNING (0)] [THREAD(21584)] [CQvDBReaderADP::~CQvDBReaderADP] Cancel current SQL when data have not be fetched out.
2016-09-21 01:30:02.017 [INFO (0)] [THREAD(21584)] [CBakCfgFileMgrTask::deleteExpiredBckupHistory] No expired backup history need to delete.

I am able to initiate TFTP backups directly from network device to the IMC server, and \server\conf\log\tftpserver.2016-09-21 confirms successful transfer as follows:

2016-09-21 18:07:00.587 [INFO (0)] [THREAD(21388)] [TFTP::handleWRQ]  Begin to transfer file: gscb4208h2117-cfg.txt from: 10.64.255.242 to tftpserver
2016-09-21 18:07:02.458 [INFO (0)] [THREAD(27228)] [TFTP::handleData()] Finished to transfer file: gscb4208h2117-cfg.txt
2016-09-21 18:07:02.458 [INFO (0)] [THREAD(27228)] [TFTP::closeSocket] closed socket and remove_handler!

I used Wireshark during both IMC-initiated backup attempts and TFTP backups initiated directly from network devices to IMC server. The traces show NO TFTP activity for IMC-initiated backups, but otherwise successul TFTP transfers for device-initiated transfers.

I am at a loss as to what else to attempt or investigate. IMC appears confused as to the status of the TFTP Service. BTW, I have stopped and restarted the TFTP service on IMC with no change in results.

HELP - please!

Hello,

I know that it is avoiding the problem rather than trying to fix it - but what about switching to a secure protocol as that will change the client-server relationship such that the iMC box becomes the client and the switch effectively becomes the sftp "server".

You don't really want to be running TFTP in this day and age anyway do you?

Sorry I can't be of more help

Thanks

Ian

Ian, thanks for the reply, but SSH is not currently used in this environment, though I may attempt to test.

Okay, I continue to investigate and I found something in the iMC Server Info drop-down menu item. It is showing that tftpserver.exe status = Failed to bind process to port "69".

Note that netstat and task manager still show this process ID bound to port 69, and process = tftpserver.exe.

Anyone?!?!?

Still, TFTP should work, and I need someone with some more IMC internals to help me figure figure out why this is not working. I modiifed the tdtpserver.cfg file and changed the parameters std_out = yes, and log=yes in support of debugging, but I cannnot find where this data might be written. Anyone know?

The tftpserver-date.txt log file shows:

2016-09-22 19:11:32.474 [INFO (0)] [THREAD(40520)] [qvdm::QvGetLogFileSize] get file size from qvdm.conf: 50
2016-09-22 19:11:32.474 [INFO (0)] [THREAD(40520)] [main()] begin main()
2016-09-22 19:11:32.475 [INFO (0)] [THREAD(40520)] [main()] File :C:\Program Files\iMC\server\bin\..\..\server\bin\imciccdm.exe exist.
2016-09-22 19:11:32.554 [INFO (0)] [THREAD(40520)] [CQvApplication::start] call globalInit().
2016-09-22 19:11:32.554 [INFO (0)] [THREAD(40520)] [CQvApplication::globalInit] CImfAppMgr::instance() begin.
2016-09-22 19:11:32.555 [INFO (0)] [THREAD(40520)] [CQvApplication::globalInit] initAppMgr begin.
2016-09-22 19:11:32.592 [INFO (0)] [THREAD(40520)] [CQvApplication::globalInit] QvGetResPath begin.
2016-09-22 19:11:32.592 [INFO (0)] [THREAD(40520)] [CQvApplication::globalInit] initResMgr begin.
2016-09-22 19:11:32.599 [WARNING (0)] [THREAD(40520)] [CQvApplication::globalInit] imf::addResFile() error, and resource file is: C:\Program Files\iMC\server\bin\..\..\server\locale\C\res\tftpserver.res
2016-09-22 19:11:32.599 [INFO (0)] [THREAD(40520)] [CQvApplication::globalInit] CQvSnmpEnv::poInstance.
2016-09-22 19:11:32.601 [INFO (0)] [THREAD(40520)] [CQvApplication::globalInit] CSysGlobalVar::instance().
2016-09-22 19:11:32.607 [INFO (0)] [THREAD(40520)] [CQvApplication::globalInit] CQvSysTaskMgr::addTaskMgr.
2016-09-22 19:11:32.609 [INFO (0)] [THREAD(40520)] [qvdm::setLogLevelFromDB] success, ProcID is 65, log level is -1
2016-09-22 19:11:32.609 [INFO (0)] [THREAD(40520)] [CQvApplication::globalInit] finished.
2016-09-22 19:11:32.609 [INFO (0)] [THREAD(40520)] [CQvApplication::start] call init().
2016-09-22 19:11:32.610 [INFO (0)] [THREAD(40520)] [CBaseCfgfileMgr::init()] Base cfgfile: autocfg_startup.cfg
2016-09-22 19:11:32.610 [INFO (0)] [THREAD(25660)] [CTFTPServiceAgent::svc] running ...
2016-09-22 19:11:32.612 [INFO (0)] [THREAD(40520)]
=====================[CQvTftpApp::init()] TFTP Server is start successful==================

2016-09-22 19:11:32.612 [INFO (0)] [THREAD(40520)] [CQvApplication::start] call run().
2016-09-22 19:11:32.616 [INFO (0)] [THREAD(25660)] [CTFTPServiceAgent::svc] running reactor event loop ...
2016-09-22 19:11:32.616 [INFO (0)] [THREAD(34040)] [TFTPReactor::svc] Running the event loop
2016-09-22 19:11:32.617 [INFO (0)] [THREAD(11256)] [TFTPReactor::svc] Running the event loop

Compared to a properly operating IMC system, this information appears similar, so no insight here.

Okay, I figured it out........

First, this is a remote site miles from me. Seems the local team there had created a new IMC server (VM) and left the old server up with IMC running.

Although I was RDP'd into the new IMC server, the favorite shortcut web link on the browser was connecting to the old IMC server GUI and it was the one with all of the problems. So while I was using the local server's Inlelligent Deployment Monitoring Agent, all IMC web interface data was reflecting the old server's information.

Wow, 2 days of confusion, but I learned a lot about IMC, TFTP, and more......

Solution = delete/update the web browser link to open the new IMC server GUI.......and shut down IMC on the old server!!!

---

@rgelotti wrote:

but SSH is not currently used in this environment

 

---

Because you stepped through some weird timewarp, and you're stuck in the 90s?