I'm trying to decode a DB2 trace. It's in DRDA format, but I can't assign the DRDA decoder to the tcp port I'm using - DRDA won't appear in the Decode as list of potential protocols. It does show as enabled, however.
I assume there's something obvious I'm missing because I can't be the only one who's run across this.
packet-drda.c - Routines for Distributed Relational Database Architecture packet dissection
It's a heuristic dissector that uses contents of the packet to determine if it is DRDA.
proto_reg_handoff_drda(void)
{
heur_dissector_add("tcp", dissect_drda_heur, "DRDA over TCP", "drda_tcp", proto_drda, HEURISTIC_ENABLE);
<snip>
#define DRDA_MAGIC 0xD0
dissect_drda_heur(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data)
{
conversation_t * conversation;
if (tvb_captured_length(tvb) >= 10)
{
/* The first header is 6 bytes long, so the length in the second header should 6 bytes less */
guint16 cOuterLength, cInnerLength;
cOuterLength = tvb_get_ntohs(tvb, 0);
cInnerLength = tvb_get_ntohs(tvb, 6);
if ((tvb_get_guint8(tvb, 2) == DRDA_MAGIC) && ((cOuterLength - cInnerLength) == 6))
Are the packets being decoded as something else and if so, you could disable that protocol.
There is a sample capture - drda_db2_sample.tgz (libpcap) DRDA trace from DB2 - on the Wireshark wiki.
The packet dissection shows the magic number and the difference in lengths (137-131) is 6.
Thanks Chuck. I did try the sample you referred to and it doesn't work either - both it and my trace stop decoding at TCP - so it doesn't look like it's being interpreted as something different. I tried disabling everything except Ethernet, IP, and TCP and still no joy. Interestingly though, I don't see the Magic number in my TCP payload, which would explain the failure. Except I do see it in the payload of the sample trace, yet have the same issue there.
Asked: 2021-01-06 23:44:11 +0000
Seen: 374 times
Last updated: Jan 07 '21
