DPY-4011 can be triggered by OOB messaging, not just needing NNE

[lunalucadou]

1. What is the link to the documentation section that needs improving?

https://python-oracledb.readthedocs.io/en/latest/user_guide/troubleshooting.html#dpy-4011

2. Describe the confusion

This error says the only cause is having NNE enabled (and thus requiring the thick client), but it can also occur under the following circumstances:

• The Oracle server supports TLS and NNE and is running in a Docker container or otherwise on a platform/behind a firewall that does not support out-of-band break messages
  • NNE support may not be required, all I know for sure is that my environment has both TLS and NNE support
• The server's sqlnet.ora file has DISABLE_OOB_AUTO=TRUE (so no OOB test is performed upon client connect which would return ORA-12637), but does not set DISABLE_OOB=on to disable OOB altogether (so it's still possible for clients to attempt it)
• The client connects and seems to work fine until it does something that causes an out-of-band message to be sent, resulting in the connection failing and DPY-4011 appearing in the logs

3. Suggest changes that would help

Mention that DPY-4011 can also occur, even for established TLS connections, if OOB messaging is attempted in an environment that lacks OOB support (such as Docker) but whose Oracle server has not fully disabled it.

The server-side solution would be to set DISABLE_OOB in the sqlnet.ora file, but setting the disable_oob=True connection option can also mitigate it on the client side.

[cjbj]

Thanks. I can see the error does get used in a couple of places.

You mention the solution: did this work for you?

[lunalucadou]

Yes, setting the disable_oob=True connection option does prevent this from occurring, and setting DISABLE_OOB=on in the sqlnet.ora file obviates the need for the connection option entirely (but if you cannot control the server, disable_oob=True is the best you can do).

[anthony-tuininga]

Hmm, if you are using TLS, OOB is disabled automatically and no attempt is made to use it. Yet you are saying that TLS is used and OOB is attempted? Can you clarify? I do see that the DISABLE_OOB_AUTO flag returned by the server is currently being ignored. I'll adjust the client to pay attention to that flag -- but I don't see (yet!) how that will affect your scenario!

[anthony-tuininga]

I have pushed a patch that tells the thin driver to pay attention to the DISABLE_OOB_AUTO flag when set on the server and have initated a build from which you can download pre-built development wheels once it completes. You can also build from source if you prefer. This won't have much effect on your situation, I believe, but it closes a (small) hole.

[lunalucadou]

Sorry for the late reply

Yet you are saying that TLS is used and OOB is attempted? Can you clarify?

I got an unrelated issue confused; we don't setup any certs in our container (since it's just for testing purposes), so the traffic which triggers this should be unencrypted (we don't configure any encryption-related settings in the sqlnet.ora file).

Technically I don't know for sure it's OOB that is causing it, but it's the only thing I can think of (and would seem to match what I've read about Docker networking), and disabling OOB at the connection level seems to have fixed it.

If there are any debug flags I should try to help narrow things down further, let me know.

[cjbj]

@lunalucadou it would be great if you could check the behavior with a development package from https://github.com/oracle/python-oracledb/actions/runs/11829776618/artifacts/2185970208 ?

[anthony-tuininga]

The patch has been included in version 2.5.1 which was just released.