The TNS Protocol

http://flylib.com/books/en/2.680.1.18/1/

 

 

When developing raw tools to troubleshoot problems in Oracle, it is necessary to understand the TNS protocol. This section details information about the TNS protocol. The Oracle JDBC client (classes12.zip ) is a useful resource when seeking to understand the TNS protocol.

 

The TNS Header

Every TNS packet has an eight-byte header. The first two bytes (WORD) of the header are used for the packet length - inclusive of the header size. The size, like all values, is big-endian. The next WORD is for the packet checksum if checksumming is done - by default it is not, and the value for this WORD is 0x0000. The next byte is used to indicate the packet type - for example, the most common are as follows:

 

Connect packet      Type 1

Accept packet       Type 2



Ack packet             Type 3

Refuse packet       Type 4

Redirect packet       Type 5

Data packet       Type 6

NULL packet            Type 7

Abort packet      Type 9

Resend packet      Type 11

Marker packet      Type 12

Attention packet      Type 13

Control packet      Type 14

When connecting to Oracle, at the TNS level the client sends the server a Connect packet (type 1) specifying the service name they wish to access. Provided the Listener knows of such a service, one of two things can happen: The Listener could send an Accept packet (type 2) or it could redirect the client to another port with a Redirect packet (type 5). If the former option occurs, then the client attempts to authenticate. This is covered in detail in Chapter 4, "Attacking the Authentication Process." If the latter occurs, then the client sends a Connect packet to the port to which they've been redirected and requests access to the service. If all goes well, the server issues an Accept packet and authentication takes place. All authentication packets are Data packets with a type of 6.

Going back, if the Listener does not know of the service to which the client is requesting access, then it issues a Refuse packet - type 4. Once authenticated, queries and results packets are Data packets. Every so often you'll see a packet of type 12 (0x0C) - this is a Marker packet, which is used for interrupting. For example, if the server wishes the client to stop sending data, then it will send the client a Marker packet.

Continuing with the details of the TNS header, the next byte is the header flags. Generally the flags are unused, but the 10g client may set the value to 0x04.

The final two bytes form a WORD for the header checksum - not used by default and set to 0x0000:

 

WORD            00 00            Packet Size

WORD            00 00            Packet Checksum

BYTE            00               Packet Type

BYTE            00               Flags

WORD            00 00            Header Checksum

Before delving further into the packet, it would be useful to take a look at Refuse packets - type 4. Refuse packets indicate an error of some kind - for example, a logon denied error with an "invalid username/password" - ORA-01017. With these errors, the 54th byte indicates the problem. A 3 is an invalid password; a 2 indicates no such user. Clearly, you can derive potentially useful information even from Refuse packets.

 

Inside the Packet

Most packets you'll see on the wire are Data packets (type 6). With Data packets, the WORD after the TNS header is for the Data Flags. If the packet is a disconnect packet, then this WORD is set to 0x0040 - otherwise, it is generally 0x0000.

Note

There is a bug in all versions of Oracle when a server processes a Data packet (type 6) that has the second bit of the Data Flags set but the first (least significant) bit unset (e.g., numbers 2, 6, 10, 14, and so on). When the server receives such a packet it winds up in an endless loop, hogging all available CPU processing time. Obviously, this negatively impacts server performance.

The next byte after the Data Flags (byte 11) determines what's in the Data packet:

• 0x01 indicates protocol negotiation. Here, the client sends to the server acceptable protocol versions - these are 6, 5, 4, 3, 2, 1, and 0. The server will reply with a common version - for example, 6 or 5 - but it will also send over information such as the character set it uses, how many characters are in the set, a version string, and server flags.

• 0x02 indicates an exchange of data type representations.

• 0x03 indicates a Two-Task Interface (TTI) function call. The following table lists some of the functions:

   

        0x02      Open
  
        0x03      Query
  
        0x04      Execute
  
        0x05      Fetch
  
        0x08      Close
  
        0x09      Disconnect/logoff
  
        0x0C      AutoCommit ON
  
        0x0D      AutoCommit OFF
  
        0x0E      Commit
  
        0x0F      Rollback
  
        0x14      Cancel
  
        0x2B      Describe
  
        0x30      Startup
  
        0x31      Shutdown
  
  0x3B      Version
  
  0x43      K2 Transactions
  
  0x47      Query
  
  
  
  0x4A      OSQL7
  
  0x5C      OKOD
  
  0x5E      Query
  
  0x60      LOB Operations
  
  0x62      ODNY
  
  0x67      Transaction - end
  
  0x68      Transaction - begin
  
  0x69      OCCA
  
  0x6D      Startup
  
  0x51      Logon (present password)
  
  0x52      Logon (present username)
  
  0x73      Logon (present password - send AUTH_PASSWORD)
  
  0x76      Logon (present username - request AUTH_SESSKEY)
  
  0x77       Describe
  
  0x7F      OOTCM
  
  0x8B      OKPFC
  
  

Some of these may be called prior to authentication - for example, the Version (0x3B) TTI function:

• 0x08 indicates "OK" - sent from the server in response to a client.

• 0x11 indicates extended TTI functions. These were introduced in later versions of Oracle, so for backward compatibility do not use 0x03.

• Here are some function codes:

   

  0x6b      Switch or Detach session
  
  0x78      Close
  
  0x87      OSCID
  
  0x9A      OKEYVAL
  
  

• 0x20 is used when calling external procedures and with service registrations.

• 0x44 is also used when calling external procedures and with service registrations.

The best way to get a handle on the TNS protocol, other than examining the Oracle JDBC client (classes12.zip ), is to grab some packets off the wire with a network sniffer and see what's going on.

Throughout the remainder of this book you'll see a number of packet dumps; refer back to this chapter when examining the contents.