Fixup for previous patch, which forgot to update the pui using the new
variable, as done already in the same patch for M_NEXT_EXIST.
Change-Id: I92a04c708bcc6c15348324321e8890361bbc5c31
Fixes: 72cdb30ee2b1c0d71ff6d9583d51f46b2e5fdcea
If we decode Exist bit as "1" but we are at the end of the message, and
all the Next items we'd read are expected to be possibly NULL, then swap
the Exist bit in the decoded structure as "0" in order to tell the
decoder user that the related information structure is actually unset,
as if "0" was received.
Related: SYS#5552
Related: OS#4955
Related: OS#5020
Change-Id: I38602e4b680ed87297c7e440691a494c07cad446
All additional release fields are considered optional, and the
CSN_DESCR for Content_t already marks almost all as such, except
DownlinkDualCarrierCapability_r7.
It has been found that some MS transmits a MS RA Capability with a Length=61 bits
where the last bit in the buffer is setting the Exist bit for
DownlinkDualCarrierCapability_r7 as 1. Hence, the CSN1 decoder failed to
decode the whole message because it expected to keep reading there
despite there's no more bytes to read.
While this is could actually be considered an MS bug, let's relax our
expectancies and simply consider the case { 1 <end> } as it was { 0 },
and mark skip decoding DownlinkDualCarrierCapability_r7. That waht
wireshark (packet-gsm_a_gsm.c) or pycrate do for instance.
This patch itself doesn't fix the problem where actually the Exist bit
is stored as 1 in the output decoded structure, but simply allows keep
ongoing with decoding until the end. This issue will be fixed in a
follow-up patch.
Related: SYS#5552
Related: OS#4955
Related: OS#5020
Change-Id: I9a2541bd3544802a646890f32725201836abb0da
The CSN1 encoder/decoder code is already lengthy and complex enough,
there's no need to keep it in the same file, specially because when
debugging, only is interested in one of the 2 functions, and they both
look really similar (long spaghetti switches).
Change-Id: I7d1b1f7e6d7f89b052b3fd73a960419bb2673020
Pau Espin