On 20-May-2014 13:49 -0500, Keith McCully wrote:
I was looking for a log of FTP traffic connecting to an IBM i V6R1
box, specifically to check for errors.

There is an exit-point that enables an exit-program for FTP; both server and client. The following request will list some names that can be researched: WRKREGINF QIBM_QT*

There are 3rd party applications that exist specifically for logging and securing the FTP [server] on IBM i.

Infocenter recommends checking the spooled joblogs for the FTP server
jobs named QTFTPnnnnn where nnnnn is the job number of the fTP server
job submitting to the FTP server.

And the link to that doc? Presumably the following [with a horribly deceptive implication "monitoring", without the important clarifying term "attended"]?:
IBM i 7.1 Information Center -> Networking -> TCP/IP applications, protocols, and services -> FTP -> Securing FTP on i5/OS
_Monitoring incoming File Transfer Protocol users_
"By logging and reviewing File Transfer Protocol (FTP) usage, you can monitor activity and check for outside attacks.

Yet that doc link clarifies almost nothing about "logging" even while alluding to such. Visiting the parent topic, and then visiting the sibling topics would be way more helpful with regard to how one might effect logging; notably:
_Managing access using File Transfer Protocol exit programs_
You can provide additional security by adding FTP exit programs to the File Transfer Protocol (FTP) server and client exit points so that you can further restrict FTP access to your system.

WRKACTJOB JOB(QTFTP*) lists 6 QTFTP jobs running in subsystem

However, each of the 6 jobs is creating a new SPLF every minute or so
but, within a job, these logs are not wrapped but all start from the
beginning of the job plus an incremental update since the previous
log got created!

Hopefully only producing a new joblog upon servicing a new connection\session, or completing the last.?

Also, each joglog splf is several hundred pages with each successive
log larger due to the increments.

The /increments/ are each one more TCP12F5, or something else? Can an example of a spooled joblog be provided from a job used only twice or three times, and a copy of the previous, to present a /picture/ of what is the described successive increment?

Each joblog, for all server jobs, contains just one message: TCP12F5:
“FTP server unable to determine system name” repeated countless

Reference #: N1013085
_TCP12F5 Logged in the QTFTPxxxxx FTP Server Joblog_
"Technote (troubleshooting)


FTP server continues to log message TCP12F5 even when the host name and fully qualified name for the system are already defined in the TCP/IP host table.

Resolving the problem

TCP12F5 FTP server unable to determine system name will be logged in the FTP server joblog when a FTP connect is made to a local interface that is not defined in the TCP/IP host table. If multiple TCP/IP interfaces are defined for your System i, ensure the FTP connection to the System i is either made to an IP that is defined in the TCP/IP host table, or issue the ADDTCPHTE command to add that IP in the TCP/IP host table.

Historical Number: 518644205"

Additionally I tried some FTP connection tests to the server; the
connections worked okay but there was no reference to the connection
in the logs.

What logs? DSPLOG QHST? The Audit log?

With an FTP server login exit-program, whatever /logging/ is desirable for that phase can be implemented; e.g. SNDMSG TOMSGQ(QHST)

FTP and FTPS connections work fine on this server but what config
change is required to stop message TCP12F5

The search <https://www.google.com/search?q=TCP12F5+site%3Aarchive.midrange.com> yielded a few discussions; notably, one with "Subject: FTP problem":

and instead see the actual connection logs?

Only the messages logged to the joblog [not those only visible in the client session] of the currently active FTP session will be visible via DSPJOBLOG [or WRKJOB OPTION(*JOBLOG)]. When the job is reused, the joblog is cleared [apparently only of messages across a range not including the prior error msg TCP12F5].

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page