Closed bedrankara closed 1 year ago
@bedrankara : Can you please provide what exactly is the issue? If I understand correctly - it's the display format of the bitvec
that is the issue? Or somewhere decoding is broken?
I was wondering whether there was some issues in the decoding because the display format was showing me the element as the bitvec
. However, if that is just the way it is displayed, then that was a misunderstanding from my side.
Actually it's unlikely that an issue with decoding will not result in a CodecError
during decode
. So per se that's not the problem, I believe. However, as you have pointed out, the displayed information is not very useful if it doesn't actually show the bitvec
. I quickly checked, the individual bits in the bitvec
are shown. For example here's an output from the NGAP decode in one of the test cases.
ng_enb_id: MacroNgENB_ID(
NgENB_ID_macroNgENB_ID(
BitVec<u8, bitvec::order::Msb0> {
addr: 0x0000564378a3fe40,
head: 000,
bits: 20,
capacity: 64,
} [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
],
),
),
So this is at-least giving useful information. I was also thinking if this could be simplified to simply display a bitstring like 000..1..0b
. But right now I guess it's okay. Makes sense?
Yes makes sense, thanks for the quick response!
Hi, first of all thank you for providing this helpful tool.
I currently encounter an issue when looking at the decoded output of elements in S1AP (F1AP, NGAP) that are based on the BIT STRING type.
Here an example snippet of a decoded S1AP PDU:
Here is the Hex string of the S1AP message that I try to decode:
00090080c50000060000000200070008000200970042000a1805c81a406002cd29c0001800770000340072450009270f80ac100a650000000763277efa7b4f0207420149062000f1100001003d5201c101090908696e7465726e65740501ac11f1ff5e04fefe9b6927208080211003010010810608080808830608080404000d04080808080010020578500bf600f1100001011a984cf8172164020000006b000518000c0000004900200409ae936c4af5643f94a220c336c6354eb82331071245bb367a3b8fcca4c596