Windows: Troubleshooting S-TAP problems

You can use the S-TAP® Status monitor tab of the System View to begin investigating any problems. Sometimes you might need to use other tools, particularly if you are monitoring databases for which the inspection engines cannot be verified.

If an S-TAP is not connected to your Guardium® system
Check whether the IBM Security Guardium S-TAP service is running on the database server:

Check the IBM Security Guardium S-TAP service and see that it's running.

Make sure that sniffer is running on the server with the S-TAP service.
Check the communication between the sniffer and S-TAP.
For more information about possible errors, see Table 2.
How to identify the S-TAP version?
  • From the GUI, the S-TAP version number is displayed in Manage > System View > S-TAP Status Monitor
  • Alternatively, you can display the S-TAP version number from the command line of the database server.
Run debug from the command line to quickly identify configuration issues
Turn on debug from the GIM GUI or the command line. See debug levels in Protocol 7 Debug parameters.
Verify the connection between the database server and the Guardium system
  • Verify that you can ping the Guardium system at sqlguard_ip from the database server.
  • If the ping is successful, verify that you can telnet to the following ports on the Guardium system: 9500/9501 for S-TAP on Protocol 7, or 9800/9801 for S-TAP on Protocol 8.
If there is a firewall between the database server and the Guardium system
Verify that the following ports are open for traffic between these two systems: TCP port 9500 or TLS port 9501 for encrypted connections for S-TAP on Protocol 7, or TCP port 9800 or TLS port 9801 for encrypted connections for S-TAP on Protocol 8.
Verify that the sqlguard_ip parameter is set to the correct guardium hostname or the IP for the Guardium system that you are connecting to.
  1. Click Manage > Activity Monitoring > S-TAP Control to open S-TAP Control.
  2. Locate the S-TAP Host for the IP address that corresponds to your database server.
  3. Expand the Guardium Hosts subsection, and verify that the active Guardium Host is correctly configured.
  4. If necessary, click Modify to update the Guardium Hosts.
Where is the debug file located?
If the debuglevel > 0, then the log from the previous S-TAP session (if it exists) is saved as: %STAP_DIR%\Bin\StapBuffer\stap_%HOSTNAME%%YY-MM-DD%%HHMMDD%.old and the new log is created as: %STAP_DIR%\Bin\StapBuffer\stap_%HOSTNAME%%YY-MM-DD%%HHMMDD%.new.
In addition to this, start-up logs containing just messages related to S-TAP start-up are always generated in %STAP_DIR%\Logs: startup_%HOSTNAME%%YY-MM-DD%%HHMMDD%.old startup_%HOSTNAME%%YY-MM-DD%%HHMMDD%.new.
Severe spikes in traffic, and traffic getting dropped
This symptoms could be due to a buffer overflow. Check the debug log for a message indicating buffer overflow. Advanced users only: consider enabling the dynamic buffer feature. See dynamic_buffer_increase in Protocol 7 General parameters.
Verify that the S-TAP process is not repeatedly restarting
To verify the process, go to services and check the status of Guardium services.
Verify that S-TAP Approval is not turned on
If S-TAP Approval is turned on, any new S-TAP that connects to the Guardium system is refused.
  1. Click Manage > Activity Monitoring > S-TAP Certification to open S-TAP Certification.
  2. Look at the S-TAP Approval Needed checkbox . If this box is checked, new S-TAPs can connect to this Guardium system only after they are added to the list of approved S-TAPs.
  3. If S-TAP Approval is turned on, access the Approved Tap Clients report to view a list of approved S-TAPs. If the S-TAP that you are investigating is not on this list, return to the S-TAP Certification page, enter the IP address of the S-TAP in the Client Host field, and click Add.
For more information, see Allow (approve) S-TAP connection to Guardium (S-TAP certification).
S-TAP verification issues

The verification process attempts to log in to your database's STAP client with an erroneous user ID and password to verify that this attempt is recognized and communicated to the Guardium system. Your S-TAP might be configured in a way that prevents the inspection engine message from reaching the Guardium system from which the request was made.

These configuration details include:
  • Load balancing: if the S-TAP is configured to return responses to more than one Guardium system, the error message might be sent to a different Guardium system.
  • Failover: If secondary Guardium systems are configured for the S-TAP, the error message might be sent to a secondary Guardium system if the primary Guardium system is too busy.
  • db_ignore_response: if the S-TAP is configured to ignore all responses from the database, it does not send error messages to the Guardium system.
  • Client IP/mask: if any mask is defined that is not 0.0.0.0, it might prevent the error message from being sent.
  • Exclude IP/mask: if any mask is defined that is not 0.0.0.0, it might prevent the error message from being sent.
Related topics: