Ask Your Question
0

Oracle DB request connection packets always identified as malformed

asked 2019-04-24 20:09:14 +0000

rm760 gravatar image

Every request connection packet captured on a host connecting to an Oracle database is identified as malformed. Oracle support is stating there is nothing wrong. Is there any better way to identify these packets through wireshark settings? Or are these truly malformed?

edit retag flag offensive close merge delete

Comments

Unfortunately it's likely that we'd need to see the capture to comment further. You can share the capture on a public file sharing service, e.g. Google Drive, DropBox etc, and then post a link to it by amending your question.

grahamb gravatar imagegrahamb ( 2019-04-24 20:24:33 +0000 )edit

Thanks for the reply. Below is a link to one of the pcaps https://drive.google.com/file/d/1eqvD...

rm760 gravatar imagerm760 ( 2019-04-24 20:44:30 +0000 )edit

3 Answers

Sort by ยป oldest newest most voted
0

answered 2019-04-24 21:09:03 +0000

grahamb gravatar image

I can confirm I also see the issue with the latest dev version of Wireshark. I suspect Oracle have "improved" the protocol, and the TNS dissector requires an update.

Please raise a bug report at the Wireshark Bugzilla, attaching your capture. You might want to filter the capture to only hold TNS traffic (tcp.port 1521).

edit flag offensive delete link more

Comments

I have raised the issue with the wire shark Bugzilla group. Thanks

rm760 gravatar imagerm760 ( 2019-04-24 21:27:22 +0000 )edit
grahamb gravatar imagegrahamb ( 2019-04-24 21:32:29 +0000 )edit

This appears to be correct, as per my comments in the bug; it appears that the Connect packet doesn't contain the connect string - it's in a subsequent Data packet - but the Wireshark dissector expects it to be in the Connect packet and reports the packet as malformed.

This is not a regression - Wireshark never handled a split such as that.

Guy Harris gravatar imageGuy Harris ( 2020-01-03 22:22:30 +0000 )edit
0

answered 2020-01-02 23:16:46 +0000

It would be nice to know why you are seeing 'malformed packet' in 3.2

Here is why I went to 2.6 (I know it is approaching EOL)

Using thshark 1.8, all data to/from an Oracle 19c database appeared as 'malformed'. Note: Oracle 19c is really Oracle 12.2 under the covers.

After a little research, it seemed that the problem was that 1.x wireshark did not know about the changes to 12c TNS.

Using 1.8 to examine a connection to an Oracle 11g database, everything was fine.

As I could not locate a suitable binary version for Oracle Linux 7.5, I built Wireshark 2.6 from scratch.

After doing so traffic for a 19c Database appears normally, that is as TNS traffic.

Next I took a look at the tns definitions for wireshark

 [root@ora75 dissectors]# grep -h '#define' /root/build/wireshark-1.12.13/epan/dissectors/packet-tns.?
#define TCP_PORT_TNS            1521
#define PACKET_TNS_H
#define TNS_TYPE_CONNECT 1
#define TNS_TYPE_ACCEPT 2
#define TNS_TYPE_ACK 3
#define TNS_TYPE_REFUSE 4
#define TNS_TYPE_REDIRECT 5
#define TNS_TYPE_DATA 6
#define TNS_TYPE_NULL 7
#define TNS_TYPE_ABORT 9
#define TNS_TYPE_RESEND 11
#define TNS_TYPE_MARKER 12
#define TNS_TYPE_ATTENTION 13
#define TNS_TYPE_CONTROL 14
#define TNS_TYPE_MAX 19



[root@ora75 dissectors]# grep '#define' /root/build/wireshark-2.6.14rc0/epan/dissectors/packet-tns.c
#define TNS_TYPE_CONNECT        1
#define TNS_TYPE_ACCEPT         2
#define TNS_TYPE_ACK            3
#define TNS_TYPE_REFUSE         4
#define TNS_TYPE_REDIRECT       5
#define TNS_TYPE_DATA           6
#define TNS_TYPE_NULL           7
#define TNS_TYPE_ABORT          9
#define TNS_TYPE_RESEND         11
#define TNS_TYPE_MARKER         12
#define TNS_TYPE_ATTENTION      13
#define TNS_TYPE_CONTROL        14
#define TNS_TYPE_MAX            19
#define SQLNET_SET_PROTOCOL     1
#define SQLNET_SET_DATATYPES    2
#define SQLNET_USER_OCI_FUNC    3
#define SQLNET_RETURN_STATUS    4
#define SQLNET_ACCESS_USR_ADDR  5
#define SQLNET_ROW_TRANSF_HDR   6
#define SQLNET_ROW_TRANSF_DATA  7
#define SQLNET_RETURN_OPI_PARAM 8
#define SQLNET_FUNCCOMPLETE     9
#define SQLNET_NERROR_RET_DEF   10
#define SQLNET_IOVEC_4FAST_UPI  11
#define SQLNET_LONG_4FAST_UPI   12
#define SQLNET_INVOKE_USER_CB   13
#define SQLNET_LOB_FILE_DF      14
#define SQLNET_WARNING          15
#define SQLNET_DESCRIBE_INFO    16
#define SQLNET_PIGGYBACK_FUNC   17
#define SQLNET_SIG_4UCS         18
#define SQLNET_FLUSH_BIND_DATA  19
#define SQLNET_SNS              0xdeadbeef
#define SQLNET_XTRN_PROCSERV_R1 32
#define SQLNET_XTRN_PROCSERV_R2 68
#define OPI_VERSION2            1
#define OPI_OSESSKEY            2
#define OPI_OAUTH               3
#define TCP_PORT_TNS            1521 /* Not IANA registered */

So, quite a bit was changed.

It does seem curious that 3.2 is showing 'malformed' packets.

Just now I checked the TNS '#defines' for 3.2; they are identical to 2.6.

A code regression perhaps?

edit flag offensive delete link more

Comments

Unfortunately this "answer" is too big to convert it to a comment so I'll have to leave it as an "answer".

The best way to progress this is via a bugzilla item. I can't see any other open items for Oracle\TNS apart from the one referenced in the other answer.

grahamb gravatar imagegrahamb ( 2020-01-03 08:57:00 +0000 )edit

Given that, in the capture attached to bug 15727, the connect in frame 1809 is reported as malformed by code from the tip of the 2.6.x, 3.0.x, 3.2.x, and master branches, there does not appear to be a regression between 2.6 and 3.0 or between 3.0 and 3.2 - they're all reporting a malformed connect.

Guy Harris gravatar imageGuy Harris ( 2020-01-03 19:33:13 +0000 )edit

Nope, not a regression; Wireshark never handled the case where a Connect packet didn't contain the connect string, a subsequent Data packet did.

Guy Harris gravatar imageGuy Harris ( 2020-01-03 22:23:23 +0000 )edit

Thanks for that clarification.

jkstill gravatar imagejkstill ( 2020-01-03 22:43:49 +0000 )edit
-1

answered 2020-01-02 20:03:11 +0000

I found it necessary to build Wireshark 2.x (2.6.14 at this time) so that the TNS traffic for Oracle 12c+ would be correctly interpreted.

edit flag offensive delete link more

Comments

This must be a different issue, the capture in the question still shows the problem with the latest master (currently 3.3.x).

Note that 2.6.x is nearing the end of it's support cycle (Oct 2020), 3.2.x is the current stable release.

grahamb gravatar imagegrahamb ( 2020-01-02 20:40:29 +0000 )edit

If you have a capture that 2.6.x dissects correctly but 3.0.x or 3.2.x doesn't dissect correctly, that is definitely a different issue, given that, as noted, 2.6.x shows malformed connect packets for the capture that the person who originally asked the question provided.

If you have a capture that 2.6.x dissects correctly but 3.0.x or 3.2.x doesn't dissect correctly, file it as a separate bug, with a capture attached.

Guy Harris gravatar imageGuy Harris ( 2020-01-03 19:38:10 +0000 )edit

That's because the 1.8 release you were using was too old, and you needed a newer release.

The problem here is that no release of Wireshark handles this particular capture.

Guy Harris gravatar imageGuy Harris ( 2020-01-03 22:24:31 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2019-04-24 20:09:14 +0000

Seen: 7,112 times

Last updated: Jan 02 '20