Dissector Bug Protocol DRBD

retag add tags

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"]

Travis

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

edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

Dissector added here: https://bugs.wireshark.org/bugzilla/s...
You might add a note to it or open a new bug: https://bugs.wireshark.org/bugzilla/

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?

Chuckc

answered 2020-02-19 16:55:24 +0000, updated 2020-02-19 16:57:10 +0000

edit flag offensive 0 remove flag delete link

Comments

The correct place to report bugs is the Wireshark Bugzilla.

grahamb (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 ...

(more)

Travis (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 (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 (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 (2021-03-17 13:49:54 +0000) edit

add a comment see more comments

Dissector Bug Protocol DRBD

Comments

1 Answer

Comments

Your Answer

Dissector Bug Protocol DRBD edit

Comments

1 Answer

Comments

Your Answer

Dissector Bug Protocol DRBD