Troubleshooting thin mode connection error DPY-4011

[blthree]

I have been unable to get a thin mode connection working to our 19C database, which always errors out with DPY-4011: the database or network closed the connection. However, I am able to connect to the same database with no issues when using thick mode. I have tried adding disable_oob=True to my connection which does not solve the problem. I believe this is not specific to my machine since my coworkers are also running into the same thing. Possibly there's some mismatch between settings on the server and what the thin-mode driver is expecting, but I have no clue where to start looking.

Does anyone have any suggestions on how to get the thin mode connection working? I would really prefer to use thin mode rather than including the entire client libraries package in my docker image.

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.16.0.0.0

oracledb.version = 1.3.0

with oracledb.connect(user=creds.username, 
                      password=creds.password,
                      host="", 
                      port=0000, 
                      service_name="", 
                      disable_oob=True) as conn:
    with conn.cursor() as cur:
        for result in cur.execute("SELECT 'connection succeeded' from dual"):
            print(result)

PYO_DEBUG_PACKETS

0000 : 00 4A 00 00 01 00 00 00 |.J......|
0008 : 01 3F 01 2C 00 01 20 00 |.?.,....|
0016 : FF FF 4F 98 00 00 00 01 |..O.....|
0024 : 01 06 00 4A 00 00 00 00 |...J....|
0032 : 84 84 00 00 00 00 00 00 |........|
0040 : 00 00 00 00 00 00 00 00 |........|
0048 : 00 00 00 00 00 00 00 00 |........|
0056 : 00 00 00 00 20 00 00 00 |........|
0064 : FF FF 00 00 00 00 00 00 |........|
0072 : 00 00                   |..      |

2023-04-17 15:20:05.057 [socket: 1016] Sending packet:
0000 : 01 10 00 00 06 00 00 00 |........|
0008 : 00 00 28 44 45 53 43 52 |..(DESCR|
0016 : 49 50 54 49 4F 4E 3D 28 |IPTION=(|
0024 : 41 44 44 52 45 53 53 3D |ADDRESS=|
0032 : 28 50 52 4F 54 4F 43 4F |(PROTOCO|
0040 : 4C 3D 74 63 70 29 28 48 |L=tcp)(H|
0048 : 4F 53 54 3D 64 77 68 63 |OST=    |
0056 : 00 00 00 00 00 00 00 00 |        |
0064 : 00 00 00 00 00 00 00 00 |        |
0072 : 00 00 00 00 00 29 28 50 |     )(P|
0080 : 4F 52 54 3D 00 00 00 00 |ORT=    |
0088 : 29 29 28 43 4F 4E 4E 45 |))(CONNE|
0096 : 43 54 5F 44 41 54 41 3D |CT_DATA=|
0104 : 28 53 45 52 56 49 43 45 |(SERVICE|
0112 : 5F 4E 41 4D 45 3D 00 00 |_NAME=  |
0120 : 00 00 00 00 00 00 00 00 |        |
0128 : 00 00 00 00 00 00 00 00 |        |
0136 : 00 00 00 00 00 00 00 00 |        |
0144 : 29 28 43 49 44 3D 28 50 |)(CID=(P|
0152 : 52 4F 47 52 41 4D 3D 43 |ROGRAM=C|
0160 : 3A 5C 55 73 65 72 73 5C |:\Users\|
0168 : 00 00 00 00 00 00 00 00 |        |
0176 : 00 00 00 00 00 00 00 00 |   \scoo|
0184 : 70 5C 61 70 70 73 5C 6D |p\apps\m|
0192 : 69 6E 69 63 6F 6E 64 61 |iniconda|
0200 : 33 5C 63 75 72 72 65 6E |3\curren|
0208 : 74 5C 65 6E 76 73 5C 61 |t\envs\a|
0216 : 66 33 39 5F 65 6E 76 5C |f39_env\|
0224 : 70 79 74 68 6F 6E 2E 65 |python.e|
0232 : 78 65 29 28 48 4F 53 54 |xe)(HOST|
0240 : 3D 00 00 00 00 00 00 00 |=       |
0248 : 53 33 29 28 55 53 45 52 |  )(USER|
0256 : 3D 00 00 00 00 00 00 00 |=       |
0264 : 00 00 00 32 29 29 29 29 |    ))))|

2023-04-17 15:20:05.104 [socket: 1016] Receiving packet:
0000 : 00 08 00 00 0B 00 00 00 |........|

2023-04-17 15:20:05.105 [socket: 1016] Sending packet:
0000 : 00 4A 00 00 01 00 00 00 |.J......|
0008 : 01 3F 01 2C 00 01 20 00 |.?.,....|
0016 : FF FF 4F 98 00 00 00 01 |..O.....|
0024 : 01 06 00 4A 00 00 00 00 |...J....|
0032 : 84 84 00 00 00 00 00 00 |........|
0040 : 00 00 00 00 00 00 00 00 |........|
0048 : 00 00 00 00 00 00 00 00 |........|
0056 : 00 00 00 00 20 00 00 00 |........|
0064 : FF FF 00 00 00 00 00 00 |........|
0072 : 00 00                   |..      |

2023-04-17 15:20:05.105 [socket: 1016] Sending packet:
0000 : 01 10 00 00 06 00 00 00 |........|
0008 : 00 00 28 44 45 53 43 52 |..(DESCR|
0016 : 49 50 54 49 4F 4E 3D 28 |IPTION=(|
0024 : 41 44 44 52 45 53 53 3D |ADDRESS=|
0032 : 28 50 52 4F 54 4F 43 4F |(PROTOCO|
0040 : 4C 3D 74 63 70 29 28 48 |L=tcp)(H|
0048 : 4F 53 54 3D 64 77 68 63 |OST=    |
0056 : 00 00 00 00 00 00 00 00 |        |
0064 : 00 00 00 00 00 00 00 00 |        |
0072 : 65 2E 65 64 75 29 28 50 |     )(P|
0080 : 4F 52 54 3D 31 36 32 34 |ORT=    |
0088 : 29 29 28 43 4F 4E 4E 45 |))(CONNE|
0096 : 43 54 5F 44 41 54 41 3D |CT_DATA=|
0104 : 28 53 45 52 56 49 43 45 |(SERVICE|
0112 : 5F 4E 41 4D 45 3D 64 77 |_NAME=  |
0120 : 00 00 00 00 00 00 00 00 |        |
0128 : 00 00 00 00 00 00 00 00 |        |
0136 : 00 00 00 00 00 00 00 00 |        |
0144 : 29 28 43 49 44 3D 28 50 |)(CID=(P|
0152 : 52 4F 47 52 41 4D 3D 43 |ROGRAM=C|
0160 : 3A 5C 55 73 65 72 73 5C |:\Users\|
0168 : 00 00 00 00 00 00 00 00 |        |
0176 : 00 00 00 5C 73 63 6F 6F |   \scoo|
0184 : 70 5C 61 70 70 73 5C 6D |p\apps\m|
0192 : 69 6E 69 63 6F 6E 64 61 |iniconda|
0200 : 33 5C 63 75 72 72 65 6E |3\curren|
0208 : 74 5C 65 6E 76 73 5C 61 |t\envs\a|
0216 : 66 33 39 5F 65 6E 76 5C |f39_env\|
0224 : 70 79 74 68 6F 6E 2E 65 |python.e|
0232 : 78 65 29 28 48 4F 53 54 |xe)(HOST|
0240 : 3D 00 00 00 00 00 00 00 |=       |
0248 : 00 00 29 28 55 53 45 52 |  )(USER|
0256 : 3D 00 00 00 00 00 00 00 |=       |
0264 : 00 00 00 00 29 29 29 29 |    ))))|

2023-04-17 15:20:05.140 [socket: 1016] Receiving packet:
0000 : 00 2D 00 00 02 00 00 00 |.-......|
0008 : 01 3E 00 01 00 00 00 00 |.>......|
0016 : 01 00 00 00 00 2D D5 00 |.....-..|
0024 : 00 00 00 00 00 00 00 00 |........|
0032 : 00 00 20 00 00 00 FF FF |........|
0040 : 00 00 00 00 00          |.....   |

2023-04-17 15:20:05.140 [socket: 1016] Sending packet:
0000 : 00 00 00 1D 06 00 00 00 |........|
0008 : 00 00 01 06 00 70 79 74 |.....pyt|
0016 : 68 6F 6E 2D 6F 72 61 63 |hon-orac|
0024 : 6C 65 64 62 00          |ledb.   |```

[cjbj]

Does the DB have native network encryption enabled? Eg. a line like SQLNET.ENCRYPTION_SERVER = required in the DB sqlnet.ora file? You could check the same from a (thick!) client by querying select network_service_banner from v$session_connect_info and see if there is some mention of encryption.

[blthree]

Nothing like that in my sqlnet.ora, but I do see
AES256 Encryption service adapter for Linux: Version 19.0.1.0.0 - Production using the v$session_connect_info query. Here is the full output:

('TCP/IP NT Protocol Adapter for Linux: Version 19.0.0.0.0 - Production',)
('Encryption service for Linux: Version 19.0.1.0.0 - Production',)
('SHA1 Crypto-checksumming service adapter for Linux: Version 19.0.1.0.0 - Production',)
('AES256 Encryption service adapter for Linux: Version 19.0.1.0.0 - Production',)
('Crypto-checksumming service for Linux: Version 19.0.1.0.0 - Production',)
(None,)
('SHA512 Crypto-checksumming service adapter for Linux: Version 19.0.1.0.0 - Production',)
('Oracle Bequeath NT Protocol Adapter for Linux: Version 19.0.0.0.0 - Production',)
('Authentication service for Linux: Version 19.0.1.0.0 - Production',)

[anthony-tuininga]

That suggests that NNE (native network encryption) is indeed setup (note: in the database sqlnet.ora, not the client sqlnet.ora) and this is not supported in thin mode. The suggestion is to move to TCPS (TLS) instead as this is supported in thin mode and uses standards widely supported in the industry. It is unlikely that NNE will ever be supported in thin mode for a number of reasons.

[blthree]

Thanks @anthony-tuininga and @cjbj, you have been really helpful! I doubt I would have figured that out myself. Looks like we will need to switch to thick mode for the time being and talk to our DBAs to see if there are any plans to move to TCPS.