python-oracledb thin client artificial packet during login

[explorercpp]

When recording tcpdump using python-oracledb thin client, during connection process I can see an artificial network packet of size 1 with value 0x21.

`
Client -> Server
00000000 : 21 !

Client -> Server
00000000 : 00 00 00 0a 0c 20 00 00 02 00 ..... ....

Client <- Server
00000000 : 00 00 00 0a 0e 20 00 00 00 09 ..... ....
`

Can someone please explain what is this single byte packet?
I tried same python-oracledb library with instant client and such network packet is not present. Also tried sqlplus, was not present.
What could such packet sent from client to server mean? Does it indicate something special?
It was packet 18 during the login process.

Thank you in advance for any thoughts.

[anthony-tuininga]

I believe this is the OOB (out-of-band) detection that is available with certain servers. You can turn it off by passing the parameter disable_oob as the value True when creating the connection. SQL*Plus (and python-oracledb thick mode) depend on the equivalent value found in the sqlnet.ora configuration file.

[explorercpp]

I'm trying to understand if there will be different network load for different connection types from different clients and authentication methods, and sometimes artificial content appears which I never saw before, such as OOB packet. And your input is very helpful. Especially after I switched to new Mac with ARM processor and many things stopped working as expected for unknown reasons

[explorercpp]

Is there some existing reference of such OOB codes? I'm pretty sure that with variety of systems, value 0x21 is not the only one that might exist. Thank you again

[explorercpp]

changed it to

./connection.py:1043:            disable_oob: bool=True,
./connect_params.py:80:                 disable_oob: bool=True,

Still 0x21 packet appears in tcpdump. I didn't change the pool.py, but I'm not using pooling connections. Tried on 2 different laptops, seems same result.

Would you think it might be something else?

[anthony-tuininga]

If you are using thick mode you have to set the value in your sqlnet.ora file; otherwise it will have no effect. For thin mode you don't need to change any code, you can simply do this:

import oracledb
conn = oracledb.connect(user=USER, password=PASSWORD, dsn=DSN, disable_oob=True)

I confirmed with my own database that the 0x21 byte is indeed the "urgent" byte sent (it is the exclamation mark (!) symbol) as part of the test.

[explorercpp]

Indeed, code change did not affect it, but specifying it in the connection string did remove that packet. Seems there are other parameters to play with in thin mode, will explore them. Thank you

[explorercpp]

If I may may ask further questions about network packets.

I was looking at the connections, and I can see that the username that was used to login is places in this packet:

Above is example of login made by user scott.

But in some cases, I can see in this place value "1". And such user does not exist.

I was able to reproduce such case, when I tried something like "sqlplus "1"/as sysdba". But none of my applications are doing such connection.

If you have any idea what this value "1" means, will be very helpful.

[explorercpp]

Exactly, that's another way to reproduce this packet. But in my case, this user does not exist, and some connections already show such packet. Could it be some script, service, management or back up job that makes a local connection to Oracle with internal user "1"? That connection does not fail, even user does not exist.

[anthony-tuininga]

I've asked and will let you know if I get an answer. I don't know myself!

[explorercpp]

Sure, appreciate your time and help in passing the info to your colleagues!

[anthony-tuininga]

You're welcome. As for the answer: I am informed that there is no way for that to happen without someone explicitly doing it -- so you will need to find out from your end why that is happening!

[explorercpp]

Ok, I will try to narrow it down and identify specifically which connection and at what time creates such connection. Thank you!