Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win

x
?
Solved

oracle connection problem ORA-12569: TNS:packet checksum failure

Posted on 2004-04-14
7
Medium Priority
?
27,648 Views
Last Modified: 2011-08-18
We have someone outside our network trying to make a connection to our oracle database
He gets the "ORA-12569: TNS:packet checksum failure" error message.
Any idea what could be causing this error?

A google search gave me this result...
"ORA-12569: TNS:packet checksum failure
Cause: The data received is not the same as the data sent.
Action: Attempt the transaction again. If the error is persistent, turn on tracing and reexecute the operation"
I don't understand what they want me to do here...

Also, could this have anything to do with our firewall...I opened up the firewall to the ip addresses of the person making the connection and he is able to ping the server, but when he tries to make the oracle connection, he gets that error message. Any help would be greatly appreciated. Thanks!
0
Comment
Question by:meiyaps
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
7 Comments
 
LVL 23

Accepted Solution

by:
seazodiac earned 500 total points
ID: 10825016

This is from oracle metalink , you will have to contact your SYS ADMIN to fix tcp/ip packet size




The information in this article applies to:
Oracle Net Services - Version: 8.1.7.4 to 10.1.0.0
This problem can occur on any platform.

Errors
CHECKSUM
FAILURE
ORA-12569 TNS:packet checksum failure
PACKET
TNS

Symptoms
Getting following error while trying to connect through client:

SQL> system/manager@test
ERROR:
ORA-12569: TNS:packet checksum failure

- DISABLE_OOB=ON has already set into sqlnet.ora file.
- Tnsping works fine.
Cause
+ There is a mismatch in the header of the tcp packet between the client and the server.

+ Header leaving the server and by the time the client gets the packet on the other end the header has changed.
Fix
- Enable level 16 sqlnet tracing for client and server.

For the sqlnet.ora on the client.
---------------------------------

TRACE_LEVEL_CLIENT = 16
TRACE_DIRECTORY_CLIENT =
TRACE_FILE_CLIENT = client
TRACE_UNIQUE_CLIENT = ON
TRACE_TIMESTAMP_CLIENT=ON


For the sqlnet.ora on the server
---------------------------------

TRACE_LEVEL_SERVER = 16
TRACE_DIRECTORY_SERVER =
TRACE_FILE_SERVER = server
TRACE_UNIQUE_SERVER = ON
TRACE_TIMESTAMP_SERVER=ON

- Server Side trace showing packet sent from the server to the client. The first line is the

header 00 20 00 00 02 00 00 00

nspsend: 00 20 00 00 02 00 00 00 |. ......|
nspsend: 01 36 00 00 08 00 7F FF |.6......|

Client side files shows the packet header received

nsprecv: packet hdr
nsprecv: 00 20 00 16 00 F8 00 00 |. ......| ----> This has changed from the first line of the server header.
nsprecv: error exit
nserror: entry
nserror: nsres: id=0, op=68, ns=12569, ns2=0; nt[0]=0, nt[1]=0, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0
[19-NOV-2003 01:31:47] nscon: error exit

- Contact network administrators and fix the underlying tcp/ip packets problem.
0
 
LVL 12

Assisted Solution

by:geotiger
geotiger earned 500 total points
ID: 10825986

I think it is due to the setup in your firewall. You may not need to open the firewall specific to the ip address but you do need to open the ports specific to listener in the SQL*Net.

GT
0
 
LVL 8

Assisted Solution

by:baonguyen1
baonguyen1 earned 500 total points
ID: 10826061
We have two dbs connect via a firewall. What we opened the 1521 port and also allow the two IPs "talk" to each other. It works fine. Hope this works for you
0
 
LVL 5

Assisted Solution

by:fmonroy
fmonroy earned 500 total points
ID: 10830373
Try this from oracle support

Problem Description:
====================
When trying to connect with SQL*Net v2 (TCP/IP protocol adapter), you get:
ORA-12592: TNS:Bad packet
ORA-12569: TNS:Packet checksum error

Solution Description:
====================
This reflects a situation wherein you are referencing port 1525 in the
tnsnames.ora.
Port 1525 is the port number usually used for SQL*Net V1 connections. With
SQL*Net V2, port 1521 is suggested. Any port number can be used as long as
it is not being used by another application. If port 1525 is already being
used by SQL*Net V1 on the server, then trying to use port 1525 with the V2
protocol adapter on the client will result in ORA-12592 and ORA-12569.
0
 

Author Comment

by:meiyaps
ID: 10833389
Thanks everyone,
I'll see if any of these works for me and get back to you
Thanks again for your help
0

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article started out as an Experts-Exchange question, which then grew into a quick tip to go along with an IOUG presentation for the Collaborate confernce and then later grew again into a full blown article with expanded functionality and legacy…
Note: this article covers simple compression. Oracle introduced in version 11g release 2 a new feature called Advanced Compression which is not covered here. General principle of Oracle compression Oracle compression is a way of reducing the d…
This video shows how to set up a shell script to accept a positional parameter when called, pass that to a SQL script, accept the output from the statement back and then manipulate it in the Shell.
This video shows how to copy an entire tablespace from one database to another database using Transportable Tablespace functionality.

604 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question