Bug #4955
CSN1 Error observed: NEED_MORE BITS TO UNPACK (-5) at DL_DualCarrierForDTM
0%
Description
Repeats 4 times. Also no newline at the end of this log line:
DCSN1 <0000> ../../git/src/csn1.c:1468 csnStreamDecoder: error NEED_MORE BITS TO UNPACK (-5) at DL_DualCarrierForDTM (idx 71)DCSN1 <0000> ../../git/src/csn1.c:1468 csnStreamDecoder: error NEED_MORE BITS TO UNPACK (-5) at DL_DualCarrierForDTM (idx 71)DCSN1 <0000> ../../git/src/csn1.c:1468 csnStreamDecoder: error NEED_MORE BITS TO UNPACK (-5) at DL_DualCarrierForDTM (idx 71)DCSN1 <0000> ../../git/src/csn1.c:1468 csnStreamDecoder: error NEED_MORE BITS TO UNPACK (-5) at DL_DualCarrierForDTM (idx 71)
Assigning to myself at least until I add a pcap.
Related issues
Associated revisions
csn1: Avoid failing if optional DownlinkDualCarrierCapability_r7 is missing
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
csn1: Avoid storing existence bit as true if content was actually NULL
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
csn1: Add unit test showing RadioAccess Capability decoding failure
This RA Cap creaes a decoding error on our CSN1 decoder, but seems to be
handled properly by wireshark's own decoder as well as pycrate.
The ending bit of last byte in "MS RA capability 1" has a "1" which
according to spec should flag the existance of
DownlinkDualCarrierCapability_r7, but nothing else comes after it. This
matches the expectancies as per Length field of the first RA Cap.
Related: SYS#5552
Related: OS#4955
Related: OS#5020
Change-Id: I51235e8575f4b992b44078713ec67bbccfd13293
csn1: Avoid failing if optional DownlinkDualCarrierCapability_r7 is missing
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
csn1: Avoid storing existence bit as true if content was actually NULL
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
History
#1 Updated by keith 9 months ago
Another CSN Error observed. Need to try to grab a pcap of this one too.
DCSN1 <0000> ../../git/src/csn1.c:252 csnStreamDecoder: error NEED_MORE BITS TO UNPACK (-5) at p32QAM_HSR_CV_BEP (idx 182) DRLCMACUL <0005> ../../git/src/pdch.cpp:712 Dropping Uplink Control Block with invalid content, decode failed: -5)
#3 Updated by keith 9 months ago
- File QPSK_MEAN_BEP.pcap QPSK_MEAN_BEP.pcap added
#4 Updated by keith 9 months ago
- File p32QAM_HSR_CV_BEP.pcap p32QAM_HSR_CV_BEP.pcap added
#6 Updated by fixeria 9 months ago
- Status changed from New to In Progress
- Assignee changed from keith to fixeria
It looks pretty much like a mistake in TS 44.060:
- Wireshark fails to decode the packet,
- Pycrate also fails to decode the packet,
- http://lte-3gpp.info/decode_ts44060.php decodes it successfully.
The payload is: '4017e5b2cd5a2eca68655e44aec84880139300412b2b2b'O.
#7 Updated by keith 9 months ago
Another Payload observed is
x2f x83 x61 xfa x14 x14 x26 x86 x56 x4b x2c xcc x00 x40 x01 x70 x0b x2b x2b x2b x2b x2b(formatted for pasting into http://lte-3gpp.info/decode_ts44060.php)
This is the case of the DL_DualCarrierForDTM Error, is observed regularly and is an MS RAC IE.
While the other errors are always followed in the log with "Dropping Uplink Control Block with invalid content...", this one is not. Wireshark decodes the payload correctly. An example payload can be found in the pcap, towards the end.
#8 Updated by fixeria 9 months ago
- Status changed from In Progress to Feedback
- Assignee changed from fixeria to keith
Here is my attempt to fix 'QPSK_MEAN_BEP' related decoding errors: https://gerrit.osmocom.org/c/osmo-pcu/+/22524.
Unfortunately, I don't have time to work on this anymore :/
Best regards,
Vadim.
#11 Updated by pespin 6 days ago
Similar issues should be fixed by these commits:
https://gerrit.osmocom.org/c/osmo-pcu/+/25716 csn1: Add unit test showing RadioAccess Capability decoding failure
https://gerrit.osmocom.org/c/osmo-pcu/+/25830 csn1: Avoid failing if optional DownlinkDualCarrierCapability_r7 is missing
https://gerrit.osmocom.org/c/osmo-pcu/+/25831 csn1: Avoid storing existance bit as true if content was actually NULL
Please keith , if after merging it you still see problems, report a pcap file containing the relevant packets. We'll then probably need to change the CSN1 description for a few more fields in RAcap as we see we need it.
csn1: Add unit test showing RadioAccess Capability decoding failure
This RA Cap creaes a decoding error on our CSN1 decoder, but seems to be
handled properly by wireshark's own decoder as well as pycrate.
The ending bit of last byte in "MS RA capability 1" has a "1" which
according to spec should flag the existance of
DownlinkDualCarrierCapability_r7, but nothing else comes after it. This
matches the expectancies as per Length field of the first RA Cap.
Related: SYS#5552
Related: OS#4955
Related: OS#5020
Change-Id: I51235e8575f4b992b44078713ec67bbccfd13293