Enhancements to the packet-bfd.c dissector

This issue was migrated from bug 1830 in our old bug tracker.

Original bug information:

Reporter: Todd J Martin
Status: VERIFIED FIXED
Product: Wireshark
Component: GTK+ UI
OS: All
Platform: All
Version: Git

Attachments:

bfd-raw-auth-simple.pcap: BFD packets using simple password authentication
bfd-raw-auth-md5.pcap: BFD packets using md5 authentication
bfd-raw-auth-sha1.pcap: BFD packets using SHA1 authentication
packet-bfd.c.diff: Patch with enhancements to BFD dissecting

Todd J Martin said:

Build Information: Version 0.99.7-tjm-trunk-1 (SVN Rev 22683)

Compiled with GTK+ 2.10.14, with GLib 2.12.13, with WinPcap (version unknown), with libz 1.2.3, with libpcre 6.4, with SMI 0.4.5, with ADNS, with Lua 5.1, with GnuTLS 1.6.1, with Gcrypt 1.2.3, with MIT Kerberos, with PortAudio PortAudio V19-devel, with AirPcap.

Running on Windows XP Service Pack 2, build 2600, with WinPcap version 3.1 (packet.dll version 3, 1, 0, 27), based on libpcap version 0.9[.x], without AirPcap.

Built using Microsoft Visual C++ 8.0 build 50727

The attached patch to packet-bfd.c adds the following enhancements to BFD decoding:
- The Authentication Section is now decoded.  All of the authentication methods are supported.  Verification of checksums is not implemented.
- BFD flags are now shown in a tree
- Added support for the M flag
- Added a display filter for the message length
- For the Desired Min TX Interval, Required Min RX Interval, and Required Min Echo RX Interval fields, the time value is now printed in both milliseconds and microseconds.  (Previously, only milliseconds was being shown.)  The PDU represents the time in microseconds, but most implementations deal in milliseconds.
- Added a warning to flag the packet if the Authentication bit is set, but the full Authentication Section is not present.
- Added descriptions for most of the fields
- Fix the name of the protocol.  BFD stands for Bidirectional Forwarding Detection and not Bi-directional Fault Detection.
- Register the protocol on the UDP multihop port (4784).
- Change the filter name for the protocol from bfdcontrol to bfd since all of the other display filters started with bfd.


Attached are some captures which show BFD packets using the simple password, MD5, and SHA1 authentication types.


BFD packets with authentication now decode like this:

BFD Control message
    001. .... = Protocol Version: 1
    ...0 0000 = Diagnostic Code: No Diagnostic (0x00)
    01.. .... = Session State: Down (0x01)
    Message Flags: 0x04 (A)
        0... .. = Poll: Not set
        .0.. .. = Final: Not set
        ..0. .. = Control Plane Independent: Not set
        ...1 .. = Authentication Present: Set
        .... 0. = Demand: Not set
        .... .0 = Multipoint: Not set
    Detect Time Multiplier: 5 (= 5000 ms Detection time)
    Message Length: 48 bytes
    My Discriminator: 0x00000001
    Your Discriminator: 0x00000000
    Desired Min TX Interval: 1000 ms (1000000 us)
    Required Min RX Interval: 1000 ms (1000000 us)
    Required Min Echo Interval:    0 ms (0 us)
    Authentication: Keyed MD5:
        Authentication Type: Keyed MD5 (2)
        Authentication Length: 24 bytes
        Authentication Key ID: 2
        Sequence Number: 0x00000005
        Checksum: 0x01020304050607080910111213141516

added enhancement uigtk versiondev labels

Todd J Martin said:

Created attachment 900 BFD packets using simple password authentication

Todd J Martin said:

Created attachment 901 BFD packets using md5 authentication

Todd J Martin said:

Created attachment 902 BFD packets using SHA1 authentication

Todd J Martin said:

Created attachment 903 Patch with enhancements to BFD dissecting

Stig Bjørlykke said:

I find 4 bytes of data in the end of each frame not dissected by the BFD. Do you know what they are or where they belong?

Todd J Martin said:

(In reply to comment #5)  
> I find 4 bytes of data in the end of each frame not dissected by the BFD.  Do  
> you know what they are or where they belong?  
>  

That is the ethernet FCS.

Guy Harris said:

...and even dissected as such (click on it).

Stig Bjørlykke said:

Uh, blind man walking (again) :)

Did you fuzz-test this captures?

Committed revision 22825.

Todd J Martin said:

(In reply to comment #8)  
> Uh, blind man walking (again)  :)  
>  
> Did you fuzz-test this captures?  
>  
> Committed revision 22825.  
>  

No, I haven't done any fuzz-testing.  I'll get around to it, but time has been short lately.

Todd J Martin said:

(In reply to comment #9)  
> (In reply to comment #8)  
> > Uh, blind man walking (again)  :)  
> >  
> > Did you fuzz-test this captures?  
> >  
> > Committed revision 22825.  
> >  
>  
> No, I haven't done any fuzz-testing.  I'll get around to it, but time has been  
> short lately.  
>  

I just did fuzz testing with the attached captures and saw no problems.

closed