Oracle connection fails with uncleanShutdown on non-TLS server

[wiscaksono]

What happened

Tried connecting to an Oracle database (port 1521, plain TCP, no TLS) and got this:

Failed to connect to <redacted>:1521/<redacted>: OracleSQLError(code: uncleanShutdown) - Some information has been reducted to prevent accidental leakage of sensitive data. For additional debugging details, use `String(reflecting: error)`.

The same server works fine from SQL Developer and DBeaver with identical credentials. So the database itself is reachable and accepting connections -- just not from TablePro.

What I think is going on

Based on oracle-nio issue lovetodream/oracle-nio#21, the underlying error is probably NIOSSL.NIOSSLError.uncleanShutdown. My Oracle server runs on standard port 1521 with plain TCP (no TLS/TCPS). It looks like the Oracle driver is trying to negotiate TLS, the server doesn't speak TLS, and it just drops the connection.

There's also a firewall between my machine and the server, but that shouldn't matter since other clients get through without issues.

What I expected

A successful connection, or at least a clearer error message (e.g. "TLS handshake failed, try disabling SSL" or something along those lines).

Environment

• macOS (Apple Silicon)
• TablePro: latest version from GitHub Releases
• Oracle server: port 1521, plain TCP, no TLS requirement

Suggestion

It would help to have either:

• An option in the connection form to disable TLS for Oracle connections
• Auto-detection of whether the server supports TLS before attempting the handshake

[datlechin]

Thanks for reporting. I investigated and TLS is not the cause. TablePro already connects via plain TCP by default.

The uncleanShutdown error means the server dropped the connection during the TNS handshake.

Common causes:

1. Oracle server older than 12c. oracle-nio only supports 12c and later.
2. Using SID instead of Service Name. TablePro currently only supports Service Name.

Could you share your Oracle server version and whether you connect via SID or Service Name?

[wiscaksono]

Thanks for looking into this.

Checked both:

• Oracle version is 12.1.0.2.0 (12c Enterprise Edition, 64-bit, running on Solaris)
• Connecting via Service Name, confirmed via SELECT VALUE FROM V$PARAMETER WHERE NAME = 'service_names'

So neither of those should be the problem. Connects fine from DBeaver with the same host, port, service name, and credentials.

Anything else I can check on my end?

[datlechin]

Thanks for checking. 12.1.0.2 with Service Name should work in theory.

This is most likely a protocol-level issue in oracle-nio (the Swift library TablePro uses). It implements the TNS wire protocol directly, unlike DBeaver which uses Oracle's official JDBC
driver. 12.1.0.2 is the earliest 12c patchset and there may be subtle protocol differences.

I'll investigate further and open an issue on the oracle-nio repo. Could you check the Oracle listener log to see if the connection attempt shows a rejection reason?

[wiscaksono]

Don't have access to the server or listener logs, that's all on the DBA team's side.

Can try stuff from the client side if needed. Otherwise I'll just wait for the oracle-nio investigation. Down to test a new build whenever.

[datlechin]

Filed upstream: lovetodream/oracle-nio#106

I confirmed Oracle 18c XE connects fine, so the issue is specific to 12.1.0.2. Waiting on the oracle-nio maintainer for input.