Applications that implement SSL or TLS can control whether non-encrypted application data is included in diagnostic traces. Lower layers have access to only encrypted data. When using AT-TLS, the TCP, PFS, and SOCKAPI layers have access to non-encrypted data. The AT-TLS default is to suppress this data in CTRACE records generated by these layers to protect the application’s users. If you need to see this data in these records to diagnose a problem, you can set CtraceClearText ON.
AT-TLS writes trace messages to syslogd. The AT-TLS default behavior is to write syslogd messages to the daemon facility. Other TCP/IP functions, such as the SNMP TCP/IP subagent, also specify the daemon facility name when writing records to syslogd. The job name and syslog facility name are the same. Filters cannot be used to direct the records to different output files. If you want AT-TLS records to go to a different output file, you can change the syslog facility name in the TTLSGroupAction statement to direct the messages from that group to the Auth facility instead. You can then set up filtering based on the job name and facility in the syslogd configuration file to direct AT-TLS records to a different output file.
The Trace value is interpreted by AT-TLS as a bit map. Each of the options is assigned a value that is a power of 2. You should add together the values of each option that you want to activate.
The default Trace value is 2, which provides error messages to syslogd. While you are deploying a new policy, you might find it beneficial to specify a Trace value of 6 or 7. This provides connection info messages, in addition to error messages in syslogd. The info messages provide positive feedback that connections are mapping to the intended policy.
Trace options event (8), flow (16), and data (32) are intended primarily for diagnosing problems. Trace values larger than 7 can cause a large number of trace records to be dropped instead of being sent to syslogd.