On Jun 24, 2016, at 1:14 PM, John Thacker <johnthacker@xxxxxxxxx> wrote:
> I am implementing fragment reassembly of PPP Multilink (RFC 1990) and also implementing multiclass extension (RFC 2686). (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12548 https://code.wireshark.org/review/#/c/16044/)
> The protocol is unlike other protocols that do reassembly. Most protocols contain a sequence number that corresponds to the reassembled PDU, plus generally fragment numbers that indicate the position of the fragment within the reassembly and a flag that indicates when there are no more fragments expected. (There are some exceptions without fragment numbers; those have to assume that fragments are received in order and use fragment_add_seq_next().)
>
> PPP Multilink only has a single sequence number, plus flags that indicate whether something is the first or last (or both or neither) fragment of a PDU. There's no indicate of what the fragment number is within the sequence, other than "First" or "not first."
I.e., it's more like TCP, where the sequence number is a sequence number within a "connection".
I seem to remember that there are some other protocols that work that way. There should probably be an additional set of reassembly APIs to handle that case.
> A more thorough rewrite of how reassembly works could introduce new API calls that are designed to work for sequence numbers as implemented here, "front end" sequence numbers that increment with each fragment instead of end result PDU sequence numbers.
Exactly.
