Hi, I encountered malformed packets although the application works ok. This is based on WireShark 1.4.4 and 1.5. The traffic is between my Application Server via F5 to DB (and vice versa). Attached is the dump: 0000 00 1b 21 33 8b 9b 00 01 d7 c1 e5 03 08 00 45 00 ..!3.... ......E. 0010 00 39 a6 6d 40 00 ff 06 8e 82 0a 32 a8 d2 0a 32 [email protected] ...2...2 0020 89 98 f7 b0 fc b2 23 a7 42 35 de 8d 0e d0 50 18 ......#. B5....P. 0030 80 00 df 1b 00 00 05 00 02 30 b9 01 01 00 00 00 ........ .0...... 0040 00 01 01 00 00 00 00 01 14 00 00 00 02 76 73 5f ........ .....vs_ 0050 6f 72 61 63 6c 65 00 00 00 00 00 00 00 oracle.. ..... Does anyone has any ideas on the reason(s)? Thanks! regards, Jackson asked 30 Mar '11, 00:04  Jackson Lim |
One Answer:
Hi Harper, I believe WireShark made a mistake in diagnosing the packet as a DCERPC response. The connection in question is actually an Oracle SQL*NET connection on TCP. There are no DCERPC protocol used as the only DCE found in Oracle, which is used for authentication as part of Oracle Advanced Security, is not enabled at all (i.e. sqlnet.ora does not exist at all). I tried to decipher the packet manually using packet specification found in the RFC document of TCP, which specifies (as formalized in the following RFC-793: http://www.ietf.org/rfc/rfc793.txt) the requirement that the TCP header ends with padding (of variable length of zeroes) to ensure that the data starts at the 32-bit boundary. It did not specify that the data part of the TCP packet must start with any bits. The data byte of the TCP packet starts with byte "05 00" and the second packet (which is not flagged as malformed") starts with "03 81." However it seems that from WireShark's diagnosis, the byte "05 00" from the first packet denotes the start of a DCE/RPC packet of ncacn_ip_tcp type (DCE/RPC that run on top of TCP protocol). In my opinion, the byte "05 00" is actually a normal and valid TCP packet and not a DCE/RPC packet. Can you help to confirm my findings? In addition, how do I reflect this findings to the WireShark Core Development Team so that the next version of WireShark will avoid this incorrect analysis? Thanks for your advice. regards, Jackson answered 01 Apr '11, 03:50 Jackson Lim Hi, It seems that WireShark has wrongly decoded the Oracle packets at Network Layer 4 as DCE-RPC protocol instead of Oracle TNS protocol. By manually setting the decoder to "TNS", there were no packets "deemed to be malformed". Can this behaviour be automatically incorporated into the next version of WireShark? regards, Jackson (03 Apr '11, 23:48) Jackson Lim I don't know if this discussion is monitored by the core developers. I suggest to post this to the wireshark developer list. see http://www.wireshark.org/lists/ (06 Apr '11, 06:43) harper DCE RPC packets ARE "normal and valid TCP packets"; DCE RPC runs on top of TCP as well as UDP and other protocols (such as SMB). DCE RPC protocols (with a few exceptions) do not have particular ports assigned to them; therefore, the only way Wireshark can detect them automatically is to look at part of the payload for transport protocols such as TCP and UDP to see if the packet looks as if it might be a DCE RPC packet. Those "heuristics" do not, and cannot, always get the right answer. (06 Apr '11, 09:21) Guy Harris ♦♦ |
This is decoded as DCERPC response. Does your connection use RPC? If not, you can consider to disable DCERPC for a time, since it's called by heuristic.