Solved

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

Posted on 2004-04-14
7
24,698 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
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 125 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 125 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 125 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

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.

Question has a verified solution.

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

Suggested Solutions

Title # Comments Views Activity
Action link in Union Reports Not Working in OBIEE 11g 1 85
Schema creation in Oracle12c 6 46
Oracle and DateTime math 6 37
exp/imp 25 73
Why doesn't the Oracle optimizer use my index? Querying too much data Most Oracle developers know that an index is useful when you can use it to restrict your result set to a small number of the total rows in a table. So, the obvious side…
Introduction A previously published article on Experts Exchange ("Joins in Oracle", http://www.experts-exchange.com/Database/Oracle/A_8249-Joins-in-Oracle.html) makes a statement about "Oracle proprietary" joins and mixes the join syntax with gen…
This video explains at a high level with the mandatory Oracle Memory processes are as well as touching on some of the more common optional ones.
Via a live example, show how to restore a database from backup after a simulated disk failure using RMAN.

776 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