Attempt to flatten the `BgpLayer` inheritance chain.

Overview

This PR is a draft attempt to flatten the inheritance chain of BgpLayer and separate the protocol layer parsing logic from the message payload parsing logic.

In the current implementation each BGP message has a dedicated derived BGP layer class. This introduces limitations where the message payload cannot be switched to a different type without destroying the layer object and creating a new one, requiring the layer to be extracted from the stack and then readded to it.

This PR aims to simplify the following operations by providing the following objects:

• "MessageView" proxies - thin wrappers over a BgpLayer that parse the payload as a specific message. They exist in two flavors "View" and "ConstView" with the former allowing in-place data modifications and the latter being read-only.
• "Message" objects - lightweight struct objects that can be passed to the BgpLayer's constructor or a dedicated method to completely replace the underlying message with a message of a different type. Similar to the ArpLayer's helper structs.

The "View" object

The view object is a thin wrapper over a BgpLayer that holds a reference to the layer it has been created from. It provides accessors and mutators for reading and writing message specific data directly to the underlying buffer. Each view is intended to be passed by value and should be no larger than a pointer (the reference to the BgpLayer), if possible.

Each view should maintain message integrity. During construction the View should validate a minimally viable message of the type can be parsed from the buffer. Full validation can be deferred until use of accessors and/or mutators of the view object.

BGP Layer Enhancements

Improved support of full length update message path attributes.

The previous version supported path attributes with data up to 32 bytes. The new PathAttribute class supports the full spectrum of variable data lengths a path attribute block can contain specified by RFC 4271 Section 4.3. The attribute can support a data buffer of:

• standard length attribute - up to 255 bytes
• extended length attribute - unlimited, restricted by total message length of 4096 bytes.

Other enhancements

Addition of utility functions for enum class flags.

This PR adds the header EnumFlagUtils.h to the Common++ package. The header provides operators for bitwise operators and helper functions of enum class objects when they satisfy the trait EnableBitMaskOperators.

In addition the header defines the following macros:

• PCPP_DECLARE_ENUM_FLAG - to enable the operators to be used for a class.
• PCPP_USING_ENUM_FLAG_OPERATORS - to declare aliases to all templated operators in the scope this macro is used to satisfy ADL.

May 18 '25 09:05 Dimi1010

Codecov Report

Attention: Patch coverage is 0% with 682 lines in your changes missing coverage. Please review.

Project coverage is 81.89%. Comparing base (59d0b64) to head (7be7843). Report is 36 commits behind head on dev.

@@            Coverage Diff             @@
##              dev    #1820      +/-   ##
==========================================
- Coverage   84.10%   81.89%   -2.21%     
==========================================
  Files         272      285      +13     
  Lines       47578    49691    +2113     
  Branches    10344    10548     +204     
==========================================
+ Hits        40015    40695     +680     
- Misses       6518     8209    +1691     
+ Partials     1045      787     -258     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

May 18 '25 12:05 codecov[bot]

@seladb @tigercosmos @clementperon @egecetin Can I get some first impressions on the idea of this draft?

May 19 '25 05:05 Dimi1010

@Dimi1010 is it worth it to rewrite BgpLayer? 🤔

May 21 '25 05:05 seladb

@Dimi1010 is it worth it to rewrite BgpLayer? 🤔

Dunno yet. I have been mostly using it as a test bed for expanding the idea I had in the #1813 about ways it can allow direct read/write of fields of different payloads without having to decode and copy the entire buffer out.

May 21 '25 05:05 Dimi1010

@Dimi1010 Is it possible to split this PR? It seems the PR is too large to review.

May 22 '25 13:05 tigercosmos

@Dimi1010 Is it possible to split this PR? It seems the PR is too large to review.

Possibly, but this is still a WIP.

May 22 '25 13:05 Dimi1010

Might work on this later. Closing this for now so it doesn't clutter.

Jul 11 '25 09:07 Dimi1010