Bug #6169
openFrame masking against network frame ordering, not frame numbers
0%
Description
The osmo-e1d code includes functionality to save bandwidth by not transmitting timeslots, which haven't changed since the last frame.
https://gitea.osmocom.org/Manawyrm/osmo-e1d/src/branch/master/src/octoi/e1oip.c#L263
Later in development, the frame_rifo was introduced to combat packet reordering in real-world networks (like DOCSIS).
The code unpacking the timeslots into full E1 frames is currently unpacking against the last frame in the incoming buffer, not the last frame in the RIFO (random in, first out) buffer.
This means that frames will get filled with random data from other frames in the event of a re-ordering.
Unpacking/Unmasking should be done after the RIFO mechanism.
Updated by manawyrm 8 months ago
I have written a preliminary patch, which moves the unmasking logic after the RIFO code:
https://gitea.osmocom.org/Manawyrm/osmo-e1d/commit/63a9f490d75987e396f80aea1b17d5ca560ec230
(currently with broken unit tests and probably unclean?)
In my testing, this seems to behave correctly whenever reordering occurs.
