Page MenuHomeFreeBSD

Add header definition for RFC4340, Datagram Congestion Control Protocol

Authored by thj on Aug 7 2019, 11:46 AM.



Split out from

Add header definition for RFC4340, Datagram Congestion Control Protocol

Add a header definition for DCCP as defined in RFC4340. This header definition
is required to perform validation when receiving and forwarding DCCP packets.
We do not currently support DCCP.

Diff Detail

Lint OK
No Unit Test Coverage
Build Status
Buildable 26899
Build 25210: arc lint + arc unit

Event Timeline

rscheff added inline comments.



#else #warning BYTE_ORDER unexpected or not set


This definition doesn't match either the short or long header here...
For the long header, you are missing a uint8_t reserved before the 6-byte sequence, while for the short header, the sequence number would only be 4 byte here...

Its not clear if you want this header structure to be a univeral struct, but even then, mapping to the long header (if the reserved bits get used eventually) seems to be more future-proof.

Maybe point the intent out as a comment?


Reply to both comments about the ENDIAN preprocess.

This is the way that ip.h, ip6.h and tcp.h set up bit fields like this. Should we be different in dccp?


The intention is to have enough header space to hold either a long or short header. I will add a comment to clarify.

Add comment to explain the seq field is sized to hold either the short or the long sequence number

Extend the sequence number field to include a reserved byte in the long header.


shouldn't be the checksum field a uint16_t type, instead of a 2-byte array?


The opposite was a comment before I split out this change from D16851

"Due to alignment, it seems likely that an extra byte will be added before d_cksum. The easiest way to get around this is to turn this into a 2-byte array (e.g. uint8_t d_cksum[2])."

Remove extra white space around union

Fix struct so that will build, last rev I seem to have updated the review from
the wrong tree.

glebius added inline comments.

Any reason not to use C11 anonymous structs and unions? Is it expected the code will be compiled by legacy compilers?

  • Use named union and struct in header definition
This revision is now accepted and ready to land.Oct 6 2019, 6:32 PM

Approved by: bz (co-mentor)

If you move the $FreeBSD$ then this is still good to go I think.


Given this is a head file, the $FreeBSD$ should go at the end of the license comment; like in the template: as __FBSDID() needs the cdefs.h include. etc.