Solved

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

Posted on 2004-04-14
7
23,763 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
7 Comments
 
LVL 23

Accepted Solution

by:
seazodiac earned 125 total points
Comment Utility

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 125 total points
Comment Utility

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 125 total points
Comment Utility
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 125 total points
Comment Utility
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
Comment Utility
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

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Join & Write a Comment

Suggested Solutions

Article by: Swadhin
From the Oracle SQL Reference (http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/queries006.htm) we are told that a join is a query that combines rows from two or more tables, views, or materialized views. This article provides a glimps…
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…
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.
Video by: Steve
Using examples as well as descriptions, step through each of the common simple join types, explaining differences in syntax, differences in expected outputs and showing how the queries run along with the actual outputs based upon a simple set of dem…

743 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

Need Help in Real-Time?

Connect with top rated Experts

16 Experts available now in Live!

Get 1:1 Help Now