Ask Your Question

Why is Mikrotik router using DRDA protocol?

asked 2024-01-16 15:46:26 +0000

span gravatar image

updated 2024-01-17 08:30:34 +0000

Hello, I am seeing a lot of traffic on protocol DRDA between my router ( and laptop (

Any idea what this is? I have searched and cannot find much, all I found is linked at the bottom

I am using a Mikrotik hEX RB750Gr3 running router OS version 6.49.10 (stable)

The other day I also noticed TDS / TDS5 packets going between the router and laptop (but very few, like 1 or 2 at a time very infrequently)

Link1: Here you'll see the Info column usually has info, all of mine are Unknown

Link2: Here again something other than Unknown in the info column.

See screenshot here:

UPDATE: Thanks to Chuckc for the helpful posts, I disabled DRDA in the list of enabled protocols and now Wireshark decodes the packets as TCP so it looks like it was a case of it incorrectly seeing this packets as DRDA

edit retag flag offensive close merge delete


Wireshark is a packet analyser. It can attempt to tell you what is in the packets but not why they are sent.

grahamb gravatar imagegrahamb ( 2024-01-16 15:53:06 +0000 )edit

Please update question with output of wireshark -v or Help -> About Wireshark:Wireshark.

Chuckc gravatar imageChuckc ( 2024-01-16 17:34:54 +0000 )edit

The Wireshark Wiki Sample Captures has a DRDA capture:

drda_db2_sample.tgz (libpcap) DRDA trace from DB2.

Chuckc gravatar imageChuckc ( 2024-01-16 21:25:59 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2024-01-16 17:28:47 +0000

Chuckc gravatar image

It's most likely not DRDA which is a heuristic decoder.


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

It's tough to confirm without a capture file. You can work through the code to see why your packets are a match.

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))
            /* Register this dissector for this conversation */
            conversation = find_or_create_conversation(pinfo);
            conversation_set_dissector(conversation, drda_tcp_handle);

            /* Dissect the packet */
            dissect_drda_tcp(tvb, pinfo, tree, data);
            return TRUE;
    return FALSE;

Disable DRDA (Analyze -> Enabled Protocols...) to see which dissector grabs it next.

edit flag offensive delete link more


Also, the Magic: value displayed in the screen shot is invalid for DRDA.
Was updated in Cleanup DRDA dissector.

Chuckc gravatar imageChuckc ( 2024-01-16 17:37:02 +0000 )edit

Thanks for the feedback, when I disable DRDA in the list of enabled protocols then most of the packets go to TCP so it seems it was maybe just incorrectly trying to decode them as DRDA

span gravatar imagespan ( 2024-01-16 20:19:11 +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: 2024-01-16 15:46:26 +0000

Seen: 149 times

Last updated: Jan 17