On Jun 24, 2016, at 1:14 PM, John Thacker <[email protected]> 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. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
