Ask Your Question

unable to assign DRDA decoder to tcp.port

asked 2021-01-06 23:44:11 +0000

EMF gravatar image

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.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2021-01-07 00:27:38 +0000

Chuckc gravatar image

updated 2021-01-07 00:29:09 +0000

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.

    heur_dissector_add("tcp", dissect_drda_heur, "DRDA over TCP", "drda_tcp", proto_drda, HEURISTIC_ENABLE);


#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.

image description

edit flag offensive delete link more


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.

EMF gravatar imageEMF ( 2021-01-07 00:51:47 +0000 )edit

Did you have DRDA and drda_tcp protocols enabled when looking at the sample capture?
What version of Wireshark are you working with?

Chuckc gravatar imageChuckc ( 2021-01-07 02:49:14 +0000 )edit

I have tried 1.4.1, 2,2 and the latest version of Wireshark. Did confirm that DRDA and -tcp were enabled at capture-time.time.

EMF gravatar imageEMF ( 2021-01-07 21:21:14 +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


Asked: 2021-01-06 23:44:11 +0000

Seen: 330 times

Last updated: Jan 07 '21