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?
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).
For reference this is bug 15727 - TNS request connect defined as malformed.
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.
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?
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.
Nope, not a regression; Wireshark never handled the case where a Connect packet didn't contain the connect string, a subsequent Data packet did.
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.
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.
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.
Asked: 2019-04-24 20:09:14 +0000
Seen: 6,106 times
Last updated: Jan 02 '20
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
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.
Thanks for the reply. Below is a link to one of the pcaps https://drive.google.com/file/d/1eqvD...