Dissector Bug Protocol DRBD

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

Travis
1 ●2 ●2 ●2

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

add a comment

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

Chuckc
3023 ●6 ●608 ●20

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

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?

edit flag offensive 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

see more comments

Dissector Bug Protocol DRBD

1 Answer

Comments

Your Answer

Question Tools

Stats

Dissector Bug Protocol DRBD edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Dissector Bug Protocol DRBD