Ask Your Question

Dissector Bug Protocol DRBD

asked 2020-02-19 16:50:40 +0000

Travis gravatar image

I had recently made some changes to my network to try to provide residents with a more private network experience. When I ran scan to see if traffic was coming through the router onto our network I picked up at least one device so far that is from a different subnet and displayed the error you can see below. If any one could advise me on how to correct the issue or if this is possibly a result of malware or security concerns it would be greatly appreciated.

Thank you.

[Dissector bug, protocol DRBD: C:\buildbot\builders\wireshark-3.2-64\windows-2019-x64\build\epan\dissectors\packet-tcp.c:3750: failed assertion "proto_desegment && pinfo->can_desegment"]

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2020-02-19 16:55:24 +0000

Chuckc gravatar image

updated 2020-02-19 16:57:10 +0000

Dissector added here:
You might add a note to it or open a new bug:

It's possible it is some other protocol that has been mis-identified.
Can you share a small capture of the packets flagged as DRBD?

edit flag offensive delete link more


The correct place to report bugs is the Wireshark Bugzilla.

grahamb gravatar imagegrahamb ( 2020-02-19 17:01:49 +0000 )edit

Here is the complete packet information excluding IP's and MAC's:

Frame 1: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface \Device\NPF_{6D366D67-73CF-40B0-B926-3C21A41AC815}, id 0
    Interface id: 0 (\Device\NPF_{6D366D67-73CF-40B0-B926-3C21A41AC815})
        Interface name: \Device\NPF_{6D366D67-73CF-40B0-B926-3C21A41AC815}
        Interface description: Wi-Fi
    Encapsulation type: Ethernet (1)
    Arrival Time: Feb 18, 2020 20:46:29.569851000 Central Standard Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1582080389.569851000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 1514 bytes (12112 bits)
    Capture Length: 1514 bytes (12112 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:tcp:drbd]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
Ethernet II, Src: *** , Dst: ***
    Destination: ***
        Address: ***
        .... ..0. .... .... .... .... = LG bit ...
Travis gravatar imageTravis ( 2020-02-19 17:06:31 +0000 )edit

Again, please file a bug, and attach a capture file (raw pcap/pcapng capture file, not a text version of what's dissected - a raw capture allows us to try it with the current code to try to figure out the bug, and to try it with changed code to see if it fixes the problem), rather than continuing to post stuff in the question. That lets us keep track of bugs and fixes.

Guy Harris gravatar imageGuy Harris ( 2020-02-19 17:47:24 +0000 )edit

Sorry I misunderstood. Thank you.

I just was about to submit the capture to Bugzilla but now when I opened it I didn't see that same error. It seems to have gone away. I must have had a setting wrong. I'm pretty new to wireshark and analyzing network traffic. Thank you for all your help.

Travis gravatar imageTravis ( 2020-02-19 19:18:46 +0000 )edit

I'm running wireshark 3.2.3 on fedora (slightly out of date fedora 30). I definitely still see this. And there's no way I can find to disable protocol DRDB. Even if there were, i doubt it would disable its logic in epan/dissectors/packet-tcp.c, which is presumably making the decision about whether or not the packet actually is DRDB. I will open bug if I find this is still true on my fedora 34 system

ilium gravatar imageilium ( 2021-03-17 13:49:54 +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: 2020-02-19 16:50:40 +0000

Seen: 2,951 times

Last updated: Feb 19 '20