Skip to Main Content
  • Questions

  • ORA-12569: TNS:Packet Checksum Failure - How is this error even possible?

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Leandro.

Asked: January 22, 2024 - 2:49 pm UTC

Last updated: February 28, 2024 - 6:34 am UTC

Version: 19.16.0

Viewed 1000+ times

You Asked

Hello masters. Here I am again with another mystery from our favorite DBMS (no, that was not sarcasm, I do love Oracle in fact).

So, in my company we are facing the referred error, ORA-12569: TNS:Packet Checksum Failure While Trying To Connect Through Client. The message itself is kind of self explanatory, apparently a tcp package failed the checksum. There's a document for this error specifically, Doc ID 257793.1, which states it plain clear:

There is a mismatch in the header of the tcp packet between the client and the server.
In other words, the "Packet Header" leaves the DB server but by the time the client gets the packet on the other end, the header has changed (or visa versa).


The doc even gives an exemple of captured packages with Net tracing from both the server and the client, demonstrating a corruption on the tcp header.

And the proposed solution does not involve the database/client itself, but rather analysis on the network:

Check what components may be interfering with TCP Packet information, such as Firewalls or other NIPS (Network Intrusion Prevention Systems).
Contact the Systems / Network Administrators for this and have them fix the underlying tcp/ip packets problem or disable any "SQL altering" programs / settings.


Well, all this make kind of make sense to me. But then after thinking a little about the situation, something struck me: the oracle client (the application on the higher level) should not receive any bad tcp packages because they are checked by network interface (the transmission itself on the lower level).

I mean, the Transmission Control Protocol has it own checksum at the transport layer; before seding the datagram to the application layer, the transport layer validates the package and in case of errors it requests the client to resend that specific bad datagram. How is it possible that corrputed tcp packets arrive to the aplication level?

I'm not a network specialist, but this situation (and the Oracle error), is really puzzling me. So riddle me this, masters: how come the oracle client detects a bad tcp package when the network level doesn't???

and Chris said...

We're hardly networking experts ourselves! You're probably better off asking on a networking forum if you want specific details.

That said, a bit of searching reveals that the TCP checksum is relatively poor as stated on this Stack Overflow answer:

So if you randomly flip any number bits anywhere in the data part of the packet, the chances are 1 to 65536 that this error is not detected

https://stackoverflow.com/questions/3830206/can-a-tcp-checksum-fail-to-detect-an-error-if-yes-how-is-this-dealt-with

So it's possible the TCP layer isn't picking up the corruption.

Rating

  (5 ratings)

Comments

Unlikely that the corrupt packet makes it to the higher levels

mathguy, January 25, 2024 - 5:00 pm UTC

I may certainly be wrong, but I don't believe the corrupt packet ever leaves the TCP layer. All you are seeing are error messages: the TCP layer catches the checksum mismatch, it reports it to TNS - perhaps after a fixed number of failed attempts to correct it, and TNS reports it back to its caller. I believe the ORA error is simply a wrapper for the TNS error, which in turn is a transparent (the "T" in TNS) pass-through from the TCP layer. Why do you think the database or the application ever sees the corrupt packet?
Chris Saxon
January 26, 2024 - 6:31 pm UTC

It is an ORA error, suggesting it's coming from the app layer rather than the network layer. But as stated this is way outside my knowledge zone.

Patrick Dung, January 26, 2024 - 11:49 am UTC

I had encountered this problem about one years ago

For my case, it is an out dated JDBC library was used (JDK 1.6) to connect a modern Oracle database.

The error reported something related to checksum but the error log did not mention anything about the JDBC client version.
Chris Saxon
January 26, 2024 - 6:31 pm UTC

Thanks for sharing - something for OP to investigate!

Leandro, January 26, 2024 - 2:57 pm UTC 

@mathguy  "Why do you think the database or the application ever sees the corrupt packet?"


Well, this is an ORA error, so it seemed logically to me that it comes from the application. The explanation on Chris' link seems plausible, maybe the TCP stack is letting some corrupt packets go through. But it just weird how often this has been happening, like twice or trhice a week. The guy on stackoverflow metions that "the chances are 1 to 65536 that this error is not detected" and to be honest, this is the very first time see this specific error in 20 years working with Oracle. I don't believe the network in my company is that bad, otherwise we would have similar cases with other system as well.

Well, the matter is now with the Network team. I will wait for their analisys and (try to) update this question with their findings (which may take some weeks, or maybe months).
Chris Saxon
January 26, 2024 - 6:34 pm UTC

My thoughts too, but honestly I don't know.

I've never seen this error before in ~20 years too; to be happening that regularly does suggest a specific cause, particularly if it's started recently.

See the comment above - are all drivers & clients using up-to-date versions?

Not an app error (I don't think).

mathguy, January 27, 2024 - 3:05 am UTC

The database is the one throwing the error (ORA in "ORA-12569"), because that is what you are interacting with. But the TNS layer has its own error, TNS-12569, with the same definition. This can't be a coincidence; and, I believe if you try hard enough you can get the same TNS error about a failed checksum from a utility like TNSPING. And it would indeed show as TNS-12569, nothing about "ORA"; ORA-12569 is simply the Oracle error that says "TNS reported back error 12569", nothing more and nothing less. It is not saying that the database itself received the packet, inspected it and found it to be faulty. That's what I was suggesting; I can be 100% wrong, I am not an expert either; but this makes the most sense to me.

It is also possible that TNS has its own checksum mechanism, different from that of TCP, and a packet that looks good to TCP is caught by TNS, but I strongly doubt that.

In any case, I believe you did the right thing already: you put it in the hands of networking experts.

Problem solved, but not my curiosity.

Leandro, February 27, 2024 - 8:39 pm UTC

Hello again folks.

Just to give you an update on this matter, I have a good news and a bad news.

The good news is that we managed to solved our issue here. After opening a SR, the support instructed us a to set a hidden parameter in the SQLNET.ORA file. Since adding it we no longer have these TNS Packet Checksum Failure anymore; our application no longer behaves erraticaly, so investigations on the network itself will not be performed.

The bad news is that the core of this question will remain open: where were these bad tcp packets actually being caugh? Did they really get through the network layer up to the application (fooling the TCP checksum on the transport layer as supposed by Chris)? Or as @mathguy speculated, were them being reported byt the TCP stack to Transparent Network Substrate and then sent back to the client encapsulated with an Ora error message?

Well, if anyone ever comes across this thread with some knowledge on this situation, fell to share your experiences. Like I said, given our main problem is solved I don't have any more inputs to add.

Thanks for your help and attention, gentlemen.
Connor McDonald
February 28, 2024 - 6:34 am UTC

Thanks for getting back to us
more

Connor and Chris don't just spend all day on AskTOM. You can also catch regular content via Connor's blog and Chris's blog. Or if video is more your thing, check out Connor's latest video and Chris's latest video from their Youtube channels. And of course, keep up to date with AskTOM via the official twitter account.

More to Explore

PL/SQL demos

Check out more PL/SQL tutorials on our LiveSQL tool.

PL/SQL docs

PL/SQL reference manual from the Oracle documentation library